asw173

Application Security Weekly Episode #173 – November 08, 2021

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

1. A Standardized Approach to SBOM – 12:30 PM-01:00 PM

Sponsored By

sponsor
Visit https://securityweekly.com/cloudsmith for more information!

Announcements

  • In case you missed it: Paul’s Security Weekly’s new streaming time is Wednesday nights from 6pm-9pm ET & Enterprise Security Weekly’s new streaming time is Thursday afternoons from 3pm-4:30pm ET. You can view our live stream schedule at any time at https://securityweekly.com/live!

  • Join us for our next live webcast on November 11th to learn the key insights and takeaways from the the 2021 OWASP top ten. Visit https://securityweekly.com/webcasts to save your seat! Don’t forget to check out our library of on-demand webcasts & technical trainings at https://securityweekly.com/ondemand

Description

In this segment, Mike and Dan McKinney from Cloudsmith will be discussing SBOM and what that looks like for your applications. Other topics include: cloud-native tooling for your software supply chain, the history of provenance, GPG Keys & signing commits, package consumption, understanding threat modeling, and knowing the roles and responsibilities when it comes to security of your assets.

This segment is sponsored by Cloudsmith.

Visit https://securityweekly.com/cloudsmith to learn more about them!

Guest(s)

Dan McKinney

Dan McKinney – Developer Relations at Cloudsmith

With over 10 years in the world of engineering, Dan currently leads Developer Relations at Cloudsmith. Bridging the gap between customer success, engineering, and marketing, Dan is incredibly passionate about helping people and organizations implement and adopt technologies that secure their software supply chain. In addition to Developer Relations, Dan is also the voice and creator behind Cloudsmith’s YouTube tutorials, guides, and the key writer behind all blogs and documentation. Fun fact: Dan is also a professional DJ with over 2,000 gigs under his belt alongside some of the biggest names in the industry.

Hosts

JohnKinsella

John Kinsella

@johnlkinsella

Co-founder & CTO at Cysense

MikeShema

Mike Shema

@Codexatron

Security Partner at Square

2. Linux Kernel TIPC RCE, NPM Malware, OTP 2FA Bots, & Security Labels – 01:00 PM-01:30 PM

Announcements

  • InfoSec World 2021 is proud to announce its keynote lineup for this year’s event! Hear from Robert Herjavec plus heads of security at the NFL, TikTok, U.S. Department of Homeland Security, Stanford University, and more… Plus, Security Weekly listeners save 20% on Digital Pass registration! Visit https://securityweekly.com/isw2021 to register now!

  • Security Weekly Unlocked will be held IN PERSON this December 5-7 at the Hilton Lake Buena Vista! Keynotes from Alyssa Miller, John Strand, Lesley Carhart, Dave Kennedy, & Maril Vernon! Visit https://securityweekly.com/unlocked to register and check out our rockstar lineup!

Description

This week in the AppSec News, Mike and John talk: Excel gains support for JavaScript data types and functions, arbitrary code execution in Linux kernel TIPC, more malware in npm packages, threat models and OTP/2FA bots, NIST Security Labels!

Hosts

JohnKinsella

John Kinsella

@johnlkinsella

Co-founder & CTO at Cysense

  1. Mitre-for-malware project MalAPI seeks community support – 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.
  2. Two more popular npm packages backdoored – Coa and rc found to have malicious code added by the same actor.
MikeShema

Mike Shema

@Codexatron

Security Partner at Square

  1. Microsoft opens up Excel to custom data types with images, arrays, and more – 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.
  2. CVE-2021-43267: Remote Linux Kernel Heap Overflow | TIPC Module Allows Arbitrary Code Execution – 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.

  3. Malware found in coa and rc, two npm packages with 23M weekly downloads – 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?

  4. The Booming Underground Market for Bots That Steal Your 2FA Codes – 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

  5. HTTPS is easy, just turn it on… – 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”.

  6. NIST unveils draft criteria for ‘seal of approval’ scheme on consumer software security – 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

  7. ‘Focus on brilliance at the basics’ – GitHub CSO Mike Hanley on shifting left and securing the software supply chain – 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.
  8. Global AppSec US 2021 Virtual – 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!
  9. Smashing The Stack For Fun And Profit – 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.