Amadeus! Amadeus! Pwn me Amadeus! Airline check-in bug may have exposed all y'all boarding passes to spies A now-patched vulnerability in the Amadeus flight reservation system – used by airlines around the planet – could, or may, have been exploited by miscreants to view strangers' boarding passes. David Stubley, CEO at UK security consultancy 7 Elements, told us last night he discovered the privacy-busting flaw, which was present …
I recall The Reg reporting a few years ago that some domain registrar (123-reg I think?) had an admin portal where the domain name you were changing DNS records for was part of the URL so you could essentially hijack anyone's domain as long as it had been registered through them.
Then there was some telecoms company that passed the billing amount in the URL(!) so you could pay whatever you wanted.
One obvious issue here is using sequential or auto incrementing ID's as that almost guarantees you'd be able to "guess" one that's valid. At least some others use randomised tokens which are harder to pre-determine, or require you to enter some other known detail like your surname to validate it.
Mind boggling that companies of this scale can't avoid such basic blunders. Then again, they probably employed some over paid UX consultant who said something like "but our customers don't want to login or enter information, we want to make this as easy as possible for them". D'oh.
This is meant as an explanation rather than a defence.
Where I have seen this happen is with legacy (or largely legacy) apps that get a web front end. Usually this is deployed internally and everyone is happy and nothing bad happens. At some point, someone decides to run it either on an Internet facing server or via a proxy (for security...while proxies can provide security, they don't cure all ills...) and you now have a vulnerable application.
If no one notices for a few years (automated tests are unlikely to pick it up unless their is a public flaw, legacy app people are likely to rely on the vendor web framework rather than digging into details themselves) then they can drift on for some time.
Auto-incrementing IDs are not the problem. Obfuscating that is just security through obscurity.
It doesn't matter whether you can guess the ID or not because there's access controls beyond that. If you're trying to access data for an ID that doesn't match the one you're logged in with, it gets rejected (unless you're logged in with superuser rights). Or at least that's how it is on any system that I'm involved in building.
"doesn't match the one you're logged in with"
That's the problem though - the end-user (airline customers) cannot be logged in, in this case. When you make a booking with, for example Air France, your booking and account is with them. You might have logged in to the Air France website ... but you don't have an "account" on Amadeus that would require you to login. Air France have passed the data to Amadeus, but this problem is when sending data the other way.
Where I've seen this is API's that require something basic to be passed (like an order or booking ID) and they return the data. They were intended to work in conjunction with the booking systems, e.g. Air France's website, but not be exposed to the public.
I posted before saying some will require certain information to be entered by the user to validate it, but it's not always the case that the application the API interfaces with will ask for that information, which is why it probably worked in this way to begin with. It's trivial to see HTTP requests in a browser, but I don't think the people who implement these systems assume people will do.
Couple of years ago a vulnerability was found on the website of the City of Johannesburg where you were able to view utility bills from CoJ residents simply by manipulating the URL. IIRC it was also an unique identifier coupled to the person/bill/property.
The person who found the vuln tried to contact the CoJ, but nobody was interested, So, he went public.
Lots of people logged in to try out the vulnerability :)
One guy even wrote a script to download thousands of bills.
A lot of noise was generated from the direction of CoJ officials, including the threat of jailtime or a steep fine, but nothing came from that. They shut the website down for a couple of days to get it fixed.
A lot of fuss and a nice mess.
In contrast, one South African ISP also got a vuln on their website, when notified about that, they thanked the informer and fixed their website. No fuss, no mess.
If its only boarding passes and not PNR's then it was tough to exploit usefully. Its also not clear if it includes more sensitive PII like passport no.
Assuming you did a bulk download and found boarding passes for flights local to you, or your henchpeople.
Then either you need a local flight that doesnt check for ID or some fake ID to go with it.
Either way in most cases it doesn't seem worth while to do it....
This post has been deleted by its author
That is de-rigeur at all airports I've used recently in Europe.
For outbound passengers they don't care too much, as long as you're not going to pose a danger to the flight (hence bag checks looking for explosives). It's the airline's responsibility to make sure you are who you say you are and that you have the right of entry at the destination.
For inbound passengers, they do care who you are. That's why there's immigration (passport control)
In summary: anyone can leave, but only those we know can come in.
Heathrow is not better, it seems:
Boy slips through Heathrow security to board British Airways flight to Los Angeles
where you just scan your boarding pass just before security checks
This is very common, especially for pax that fly without checked luggage.
That scan is just for the purposes a total head count and for a record showing that a pax is about to pass through security and will be entered a secure area. This also allows the airline to know if the pax has started to go through the security checks, or if the pax is going to be a "no-show".
The actual pax "identity verification" often occurs only at the boarding gate where the pax's passport/ID is checked against the name on the boarding pass.
And having had first hand experience with their backend code and the way its written this comes as a complete non-shock. Layers upon layers of framework cruft that no one person can understand and management are too scared to order a rewrite because of incomplete documention. When a new features was required it was simply slapped on top or shoehorned in sideways to the current codebase.
A/C for obvious reasons.
That's because your queries are unbounded by the user executing them.
If you have even a resemblance of proper security, Customer A - no matter what they query of the database, could only ever have access enough to query records of Customer A and nobody else. Changing the magic number would just error.
However, I bet what happens is that Customer A authenticates to the web session. That plants a cookie that lets them query bookings. Then the script that actually returns a boarding pass is executed as a database user with at minimum read rights to the *entire* database of boarding passes.
And I bet their "fix" is to just check inside that script that Customer A is asking for Customer A's boarding pass. *NOT* a proper row-level security that stops them even being *able* to see anyone else's information, no matter what script, portal, compromise or whatever other action is performed by that authenticated user.
We really just don't do security properly *anywhere*.
And if you say "That's an expensive operation"? Then that is why the database query for that shouldn't be direct against the main database with *everyone's* data but to an intermediary server. That is literally programmed as the only thing with full database access. And which refuses - point blank refuses - to return anything other than a rowset filtered to the authenticated user. Then the database is just being polled from (and therefore only needs to be accessed by) one machine and can cache the full results, but the intermediary (which is only allowed to talk to the web machines and the main database) is literally just doing nothing but filtering all results to those that the user that it's being accessed as should see.
Changing an ID in a URL is a classic security mistake. Not because of missing a line of code that should be checking. Because it's indicative of a complete design catastrophe in terms of security.
Least privilege principle. The web servers get nothing. The user authenticates to the web server. The web server passes on that authentication to the query server. The query server checks the authentication and queries the database. Now the database may well contain other people's results (if the query is particularly fecking awful!). But then the query server removes anything that the user doesn't have row-level permissions to see, returns that to the web server, who returns that to the user.
The web server has no access to the database.
The web server has no access to the authentication database.
The authentication server has no access to the web server or the database.
The database has no access to the web server.
The "query" server acts as a blind intermediary. If you request the wrong details, the authentication fails for the rows you are after and the query server baulks. If the query used is changed and accidentally returns an off-by-one record, or the entire database, the query server baulks or filters to only that stuff that you should be able to see anyway. If the web server is hacked entirely, it gets no access to the database except what it can see of live, running queries for limited users (and thus compromises only *their* account information at worst, not the entire database).
And then you go full, proper "I am a commercial enterprise with millions of pounds of business" and you put a firewall, a reverse proxy, an IDS and layers of VLANs over the whole thing to stop that happening anyway.
And you can literally keep your entire customer database, on one huge system, locked away from everyone, with one cable coming out, going to one computer / rack / whatever, which is the *only* way to query the database unless you're literally standing in that room with administrator privileges. One path to audit. One path to log. One path to monitor.
This doesn't take a genius. But if I'm able to just change an ID in a web query, that means the web servers are running scripts that are querying the main database directly, and returning whatever dross it pumps their way, and then pushing that straight to the user's screen *without* at any point bothering to check they own it, or in any way limiting one user's access to another user's information. An "if real_user == intended_user" at that point is *NOT* security.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
