Stealing User Data from a Hotel Housing Portal + Abusing Tokens to Shut Down Portal Functionality

Background Info

CVENT is an event management software company

Gencon is an annual Board Gaming Convention in Indianapolis Indiana

Q-Rooms is an event management services provider

What was discovered (the tldr)

Gencon utilizes Q-Rooms to provide access to Cvent’s software, PassKey

PassKey is a hotel room booking solution For example, large conferences that occupy several hotels might use PassKey to centralize the booking experience for the end-user

An insecure method of generating random authentication tokens is utilized that can be combined with how forms are auto-populated to collect PII on users.

A secondary flaw was discovered that allows for token re-use and can be combined with lack of identity verification to render the portal useless.

Gencon’s configuration

For a user to purchase a badge for Gencon, they must create an account. This purchase action requires the user to provide billing information, such as full name, address, e-mail, and phone number. This Gencon account is also how the user gains access to the hotel housing portal, as shown here:

When clicking the “Go to Housing Portal” Link as shown in the above image, the user will arrive at the following page, operated by Q-Rooms and running Cvent’s PassKey software.

From this point, the user would proceed with attempting to book any available room, selecting desired dates, hotels, room, etc. After selecting desired hotel room, the user has two additional forms to complete, an information update page and a payment page. The information page is involved in this first vulnerability. This is how the information page would be presented to the end-user with fields indicated pre-populated with data noted.

The Security Weakness

As noted in the first and second images, each user is assigned a token that allows access to the housing portal. The user does NOT need to go through Gencon’s site to first access the housing portal itself, rather they simply need that token value.

Further – by analyzing several tokens, it became apparent that, while they were 12 characters in length, they weren’t fully random. Lets look at the 3 sections of the example token “32ZXABCG-56EF“:

32Z – This appears consistent across the various tokens observed

– This appears consistent across the various tokens observed X – This appears to be an increment counter, mostly C’s and D’s in tokens observed

– This appears to be an increment counter, mostly C’s and D’s in tokens observed ABCG-56EF – Randomized Token

This means that the randomized token is only 8 characters in length with a 36 character dictionary, using 0-9 and A-Z. Such a short randomized token leaves brute-forcing as a viable option.

When attempting to access the housing portal using an invalid token, a consistent error message will be generated, as noted here:

Combining all the above information, it become clear all potential housing token forms could be brute-forced, especially as the booking system does not appear to have a rate limiting mechanism in place. The following is some quick-and-dirty code to generate URLs with token fields, with the error message on invalid tokens serving as “discard this token” indicator.

This assembles the tokens to use and passes them child script that does the testing

This is the child script that attempts to reach the target page, tests if the token is valid, and when a correct token is found will output the value to a text file.



Combining this script with the pre-populated data in the user information update fields when booking a hotel rooms means one could feasibly collect PII for those that had not yet booked hotel rooms without having to first authenticate to any system.

The Brute-Force Result

It was not appropriate to allow the brute-force to run until it successfully turned back valid tokens. This would constitute DoS attack and/or an attempted compromise of user data. It was pretty clear the script worked so execution was halted and attempts at notification were started.

Further Vulnerability – Shutting Down function of the Housing Portal

Under normal operation, when a user books a hotel rooms successfully, their token would be invalidated in the PassKey software and their profile on Gencon would provide a link to their confirmed reservation information, as noted below:

Clicking the Link would take to the housing portal, but requires knowing the email address and another personal detail of the user, such as First Name, Last Name, or other.

By running through the booking process of a room with BurpSuite, it is clear the application, while heavily utilizing Javascript, provides all the necessary data in the form of JSON objects to execute a booking without rendering the Javascript.

An automated method of booking was devised that would parse availability of hotel rooms and execute constructed POSTs that match the format used during normal booking. This script will not be disclosed here, but the following is an example of the POST constructed by the tool:

The standard booking process would involve 1 PHP POST, 2 JSON POSTs, and finally 2 PHP POSTs

The completed script successfully booked a room automatically when the proper conditions were met.

It was quickly apparent that the initial login token was not invalidated through this synthetic booking technique. Further, it was also apparent that the data entered was not validated server-side nor was the credit card data validated.

This means it would be feasible to simply run the automated booking script on a loop, utilize fake data for user and payment fields, and re-use the same token repeatedly to book every hotel room. This would functionally shut down the hotel booking portal as the intended function would no longer be available to the end user.

Disclosure Process

Attempted reporting started on January 31, 2019. Research showed Gencon, Q-Rooms, and Cvent all lacked a formal bug bounty program. Attempts were made to contact the software owner, Cvent, through their website support forms and through Twitter, but these attempts failed.

Unable to reach Cvent, further contact was attempted through Gencon. This was more fruitful and Mike Boozer at Gencon encouraged Cvent to reach out.

The demo script was provided to Mike and Ed Palazzo reached out shortly thereafter.

After some back and forth, Dustin Su and Harika Koppula were brought in to validate and address the issues.

The security issues were validated and the development team was tasked with addressing the security issues. A wonderful response.

30 Days Post-Discovery (1/31/2019 – 03/02/2019)

User information field now only pre-populate First name and Last name, well under the threshold of PII disclosure

The token invalidation check, if effective, would block the attack scenario described. Authorization to test the fix was not provided.

No bounty was awarded. The stated reason was that a bounty was not requested on the first vulnerability while the second vulnerability was already patched prior to making contact.



As of making initial contact, the second vulnerability had been accidentally utilized and was not patched. Whether or not the subsequent patch corrected any issues is unknown at this time as authorization to test was not provided.

Update – 03/06/2019

The portal and authentication system has been updated. There is now a 64 character hex string required as an additional authentication mechanism. This, when combined with the removal of most PII from the portal on initial login, removes most security concerns.

Note the new link format the user receives when accessing the portal link from Gencon.com.

Until Cvent or QRooms is able to validate no PII was previously compromised, it is still possible for PII to have been collected and possibly used in a second-level attack on the portal system. This, however, seems unlikely.