Schools of Magic – ASW #173

Microsoft announced at its Ignite conference that it'll be bringing JavaScript APIs to Excel. Of course, everyone immediately made their predictable jokes about Excel, security, and JavaScript. But is this really a bad idea? JavaScript has become pretty ubiquitous and while the JavaScript engines in modern browsers remain a painful attack surface to secure, they've also received significant scrutiny, hardening, and sandboxing in modern software architectures. Rather than try to preserve some backwards compatibility with existing functionality, this seems like a smart way to make a break for modern app design that supports a user-friendly feature. With that said, it'll be important for the implementation to ensure that it's resistant to the kinds of attacks that have hit browsers' JavaScript engines over the past several years -- things like manipulating array indexing and references to trigger null pointer dereferences, or manipulating data objects to trigger other types of memory safety issues.

One of the cool things about this article is that it starts off with the mindset of using CodeQL to find suspicious software patterns. What's even cooler is that it was successful! These researchers found a remotely exploitable flaw in the Transparent Inter-Process Communication (TIPC) protocol -- " a protocol that allows nodes in a cluster to communicate with each other in a way that can optimally handle a large number of nodes remaining fault tolerant." It also looks like a classic implementation mistake in mishandling the header size of incoming packets. While there are validation rules to ensure that the sizes declared in a packet's header and message sections match up with the actual size of the packet, a recent addition of a packet type intended for sharing encryption keys had a field that wasn't considered in this validation. Consequently, an attacker could control the heap allocated for a relatively small packet, and then use this field to write past that memory boundary.

There are a couple of lessons in this article, but first and foremost is what we should learn from the attack vector: "...the result of attackers gaining access to a package developer’s account." In other words, enable 2FA for all of your accounts and ideally use only a FIDO key for authentication -- and if your application doesn't support FIDO keys, make some noise in a support ticket or feature request. Another lesson is to go through an exercise with your DevOps and Appsec teams to see how quickly and with how much confidence they can answer whether one of these npm package is in use by an app and, as a bonus effort, what specific versions have been used and when were they in use. And there's a final thought exercise that we'll have to explore on the show. The article ends with the premise that, "Both libraries are extremely widely used, the malicious code was poorly hidden, and both libraries hadn’t seen new releases since December 2018 and December 2015, respectively, meaning that any new release would have triggered a security audit for most professional developer teams." Those statements reflect good security practices and expectations, but are they too optimistic? Are there more effective ways to approach this kind of scenario?

There are a couple of ways to respond to an article like this. One perspective is as a security purist who disdains any SMS-based or OTP 2FA solution. Considering that we've seen industry numbers where adoption of 2FA is on the other of 2% for large apps like Twitter and Google, that doesn't seem like a productive response. In fact, Google has shared research in the past at how effective any 2FA mechanism was at inhibiting account takeover attacks and, more recently, they've started to auto-enroll users into 2FA. So, the perspective that feels more useful with regard to this article is understanding evolving threat models and knowing where the potential weaknesses are in various security controls, including this example of attacks against OTP 2FA. And hopefully this generates a broader discussion of how to create a user experience that not only makes 2FA a required default, but one that also leans towards push notifications and WebAuthn-style solutions. That sets up the next step in the conversation to be how to handle account recovery workflows. There's no point in deploying a stronger 2FA mechanism if it leads to users locking themselves out too often or merely shifting the weaknesses in identity and authentication from the login page to the forgot password page. Check out some of these related articles: - https://blog.twitter.com/engineering/en_us/topics/insights/2021/how-we-rolled-out-security-keys-at-twitter - https://blog.google/technology/safety-security/making-sign-safer-and-more-convenient/ - https://security.googleblog.com/2019/05/new-research-how-effective-is-basic.html

One of the reasons that shifting responsibility for security to DevOps teams can be more successful is that they're the ones that often have to do all the work. Ideally, appsec teams become strong collaborators in this type of shift, either going down the route of programming alongside the DevOps team or serving as more of a product manager to help clarify requirements and work with the DevOps teams towards a solution. The old-school appsec approach of commanding, "Use X" and then walking away without further engagement hasn't been particularly helpful. This article gives some insight on the implementation hurdles and edge cases that come up when teams move towards more secure architectures. Obviously, it's a direction we want to encourage, but it also needs collaboration and support in order to work. This is like the Let's Encrypt example I often go back to. The Let's Encrypt project solved two problems. One, it made certs free and therefore budget friendly. That removed an initial budget burden to adopting HTTPS. Second, it introduced automation via the ACME protocol that help with the ongoing maintenance of certs, thus making provisioning and rotation a little bit easier. Those two steps were infinitely more useful than any security conference talk that just stopped at, "Use HTTPS".

We know you like reading NIST documents as much as we do, which is why we never hesitate to share the ones that NIST creates around the appsec space. Here's a draft about consumer software labeling that's out for community feedback. Some of the areas it focuses on would be great inspiration for your appsec plus DevOps security practices. They cover basic, but critical, practices such as vulnerability reporting, how you deploy software free from know vulnerabilities, use of MFA, and even what type of data it collects. Each of these (and more) are good steps for maturing your SDLC. Check out the PDF at https://www.nist.gov/system/files/documents/2021/11/01/Draft%20Consumer%20Software%20Labeling.pdf

We're pulling in another article from the Daily Swig this week that touches on several items from this episode as well as the broader themes of supply chain security and the security responsibilities of DevOps teams. One of the things that resonates the most with me is the attention to basics -- these are items that are easy to say, yet hard to do well. But if you can create a reliable app inventory, can get near-100% coverage with software composition analysis, and do so in a dev-friendly way that's heavily automated, then you've managed to tackle a complex, non-trivial problem.

The OWASP Global AppSec US Virtual conference is this week, with presentations on November 11th and 12th. We'll be keeping an eye out for presentations to talk about in future episodes. If you watch one that stands out, let us know! We'd love to share and cover it!

It's the 25th anniversary of one of the most famous articles to popularize and explain the mechanics behind buffer overflows, "Smashing The Stack For Fun And Profit." Don't worry if you're not a C programmer or if assembly is indistinguishable from Egyptian hieroglyphics, the article steps through the basics of the stack and how it can be manipulated through buffer overflow exploits. It's a quick read and an important part of infosec history. And even if modern memory safety issues are more in the realms of heap overflows and null pointer dereferences, the underlying principles are similar. So, the next time you're ensuring ASLR is enabled or you're running one of LLVM's sanitizers on your code, think about how 25 years later there are still CVEs being created for the very vulns this paper is describing.

This looks like a neat project to get more community involvement behind - The researcher is trawling through malware source code written in C/C++ that utilizes WinAPIs and categorizing them.

Coa and rc found to have malicious code added by the same actor.