Agreed. I read the headline as "... US Airlines' ..." not "... US Airline's ..." and it seemed much more concerning. Instead it's a single airline I've never heard of. Looking them up, they are more established than I might have guessed (started as Casino Express Airlines 38 years ago, but current incarnation is only 4 years old), but also pretty small - roughly 1/100 the staff and 1/50 the fleet of United.
This is about a non-rate-limited endpoint providing ticket data given a booking code only (and not last name as it's usually the case), which makes it feasible to bruteforce the entire search space.
(unfortunately, I feel like AI was overused in authoring the writeup)
>The Avelo team was responsive, professional, and took the findings seriously throughout the disclosure process. They acknowledged the severity, worked quickly to remediate the issues, and maintained clear communication. This is a model example of how organizations should handle security disclosures.
Sounds like no bug bounty?
It's great if OP is happy with the outcome, but it's so infuriating that companies are allowed to leak everyone's data with zero accountability and rely on the kindness of security researchers to do free work to notify them.
I wish there was a law that assigned a dollar value to different types of PII leaks and fined the organization that amount with some percentage going to the whistleblower. So a security researcher could approach a vendor and say, "Hi! I discovered vulnerabilities in your system that would result in a $500k fine for you. For $400k, I'll disclose it to you privately, or you can turn me down and I'll receive $250k from your fines."
> it's so infuriating that companies are allowed to leak everyone's data with zero accountability and rely on the kindness of security researchers to do free work to notify them.
This is a matter for lawmakers and law enforcement. Campaign for it. Nothing will change otherwise
The 6 hour claim is interesting, but I highly doubt Avelo (or any airline) would handle 100k requests/sec
If we consider that the real major's move about 400k-500k passengers/day, let's be really optimistic and say that they check their booking 6 times a day for the week before they fly. That's around 250 requests/sec.
Anyone know about the consumer facing tech stacks at airlines these days? Seems unlikely that they'd have databases that would auto scale 400x...
I doubt their API would handle 100k requests per second. That math was roughly indictive of what the cost to send 100k requests per second would look like. He did mention that that was assuming the target didn't have rate limiting, either intentional or just pure limits of the hardware.
> They were responsive, professional, and took the findings seriously, patching the issues promptly.
The "issue" is that they're returning the entire PNR dataset to the front-end in the first place. He doesn't detail how they fixed it, but there's no reason in the world that this entire dataset should be dumped into Javascript. I got into pretty heated arguments with folks about this at Travelocity and this shit is exactly why I was so adamant.
The lack of needing the last name might have allowed a hacker to brute force the whole list; but it seems that even with a last name, it could expose a lot of PII. Just pass codes along with popular last names (Smith, Jones, Nelson, etc.) and it seems like it could spit out a bunch of reservations.
Do we know what GDS Avelo is using? In other GDSes, is the confirmation code always sufficient to fully identify a booking? I was under the impression that PRLs could be re-used as long as the passenger surname was different.
The space of all possible PRLs is about 2 billion, I can imagine a really big Airline moving that many passengers.
Always consider rate limiting if you deploy a public endpoint. Always require authentication to perform resource-consuming and/or privacy leaking requests.
(Requiring authentication makes rate limiting more practical since even a distributed attacker would need many credentials, which they probably don't have).
> I immediately disclosed this to the Avelo team. They were responsive, professional, and took the findings seriously, patching the issues promptly.
(emphasis my own)
Sorry but I strongly disagree with this phrasing. This is a company "serving over 6 million customers since its 2021 launch" (from Google) that took four weeks to patch an embarrassing security flaw, after being handed all the details on a silver platter.
Imagine a food chain serving a million meals a year was revealed to be storing their food products in unsanitary conditions, and it took them a full month to correct this. That story would make national headlines, not to mention they could get promptly shut down by any competent health ministry.
I think this attitude mostly reveals how complacent we've become about these """incidents""": we just expect this to happen, everywhere and all the time, then we just shrug and say "they fixed it within a month, how responsible of them".
17 comments
[ 164 ms ] story [ 277 ms ] threadhttps://en.wikipedia.org/wiki/Avelo_Airlines
(unfortunately, I feel like AI was overused in authoring the writeup)
Sounds like no bug bounty?
It's great if OP is happy with the outcome, but it's so infuriating that companies are allowed to leak everyone's data with zero accountability and rely on the kindness of security researchers to do free work to notify them.
I wish there was a law that assigned a dollar value to different types of PII leaks and fined the organization that amount with some percentage going to the whistleblower. So a security researcher could approach a vendor and say, "Hi! I discovered vulnerabilities in your system that would result in a $500k fine for you. For $400k, I'll disclose it to you privately, or you can turn me down and I'll receive $250k from your fines."
This is a matter for lawmakers and law enforcement. Campaign for it. Nothing will change otherwise
If we consider that the real major's move about 400k-500k passengers/day, let's be really optimistic and say that they check their booking 6 times a day for the week before they fly. That's around 250 requests/sec.
Anyone know about the consumer facing tech stacks at airlines these days? Seems unlikely that they'd have databases that would auto scale 400x...
I think more likely the API would be behind some kind of bot protection that would shut this down before any kind of technical rate limit is reached.
The "issue" is that they're returning the entire PNR dataset to the front-end in the first place. He doesn't detail how they fixed it, but there's no reason in the world that this entire dataset should be dumped into Javascript. I got into pretty heated arguments with folks about this at Travelocity and this shit is exactly why I was so adamant.
The space of all possible PRLs is about 2 billion, I can imagine a really big Airline moving that many passengers.
https://bsky.app/profile/jjindc.bsky.social/search?q=avelo
(emphasis my own)
Sorry but I strongly disagree with this phrasing. This is a company "serving over 6 million customers since its 2021 launch" (from Google) that took four weeks to patch an embarrassing security flaw, after being handed all the details on a silver platter.
Imagine a food chain serving a million meals a year was revealed to be storing their food products in unsanitary conditions, and it took them a full month to correct this. That story would make national headlines, not to mention they could get promptly shut down by any competent health ministry.
I think this attitude mostly reveals how complacent we've become about these """incidents""": we just expect this to happen, everywhere and all the time, then we just shrug and say "they fixed it within a month, how responsible of them".