Delta Airlines flaw lets others access your boarding pass

library
crime | hacking | security

Have you travelled on planes in recent years?

If so, I’m sure you’ve had your fair share of security seriousness at airports.

One of the strictest, and perhaps the most peculiar, exchanges I’ve overheard went something like this:

And as for finding out whether your mother-in-law managed to board her connecting flight in Singapore, having been worried about getting lost in Changi airport?

Forget it.

Actually, unlike the dentifrice disaster story above, the lockdown of passenger lists is a good thing.

The privacy of passengers should be strongly protected, so no complaints there.

Delta disappointment

So, what a disappointment to read that Delta, and apparently other US airlines, didn’t seem to see it that way.

Hackers of NY denizen Dani Grant found that out last week when she received a URL from Delta that led to her boarding pass.

(She didn’t say in her post but it looks from the screenshots like a non-HTTPS URL; that’s a concern for another time.)

The SNAFU was just like last week’s flaw at AliExpress, the online retail portal of Chinese e-commerce megabrand Alibaba.

By changing characters in a parameter in a URL, AliExpress users could retrieve the home address and phone number of other users.

At least in the AliExpress case, you had to login as someone first, before accessing the data of anyone.

In Dani Grant’s case, arbitrarily changing even a single character in her URL brought up other people’s travel plans, without any authentication stage at all.

A bit more URL fiddling, and she had a boarding card for a third passenger on a different airline:

The cybercrime angle

We’ll ignore that this makes a mockery of the security precautions at many airports.

Let’s look at why this is a problem in general terms, by forgetting the in-flight safety angle for a moment, and considering the cybercrime side of things.

Both the Delta Airlines and the Alibaba URL vulnerabilities play right into the hands of online scammers and social engineers.

In many, if not most, online scams, the crooks don’t need to know that you are flying to Florida this evening, arriving at 19:45.

They just need to know that somebody is going to be on that plane, or some other plane, to be able to tweak their criminality to target that person.

And if they can automate the process of recovering that sort of information by simply scraping URLs until they get lucky, they can attack even more broadly.

How to tell?

Of course, this raises the question, “As a consumer, how can you tell if a website is guilty of this sort of data leakage carelessness?”

Sometimes, you’d be wise to assume there’s a problem, for example if the confidentiality of a web page relies on some text in the URL, but the text looks far from random:

But even then, proving there really is a vulnerability is tricky, because:

You might get close by trying nearby strings (e.g. id=32767, id=32768), but not close enough to hit paydirt. (Maybe you needed to try id=42766 instead?)
You might actually hit paydirt, and then what? (Whom do you tell? What if you just broke your country’s equivalent of the Computer Misuse Act?)

What to do?

“Having a go” at URLs to see what you can find is not a good idea, and we don’t recommend it.

Even if your motivation is pure, you could end up in trouble if you don’t have explicit permission.

A court might form the opinion that you knew jolly well you were going after data that wasn’t yours, and find you at fault.

All we can recommend is that if you do encounter what you consider to be security through obscurity, report it and ask what the company concerned has to say about it.

Dani Grant did just that in the case above; Delta, bless their hearts, replied to her, and didn’t try to brush it under the carpet, either:

[We] certainly understand how insecure you must have felt due to the unpleasant incident you experienced while trying to view and print [your] boarding pass from our website.

That’s not as good as a clear statement that the problem is being fixed, and how solidly, but it’s a good start, not least because it explicitly admits the flaw as an insecurity.

By the way, if your company deploys “secret” URLs for any purpose, whether customer facing or internal, why not review how they are generated, distributed and used?