Craig Hays

Pre-Account Takeover by Reversing a Weak Email Verification Token Algorithm

By Leave a Comment

Reading Time: 6 minutes

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.

Pre-account takeover weak token algorithm
Photo by Markus Winkler on Unsplash

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.

Analysing The Token Generation Algorithm

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.

Pre-Account Takeovers

Modern web applications often have multiple ways to log in to a user account. These can include:

  • Username and password
  • Email address and password
  • Oauth such as ‘Sign in with Facebook’ or ‘Login with Twitter’
  • SAML Single Sign-On from any SAML compatible Identity Provider (IdP)
  • Passwordless using tokenised ‘magic’ links

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:

  1. The attacker creates a user account on a web application using an email address that they don’t own.
  2. The application doesn’t verify that they are the owner of the email address
  3. The account sits dormant for a period of time
  4. The real owner of the email address chooses to ‘sign-in with Facebook’ and Facebook provides the users validated email address.
  5. The Facebook email address matches the email address the attacker signed up with and the two accounts are linked.
  6. Now the attacker can log in to the victim’s account with an email address and password that they supplied and they can see everything the victim does inside their account each time they log in with Facebook.

Email Verification Token Recon

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.

Digging Deeper

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.

Upper and Lower Bounds

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:

  1. Create an account with an email address I own
  2. Create an account with the email address I don’t own, but want to validate
  3. Create an account with an email address I own

Putting This Into Practice

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 Algorithm

Cracking Encrypted Credit Card Numbers Exposed By API

By Leave a Comment

Reading Time: 5 minutes

I found an API that exposed encrypted credit card numbers. Here’s how I cracked them to reveal the full card details.

Photo by Avery Evans on Unsplash

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 Card Numbers Explained

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

One Time Code Bypass With An Inverted Brute-Force Attack

By Leave a Comment

Reading Time: 4 minutes

“We’ve sent a six-digit code to your email address. Enter it below to login.”

One Time Code Logic Inversion Attack
Photo by Alvin Lenin on Unsplash

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

“Alexa, Put The Kids to Bed and Make Them Sleep”

By Leave a Comment

Reading Time: 3 minutes

How my Alexa voice assistant’s bedtime routine settles my kids down for an easy bedtime, every single night.

Alexa bedtime routine
Photo by Annie Spratt on Unsplash

As parents of young children, we dream of quick and pain-free bedtimes with no tantrums, tears, or bargaining. Our kids, on the other hand, often see bedtime as playtime in a different room with the lights turned down.

To combat this, my wife and I have a strict bedtime routine to ensure our little ones fall asleep happily with the least resistance possible. Our beloved Alexa is a critical member of our team. This is how it works.

Our Amazing Alexa Kids Bedtime Routine

After dinner, it’s time for a bath with some playtime followed by a wash and wind-down time. Then it’s pyjamas on, hair and teeth brushed, and into bed with a bottle of milk and a story. Once the story is done, Alexa takes over.

“Alexa, night night”

“Night night, sweetheart”, Alexa replies. The delicate sound of Baby Mine from Dumbo played soothingly on a xylophone fills the room with an audible warmth.

Within a few minutes, my little one is asleep.

Like Pavlov’s dogs, we’ve conditioned my eldest to associate going to sleep with our chosen Spotify playlist. My youngest daughter is only 7 weeks old and we’ve already started planting that same mental trigger in her head.

We could do all of this without Alexa, but having a voice assistant that kicks off the routine on a spoken command makes consistency so easy to maintain it would be more difficult to not be consistent.

Setting Up The Perfect Kids Bedtime Alexa Routine

The perfect kids bedtime Alexa routine – simple yet effective
  • From the Alexa app, go to More > Routines, then create a new routine by clicking on the + icon in the top right corner.
  • Give your new routine a suitable name. I simply call mine ‘Night night’.
  • Pick your welcome phrase. When I say “Alexa, Night Night”
  • Add your actions. Mine are:
    • Alexa says, “Night night, sweetheart”
    • Play my kids’ bedtime playlist on Spotify
    • From the device that I’ve spoken to.

