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 websites (e.g. 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 hackers address. The personal information of legitimate buyers 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 users’ tickets where they have the reg:postcode.

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

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, 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

While this attack does require fairly specific conditions with prior knowledge of a registrationnumber:postcode combination, these appear to be shared around the Glastonbury community freely from the creation and common use of community / public spreadsheets.

While this attack does require fairly specific conditions with prior knowledge of a regnumber:postcode combination, these appear to be shared around the Glastonbury community freely from the inclusion of community / public spreadsheets. It doesn't appear users may be aware of the dangers of posting this publicly as it can lead to their whole registration being compromised and potentially purchased tickets being redirected.

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.

The post Glastonbury ticket hijack vulnerability fixed first appeared on Pen Test Partners.