6 ms·

I feel like this buries the lede massively: Qantas' system was run by Amadeus, who also run the booking system for some 200 other airlines [0]. If you could do

I feel like this buries the lede massively: Qantas' system was run by Amadeus, who also run the booking system for some 200 other airlines [0]. If you could do this with Qantas and get all those notes, you could probably do it to any other airline and get them too. That would be bad enough, but it also appears that this issue (or one very much like it) has been reported widely at least back in early 2019. So, either Amadeus didn't fix the issue until it was disclosed here (very very bad) or Qantas didn't update their booking system for a security patch (also very bad). [0] https://techcrunch.com/2019/01/15/amadeus-airline-booking-vulnerability-passenger-records/ https://techcrunch.com/2019/01/15/amadeus-airline-booking-vu...

robjan 6y ago
The issue isn't Amadeus, it's that some airlines don't bother to use accounts with lower levels of privileges for operations which don't need full access. There are a number of different levels which are intended to be used for different purposes: for example, the credit card numbers are not visible to booking agents but can be accessed by the anti fraud department. Some airlines just use a single "god mode" account for their whole e-commerce platform because it's cheaper / more convenient for their developers / vendors.
- saberdancer 6y ago
  Could you explain how returning all data to the frontend is connected with "god mode" usage? Is the Amadeus system such that it created/masks different fields in the data depending on the access level you have? In this case, "hacker" logged in a customer facing portal, this is probably not even an user account in the strict sense of the word. I am asking as I fail to see how it is not a development issue. If they returned only the data that was needed on the page, it wouldn't expose internal comments or passport IDs.
  - robjan 6y ago
    There are of course two errors that the developer of the backend made. The first is not filtering what came back from the Amadeus API, but the second one - the one I am referring to - is using an Amadeus API key with too much access. Amadeus filters the booking record depending on the level of access that the user accessing it has (the user being the backend in this case). In a previous life for another airline, I have experienced this problem before when a vendor tried to get something through to production which was retuning credit card numbers and expiry dates to the frontend (but not the CV3). This was all because the vendor tried to use the highest privilege API key rather than the one with access to the specific info they needed. It never got past UAT thanks to thorough security review in this case.
    - underwater 6y ago
      The API key shouldn't change what type of data an API call returns. The developer should explicitly request data and that either succeeds or fails based on authorisation. Making assumptions about the use case from the key will of course lead to this kind of error.
      - robjan 6y ago
        The PNR (passenger name record) is the data record which represents your booking on Amadeus. It's basically a semi-structured flat text file. Each line is an entry which may represent a leg of your journey, your name, the payment method used to make the booking or various remarks (which themselves are arbitrarily structured). These lines are filtered / redacted depending on your role. You have to remember that this is a legacy system which has remained pretty much unchanged for 40-50 years. It's hard to change because hundreds of airlines have their own legacy systems which rely on bookings being structured this way. And when you book a multi-carrier itinerary, the airlines often all access this same record directly on Amadeus. There has been some movement in recent years in a platform called NDC[0] (new distribution capability) but most airlines still rely on the PNR at the moment. [0]: https://www.iata.org/en/programs/airline-distribution/ndc/ https://www.iata.org/en/programs/airline-distribution/ndc/
      - pathseeker 6y ago
        This is pretty standard when fetching entire complex objects from many backends. You get the full object with all of the fields the authorization layer allows you to see. Something like "GET /reservation/<id>" would rarely require you to specified the 50 fields that you would like included in the response. Many offer fields to explicitly filter for specific things, but the default is almost always to return the full object as much as the caller is allowed to see.
        Aeolun 6y ago
        You shouldn’t arbitrarily include or exclude information. The response to a given input should always be the same output, and not depend on what API key you are calling with.
bostik 6y ago
The underlying issues have been known for quite a while. There was a fantastic talk in CCC at 2016 about the airline booking systems and the various bits of information you can glean from them.[0] 0: https://media.ccc.de/v/33c3-7964-where_in_the_world_is_carmen_sandiego https://media.ccc.de/v/33c3-7964-where_in_the_world_is_carme...
- namdnay 6y ago
  The underlying issue is that PNR+Last Name has always been the "secuirty" to access a booking, and no airline or travel agency wants to enforce stronger measures unilaterally, for fear of increasing friction for their customers
