Issue 136: OAuth 2.0 security checklist and pentesting ✔️

Companies typically avoid providing details on their data breaches. Today we have a rare exception. The staff of the Russian opposition leader, Alexey Navalny, has posted a detailed report on both the breach they had earlier this year and their investigation into the breach. Unfortunately, the report is in Russian, so you might need to use Google Translate or auto-generated English subtitles in the video version that they posted on YouTube.

When Navalny got imprisoned earlier this year, his supporters set up a website to campaign for his release. The site collected supporters’ email addresses and approximate postal addresses to be used to coordinate public protests across the country.

Right before the protests, attackers that are believed to be connected to the Russian government leaked the list of the email addresses. Later, they used the email addresses along with additional data from government sources (names, registration addresses, dates of birth, employer information) to intimidate the supporters and their employers. The consequences have been very real, with multiple reports of people losing their jobs as a result.

According to the investigation, attackers got in through the API of the mass email system, Mailgun, that the campaign used.

1. One of the former administrators of the system (fired years before the breach) had retained an API key to Mailgun issued to the campaign.
2. The ex-admin used the API key for a scraping script to extract the email addresses from Mailgun. This script had built-in delays to avoid getting throttled or causing suspicious spikes, thus not raising an alarm.
3. Looks like there were early reports of the ex-admin possessing at least some of the email addresses as early as January this year, but the reports were ignored at that time.

The investigators managed to correlate Mailgun logs and the leaked data to prove that this was indeed the system that was breached and that no other system or data got compromised.

Quite a few lessons learned here:

• Personally identifiable information (PII) can be extremely sensitive, and even just breached email addresses can lead to very tangible real-life consequences.
• We live in a world in which breached PII can be augmented with data from other sources and thus further weaponized.
• Long-living API keys are extremely dangerous and must be avoided. Use OAuth whenever possible, and frequently rotate API keys if not.
• Limit API key access, issue the keys with minimal permissions, control which employees have access to the keys, deprovision the keys when employees who potentially have access to them depart the company.
• Use IP whitelisting and check IP addresses in the logs to ensure that only the expected client call your APIs.
• Monitor API logs.
• Take any reports on data leaks seriously and investigate and treat them promptly.

Researchers from Binary Brotherhood have taken IETF OAuth 2.0 Security Best Current Practice and added other common OAuth2 vulnerability lists that they found on the internet to compile their well-rounded OAuth 2.0 Pentest Checklist.

Check out their page for the detailed checklist and links to additional resources.

Nishith K has posted both an introduction to OAuth 2.0 and details on the following common vulnerabilities:

• Improper implementation of the implicit grant type
• Flawed cross-site request forgery (CSRF) protection
• Leaking authorization codes and access tokens
• Flawed scope validation
• Unverified user registration
• Host header injection
• Reusable OAuth access tokens

A researcher going by the name of Bend Theory has posted details on his API penetration testing process:

• Google Dorking, or using Google search techniques to locate JavaScript and other files that contain API endpoint references
• Using web apps in the browser while proxying calls through Burp
• Analyzing JavaScript files and endpoints, including BurpJSLinkFinder plugin and Python scripts
• Wordlists
• CLI recon tools, such as gau, qsreplace, httpx, LinkFinder, dirsearch, ffuf, kiterunner, urlscan.io

He then gives examples on the approach he used to discover a couple of recent real-life vulnerabilities:

• A profile access API call leaking user profile data due to BOLA/IDOR
• API information disclosure and privilege escalation to administrative access