By Brad Garnett, Miguel Alvarez Esmoris, Terryn Valikodath and Bob Doyle.

As we mentioned in a previous case study, relationships are tried and tested during incident response. So, when a customer came to Cisco Talos Incident Response with concerns about their public-facing website, CTIR knew immediately that we could jump into action and perform a penetration test. The relationship between CTIR and the customer had improved to the point we were confident any recommendations given to the customer would be taken to heart, while we knew all the information the customer, a company in the arts and entertainment industry, were closely following their incident response plan. Thanks to that relationship, the recently created CTIR Red Team (CTRT) conducted a penetration test that uncovered several authentication flaws in the site’s API that could have easily opened the door for an attacker. After this web application penetration test, we discovered the client’s site could be abused to view users’ payment methods, steal sensitive information, and much more.

As organizations continue to shift infrastructure and applications to the cloud, APIs play a critical role in the multi-cloud, hybrid world, so this could happen to virtually any organization. Penetration testing and red teaming are just two of the proactive services that benefit CTIR retainer clients. If your organization’s incident response plan and playbooks don’t reflect the organization’s capability to respond to web and cloud infrastructure, or you’re just looking to conduct assessments against this infrastructure, contact CTIR today.

Scope

The customer initially brought CTRT in to conduct a standard web application penetration test against the client’s primary website. The site handled scheduling, off-site sales, and loyalty card discounts for their core business. Payment processing was handled through a third-party service. The site had been developed by an outside firm and the client wanted to understand how resilient the new site was to an attack. To avoid affecting their business, we tested against a QA instance with some production testing to verify findings.

Initial Analysis

CTRT began by mapping the application and their backend functionality using an attack proxy (Burp Suite Professional). Initial data gathering found a standard web design with an Amazon CloudFront CDN hosting static content and JavaScript that, once loaded by a user’s browser, would make direct calls to API endpoints hosted in cloud services for application functions (scheduling, user profiles, authentication, telemetry, payment processing, etc.). By registering for an account and walking through the application’s usage, CTRT quickly determined the calls used for various application functions and what web services they interacted with.

Once the initial analysis was complete, CTRT focused on areas of the application that handled:

• Appointment scheduling.
• Off-site sales.
• User profile storage.
• User wallet storage.
• User account creation and authentication.
• Payment Processing.

Reviews of the account creation and payment processing services found that they appeared resistant to misuse, however, the main application APIs lacked any sort of authorization controls.

Main finding: Lack of authorization at the API layer

During the login process, the client browser receives a bearer token for use against the backend application APIs. Many of the core APIs require a valid token, but do not validate any user permissions, so any user with a valid bearer token can execute an action against any user if the request is properly formatted. CTRT used this to:

• View arbitrary user profile data including phone, email and date of birth.
• Spray email lists to locate valid accounts.
• View arbitrary user wallets including loyalty cards and credit card token values.
• Delete cards from other users’ wallets.
• View appointment confirmation codes in targeted user accounts.
• Steal loyalty cards from a victim wallet and add it to an attacker account.
• Apply discounts from other users’ accounts to execute off-site transactions at no cost.
• Use a credit card token from a victim wallet to make off-site purchases without seeing the victim’s full credit card number.

Client response and activation of CTIR

CTRT kept the client team informed throughout the assessment and briefed stakeholders on key findings. Given the nature of the primary findings, the client chose to activate CTIR to look for signs that the flaw had been exploited against their production web site.

Initial notification

Eventually, the customer requested that CTIR respond to the misuse of APIs after they reviewed CTRT’s findings. CTIR and began supporting the client with an assumed breach of the web application via the client’s incident response retainer.

Detection and analysis

Understanding the vulnerabilities provided CTIR more details and investigative leads. Without the prior CTRT engagement, it would have been difficult to understand the potential scope and identify areas to investigate. Searching for a needle in a haystack proves much easier when you have a strong red team that has critical knowledge of the client’s web application APIs.

Due to the infrastructure of APIs, the investigation did not follow the typical incident response sources of evidence. The most important detail to first understand was the entire infrastructure of the API. The previous penetration test proved to be invaluable again, since a lot of the mapping was done during this engagement. Unlike a web server, API requests will travel through numerous layers to retrieve the necessary information and send it back to the requestor. It is important for CTIR to understand the entire flow of this request since the misuse could be done at any of these layers. Identifying the layers early gives more potential log sources for further investigation before they are potentially overwritten.

APIs typically use token-based authentication to facilitate large amounts of users from various locations and networks. A token may not always be attributed to a single user and, in most cases, the token will expire, giving only a limited scope into what time a breach could have occurred at. The limited logging prevented a thorough forensic analysis of the available logs. However, CTIR identified anomalies and large spikes of activity to establish a timeline of known events.

This gives a clear timeframe to investigate additional sources of data for potential compromise or additional containment measures to ensure no further actions are taken by the adversary.

Two anomalies were observed within the available logs related to API activity: “GetUser” requests and “User does not exist” errors. The “GetUser” request was an indication of an attempt to retrieve details about a user, which is typically limited to administrator-level accounts. A common user would not have the ability to perform this request; but if an attacker attempted this, the logs would indicate the error or denied request.

Additionally, “User does not exist” errors were seen more often than expected. These errors appear when a user attempts to sign in with the wrong user ID or tries to take specific actions. Based on the trends identified and known vulnerabilities, CTIR provided recommendations on how to combat a potential brute-force attempt via externally facing APIs.

MITRE mapping

Gather Victim Identity Information (T1589)

The adversary attempted to collect information about various users through the API. This was attempted via “GetUser” commands and attempting to access the users directly via the API. The API could have led to obtaining further details regarding the user’s personal or financial details.

Brute Force (T1110)

The adversary had numerous attempts to gain access to users. Due to the number of failed attempts, it appears this was done with simple Password Guessing (T1110), but it is possible the adversary used more methodical approaches.

Containment, eradication and recovery

CTIR worked closely with the client to ensure no further actions would be possible. In this case, this meant limited external access to APIs, validating permissions on common users, taking down the affected API when activity was identified, revoking user tokens, and enhanced monitoring of the logs to look for additional signs of compromise. Additionally, the penetration test found other potential security flaws in the API, including a race condition and some outdated web server versions, which we encouraged the customer to update as soon as possible.

This is another great example of how incident response retainers augment an organization’s IR capabilities. A global, agile IR provider who can quickly pivot from offense to defense is key to identifying risks, rapid containment, eradication, and recovery to business as usual to minimize business impact. A web application penetration test was invaluable to this organization to not only identify application weaknesses and identify a possible vector for compromise but to also activate the organization’s incident response plan and quickly engage to mitigate the threat and risk quickly.