Posts Tagged ‘bruteforce’

A closer look at Dine & Discover NSW Vouchers

25 Mar 2021


The NSW Government has launched Dine & Discover NSW to encourage the community to get out and about and support dining, arts and tourism businesses.

NSW residents aged 18 and over can apply for 4 x $25 vouchers, worth $100 in total.

  • 2 x $25 Dine NSW Vouchers to be used for dining in at restaurants, cafés, bars, wineries, pubs or clubs.
  • 2 x $25 Discover NSW Vouchers to be used for entertainment and recreation, including cultural institutions, live music, and arts venues.


The Vouchers

There are two ways to access these vouchers:

  1. Email – Vouchers are initially emailed to eligible participants of the program after they sign up.
  2. ServiceNSW App – Vouchers can be accessed from the ServiceNSW


The initial email contains a PDF attachment that contains vouchers that look like this:

Discover NSW Voucher

Dine NSW Voucher

Each voucher has a few pieces of metadata attached:

  • The voucher type (Dine or Discovery)
  • A 9 character voucher code such as ED04K31MB (omitted from screenshots above)
  • A QR code with embedded data
  • An expiry date (in this case 30-Jun-2021)
  • Value (in this case $25)


Using the vouchers

There are two ways you can redeem your vouchers online or in-person:

  1. You can supply a participating business with your 9-char voucher code such as ED04K31MB
  2. You can show a participating business the QR code which exists to promote COVID-safe contactless interactions.

Email Vouchers vs ServiceNSW App Vouchers Discrepancy

There appears to be a discrepancy between the voucher codes and QR codes sent in the original email and the ones that appear in the ServiceNSW mobile app. The codes sent in the email seem to be the original codes and are “long life”. The codes generated in the ServiceNSW app seem to be generated each time you click on a voucher. They are likely temporary codes that, in the end, are all linked back to the unique identifier for your voucher. So once you use the code in the email or any code generated by the app, your uniquely identified voucher will be marked as used.

ServiceNSW App Dine Voucher

I didn’t test using old codes though but I’ll give ServiceNSW the benefit of the doubt here. 😉

Voucher format

Dine and Discover NSW Voucher Format

Each voucher is 9 characters in length.
Discovery vouchers always start with the letter G. Dine vouchers always start with the letter E.
The remaining 8 characters seem to be random alphanumeric characters (case-insensitive).


That QR code though…

Scanning any of the voucher QR codes gives us some plain text.

Dine/Discover Voucher (ServiceNSW App)

For example here is the output from scanning a Discover voucher from the ServiceNSW app:

This is a Base64 encoded string that represents the following JSON object:

We have a few fields present:

  • v: voucher
    • d: data – the first 8 characters here appended to G or (based on type) to create the voucher code; it is unclear what the last 8 digits represent (checksum or additional code?)
    • t: type of voucher, either CSG (for discovery vouchers) or CSE (for dine vouchers)
  • ts: timestamp – ISO8601 time string representing the time the voucher code was generated
  • m: unknown – as a 64 character hexadecimal hash it may be a SHA256 hash but I am not sure what it could represent (perhaps member?)


Dine/Discover Voucher (Email)

Interestingly, the QR code output from the vouchers in the email is different.

For example here is the output from scanning a Dine voucher from the email:

This is a Base64 encoded string that represents the following JSON object:

We have a few fields present:

  • v: voucher
    • d: data – this appears to be the unique identifier of our voucher in UUID format (which is what the temporary voucher/QR codes from the ServiceNSW app are likely linked to)
    • t: type of voucher, either CSG (for discovery vouchers) or CSE (for dine vouchers)

Notice how the ts (timestamp) and m (unknown) fields are missing here.


Third-Party Validation API

The obvious attack vector here is the participating businesses that accept these codes. There is likely a private API exposed by ServiceNSW and provided to participating businesses to validate and use these vouchers. I discovered that Hoyts (a participating business) was using this API behind the scenes through their own API proxy here:

