Unlimited airline miles courtesy of Points.com’s insecure APIs

In a blog post on his website, Sam Curry along with two other bug bounty hunters, Ian Carrol and Shabham Shah, explain how they identified several vulnerabilities in APIs at points.com, a reward program service provider for multiple large airlines and international hospitality brands. The vulnerabilities were reported to the responsible engineering team and have since been patched.

There were a number of vulnerabilities related to APIs that allowed disclosure of customer PII and unauthorized transfer of reward points from a victim account to another account. Effectively exploited, attackers could have used these vulnerabilities to grant themselves unlimited airmiles and hotel reward points.

Reaching internal API through directory traversal lead to customer PII

A directory traversal vulnerability on an external API let the security researchers reach and use a Points.com internal API that could query over 22 million customer records.

One of the two parameters of the external API was vulnerable to directory traversal and was able to access the internal API with the payload “../../v1/search/orders/?”. The second parameter was used to pass additional parameters to the internal API targeted by the directory traversal vulnerability.

The disclosed customer records contained:

• Full names
• Payment information (credit card numbers, costs etc.)
• Personal information (physical address, phone numbers etc.)
• User information (member ID, balance etc.)
• Flight booking details

This vulnerability was Points.com-wide, meaning it affected the vast majority of Points.com customers. 

Improper authorization on API endpoint led to account takeover and mile transfer

An API endpoint allowing someone to “buy miles for someone else'', was improperly configured. After submitting the last name of that “someone else” and their rewards number, the endpoint leaked the access token of the target in the response, allowing the attacker to use it and authenticate as them.

The attacker could then read the victim’s PII, such as billing address, phone number, email, redacted credit card information, and billing history, as well as transfer miles on the target’s behalf.

Exposed credentials lead to Virgin Atlantic account takeover

A Virgin-owned subdomain was exposing a PHP file that contained points.com API credentials for testing purposes. These credentials gave full administrative access to the Virgin Atlantic account on Points.com, allowing an attacker to transfer reward points, access customer accounts and PII, as well as modify tenant information of the Virgin reward program.

Inconsistent authentication methods allowed attackers to authenticate as any user

The researchers discovered multiple United Airlines login pages. Each of them required different parameters and each of them returned information of different sensitivity, depending on the parameters provided. There were login pages that required:

• Username:Password
• United MileagePlus number:Password
• MileagePlus number:last name

The researchers discovered that each login page returned an access token that could be used in the rest of the pages as well. This means that only by knowing the MileagePlus number and the last name of a victim, an attacker could access the account of the victim where username and password credentials were required. This led to PII disclosure and unauthorized miles transfer from one account to another.

Weak session cookie secret led to unauthorized access to the points.com administrative panel

The console.points.com host was using a Flask session cookie that was signed with a weak secret, namely “secret”. By unsigning the cookie, modifying its content so that it belongs to an admin user, and then re-signing it with the same secret it resulted in the researchers gaining full access to the points.com administration console and loyalty platform.

Assessment

The directory traversal vulnerability is clearly part of the OWASP API Top 10, namely OWASP API10:2023 Unsafe Consumption of APIs. The API endpoint did not properly sanitize data provided by the end user. Special characters and character sequences that lead to certain vulnerabilities (such as “../”) should have been properly identified and handled.

In the case of the improper authorization issue, APIs should provide the minimum amount of necessary information back to the response. Even if the front-end of the website is filtering this information, malicious users can always see what is happening behind the scenes. This is a very common case of OWASP API3:2023 - Broken Object Property Level Authorization, specifically an issue of “Excessive Data Exposure”.

In the case of the exposed Virgin Atlantic API credentials, sensitive files and endpoints are covered by OWASP API8:2023 Security Misconfiguration. Even if the PHP should exist, it certainly shouldn’t contain any sensitive information that can be used by malicious actors against the organization or its users.

The inconsistent authentication methods finding is the only finding in this writeup that isn’t of a technical nature. The flaw here is in the logic behind the development team and the fact that they didn’t consider the possibility of access token misuse from end users. This vulnerability isn’t strictly part of the OWASP API Top 10 but it could be categorized as OWASP API8:2023 Security Misconfiguration.

Although the last vulnerability isn’t API-related, an analogy can be drawn. APIs often make use of JSON Web Tokens (JWT), which are signed with a secret chosen by the developer and used as an authorization method. An admin can access all administrative actions with their JWT, whereas a low-level user can only access certain actions, based on their JWT. So, similarly to a JWT, the Flask session cookie works as a user session identifier. Hence, it should be signed with a strong, non-predictable secret that cannot be cracked by attackers.

How can FireTail help?

FireTail provides an end-to-end API security platform that can help security teams to identify and remediate vulnerabilities like those outlined above. Here’s how:

• Discovery and proactive assessment of APIs and associated security risks from API misconfigurations and coding vulnerabilities
• In-line, real-time inspection of API calls at app layer
• Preventative controls to block malicious API calls
• Centralized audit with application-layer visibility
• Detection & Response (D&R) built on both app and network logs

References

• https://samcurry.net/points-com/

‍