This is a fine example of developers being lazy and how not to implement "security".
National Express are one of the biggest public transport companies in the UK with a huge fleet of coaches and trains.
This has been patched.
Another one of there @ replies suggests they did reply to my e-mails within 24 hours, but nothing was received.
This vulnerability discloses customers information to a potential attacker such as the passengers names, destination, last 4 digits of the card, price the customer paid for the tickets and of course the ticket itself.
An attacker could potentially disrupt customers journeys by amending or even cancelling bookings using the online Manage Booking service, which is accessed by entering a ticket number and the last 4 digits of the card. If one was to be malicious you would write a program that constantly checks for new tickets and then automatically changes the destination, for example.
If may also be possible to plot customers on a map who are currently on a National Express coach by integrating with the Live Coach Tracker.
After you purchase an e-ticket (print-at-home) you are sent to the "print ticket" page:
Let's break down the URL:
ticketnumber seems to be a sequential 8-character-long alphanumeric. The first 6 characters are A-Z and the last two are 0-9 - a few examples:
FFCBCH73 FFCYMG19 FFCYCG44
Now for the
printkey. Just by looking at the value it looks like half-MD5. The first thing I tried was to MD5 the ticket number which gives:
1c6e488449e3741a999388f7bd7d07ae. Errr what... could it be?! Yep, the last 16 characters is our
printkey - fantastic security.
One could write a simple program that generates a bunch of ticket numbers and print keys, hit the endpoint and parse out the HTML. As there is no rate-control an attacker could easily pull out 1000s of tickets within minutes.
There is no excuse here, it's pure lazyiness. Ideally you would generate a random string (e.g. uuid) and store this along with the ticket number but that requires database schema changes and may not be easy/quick to implement depending on their infrastructure. A simple "quick fix" solution would be to use HMAC-SHA256 to hash the ticket number with a private key. Any old URLs with an MD5 print key can be redirected to the "Manage Booking" page so the user has to explicitly authenticate themselves.
I attempted to contact National Express via their website on three occasions over three months with no response. Hopefully this blog post grabs their attention and forces them to patch the vulnerability and protect their customers.
- Jul '14 - Attempted initial contact with vendor - no response.
- Aug '14 - 2nd attempt to contact vendor - no response.
- 13th Sep '14 - Final attempt to contact vendor - no response.
- 25th Sep '14 - Full disclosure.