This API takes a voucher code and returns a few responses based on the result of the validation.

Valid (unused) voucher:

Valid (unused) voucher but the user has already redeemed voucher at this business during this business day:

Valid (unused) voucher but wrong type:

Invalid (already used) voucher:

Invalid (not found) voucher:

Invalid (wrong format) voucher:


Bruteforce attack

Each voucher code is 9 characters long. As the first character is hardcoded, this leaves only 8 characters. It appears that the next 8 characters are random alphanumeric characters. Furthermore, by testing an API we discover we can confirm that upper and lowercase characters are equivalent. In other words, the voucher codes are case insensitive.

This leaves us with a character set of 36 characters (26 letters of English alphabet + 10 digits):

There are roughly 8 million residents in NSW. Modestly assuming 60% of those are adults over 18 and eligible for the NSW Dine & Discover voucher program, there are potentially up to 4.8 million vouchers originally generated and sent to a users email address. However, the total number of unique 8 character combinations with the above character set is 36 pick 8, or 2 821 109 907 456 (~2 trillion). Double that for each voucher type. That means that at best only 0.0001701% of the maximum combinations will be valid voucher codes for each voucher type. We are ignoring the temporary generated voucher codes here as they may expire and are likely not frequently generated until just before they are used.

If this were a password hash, with only 8 characters of entropy and a 36 character set, it would definitely be feasible to brute force the entire combination set. 8 character passwords with a character set this small are not secure and can be cracked offline from a hash within 10 – 30 days with moderately cheap hardware.

Unfortunately, though, we are forced to validate our codes online through the Hoyts API. This is much, much slower than GPU hash cracking due to the cost of networking and has other unwanted side effects:

  • Slow network-based validation technique
  • Raising suspicion by server maintainers through metrics they collect around API usage
  • Bringing additional load onto Hoyts servers and by extension ServiceNSW servers
  • Running into rate limiting issues (severely reducing the effectiveness of our brute force attack)

Bruteforce attempt and results

Nevertheless, in the spirit of giving it a go and in good faith I attempted a hopeless brute force attempt. I started a cluster of AWS lambdas in the ap-southeast-2 region running a simple Python scraping script. For simplicity, I logged any unexpected API responses to Cloudwatch. This code will not be released publically for obvious reasons. Furthermore, I time-boxed this experiment to only 12 hours as I would prefer to not needlessly burn money through AWS fees.

Unsurprisingly, I found no other valid voucher codes and that is good news for everyone.

Now get out there and kick start NSW again!



Posted in Penetration Testing


Hackvent 2019: Day 21

21 Dec 2019
CTF: Hackvent 2019
Link to challenge:
Date Completed: 21 December 2019



HV19.21 Happy Christmas 256


We review the clues the elves gave us and first start by trying to find Santa password that was leaked 10 years ago. We are looking for data breaches in 2009 so we look at a list of data breaches. We find that the rockyou breach was the biggest breach that year and that is password dumps are readily available (with usernames stripped out) so we download this dump. We also know that Santa’s password is of length sqrt(256) = 16. There are roughly 118k passwords in the dump that meet the length requirement. Another clue tells us that the AES256 key can be derived with pbkdf2_hmac with the salt TwoHundredFiftySix and with 256*256*256 iterations. We also know that Santa’s password is of length sqrt(256) = 16. We attempt to bruteforce the AES key but realise very quickly this is very slow and would take a long time. To be clear, it is quite feasible to crack the AES key this way over the course of say 48 hours but we want a faster solution. We also tried to guess that the password would contain the text 256 and used this to limit our bruteforce space for AES key cracking. This unfortunately failed but was a cool idea! (If only we used the word santa instead).

Instead, we look at Santa’s private keys and notice how the corresponding private key is his password with SHA256 encryption. This is much, much faster to bruteforce as we can generate potential private keys and attempt to sign and verify a test message. If our verification is successful, we will have our original password which we can then use to decrypt the AES cipertext directly.

