Glastonbury ticket hijack vulnerability fixed

The Glastonbury ticket website was vulnerable to a relatively simple attack that that allowed ticket theft and data leakage.

What’s the issue?

An attacker could scrape collaborative ticket buying information (e.g. on Reddit) to gather people’s details, use a flaw in the registration process and session token handling, and take complete control of multiple ticket delivery addresses, as well as other details. This would allow the tickets to be diverted to the attackers address. Buyers’ personal information would also be exposed.

The vulnerability existed because of poor session token handling. The session token used to check authorisation on the glastonbury.seetickets.com/registration/editdetails endpoint is the same one assigned to a user when authenticating against the contact us form.

This skips the need for email access for the unique link to edit details on the registration page. Many users form groups on sharing sites such as Reddit (e.g. https://www.reddit.com/r/glastonbury_festival/comments/170dkct/spreadsheet/). These shared spreadsheets contain users regnumber:postcode combination, so everyone in a group can access PII, edit profiles, and redirect any user’s tickets where they have the reg:postcode.

SeeTickets, the service provider, were responsive to our report and fixed the bug quickly.

How does the attack work?

Using cURL the following fairly simple attack steps are taken.

Step 1.
Attacker retrieves large number of registrationnumber:postcode combinations from public spreadsheets used on social media

Step 2.
Attacker uses the following request to submit the registrationnumber :postcode to the “https://glastonbury.seetickets.com/gfl/registration/contactus/login” endpoint with the following request:

$ curl -s -v "https://glastonbury.seetickets.com/gfl/registration/contactus/login"
-X POST -d "RegistrationNumber=XXXXXXXXX&Postcode=XXXXX"

…where the example X’s replace the valid registration number and postcode.

Step 3.
Attacker grabs the HTTP header response, which contains the “IkTmgflrEi72NixCIcjzA” cookie value which is used for session management.

< HTTP/1.1 302 Found
< Location: /gfl/registration/contactus
< Pragma: no-cache
< Transfer-Encoding: chunked
< Set-Cookie: IkTmgflrEi72NixCIcjzA=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX; path=/; secure; samesite=none; httponly

The Xs are the token value. This is the same value as sent in the email link to users wanting to sign in to edit their registration. The link used to edit and access user details requires a user to access this exclusively from their assigned email account as seen below (Example email link sent to users when requesting permission to edit their registration form and user details):

https://glastonbury.seetickets.com/gfl/registration/edit?editId=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

…where the Xs are the same value as the “IkTmgflrEi72NixCIcjzA” session cookie value assigned from querying the /contactus/login endpoint, with only a registration number and postcode.

Step 4.
Attacker then loads that cookie value, and visits the https://glastonbury.seetickets.com/gfl/registration/editdetails page, where they now have complete control over a user’s ticket delivery address, and PII (including full address, name, phone number, and email).

It’s important to note that Glastonbury operates a strict identity verification process when purchasing and using tickets. It helps prevent ticket scalping, where people resell tickets at inflated prices.

Caveats

This attack requires specific conditions and a valid registrationnumber:postcode combination.

It appears that users weren’t aware of the risks from sharing registrationnumber:postcode information publicly. If they understood that it could have led to their registration being compromised and purchased tickets being redirected, I’m guessing it would have been less of an issue.

Conclusion

Following good interactions with SeeTickets the issue was resolved quickly. Key to all this is that they have a security.txt file which shows who to contact. This is always a good sign.

The most important thing here is that they have a well thought out and explained vulnerability disclosure program.