asw153

Application Security Weekly Episode #153 – June 07, 2021

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

1. API Security: Understanding Threats to Better Protect Your Organization – 12:30 PM-01:00 PM

Sponsored By

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

Announcements

  • Security Weekly is more than happy to announce that we will be at InfoSec World 2021 IN PERSON October 25th-27th, 2021! This year, our annual partnership with InfoSec World is extra special, as we are both business units under the CyberRisk Alliance brand! What does that mean for Security Weekly listeners & InfoSec World attendees? You will get to see and hear from many of the Security Weekly team at the event AND you will save 20% off on your world pass! Visit https://securityweekly.com/isw2021 to register using our discount code!

  • Do you want to stay in the loop on all things Security Weekly? Visit https://securityweekly.com/subscribe to subscribe on your favorite podcast catcher or our Youtube channel, sign up for our mailing list, join our Discord Server, and follow us on our newest live-streaming platform, Twitch!

Description

While web application security is a highly researched topic with a lot of subject familiarity among security professionals, it’s still not easy for security and development teams to navigate modern threats, and understand the differences, and more importantly, the similarities between securing web apps and securing APIs. In the endless battle to keep networks and applications safe, organizations need to rely on real-time data to better understand the differences between attacker behavior and legitimate traffic. Join this discussion with Daniel Hampton for a look inside a unified and collaborative approach to the modern tools and processes needed to monitor for and stop real-time web application and API security threats, and clarify the complexities teams often navigate.

This segment is sponsored by Fastly.

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

Guest(s)

Daniel Hampton

Daniel Hampton – Senior Solutions Architect at Fastly

Daniel is a Sr. Solutions Architect at Fastly where he is responsible for assisting customers in the post-sales process by delivering a pragmatic and effective application security experience. Daniel recently joined Fastly through the Signal Sciences acquisition. He has spent a total of 16 years in the enterprise security space, covering database, web application and container security, policy management and managed services for small-to-medium businesses.

Hosts

MikeShema

Mike Shema

@Codexatron

Product Security Lead at Square

TylerRobinson

Tyler Robinson

@tyler_robinson

Director of Offensive Security & Research at Trimarc and Founder & CEO of Dark Element at Trimarc Security

2. HTTP Goes QUIC, Security & Humans, Amazon Sidewalk Privacy, & Product Abuse – 01:00 PM-01:30 PM

Announcements

  • Security Weekly is ecstatic to announce that Security Weekly Unlocked will be held IN PERSON this December 5-8 at the Hilton Lake Buena Vista! Call for presentations & early registration for Security Weekly listeners is open now! Visit securityweekly.com/unlocked to submit your presentation & register for the early registration price before it expires!

  • Join us on June 10 at 11am ET for our technical training on insider risk to learn how to quickly mitigate data exposure risks. Then join us June 24 at 11 AM ET to learn how web application firewalls can help mitigate exposure in a complex threat landscape. Visit https://securityweekly.com/webcasts to register now! If you missed any of our previously recorded webcasts or technical trainings, they are available for your viewing pleasure at https://securityweekly.com/ondemand

Description

This week in the AppSec News, Tyler Robinson joins Mike & John to discuss: HTTP/3 and QUIC, bounties for product abuse, Amazon Sidewalk security & privacy, security & human behavior, authentication bypass postmortem, M1RACLES, & more!

Hosts

JohnKinsella

John Kinsella

@johnlkinsella

Chief Architect at Accurics

  1. Register access flaw in M1 chips allows cross-process communication – A researcher found a vulnerability in Apple’s M1 CPU where unprivileged processes are able to read or write to a 2-bit (ha!) register that was intended to be used by higher privileged programs, only. So far the only malicious use described is side-channel communication.
MikeShema

Mike Shema

@Codexatron

