Log4j for FTC, More JNDI, Cache Poisoning, Improving Default Configs, ThinkstScapes – ASW #179

Even though we're starting off the year with more log4j, there's far more to appsec than fixing this specific CVE. (Well, group of CVEs by now. But several of them have very limited attack scenarios.) This article is a reflection of modern appsec and a maturing of the industry that the "we take security seriously" platitudes need to have some demonstrable actions behind them. In this specific case, the FTC is concerned about remediating log4j since it's so pervasive and potentially impactful. But setting aside the specific vuln, the true measure of taking security seriously is in the processes and tools related to app inventory, SCA, and speed of remediation. In other words, building up an effective DevOps program that takes security patches in stride and avoids always chasing the latest patching emergency. After all, chasing bugs isn't a strategy and no one has been trying to sell the benefits of a BugOps approach to application development. Read the FTC announcement at https://www.ftc.gov/news-events/blogs/techftc/2022/01/ftc-warns-companies-remediate-log4j-security-vulnerability

Log4j received lots of additional scrutiny from security researchers after the initial disclosure of CVE-2021-44228, which led to a handful of additional weaknesses being found within the codebase. It's an example where researchers either get excited about a new attack surface (thing of the Exchange vulns littered throughout 2021) or an attack surface new to them (after all, popularizing the RCE possibilities of JNDI reach back to at least BlackHat 2016). Here's similar research that identified potential RCEs in the H2 database. As the writeup notes, "several code paths in the H2 database framework pass unfiltered attacker-controlled URLs..., which allows for remote codebase loading..." It's a good time to step back and re-evaluate architectures that rely on instantiating arbitrary remote objects, not to mention architectures that fail to authenticate and authorize the peer from which they're retrieving such objects.

I've often found cache poisoning attacks unexciting -- they often seem to rely on less likely "what if" scenarios or have impacts that are temporary annoyances more so than compromising confidentiality or integrity of a system. But confidentiality in the CIA triad is something we talked a lot about last year and bugs are bugs, meaning if it's a bug worth fixing then that's an improvement to the quality and security of the app. Another angle that's interesting in this topic is how it highlights the challenge of normalizing data such as URLs and Headers, and how the variance in normalization leads to security issues. In fact, this is partially how HTTP Smuggling found new life in HTTP/2 services -- many services would accept HTTP/2 only to fall back to HTTP/1 when communicating with their backend services. So, this is a good lesson in paying attention to details and having a uniform approach to normalizing data. Plus, the researcher had a nice writeup of their work, which is something we always like to highlight. Read the researcher's writeup at https://youst.in/posts/cache-poisoning-at-scale/

The folks at Wiz continue to poke at the security models within Azure. Here they found a behavioral mismatch between IIS and other web servers. Microsoft knew that the "Local Git” directory should be something that stays local -- meaning a .git directory within a web root shouldn't be served. They enforced this by adding a web.config file to the repo that would instruct IIS to not serve the folder. (The config had a typo, but the parsing step failed secure in the sense that it still prevented access to the directory.) Of course, a problem arises when the .git directory lives within the web root used by a server other than IIS. This meant things like PHP, Node, and Ruby could unwittingly serve this repo if it were placed within the web root. It's an example where partial credit for identifying the risk still leads to complete failure in addressing that risk.

If everybody spent the end of 2021 putting "${jndi:ldap//.../}" strings in any conceivable place where a string can go, 2022 might be a year where everyone puts 500,000 characters into strings to see what happens. This is a pretty basic hack that involved shoving 500,000 characters in the name of a HomeKit device that would in turn cause the iPhone associated with the device to crash. The permanent aspect is more about the fact that the device name would be preserved in iCloud, which meant that if you restored your phone and then resynced with iCloud the iPhone would crash once again. Super long strings (kilostrings? megastrings?) aren't new in security research. They can be part of an algorithmic DoS against authentication APIs if a site accepts arbitrarily long passwords. Submit a 1MB (or orders of magnitude larger) password and (potentially) watch as the system occupies CPU time with hashing such a password with bcrypt or similarly work-factor heavy algorithm.

This article comes by way of the TL;DRsec newsletter (https://tldrsec.com), which understandably has an eye towards all things semgrep. What I liked about this example is that it's using the technique of looking at an AST for common patterns to then modify that AST in order to produce a more secure configuration. Refactoring isn't a new concept, especially in modern IDEs. But this shows an effective way to do security-minded refactoring that can be repeated across many repos and, in principle, can be done against legacy code, too. It's nice to see security tools leading to fixes rather than always just being relegating to finding flaws.

Thinkst does a great job at providing informative infosec material. It's one of the reasons they don't need to lapse into more common (and unfortunate) marketing techniques like registration walls. This is another of their quarterly reviews of trends and highlights they've seen from infosec conferences. The topics range from post-quantum algorithms to breaking Azure AD endpoints to insights on ransomware negotiation. Even if the topics aren't directly relevant to your environment, they're good things to keep abreast of. Another reason for highlighting this report is how well its format concisely communicates several presentations into summary, takeaways, and a graphic from the presentation. It's a nice model for appsec or infosec teams who are looking for ways to distill lots of complex information across several domains or disciplines. It shows why we believe good communication is an important component of appsec.

This article pulls in authentication, risk, DevOps, user experience, and threat modeling -- all the great ingredients for an appsec discussion. Salesforce is making a commendable push to require MFA for all users and, notably, they're placing SMS and email-based delivery as unacceptable mediums for receiving one-time passcodes. Any MFA is better than no MFA. Salesforce is setting their risk tolerance to a minimum of authenticator apps for TOTP and encouraging more secure approaches that rely on Webauthn or U2F. This follows on the news near then end of 2021 where Google was slowing enforcing MFA for all of its Gmail users. It looks like MFA everywhere might be the new HTTPS everywhere -- and that's great to see. Read the Salesforce announcement at https://help.salesforce.com/s/articleView?id=000352937&type=1

We have to go to the Internet Archive's Wayback Machine for this bit of history from January 2000. It's an advisory from L0pht member dildog -- our guest on this week's interview segment. Not only did L0pht gain a lot of fame for their research at the time on Windows vulnerabilities, in particular Internet Explorer 4, but they also had a deep knowledge across Unix and Linux systems. This particular vuln was fun because it was a local privilege escalation that took advantage of the PAM (still in use today), how its behavior could be influenced by config files, and -- here's the fun part -- how our wonderful friend the "../" directory traversal could point to an arbitrary config file. Part of the advisory has this easily generalizable recommendation in the fix: "Get rid of the .. paths... Remember 'strcat' isn't a very good way of confining a path to a particular subdirectory." The CVE is at https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2000-0052

It's too easy to talk about the negatives in infosec. Here's some positives from 2021.