Something’s Out There – ASW #153

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/

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.

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

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"

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

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.

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

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.