BadAlloc Vulns, Gatekeeper Bypass, & More Spectre in Micro-Op Caches – ASW #149

Mike Shema

1. Microsoft discloses ‘BadAlloc’ bugs affecting smart devices, industrial gear
   The "OT" impacts from these vulns are less about the "Of Things" in retail IoT and more about Operational Technology and Industrial Control Systems. Microsoft researchers found several flaws in Real-Time Operating Systems (RTOS) and SDKs where common memory functions had common memory handling mistakes. Yes, it's disappointing to see the presence of these fundamental mistakes in modern software, but there's at least a glimmer of hope in how effectively dedicated researchers can find these flaws at scale and push the industry forward -- even if forward still reflects a decade or so of lag in secure architectures. Check out the Microsoft blog post at https://msrc-blog.microsoft.com/2021/04/29/badalloc-memory-allocation-vulnerabilities-could-affect-wide-range-of-iot-and-ot-devices-in-industrial-medical-and-enterprise-networks/ For more background on the types of threats and security concerns within OT and ICS, check out this 2020 retrospective from Dragos at https://www.dragos.com/year-in-review/
2. Apple patches macOS Gatekeeper bypass vulnerability exploited in the wild
   It's always hard to prevent "user assisted" infections in the sense of a user who downloads and executes an app. Over the years, macOS has put significant effort into various signing, quarantining, and alerting mechanisms to help users be aware of what an unknown and untrusted download might do. In this case, a subtle logic bug bypasses these controls to execute surreptitious scripts without any alarms. Be sure to read through the details of the original blog post by Cedric Owens at https://cedowens.medium.com/macos-gatekeeper-bypass-2021-edition-5256a2955508 and additional work by Patrick Wardle at https://objective-see.com/blog/blog_0x64.html
3. Silverfort Researchers Discover KDC Spoofing Vulnerability in F5 Big-IP
   In an internet timeframe, Kerberos is a pretty ancient protocol. Yet it remains a robust authentication mechanism. Even though this particular vuln requires network intermediation -- a means to inspect and inject traffic to the domain controller -- it's a good reminder of the gap between secure design and secure implementation. The article also includes an overview of the Kerberos protocol and the design properties intended to prevent this kind of attack, including a shout out to the history of this type of vuln. Even if you're not using Active Directory or Kerberos, the security model and principles behind its design can inform the design of authentication and authorization mechanisms in your own service-to-service communications. As an added thought, it's not surprising to see rough edges in protocols -- even security-minded ones. What has improved over the years is that protocol designers have been more explicit in noting potential implementation errors and pitfalls. TLS 1.3 noted some general advice in Appendix C of its RFC (https://tools.ietf.org/html/rfc8446#appendix-C.3) and it took care to note the performance and security trade-offs of a feature like zero round-trip time (https://tools.ietf.org/html/rfc8446#appendix-E.5).
4. Experian API Exposed Credit Scores of Most Americans
   A data leak from an API that uses your own APIs and leaks your own data is still your security problem, even when it's not your API where the flaw lies. It's hard enough to manage security for applications your own org is building, how do you successfully extend that to the third-parties consuming your data and applications? This also opens discussion to dealing with enumeration attacks and authenticated vs. un-authenticated traffic, plus the business context of the inherent risk around data sets like this and their potential for abuse.
5. Abusing Replication: Stealing AD FS Secrets Over the Network
   Another article with a good mix of historical context and technical detail on a recent technique for obtaining a Token Signing Certificate from Active Directory Federation Services and using it to gain access to arbitrary services. Like the KDC spoofing article also in this week's news, there are security lessons in here even if you're not relying on AD. The attackers discovered a less protected avenue to the Token Signing Certificate and further benefited from a lack of sufficient monitoring for the service they abused. The strategy behind those attacks can transfer nicely to the complexity of IAM and service policies that DevOps teams must deal with for cloud native apps.
6. Changing Security Tool Requirements in the New DevSecOps World
   A quick read that summarizes many of the desirable properties of modern appsec and DevOps: integration with where devs work and automation for workflows. Whether you're shifting a security responsibility left or right, putting it into the SDLC in a way that helps deploy apps quickly is going to be a major indicator of success.
7. UVA Engineering Computer Scientists Discover New Vulnerability Affecting Computers Globally
   Spectre continues to haunt processors. New research shows another method for leaking data from a cache, further highlighting the strain between CPU performance and security -- where speculative execution and caching prepare data in expectation of an access control check, only to have that preparation's activities reveal useful info before the access control ever occurs. Just this past March, Google security researchers demonstrated proof-of-concept Spectre attacks against modern browsers. So it remains to be seen which will haunt security longer: Caches or JavaScript... The abstract is available http://www.cs.virginia.edu/venkat/papers/isca2021a.pdf
8. University of Minnesota responds to Linux security patch requests
   UMN has a good response to the security research that used deception to introduce flaws into the Linux kernel. They acknowledge the time wasted by the deception and the experiment's poor design. They've also withdrawn the paper in order to prevent it from becoming a model for this type of research. Securing a codebase of 30 million+ lines of code with thousands of contributors isn't trivial. It'll be great to see future research that helps guide how to secure code contributions at scale as well as introduce mechanisms that rely less on reminders that bad actors exist and more on reliable attestation of safe code. We covered this in a dedicated segment in ASW #148 if you're interested in hearing more about it.