Recent reports of United Airlines’ mobile applications vulnerability were reminiscent of the famous magicians’ trick of focusing attention to one hand while quickly putting a rabbit in place with the other. It seemed that everyone was focusing on the mobile application, while in reality the vulnerability lays within the web application server.
In fact, that server could be exploited without using the mobile application at all. So before explaining the vulnerability and its effects, here’s the bottom line: most (if not all) of the recent reports about vulnerable mobile applications actually disclose a vulnerability in the application server.
A vulnerability could be exploited using a simple tool like a web browser. Most of these vulnerabilities are trivial to avoid and mitigate using the same tools that are used for mitigating any web application vulnerabilities and attacks (i.e. web application firewalls).
>See also: United Airlines in meltdown as IT glitch leaves ALL flights grounded
The abundance of these vulnerabilities in correlation with mobile applications is no coincidence and stems from two sources: the misconception of programmers that the exposed server functionality can only be accessed through a mobile application; and strong faith in security by obscurity (understanding how the mobile application interacts with the server is too much of an effort for attackers).
So without further ado, here’s the story of the United Airlines mobile application.
The United Airlines mobile application includes a mobile check-in function. As part of the mobile check-in, a user can provide a MilagePlus number and see account information that includes personal details.
It is easy for anyone with some networking skills to install a network monitor or an interactive proxy (such as Burp) and inspect the communications between the mobile application and the application server. These communications rely (as expected) on the HTTP protocol and use a dedicated web API.
The API relies only on the “ActivateInput” parameter, which is the MileagePlus number, entered by the user. This number consists of two letters followed by six digits, for example “AB123456”.
By comparison, the same functionality when provided through the standard United Airlines website requires that a PIN code or a password be supplied in conjunction with the MileagePlus number.
This minute difference stems, as mentioned above, from a strong faith in security by obscurity and a failure to understand the nature of mobile-device-to-server communications.
All in all, the structure of the MileagePlus number provides for 676,000,000 possible numbers. Given that the personal details are only available 24 hours before a flight, it seems like a difficult attack to pull off.
>See also: What the NYSE, United Airlines and WSJ glitches show us about mitigating the cost of downtime
However, using the same traffic inspection technique, it became evident (this issue has already been fixed) that valid numbers can be distinguished from invalid ones at any point in time.
Therefore, an attacker can first enumerate all active members – and thus reduce the list to one tenth of its original size – and then start pounding the API in 24-hour cycles, removing any successful hit.
Valid MileagePlus number error: “We’re unable to complete the check-in process”
Invalid MileagePlus number error: “No reservation has been found”
This is yet another example of the programmer misconceptions mentioned above. The web API has no brute force prevention controls in place. So while this attack requires some patience in order to avoid becoming a DDoS attack, it is perfectly feasible.
Sourced from Amichai Shulman, CTO, Imperva
