HTTPSignatures is a PortSwigger Burp Suite extension that implements the Signing HTTP Messages draft-ietf-httpbis-message-signatures-01 specification draft document. What motivated my creation in this tool was the lack of an easy way to test applications and services using HTTP Signatures. This extension allows Burp Suite users to seamlessly test applications that require HTTP Signatures.
What are HTTP Signatures?
Signing HTTP Messages is an IETF draft document that describes how to add, encode, and verify digital signatures in the request (or response) headers of HTTP messages. HTTP Signatures are similar to AWS Signatures but designed as an open standard. Other related standards are JSON Web Signatures (JWS) defined in RFC 7515 and Linked Data Signatures for JSON-LD documents. The current (December 2020) status of the specification is an Active Internet-Draft. Previous iterations of the specification have been developed under the draft-cavage-http-signatures name until mid-2020, when similar IETF drafts were consolidated under draft-ietf-httpbis-message-signatures.
HTTP Signatures permit HTTP endpoints to verify the authenticity of parts of an HTTP message, including some or all of its following contents: request method, request path and query, host, and other HTTP request headers such as date, content-type, digest, content-length. This allows the verifier to check the validity of the signature even when the HTTP message has been modified for example by content delivery networks (CDN), reverse proxies, web application firewalls (WAF), or other middleboxes that add/remove HTTP headers or TLS.
Note that the standard does not cover the management of the signing keys.
What are HTTP Signatures Trying to Solve?
Why would you want to use HTTP Signatures when everyone uses Transport Layer Security (TLS) for message integrity and authenticity? As ubiquitous as TLS encryption is, TLS is generally not used end-to-end. HTTP messages may pass through multiple hops such as (reverse or caching) proxies, web application firewalls, and CDNs. HTTP Signatures provide end-to-end message integrity and authenticity for the content in the HTTP message that was signed, if implemented and enforced correctly. HTTP Signatures are intended to complement TLS as opposed to replace TLS.
HTTP Signatures allow the sender to sign the content (e.g. the HTTP header values) that is relevant for the message. The verifier can verify the signature even if non-relevant parts of the message have been modified. For example, the message may have been stripped of TLS, or may have been modified to add or remove certain HTTP headers by a CDN or reverse proxy.
Applications or protocols such as ActivityPub require an application-level key (e.g. the public key of the actor in ActivityPub). This key is independent of TLS keys.
Where are HTTP Signatures Used?
HTTP Signatures are used in corporate environments and open source products:
- Oracle Cloud (OCI): All requests to the OCI API (including the web console) require HTTP Signatures.
- NextGenPSD2: PSD2 is the second Payment Services Directive, designed by the countries of the European Union. PSD regulates payment services and payment service providers throughout the European Union (EU) and European Economic Area (EEA). The goal of the NextGenPSD2 framework is to offer an open, harmonized and interoperable set of Application Programming Interfaces (APIs) for end-users and banks to interoperate. Implementation guidelines describe under chapter 12 that Account Servicing Payment Service Provider (ASPSP) can require that Third Party Payment Service Providers (TPP) to employ HTTP Signatures.
- ActivityPub is a W3C recommended protocol designed for a decentralized social networking protocol based upon the ActivityStreams 2.0 data format. ActivityPub describes a client to server protocol for creating, updating and deleting content, as well as a federated server to server protocol for delivering notifications and content. ActivityPub is used by multiple federated social networks such as the following:
Why the HTTPSignatures Burp Suite Extension was Developed
Signing HTTP messages is an emerging IETF draft with the potential for wide adoption. HTTP Signatures are used in established open source software as well as commercial products.
NCC Group performs security assessments through manual penetration testing where we use tools such as Burp Suite to observe, analyze and modify HTTP traffic in real-time or asynchronously. As signing HTTP messages require a signature of elements of the HTTP request, performing manual testing becomes difficult; modifying the contents of a request may require the computation of a new signature. The HTTPSignatures Burp Suite extension allows a tester to use Burp Suite functionalities such as creating manual requests with the Repeater tool as the extension will sign each modified request on the fly. This extension enables users to perform application testing the same way they test any other application using Burp Suite.
Features
HTTPSignatures allows users to test applications that require signatures using Burp Suite the same way as they are used to test any other application. The Burp Suite extension automatically creates new signatures and digests in Burp Proxy, Repeater, Intruder, and Scanner when the extension detects an existing HTTP Signature header. It supports the “rsa-sha256” algorithm for signing messages (RSASSA-PKCS1-v1_5 RFC8017 using SHA-256 RFC6234) and SHA-256 for the digest header.
Usage
To install the HTTPSignatures extension in your Burp Suite installation, load the latest release JAR file in Burp through the Extender Tab -> Extensions -> Add. After loading the extension, a new HTTP Signatures menu item will be added to Burp. Open the configuration window by clicking on the HTTP Signatures menu. The minimum configuration requires the Header Name, the keyId, and the Private key file name and path settings to be configured. Please see the README file on GitHub for detailed instructions on how to configure the extension. You can now use Burp Proxy, Repeater, Intruder, and Scanner with HTTP Signatures. The extension will create a new signature for each request that contains the configured Header Name.
Common Security Vulnerability Classes
During the development of the HTTPSignatures Burp Suite extension, the author discovered multiple security vulnerabilities in HTTP Signature implementations. The following describes common security vulnerability classes encountered in various services and applications. Each vulnerability class includes at least one specific security flaw the author discovered in an application or service. All flaws described were discovered by the author and have been reported, publicly disclosed, and fixed.
Authentication: Lack of HTTP Signature Checks
Authentication is the process of proving the identity of the user. Authentication using HTTP Signatures is as crucial as with any application. A common flaw is to accidentally omit checking HTTP signatures for some endpoints, therefore allowing unauthenticated access to resources.
The author discovered that Nextcloud Social App and Hubzilla were lacking signature checks for displaying ActivityPub messages and for sending ActivityPub messages respectively, thus allowing attackers to perform these activities anonymously.
Authorization Issues
HTTP Signatures permit to check the authenticity of a request to a service. It is not sufficient by itself to control access to resources; services must further establish that authenticated users are authorized to access a specific resource. NCC Group discovered applications that successfully authenticated users using HTTP Signatures but did not attempt to determine whether these users were authorized to access the requested resources.
Using the HTTPSignatures Burp Suite extension, the author discovered that 3 Oracle Cloud Infrastructure (OCI) API endpoints did not perform authorization checks and allowed an attacker cross-tenant access to other OCI accounts.
No Minimum Signed Headers Required
HTTP Signature verification systems are supposed to require a minimum set of request header values signed such as the request path and its parameters, the date, and a digest of the request body. This ensures that an attacker with access to a signed request from a victim is unable to change security relevant parts of the request. Applications that omit such checks allow attackers to specify which HTTP headers they want to sign.
PeerTube was vulnerable to this issue allowing attackers to only sign the date header and to submit arbitrary malicious ActivityPub requests.
Lack of TLS Server Certificate Validation
Systems such as ActivityPub specify the actor in the keyId parameter which is part of the HTTP Signature in the form of a URL. The HTTP Signature verification implementation must reach out to this URL to fetch the actor’s public key to verify the HTTP Signature. This outbound connection should only be allowed over a TLS encrypted connection to an endpoint configured with a valid certificate signed by a trusted Certificate Authority (CA).
The Nextcloud Social App was vulnerable to this issue because TLS certificate validation was explicitly disabled. This would have allowed an attacker in a privileged network position between a Nextcloud instance and the web server hosting the actor’s public key to perform a man-in-the-middle attack where they could replace the victim’s public key with their own and initiate ActivityPub actions as the victim.
Lack of attributedTo Property Validation
While this issue is not part of the HTTP Signature validation, it was a common security issue discovered in multiple ActivityPub implementations. ActivityPub defines multiple properties in a message such as the content (the message), the to field (destination of the message) and the attributedTo property specifying who sent the message. The attributedTo property can be used to impersonate (spoof) other users using ActivityPub actions if the implementation does not make sure that the actor and attributedTo fields contain the same actor.
Friendica and Hubzilla were vulnerable to this issue allowing an attacker to perform ActivityPub actions such as sending messages as any actor and therefore impersonate any ActivityPub user.
Conclusion
HTTPSignatures is a Burp Suite extension that implements the Signing HTTP Messages draft-ietf-httpbis-message-signatures-01 draft specification to enable seamless testing of applications that require HTTP Signatures. With HTTPSignatures, testers can use Burp Suite functionality such as Proxy, Repeater, Intruder, and Scanner to perform security testing of applications leveraging Signing HTTP Messages the same way as they are used to test any other application. HTTPSignatures is open source and is available for download on the NCC Group GitHub repository: https://github.com/nccgroup/HTTPSignatures
Author
Roger Meyer (@sanktjodel)
