Skip to main content

Bypassing GSuite CAPTCHA for Username Enumeration and Password Spraying

While performing a recent assessment of an organization using GSuite, I discovered that the implementation of CAPTCHA to stop automated activity is wholly inadequate, and I was able to accomplish both username enumeration and password spraying with relative ease. 

Classic Username Enumeration

When you enter an invalid email address in the Google login form, you are returned an error which states -- "Sorry, Google doesn't recognize that email."  But when you enter a legitimate email address, you are prompted for a password.  This varied response is the basis for any username enumeration attack. Automate the process of iterating through a list of emails, then measure the responses to determine which are legitimate.

But of course, Google throws another wrench in the mix, which might seem at first to be a show-stopper. After a couple of invalid usernames are supplied, Google throws you a CAPTCHA to solve.
I quickly discovered while interacting with this, that the best way to bypass the CAPTCHA is to just ignore it altogether.

So How to Beat the CAPTCHAs?

No complex machine learning to solve CAPTCHA puzzles. No rotating IP addresses through proxies. It was as easy as just programmatically closing the browser between each task and opening a new one.  In each case, you would be able to supply at least an initial username without being prompted to solve a puzzle. So to do this ad infinitum, you simply have to automate the process of opening and closing the browser between each attempt.  Fortunately, with Selenium, this is extremely easy to do.

For each email in the emails list, it will open a new browser instance and test whether the username is valid. And after running, you will have a list of which emails are valid, and which ones are not.  Obviously, this is just a POC and doesn't scale well if you are going to be attempting to test thousands of email addresses.  Of course, this could be resolved through multi-threading and then configuring the browsers to be headless.

And Password Spraying Too!!!

Better yet, this even works for password spraying too. Just cycle to a new browser for each attempt and CAPTCHA is no longer an issue.  As long as your robot knows how to open and close browsers, it no longer has to try and prove that it's human.  PROBLEM SOLVED!!!

Comments

Popular posts from this blog

Bypassing CAPTCHA with Visually-Impaired Robots

As many of you have probably noticed, we rely heavily on bot automation for a lot of the testing that we do at Sociosploit.  And occasionally, we run into sites that leverage CAPTCHA ("Completely Automated Public Turing Test To Tell Computers and Humans Apart") controls to prevent bot automation.   Even if you aren't familiar with the name, you've likely encountered these before. While there are some other vendors who develop CAPTCHAs, Google is currently the leader in CAPTCHA technology.  They currently support 2 products (reCAPTCHA v2 and v3).  As v3 natively only functions as a detective control, I focused my efforts more on identifying ways to possibly bypass reCAPTCHA v2 (which functions more as a preventative control). How reCAPTCHA v2 Works reCAPTCHA v2 starts with a simple checkbox, and evaluates the behavior of the user when clicking it.  While I haven't dissected the underlying operations, I assume this part of the test likely makes determination

Building Bots with Mechanize and Selenium

The Sociosploit team conducts much of its research into the exploitation of social media using custom built bots. On occasion, the team will use public APIs (Application Programming Interfaces), but more often than not, these do not provide the same level of exploitative capabilities that could be achieved through browser automation. So to achieve this end, the Sociosploit team primarily uses a combination of two different Python libraries for building web bots for research. Each of the libraries have their own advantages and disadvantages. These libraries include: Mechanize Pros: Very lightweight, portable, and requires minimal resources Easy to initially configure and install Cuts down on superfluous requests (due to absense of JavaScript) Cons: Does not handle JavaScript or client-side functionality Troubleshooting is done exclusively in text Selenium Pros: Operations are executed in browser, making JavaScript rendering and manipulation easy Visibility of browse

Another "Fappening" on the Horizon?

So in case you aren't fully up-to-speed on useless hacker trivia, "The Fappening" (also sometimes referred to as "Celebgate") was a series of targeted end-user cyber attacks which occurred back in 2014 (which strangely feels like forever in tech years), that resulted in unauthorized access to the iCloud accounts of several prominent celebrity figures.  Following these breaches, photographs (for many including personal sexually explicit or nude photos) of the celebrities were then publicly released online.  Most evidence points to the attack vector being spear phishing email attacks which directed the victims to a fake icloud login site, and then collected the victim's credentials to subsequently access their real icloud accounts. Migration to MFA In response to these events, Apple has made iCloud one of the very few social web services that implements compulsory MFA ("Multi-Factor Authentication").  But while they might be ahead of the indust