ChaosDB, OpenSSL String Bugs, Revealing Locations, & More Top 15 Vulns – ASW #164

Researchers discovered how to abuse a flaw in Azure's deployment of Jupyter notebooks for their CosmosDB environment that enabled them to access arbitrary databases. It's a particularly unfortunate vuln because the underlying choice of using Jupyter is a good one -- it's a way to have consistent, well-configured, auditable, and interactive access to datasets. The technical details still haven't been revealed, but it looks like a topic worth keeping an eye on to learn how to better protect and isolate cloud resources. Here are some additional links to check out: - https://docs.microsoft.com/en-us/azure/cosmos-db/secure-access-to-data?tabs=using-primary-key - https://jupyter.org

We're back (unsurprisingly...sigh) into the land of C and memory safety issues with a pair of bugs in OpenSSL. The silver lining is that they're apparently difficult to exploit -- one is in an algorithm created by the Chinese government that few are likely to use and the other in ASN.1 parsing that fortunately doesn't have easy attack vectors. There's still some useful general lessons to take from this situation. One, disable features you don't need. This is probably an under-appreciated aspect of supply chain security, where recompiling binaries to remove unneeded features reduces your attack surface. The catch is how much engineering time you have to ensure you haven't removed or disabled features that a rare code path in your app needs. The other lesson is a callback to last episode when we talked about the programming minefield that is ASN.1 parsing -- it's been a notorious attack surface for decades. And, in this specific case, it's a lesson in assumptions when crossing implementation boundaries where C-style strings are expected to have a NULL byte terminator and ASN.1 strings have a length field, but no guarantee of NULL terminator. In other words, it's a mismatch across APIs in terms of "what does a string look like" for APIs that have different rules. This is similar in spirit to the glibc vuln that we also discussed last episode, where the expectation for NULL pointers differed between two APIs. Check out the OpenSSL advisory and technical details at https://www.openssl.org/news/secadv/20210824.txt

This is a good example of the impact of appsec on the safety and user experience of an app. It's easy to focus on technical details of vulns and exploits, or focus on privacy issues, but threat models should also take into account user interactions and how app features might be abused to target users in unwelcome and unexpected ways. Another thing that stood out from this article was the robustness of the fix, not only did Bumble address the location precision and hashing issues, but they improved the app logic to "prevent you from matching with or viewing users who aren’t in your match queue". It's nice to see a more concrete example of business logic issues and how they're addressed. Check out similar research on the dating app Tinder at https://robertheaton.com/2018/07/09/how-tinder-keeps-your-location-a-bit-private/

This is a short article and, like other vendors' "State of" report, inches towards marketing material. The takeaway seems to be old vulns not being patched (lots of CVEs from 2017 to 2020, with one from 2013) and an overrepresentation of Apache Struts along with the too-familiar Drupal and WordPress. If we took a step back and queried this through a lens of appsec architecture, some bigger questions might be: Are these app's designed in a way that make them harder to secure by default? (Hint: WordPress core seems relatively secure; it's the plugin model where it falls down.) Or, what makes these apps more difficult to patch? The more detailed report is at https://www.trendmicro.com/vinfo/us/security/news/cybercrime-and-digital-threats/linux-threat-report-2021-1h-linux-threats-in-the-cloud-and-security-recommendations

Here's an article from the TL;DRsec newsletter that's rich in its overview of cloud security principles and its links to detailed resources. You'd be well served if all you did was use it as bookmark to other material (and, well, read and implemented the recommendations in that material -- so set asides lots of time). For the more time-pressed readers or those looking for more actionable advice, there's a companion checklist you can find at https://tldrsec.com/blog/cloud-security-orienteering-checklist/

Here's another doc highlighted from the most recent TL;DRsec Newsletter (https://tldrsec.com/blog/tldr-sec-098/). But at 163 pages, it's possible the S3 security document that you'll never read as opposed to ever need. The doc's length and the data flow diagram on page 3 make the "Simple" in Simple Storage Service suspiciously something other than simple. But it's also likely that the doc could be distilled to simple steps of 1) block public exposure of S3 buckets by default at the account level, audit IAM for least privilege, choose an encryption strategy that matches the sensitivity of the data stored (whether default encryption for the bucket or per-object encryption with a client-managed key).

The latest Linux kernel includes several appsec improvements, including the ability to not mix trusted and untrusted tasks on the came CPU core.