Product Security Lead at Square

  1. https://www.cnet.com/news/quic-gives-the-internets-data-transmission-foundation-a-needed-speedup – The QUIC Working Group (https://quicwg.org) has finalized RFC 9000 (https://www.rfc-editor.org/rfc/rfc9000.html), a new transport protocol that in turn will be used to deliver the upcoming HTTP/3 protocol (https://quicwg.org/base-drafts/draft-ietf-quic-http.html#name-table-of-contents). What’s nice to see in this modern protocol design is a more robust section on security considerations — from on- and off-path attacks to anti-amplification (think DDoS) to request forgery to slowloris-style attacks — in addition to its design for performance and encryption.
    We’re also in an age where implementations are choosing languages like Rust to avoid common memory safety and buffer overwrite vulns that have plagued C-based TCP/IP stacks in the past. Cloudflare has an open source implementation at https://github.com/cloudflare/quiche.
    Fastly also has some background on QUIC and links to some protocols, old and new, that make this protocol appealing. You can find it at https://www.fastly.com/blog/quic-is-now-rfc-9000
    Daniel Stenberg, the creator of curl, also has a post about it, including a link to his “HTTP/3 explained” site. Check out the post and link to the online book at https://daniel.haxx.se/blog/2021/05/27/quic-is-rfc-9000/
  2. Akamai offers post-mortem on recently resolved authentication platform vulnerability – Once again we encounter an impersonation attack leveraging SAML. In this case, an app used a version of the open source Lasso library that had an XML Signature Wrapping (XSW) vulnerability (https://lasso.entrouvert.org). Essentially, an attacker who obtains a signed SAML message can inject content in a way that takes advantage of a mismatch between how the app verifies an XML signature and what XML elements it uses within its business logic.
    Akamai provides a detailed postmortem about this at https://blogs.akamai.com/2021/06/akamai-eaa-impersonation-vulnerability—a-deep-dive.html. Notably, the test suite created for this integration wasn’t robust enough to capture this scenario — pointing to a common theme about the importance of security testing and building test cases to address various parts of a threat model.
    Check out this research paper (https://www.nds.ruhr-uni-bochum.de/media/nds/veroeffentlichungen/2012/08/22/BreakingSAML_3.pdf) for more details on XSW attacks and a good write-up of prior work in this area and the effectiveness of various countermeasures proposed to deal with this underlying flaw.
  3. Google Online Security Blog: Announcing New Abuse Research Grants Program – Google has had a dedicated product abuse bounty program for the past three years. Now they’ve announced a shift to proactive grants for a handful of researchers to explore this class of problems more deeply. Unfortunately, there’s not much information in the post beyond a link to a high-level definition of product abuse at https://sites.google.com/site/bughunteruniversity/improve/what-is-an-abuse-risk.
    However, this was a good way to highlight the importance of including product abuse scenarios within your threat models. It’s entirely possible to have an app that has addressed all the OWASP Top 10 categories — including business logic issues — and still have design flaws that can be abused against user’s of the product or their data. Think of these issues in terms of what your Trust & Safety team might deal with (you have such a team, right…?). In other words, consider how could your product’s features be abused or misused in a way that degrades the product experience for others, has asymmetric user costs (imagine messaging apps without a mute or block capability), or leads to a situation that surprises a user (imagine a payment app that reveals a user’s full contact info to the recipient).
    Here are a few recent examples of potential product abuse:
    – https://www.wired.com/story/twitter-tip-jar-privacy-fiasco-entirely-avoidable/
    – https://www.theverge.com/2021/3/24/22348743/slack-connect-dm-abuse-harassment-disable-message-invite-response
  4. Workshop on Security and Human Behaviour (SHB 2021) – Although the discussions from this two-day workshop aren’t available, there’s an excellent summary of them at https://www.lightbluetouchpaper.org/2021/06/03/security-and-human-behaviour-2021/
    Not all of the discussions nor position papers fall directly under the umbrella of appsec, but there’s at least a few that touch on the relation between how software is developed and the adoption (or lack thereof) of security and privacy principles.
    A few that might interest Application Security Weekly listeners are:
    – “Comparing the Usability of Cryptographic APIs” (http://www.cl.cam.ac.uk/~rja14/shb17/fahl.pdf) — emphasizes how “simplicity does promote security (to a point)” by looking at how features and documentation helped or hindered developers in using a cryptographic library
    – “Security Update Labels: Establishing Economic Incentives for Security Patching of IoT Consumer Products” (https://faui1-files.cs.fau.de/filepool/publications/ieeesp2020-security-update-labels.pdf) — finds a desire in some users for security labels in IoT and explains why it would benefit them, but the industry still lacks compelling motivations to provide clear labels or labels that can’t be trivially misused
    – “WiP:Factors Affecting the Implementation of Security and Privacy Practices in Software Development: A Narrative Review” (https://www.cl.cam.ac.uk/~rja14/shb21/frik2021.pdf) — talks about challenges to bringing security and privacy into development practices. It mostly describes the factors that work for and against this (e.g. security champions and tensions with business priorities). At the end it lays out a few ideas on leveraging motivation, capability, and opportunity — not surprisingly, it captures some common themes like “it is important to not only provide the appropriate tools and libraries, but also make them easy to use”
  5. Do you trust Amazon to share your internet connection with others? – After talking about Apple’s AirTags in the last few episodes we now turn to Amazon’s Sidewalk. There’s a quite a range of lessons here, from design choices to protect security and privacy of data to communicating the threat models those designs are intended to address. It also ties in with the theme of product abuse — perceived or otherwise — in the other articles for this episode.
    On a technical front, their white paper describes the use of multiple encryption keys to protect messages and minimize what metadata would be exposed to eavesdroppers or adversarial devices. On a communications front, it’s an approach that’s geared towards a technical audience who might be used to Amazon’s love of service names and acronyms.
    We’ve seen Apple respond to concerns about the anti-stalking controls in its AirTags by reducing the duration for alerting on “separated” tags from three days to one, and providing an Android app that would detect such tags (similar to how recent iPhone models can do so). This highlights a type of privacy and reputational risk associated with the scale at which these kinds of pervasive tracking and communications systems are deployed and the companies who deploy them.
    Check out the Amazon Sidewalk white paper at https://m.media-amazon.com/images/G/01/sidewalk/final_privacy_security_whitepaper.pdf
  6. TLS session caching disaster – It’s a great title for a relatively straightforward use-after-free bug in libcurl. It’s an interesting case where a malicious server could potentially gain remote code exec on the client.
    What’s more interesting about this is that libcurl is a well designed, actively maintained project and even it suffers from these types of flaws due to its implementation in C. But its use of C also contributes to what has made it so versatile and successful — it’s a core utility on systems, has extensions for many languages, and the curl CLI is part of many manual workflows.
  7. The Original HTTP as defined in 1991 – Since we’re talking about QUIC and HTTP/3 in this episode, let’s take a journey back in time 30 years to a seminar in June 1991 by a researcher at CERN named Tim Berners-Lee who was working on a “HyperText Transfer Protocol”. This new protocol, whose definition was to be in the public domain, was primarily to search and retrieve information. An early design consideration was whether a server would even need to keep state information about a client. And, though it was a new protocol, the design notes that “HTTP currently runs over TCP, but could run over any connection-oriented service.” The first server to run this protocol, CERN httpd, was released in version 0.1 that same month. The first bug fix was noted three months later — essentially a content type mismatch that parsed text files as SGML. How things change.
    Now, thirty years later, we’re dealing with more consequences and fallout from HTML, HTTP, server-side tracking of client data, and other web security issues than we ever had to worry about from CERN smashing subatomic particles together in its Large Hadron Collider…

    Some bits of the history are in these links:
    – https://www.w3.org/Daemon/Features.html
    – https://www.w3.org/History.html
    – https://www.w3.org/Protocols/WhyHTTP.html
    – https://www.w3.org/Protocols/DesignIssues.html
    – https://www.w3.org/People/Berners-Lee/FAQ.html
    – https://home.cern/science/computing/birth-web

TylerRobinson

Tyler Robinson

@tyler_robinson

Director of Offensive Security & Research at Trimarc and Founder & CEO of Dark Element at Trimarc Security