asw179

Application Security Weekly Episode #179 – January 10, 2022

Subscribe to all of our shows and mailing list by visiting: https://securityweekly.com/subscribe

1. Broadening What We Call AppSec – 12:30 PM-01:00 PM

Announcements

  • Do you have a specific guest or topic that you want us to cover on one of the shows? Submit your suggestions for guests by visiting https://securityweekly.com/guests and completing the form! We review suggestions monthly and will reach out to you once reviewed!

  • We had an absolute blast putting together this year’s SW Unlocked virtual event! All presentations are now available on-demand for your viewing pleasure. Please visit https://securityweekly.com/unlocked to register and watch now!

Description

There’s an understandable focus on “shift left” in modern DevOps and appsec discussions. So what does it take to broaden what we call appsec into something effective for modern apps, whether they’re on the web, mobile, or cloud? We’ll talk about moving on from niche offerings into successful appsec programs.

Guest(s)

Christien Rioux

Christien Rioux – DilDog at Cult of the Dead Cow

@dildog

Member of L0pht and Cult of the Dead Cow, founder of Veracode.

Hosts

JohnKinsella

John Kinsella

@johnlkinsella

Co-founder & CTO at Cysense

MikeShema

Mike Shema

@Codexatron

Security Partner at Square

2. Log4j for FTC, More JNDI, Cache Poisoning, Improving Default Configs, ThinkstScapes – 01:00 PM-01:30 PM

Announcements

  • Don’t miss any of your favorite Security Weekly content! Visit https://securityweekly.com/subscribe to subscribe to any of our podcast feeds and have all new episodes downloaded right to your phone! You can also join our mailing list, Discord server, and follow us on social media & our streaming platforms!

  • Join us January 20th to learn how to build your own security lab at home! Then join us February 16th to learn about validation techniques within applications. Finally, join us March 2nd to learn five things you can do to catch more bad guys! Don’t forget to check out our library of on-demand webcasts & technical trainings at https://securityweekly.com/ondemand.

Description

The FTC issues a warning about taking log4j seriously, JNDI is elsewhere, cache poisoning shows challenges in normalizing strings, semgrep for refactoring configs with security in mind, the Q4 2021 ThinkstScape quarterly, Salesforce to require MFA

Hosts

JohnKinsella

John Kinsella

@johnlkinsella

Co-founder & CTO at Cysense

  1. Long names in homekit make things break
  2. Year flip in Exchange breaks email delivery
  3. Celebrating infosec wins in 2021 – It’s too easy to talk about the negatives in infosec. Here’s some positives from 2021.
MikeShema

Mike Shema

@Codexatron

Security Partner at Square

  1. FTC warns legal action against companies who fail to mitigate Log4Shell – 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

  2. The JNDI Strikes Back – Unauthenticated RCE in H2 Database Console – 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.

  3. CDN Cache Poisoning Allows DoS Attacks Against Cloud Apps – 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/

  4. NotLegit: Azure App Service vulnerability exposed hundreds of source code repositories – 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.

  5. This iOS 15 bug could crash your iPhone permanently – 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.

  6. Programmatic Terraform config manipulation, Semgrep’s autofix, and an example of OSS contribution – 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.

  7. Q4 2021: ThinkstScapes Quarterly – 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.

  8. Salesforce to require MFA for all users starting next month – 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

  9. PamSlam – 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