Application Security Weekly #159

The 30th USENIX Security Symposium is coming this August (details at https://www.usenix.org/conference/usenixsecurity21). One of the papers has an appealing premise and results, albeit with a clunky name of Detecting Functionally-similar yet Inconsistent Code (FISC). The idea is to apply machine learning techniques that only rely on your own code in order to identify inconsistencies that can indicate bugs like memory leaks and mishandling pointers. The appeal is that the ML training relies on the codebase itself -- no need for a massive corpus that may be unavailable, unwieldy, or unconnected to your apps. Even if you don't have the means to dive into the underlying techniques, the basic principle is something that an appsec team should strive for. When you identify a vuln, such as through a scanner or a bug bounty, don't stop at the fix, but look for similar patterns in your code. Of course, the catch is being able to express what "similar" means, having an effective tool to search for that similarity, and producing hits that are meaningful bugs... Some other USENIX presentations with an interesting appsec angle include: - "Android SmartTVs Vulnerability Discovery via Log-Guided Fuzzing", https://www.usenix.org/conference/usenixsecurity21/presentation/aafer - "Saphire: Sandboxing PHP Applications with Tailored System Call Allowlists", https://www.usenix.org/conference/usenixsecurity21/presentation/bulekov - "ALPACA: Application Layer Protocol Confusion - Analyzing and Mitigating Cracks in TLS Authentication", https://www.usenix.org/conference/usenixsecurity21/presentation/brinkmann - "Why Eve and Mallory Still Love Android: Revisiting TLS (In)Security in Android Applications", https://www.usenix.org/conference/usenixsecurity21/presentation/oltrogge

Ok. So, the "Common Weakness Enumeration" (aka CWE) has some of the most unexciting and snooze-inducing naming conventions. After all, there's a lot of "improper neutralization of special elements used" for blah, blah, blah -- when the shorthand like XSS, command injection, SQL injection, and the like are easier to remember. However, it's a useful way to classify software weaknesses so that tools can reference a shared language. When CWEs can be tracked over time we benefit from some basic insights into the trends where appsec teams may want to focus. The latest list of the top weaknesses for 2021 hits very familiar items in compiled code (all those out-of-bounds reads and writes, use after free) and the boringly repetitive offenders of the web, from XSS to SQL injection to CSRF. And, if you look closely, you'll find ASW's favorite type of vuln coming in at number 8. A terrible way to use this list is adding CWE numbers to your secure coding training -- no one cares and it's not useful. Instead, pick a weakness or two that's relevant (and hopefully not prevalent) to your code base and set that as a vuln class to eliminate. Add a framework to prevent it, switch to a different coding pattern that makes the weakness harder to implement and easier to spot, remove potentially vulnerable code that's not even used anymore. Find something more effective that just grepping for the problem. The Root Cause Analysis page from Project Zero has a good list of vulns that fall into the top items on this list. You can find it at https://googleprojectzero.github.io/0days-in-the-wild/rca.html. For example, they describe an out-of-bounds write in IE that can be triggered by three simple lines of JavaScript (https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2021/CVE-2021-33742.html). You can also find a slew of use-after-free bugs that they've documented. If you're looking for examples of high-impact vulns with good explanations, any of these could be part of a secure coding discussion.

Here's a quick followup on the format string bug that hit iPhone's Wi-Fi connections. It was a fun bug with a dead simple implementation -- throw a few format identifiers (like "%s") into the SSID -- that lead to a gnarly DoS that prevented the device from rejoining any Wi-Fi. Apparently, the DoS is now an RCE. It's a good example of an appsec (and cryptography) premise that "attacks only get better". Fortunately, another appsec premise is helpful here: "patch your stuff".

Here's another vuln disclosure from Qualys, this time in a size_t-to-int type conversion in the Linux kernel's filesystem. What's curious about this (or frustrating, depending on your point of view) is that this type of unsigned to signed integer conversion is known to have potential security side-effects and has known patterns for correctly handling these types of comparisons. It's something that compilers can warn on and is relatively straightforward to identify with semantically aware code analysis tools. And don't write off this type of vuln as something specific to Linux or the C and C++ languages. This isn't a memory-safety issue (although it could be a precursor to one) and it's a type of vuln that even Rust could fall prey to. Fortunately, its compiler (along with modern C/C++ compilers) can loudly warn you about these issues. So, before you assume that values will never be large enough to trigger integer overflows, pay attention to what the compiler is suggesting and take the time to harden those areas of code. Here are some more links if you're interested in integer overflows - https://doc.rust-lang.org/book/ch03-02-data-types.html - https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html#silencing-unsigned-integer-overflow - https://cwe.mitre.org/data/definitions/190.html -- since we're talking about CWE this episode - https://github.com/dcleblanc/SafeInt -- Dave LeBlanc did a lot of early work in this area to harden Microsoft code - http://phrack.org/issues/60/10.html#article -- an article in Phrack from 2002

We like to highlight efforts at transparency, whether through postmortems, open source tools, or reports on what works well (or doesn't!). While it's good to keep a skeptical eye out for information masquerading as marketing, it's just as good to read docs like this to see what can be learned from them. In this case, a takeaway for the appsec community is that on 2.3% of Twitter users have enabled any form of 2FA and of that cohort 80% are relying on SMS. So, next time your advice to a product team is "make 2FA available", take the time to plan out how to measure and drive that adoption so the userbase hits a percentage that's closer to 2.3% *haven't* enabled 2FA yet. And for bonus points, make sure the account recovery process doesn't become the new weak link once you have mass adoption of 2FA.

In the past few episodes we've been talking about the cloud and risk in terms of risks that the cloud makes easier to manage and what risks it might introduce. Unsurprisingly, we'd say most of the risk is more correlated with the maturity of your DevOps team and appsec program as opposed to just being "the cloud". Here we have Phil Venables talking about paving a way forward for cloud security that leverages modern tools and approaches to address risk in more automated, consistent fashions. As an aside to last episode's discussion about banks, clouds, and availability, Phil comes from a banking background, having served as CISO for Goldman Sachs. Read the original article at https://cloud.google.com/blog/products/identity-security/cloud-ciso-perspectives-july-2021 We covered another article from Phil in episode 151 about his views on complexity, security, and using good design to keep complex systems secure. You can find the episode and article at https://securityweekly.com/asw151