Craig Hays
I found a way to alter a premium subscription service price and bought it for a penny. This is how I did it.
Whenever I’m bug hunting on a target that takes payments, I always try to buy something using a test credit card number as described in my write-up on Cracking Encrypted Credit Card Numbers. When the payment fails (or succeeds!) I look through all of the requests and responses for the entire process, searching for anything which looks interesting.
While hacking on a private SaaS bug bounty program, I went through the new user sign-up funnel and entered a test card at the payment page. The payment failed, of course, and so I went back to look at all of the requests and responses captured in Burp through this process. The subscription I had attempted to purchase via the website was the platform’s premium service at £19.99 per month.
I noticed that the request to buy with my credit card transaction token included the string “package_id”:”target:payments:packages:1205″. In the response I received the string “term”:”monthly”,”price”:{“amount”:1999,”currency”:”GBP”}. The amount was the monthly value of the subscription, £19.99 in pence. It also confirmed that the subscription was monthly. The thing that caught my attention was the numerical ID in the package_id parameter. I was curious to see if I could find any other valid package IDs and, if so, what prices and payment terms they were linked to.
Using Burp Suite Intruder I repeated my failed payment request 10,000 times, starting from “target:payments:packages:1” and incrementing the ID up to “target:payments:packages:10000”. While many of the requests errored out with a “no package found” message, I was able to find hundreds of past and future prices still listed in their pricing table,
The most expensive was £49.99 on a monthly term. The cheapest was £0.01 on both a monthly and annual term. Bingo. Now all I needed to do was confirm that the payment would actually work and I could create a real subscription with the identified package number.
Armed with a package_id number priced at £0.01 annually, I went back through the web-based new user sign-up process and enabled Burp Suite proxy intercept just as I was about to enter my payment details. This time, however, I entered my real credit card details and manually forwarded on the resulting requests until I saw the string “package_id”:”target:payments:packages:1205″ again. At this point, I changed the SKU 1205 for the annual £0.01 SKU and hit forward, then switched off Burp Suite proxy intercept.
To my surprise, it worked and I had just bought a £239.88 annual subscription for a penny. I went back into my account and reviewed my subscription and confirmed that I was a premium subscriber. The end date for my contract was 12 months later.
The package_id for this SaaS is the digital equivalent of a barcode SKU (stock-keeping unit) on the side of a box. By listing multiple SKUs and changing the sign-up form to switch between them, the target company can change prices at any time without losing the ability to renew subscriptions at the previous price.
In this case, it looks like the target company created a monthly and annual subscription SKU priced at £0.01 each to allow employees to test the live payment system after code deployments. While this is quite common, these penny SKUs are not usually publicly visible or easy to guess and are reserved for employee usage.
This bug has the potential of a big financial impact in terms of lost revenue. If this became public knowledge, all of their existing customers could cancel their subscriptions and renew for £0.01 costing the target £239.87 per customer per year. New customers could sign up for a penny losing all future revenue until the SKU is disabled. The 1p charge probably doesn’t even cover the credit card transaction fee.
The best way to fix this while keeping the ability for testers to test their payments system is to add a third value to each SKU for Enabled: True or False. That way, the team can enable the £0.01 SKUs for testing, make a purchase, then set them back to False in the application database so that they cannot be abused by people like me.
The payment processing code would need to be updated to read the value of the Enabled property from the database and cancel any transactions trying to use a disabled SKU, advising Stripe not to complete the payment for the presented token.
I spoofed access to other people’s email in order to pre-steal user accounts before they are first registered. Here’s how I did it.
One thing I always test while hacking on bug bounty programs is how applications generate tokens. Tokens are used for things such as password resets, email address verification, one-click sign-in, etc.
While hacking on one private program I discovered an application with a weak algorithm for generating email verification tokens. This is how I approached the problem and how I found a way to generate valid tokens to verify ownership of any email address, even those I didn’t actually have access to. This enabled me to pre-register accounts on any email address with a password of my choice which leads to an account takeover when the real owner eventually registers.
The first thing I test while attacking any web application with a bug bounty scope is the account creation and authentication functionality. On this occasion, I discovered that each time I created a new user account, the application wouldn’t let me do anything until I had verified ownership of my email address. The target application would email me a verification link and prompt me to check my inbox and that was as far as I could go
By forcing me to validate my email address the application owners can prevent pre-account takeovers.
Modern web applications often have multiple ways to log in to a user account. These can include:
A pre-account takeover is when an attacker creates a user account with one login method and then the victim creates another account with another login method. The application then links the two accounts together based on the matching email address. When the email address is not validated, or validations are bypassed, this can lead to pre or post account creation takeovers.
The attack happens as follows:
Checking my inbox, I found the ‘confirm your account’ email and copied the link into my favourite text editor. I always save all one-time links emailed to me along with the account name, email address, registration time, and so on, in case any patterns emerge while testing.
The link had the format https://craighays.com/verify/?P1=randomString &P2=randomString &P3=staticText &P4=staticText (without the spaces).
After generating a few verification emails for different accounts I could see that P3 and P4 were always the same things. P1 and P2, however, always changed each time an email was sent. Opening the link after removing or altering P1 or P2 resulted in an error message and the email address was not verified. Therefore, the combination of P1 and P2 together formed a two-part email address ownership verification token.
Now that I had identified the two-part token used to confirm an email address, I took a deeper look at the two parameters.
Both P1 and P2 were base64 encoded strings. An easy way to spot this is when a random-looking string ends with a single = or double ==. These = chars are used as padding to ensure the pre-encoded string meets the minimum bit length. This isn’t always the case though as a perfect-length string won’t need padding. If in doubt, always pass random strings through different decoders to see if anything interesting comes out.
After decoding multiple P1 and P2 parameters from different links I could see that P1 always had the format of four static characters followed by 12 numerical characters such as TEXT000123456789 and P2 always had the format of 9 numerical characters such as 123456789. Looking through my list of decoded P1 and P2 strings, I could see that the numbers were incrementing, going up in large steps from one email verification link to another. P1 and P2 were not correlated in any way other than that they both went up.
At first, I tried to guess the numbered strings based on the timestamps in the HTTP response, but that was getting me nowhere. Instead, I had the idea of defining upper and lower bounds within which a valid token for an email address would reside. With a small range, even a 9 or 12 digit number could be brute-forced to create a valid token.
Looking at the problem mathematically, I needed to guess two 9 digit numbers. The twelve-digit number always started with 000 so it was effectively 9 digits long. A 9 digit number has 1,000,000,000 possible combinations. Since I have two of them, I have 1,000,000,000 * 1,000,000,000 possible combinations for each email verification token. Pretty secure.
The issue with this application was that in each token generated, P1 and P2 had numbers greater than the previous P1 and P2, but lower than the next P1 and P2. If I can create a token that I can see, followed by one I can’t, then a third that I can see, I can reduce the range of possible numbers significantly. I can create upper and lower bounds on the 9 digit number which is a much smaller range than the 1,000,000,000 possible combinations.
The step by step of my token attack looked like this:
In order to prove that I could validate any email address, I decided to validate my own name at the target company domain, e.g. [email protected]
[Read more…] about Pre-Account Takeover by Reversing a Weak Email Verification Token AlgorithmI found an API that exposed encrypted credit card numbers. Here’s how I cracked them to reveal the full card details.
While hacking on a private bug bounty program, I found a graphql endpoint that exposed way more information about logged-in users than it should have done. By playing with the ‘about me’ graphql API request I was able to guess and retrieve all the logged-in user’s stored values present in the database, not just those disclosed by the web app.
Using these guessed parameters, I was able to retrieve all credit cards added to a user’s account. This included: the cardholders name, their registered address, the expiry date of the card, the last 4 digits of the card, the type of card, and an encrypted version of the full credit card number.
The application allowed users to store up to 10 payment cards on their account for easier checkout when buying products and services. In order for the company to use them in future, I knew that they must be stored in a decryptable format. The challenge I set myself before submitting my report was to crack the encryption algorithm and view the raw card numbers.
Credit and debit card numbers use an internationally recognised standard. A Payment Card Number (PCN) can be anywhere from 8 to 19 digits long and the first 6 to 8 digits are used to identify the bank which issued the card. This is known as the Issuer identification number (IIN). All American Express cards start with 34 or 37, all Visa cards start with a 4, etc.
There is also a range of card numbers that are reserved for testing purposes and which will never be assigned to real customers. (This is another bug you can test for while bug bounty hunting – can I make a purchase with a test-only card?). My personal favourite is for Visa: 4111 1111 1111 1111. Stripe has a list of test cards you can use anywhere and you can find more with a quick google search for “test payment card numbers”.
Finally, the majority of credit card numbers include a validity verification number using the Luhn algorithm. With this, the final digit of the card number is a check digit for all of the preceding numbers. For ‘4111 1111 1111 111X’ the check digit value is 1. For ‘4111 1111 1111 112X’ the check digit value is 9. You can play with this yourself using tools such as this one. As you can see, anyone can generate all possible card numbers for any given bank provided you know the prefix, the length, and whether or not it uses the Luhn algorithm. This is why you also need the card expiry date and CV2 numbers to make purchases.
Now that we’ve got a better understanding of credit card numbers, I’ll continue with my attack.
[Read more…] about Cracking Encrypted Credit Card Numbers Exposed By API“We’ve sent a six-digit code to your email address. Enter it below to login.”
We see them all the time while testing web applications. In order to verify your identity, the application sends a 6 digit numerical code to your registered email address or phone number. The purpose is to prove that the person performing the action is also in possession of the phone or mailbox attached to it. No access, no authorisation. It’s a useful second factor to apply a little extra security to a process.
If you try to guess the code it expires after 5 or so attempts. The odds of guessing correctly are 5/1,000,000, or 1/200,000 (0.0005%). Any guesses after the first 5 are invalid. This prevents you from brute-forcing all 1,000,000 combinations from 000000 to 999999.
Sounds pretty safe, right? Well, it can be. But sometimes developers make mistakes in their assumptions. Here’s one of my favourite bugs to test for and how to exploit it.
[Read more…] about One Time Code Bypass With An Inverted Brute-Force Attack