Putting all of this together we write our Python script:

Running the above gives us Santa’s password and our flag after 30 seconds:

Flag:  HV19{sry_n0_crypt0mat_th1s_year}

No Comments

Posted in Hackvent 2019


HACKvent 2015: Day 10

10 Dec 2015
CTF: Hackvent 2015
Link to challenge:
Date Completed: 10 December 2015


The following zip file was also provided: Download ZIP File


We notice that the zip file contains one zip file called, that contains one zip file called and so on. I also know that the file zile will keep getting lower and lower in file size the more we extract (due to ZIP headers and padding). Furthermore, opening the file in HxD (the hex editor) allows us to see the names of all embedded zip files. We see the number among many others so we know there are a lot of files here!

We write a quick python script to recursively extract each zip file.

Finally we reach the zip file: which is different from all of the other files.
This zip file contains one file called worst.500 and is password protected.

We use the glorious Accent Zip Password Recovery to crack the password in milliseconds.

The password for the zip file is: love

We extract the file, look inside and find the flag!

Flag:  HV15-iQYf-adNg-o4S9-JHc7-vfWu

No Comments

Posted in Hackvent 2015


HACKvent 2015: Day 9

09 Dec 2015
CTF: Hackvent 2015
Link to challenge:
Date Completed: 09 December 2015


The following sound file was also provided: Download MP3


This was a very simple challenge.
First we listen to the transmission and discover it spells out the nugget but some characters are turned into noise.

We get:

The ?  character represents a character in the set [A-Za-z0-9] (because those are the only characters that can appear in the nugget).
We notice that dashes are omitted. We also know the nugget starts with HV15 so the first unknown character is determined to be 1.

Now, we bruteforce the remaining 3 characters using our hint. We want to first find a full lowercase solution that has a sha1sum which equals B39ECFBC2C64ADBB7C7A9292EEE31794D28FE224 .
After a solution is found for that, we can then try to find the sha1sum of all permutations of the case of each character after HV15 (we know HV15 must be uppercase).

So we construct our template to be:

Then we write a python script to carry out the Bruteforce attack:

We run this and get our flag in 1 second:

Flag:  HV15-GnUj-1YQ7-vdYC-2wlr-E6xj

No Comments

Posted in Hackvent 2015


HACKvent 2015: Day 8

08 Dec 2015
CTF: Hackvent 2015
Link to challenge:
Date Completed: 08 December 2015


Link to website (may be down):


I inspect the source of the website and take a look at the background image but that seems to be fine. There is nothing else of interest on the website so I figure this may require a brute-force attack.

I then however find a cookie that is generated once I fail to authenticate with the website. I try to login using the username admin and the password pass. The following cookie is generated for me:

I then replace %3D with =  and decode the above as base64.

Thus it is obvious that the cookie is simply calculated like so:

I then try to tinker with the cookie fields. I figure that the challenge would not be making any database calls and thus the password would be hardcoded. In this case, the PHP code in the authentication script would look like so:

The above uses strict comparison. However, the PHP script may use loose comparison which opens up a vulnerability. This turns out to be the case and the script does something like this:

In the above examples SOMETHING can be anything we want it to be. It does not have to just be a string. We could modify our JSON payload to pass a value like true  as the username and password. This is what we will do as a loose comparison with true is almost always true (unless the true username or password is “0” which is unlikely).

We construct our payload:

Then we encrypt this using base64 (converting all =  symbols back to %3D ):

Finally, we use a scripting language or a web browser extension (I used EditThisCookie for Chrome) to load the cookie for the webpage. Then we refresh the page and are greeted with the following message:

The goodie is our flag!

Flag:  HV15-0Ch0-91zo-m99Y-kxGI-8iQ5

No Comments

Posted in Hackvent 2015