The Spotify playlist is a custom playlist I’ve created that is simply the album “Disney Lullabies” from the artist “Rockabye Lullaby”, released in 2011. I created a playlist as, for some reason, Alexa struggles to find the album when referenced directly. Instead, the uniquely named playlist ensures that it plays the correct album every time. The last thing I want when putting my kids to sleep is unexpected death metal.

Consistency at Bedtime is Critical

Having a consistent bedtime routine is the most important element of this. The Alexa technology is a nice-to-have, hands-free, luxury that means I don’t need to get up and disturb my soon-to-be-sleeping child in order to start the music. But it isn’t Alexa that actually makes them sleep.

Doing the same thing every night establishes an automatic behavioural response from the kids which helps us to achieve what we want. Familiarity over novelty.

Recently, while my eldest was acting up at bedtime, I dropped the “Alexa, night night” bomb and as soon as the music came on she climbed straight into bed and lay down without any further encouragement. I was stunned. While I hoped it would calm her down, I didn’t think the effect would have been so instantaneous and overwhelming. I would never have thought going from tantrum to tucked up tight so quickly was possible.

Alexa routines are a great way to automate consistency in your life. Don’t get me wrong, bedtimes haven’t always been this easy, but the effort we’ve put into establishing this routine has been well worth it. Now if only Alexa could do laundry…

Why You Should Never Trust a Free Proxy Server

By Leave a Comment

Reading Time: 6 minutes

Free and open proxy servers promise anonymous internet access, but at what cost?

Never trust an open proxy server
Photo by Mikael Seegen on Unsplash

In a world of ever-decreasing online privacy, it’s easy to get sucked into the ‘use an anonymous proxy to stay safe’ narrative. I’ve got nothing against using reputable proxy services or VPNs (virtual private networks), but the ‘free’ proxy services you find on the web can be anything but.

What’s the Difference Between a Proxy and a VPN?

People use proxies and VPNs (Virtual Private Networks) to hide their real IP address and masquerade as other devices on the internet. There are many reasons to do this including bypassing content geo-restrictions, bypassing government filters (Great Firewall of China), bypassing censorship enforced by your Internet Service Provider (ISP), and hiding your real identity from others online.

Your standard internet connection gives you direct access to everything on the internet. Web pages, Skype and Zoom calls, online gaming, it all goes straight from your device to the final destination. To everyone else on the internet, you are you. Your access is limited to what your ISP and government will let you see. All of your traffic is from the country in which you reside.

A virtual private network (VPN) wraps all of your online activity in an encrypted envelope and sends it to another server, your VPN server. This server then unwraps it and sends it to where you wanted it to go. To everyone else on the internet, you are the VPN server, not the real you. Depending on the location of your VPN server, you will be able to bypass some or all of the restrictions described earlier.

A web proxy receives requests for web pages from your device and fetches those pages on your behalf. All other communication remains direct from your device to the destination servers and back. To all web servers on the internet, you are the proxy server. To everything else, you are you. This has a similar effect to a VPN but only for web browsing.

VPN vs web proxy
Standard access vs. VPN access vs. web proxy access

In summary, a VPN moves your visible internet connection from your device to a remote server. A proxy server fetches web content on your behalf but you still appear as your device to anything non-web related.

Free vs. Paid Proxies and VPNs

When you pay for a VPN or web proxy you can expect a minimum level of service in exchange for your money. That minimum level covers things like:

  • High-availability of access
  • Good transfer speeds
  • Untampered data transfers
  • No logs stored anywhere of what you do (optional for anonymous VPNs/Proxies)

They make money because you pay them. Therefore, they are incentivised to give a good service to keep you coming back for more.

