2020-10-09 Credential Stuffing Attack

Summary

Executive summary On October 4, 2020 and October 5, 2020, an attacker launched two credential stuffing attacks against HackerOne.com. On October 9, 2020, HackerOne’s Security team noticed the attack during their weekly audit of anomalies in their log aggregation platform, leading to the Incident Response team starting an investigation.

The Incident Response team identified that a number of accounts had valid authentication attempts, of which some were blocked due to two-factor authentication. One account in particular had user activity from an unauthorized party, which viewed a number of report titles. After an investigation, the Incident Response team concluded that report contents hadn’t been accessed.

On October 9, 2020, HackerOne immediately locked all affected accounts that had their credentials compromised. After the accounts were locked, HackerOne reached out to the account holders to notify them with instructions how to unlock their account and advice regarding their credentials. In the abundance of caution, programs of which report titles were viewed received a notification from HackerOne as well.

Incident timeline

Root Cause Analysis HackerOne has alerts in place to detect large numbers of authentication attempts per account, including a lockout strategy, and alerts to detect large numbers of authentication attempts per IP address. HackerOne also offers two-factor authentication for every user on the platform. Yet, the credential stuffing attack went unnoticed for four days. As a mitigation against missing alerts, HackerOne’s Security team does an audit for anomalies on its log aggregation platform on a weekly basis. The anomaly in sign-ins was detected during this audit.

Why did the attack go unnoticed for four days? As is typical for a credential stuffing attack, the attack specifically enumerated one password per account. This is different from a brute force attack, where many passwords are enumerated for a single account. Because each authentication attempt was for a different user, it avoided the account lockout strategy to be initiated. The attack itself was routed through the Tor network, which effectively changed the IP address for each authentication attempt. Neither of the alerts HackerOne has set up could therefore detect the attack.

Action items for HackerOne HackerOne has implemented an alert for anomalous authentication volume, regardless of their origin or user account. This will help to proactively alert the Security team when a similar attack would be launched.

HackerOne will also prioritize a feature that helps keeping its users more secure by identifying machines they haven’t authenticated from in the past. HackerOne will start to require the user to confirm their authentication attempt through a 3rd party system before the newly identified machine can authenticate against the platform.

Advice for users This incident is a great reminder of the benefits of two-factor authentication. You can enable this for your account under Authentication.

HackerOne also recommends its users to use a password manager and refrain from reusing passwords across multiple systems.

Note on breadth of the attack As mentioned earlier, the attack covered many accounts and used unique IP addresses for each attempt by using the Tor network. The Incident Response team identified two commonalities in the authentication requests, namely the browser’s user agent and a client-generated authentication fingerprint. The user agent gave a slightly broader set of accounts that were affected than the fingerprint.

To err on the side of caution, the Incident Response team decided to use the browser’s user agent to avoid missing an account that was authenticated. This may have resulted in people having their accounts locked by error. Due to the sensitive nature of the information that could’ve been accessed, the Incident Response team believes that this was the right decision.