- bonzini 6y ago
  There was another great talk by a (former?) ITAsoftware engineer, unfortunately I can't find it. Among various things he shares is that there's provision for the passenger being a child at arrival but not on departure. Which obviously can happen if you cross the date line backwards. It would be great if anyone can find it, I am certain I got it from HN.

robjan 6y ago

The issue isn't Amadeus, it's that some airlines don't bother to use accounts with lower levels of privileges for operations which don't need full access. There are a number of different levels which are intended to be used for different purposes: for example, the credit card numbers are not visible to booking agents but can be accessed by the anti fraud department. Some airlines just use a single "god mode" account for their whole e-commerce platform because it's cheaper / more convenient for their developers / vendors.

saberdancer 6y ago
Could you explain how returning all data to the frontend is connected with "god mode" usage? Is the Amadeus system such that it created/masks different fields in the data depending on the access level you have? In this case, "hacker" logged in a customer facing portal, this is probably not even an user account in the strict sense of the word. I am asking as I fail to see how it is not a development issue. If they returned only the data that was needed on the page, it wouldn't expose internal comments or passport IDs.
- robjan 6y ago
  There are of course two errors that the developer of the backend made. The first is not filtering what came back from the Amadeus API, but the second one - the one I am referring to - is using an Amadeus API key with too much access. Amadeus filters the booking record depending on the level of access that the user accessing it has (the user being the backend in this case). In a previous life for another airline, I have experienced this problem before when a vendor tried to get something through to production which was retuning credit card numbers and expiry dates to the frontend (but not the CV3). This was all because the vendor tried to use the highest privilege API key rather than the one with access to the specific info they needed. It never got past UAT thanks to thorough security review in this case.
  - underwater 6y ago
    The API key shouldn't change what type of data an API call returns. The developer should explicitly request data and that either succeeds or fails based on authorisation. Making assumptions about the use case from the key will of course lead to this kind of error.
    - robjan 6y ago
      The PNR (passenger name record) is the data record which represents your booking on Amadeus. It's basically a semi-structured flat text file. Each line is an entry which may represent a leg of your journey, your name, the payment method used to make the booking or various remarks (which themselves are arbitrarily structured). These lines are filtered / redacted depending on your role. You have to remember that this is a legacy system which has remained pretty much unchanged for 40-50 years. It's hard to change because hundreds of airlines have their own legacy systems which rely on bookings being structured this way. And when you book a multi-carrier itinerary, the airlines often all access this same record directly on Amadeus. There has been some movement in recent years in a platform called NDC[0] (new distribution capability) but most airlines still rely on the PNR at the moment. [0]: https://www.iata.org/en/programs/airline-distribution/ndc/ https://www.iata.org/en/programs/airline-distribution/ndc/
    - pathseeker 6y ago
      This is pretty standard when fetching entire complex objects from many backends. You get the full object with all of the fields the authorization layer allows you to see. Something like "GET /reservation/<id>" would rarely require you to specified the 50 fields that you would like included in the response. Many offer fields to explicitly filter for specific things, but the default is almost always to return the full object as much as the caller is allowed to see.
      - Aeolun 6y ago
        You shouldn’t arbitrarily include or exclude information. The response to a given input should always be the same output, and not depend on what API key you are calling with.

bostik 6y ago

The underlying issues have been known for quite a while. There was a fantastic talk in CCC at 2016 about the airline booking systems and the various bits of information you can glean from them.[0] 0: https://media.ccc.de/v/33c3-7964-where_in_the_world_is_carmen_sandiego https://media.ccc.de/v/33c3-7964-where_in_the_world_is_carme...

namdnay 6y ago
The underlying issue is that PNR+Last Name has always been the "secuirty" to access a booking, and no airline or travel agency wants to enforce stronger measures unilaterally, for fear of increasing friction for their customers
bonzini 6y ago
There was another great talk by a (former?) ITAsoftware engineer, unfortunately I can't find it. Among various things he shares is that there's provision for the passenger being a child at arrival but not on departure. Which obviously can happen if you cross the date line backwards. It would be great if anyone can find it, I am certain I got it from HN.