Free VPNs and proxies, on the other hand, don’t make money directly from you. Sure, some of these services offer a ‘free tier’ where they give you a few GB of transfer for free each month. They make a profit when you upgrade to the paid version. These are freemium services with limited trials that entice you to upgrade and pay. When I talk about free proxies and VPNs I don’t mean limited-use free trials.

A ‘free’ service is one that never asks you for money, ever. When you look at these services, you must ask yourself, “why do these exist?” People generally don’t run free VPNs and open proxies for the good of humanity. When you consume these services they’re likely to be using you in some way.

As the saying goes, “if you’re not the customer, you’re the product.”

Finding ‘Free’ Open Web Proxies

A quick search on google for ‘open web proxies’ or ‘anonymous web proxies’ returns thousands of results with links to websites listing proxy servers that anyone can use without paying a penny.

Open proxy server list from a Google search

The above is a screenshot of one of these lists. Each list contains lots of server IP addresses and ports. Anyone can configure their web browser to use any of these free, open proxies to proxy all of their web traffic to the internet. None of these servers come with any guarantees and there’s no indication of who is operating them. Many of them are in countries with very lax cybersecurity laws.

Proxy directories maintain their lists by brute-force scanning the internet for open proxies and accepting user submissions by random members of the public. There is no quality control, no peer review capability, and no oversight in any way. This means people like me can set up our own malicious ‘anonymous’ proxy servers and, within a few minutes, have strangers on the internet sending us all sorts of things.

So what can we do to the users of open proxies?

Data Loss Through an Open Proxy

If you use a proxy server for browsing the web, anything you send or receive that isn’t encrypted, (anything in plain text), can be read by the owner of the proxy service. When your communications are encrypted, the attacker can spoof messages from the target server and force you to downgrade your encryption to a crackable level. When this happens, the server can crack the encryption and read your messages without you ever knowing about it. You or your company IT team can configure your devices to prevent this, but how many actually do it?

Failing that, any content you download that isn’t encrypted can be altered to change all links to secure HTTPS sites to the insecure, plain-text HTTP version. You may not even notice that your browser is no longer asking for encrypted versions of sites as it usually would.

This probably isn’t something you need to worry about with a legitimate service, but that ransom, open proxy server you found on the internet?…

Data Tempering and Content Injection by the Proxy

When data is unencrypted (plain-text), malicious proxies can do more than read what you’re talking about. They can actively contribute to the conversation.

Imagine what would happen if you received a quote for a service and the proxy server you were browsing through changed the bank details of the intended recipient to their own? What if they blocked your content altogether? What if they corrupted it so that it couldn’t be trusted? All of these things are possible when you’re using an untrusted machine-in-the-middle of your comms.

Something else which is possible is ad-fraud. The proxy owner changes any advertising content requests sent by your browser for their own ads. The subtlety of this may vary and you may not even notice it happening. When it does, the legitimate owner of a site loses the revenue you would have generated for them. For many site owners, advertising revenue is what keeps them online.

One of the scariest things I’ve seen with open proxies is the injection of malicious javascript code into the existing javascript of every web page downloaded. Nothing else was changed, it just loaded a small piece of code into your browser every time you opened a new page. This code can access your cookies, make requests on your behalf, and even join a botnet directly from your browser.

Hanging Around With a Bad Crowd

Something not often discussed with open proxies is the behaviour of other users. While you might not be committing any crimes via an open proxy, that doesn’t stop others from doing it beside you. If someone commits a crime and the ‘anonymous’ proxy server is confiscated and reveals its not-so-deleted logs, your IP address and traffic history is going to be right there with the criminals. For pretty much every scenario I can think of, I wouldn’t want my name and address linked with that activity.

Summary

Open proxies may look like a good deal, but most of the time, they’re not. If you’re not paying for them you’re most likely to be the product being sold. Stick with paid and legitimate services to stay safe. The prices are relatively low and the ‘free’ versions could cost you more in other ways.

Craig Hays