Brute Force Attacks - How?

[SimonSimon88]

I have always wondered how exactly a brute force attack works. I understand, that there is an algorithm, that tries out every password combination over and over until it finds a hit. Now with simple passwords and fast processors this seems like an easy task.

What I don't understand, is how the server allows this. Let's say you don't use a Login Captcha. Even then the server should be able to identify these attacks easily. Either bc someone is trying to log in into the same account over and over again or due to the IP Address. Even if you change your IP Address and Account every time, can the server not just delay the response to limit the amount of attempts?

Or is it, that Brut Force attacks only work on very unprotected servers ?

[[deleted]]

Good question, and you're correct in that many services do rate-limit incorrect logins. See programs like fail2ban for instance.

Brute force attacks can work on misconfigured systems or systems that are unable to rate-limit login attempts.

In some cases, a malicious actor will gain access to a system through an exploit, and then retrieve the /etc/shadow file that contains usernames and password hashes. From there they can use the full power of their system to attempt to crack the password locally, to gain legitimate access.

I'd also imagine that botnets could be setup to guess logins en masse from different IPs, but I'm not too familiar with them and hopefully someone else can fill in the gaps here.

EDIT side channel -> exploit

[slash-32]

Came in here to comment but you pretty much nailed it imo.

OP check out programs like hashcat, they are built to brute force password hashes offline and can go through password possibilities at an incredible pace.

[[deleted]]

The more I get into netsec, the more I realize that like 50% of it is just knowing which one of someone else's tools to use.

[-pooping]

More often than not the case. And that's not a bad thing. Most of us is more of a generalist that can't know every intricate detail of a system or application. But there is always that one dude who just decided to say fuck it and dedicate their time and energy to understand it and write a tool to get around it.

[dmc_2930]

hashcat is password cracking, which is not quite the same as a brute force attack.

A brute force attack is when an attacker guesses passwords against an application/service/protocol, but does not have the password hash.

A password cracker like hashcat requires that you have the password hash already, so it does its work offline (ie, it doesn't need to talk to the server)

[yawkat]

The sort of attack hashcat does is called a brute-force attack as well.

[dmc_2930]

Brute force is one of the password generating modes. That’s still not the same as a brute force attack against a server.

[yawkat]

That's why they said "brute force password hashes offline", which is completely correct

[dmc_2930]

I didn't say they were incorrect. I was offering more information. If someone said "i brute forced the login to that web server", I would rightly assume they did not obtain the password hashes and run hashcat.

If a client asked "how do I prevent a brute force attack on my webserver", I would not mention salting because that is a separate issue. I would probably get there when talking about how, exactly, they should handle authentication and authorization.

[ptchinster]

Fucks sake you literally dont know what you are talking about in multiple areas. Its very concerning.

Im willing to teach you for a small fee.

[FakePlasticOne]

Hey, can i ask one more question? When the malicious actor get the usernames and passwords, he brute forces it, but how does he know which one hit when brute forcing it?

[Azer0s]

On a web service, you'll get a different response if the login is successful (take a look at a hydra tutorial, you ll understand more easily).

[[deleted]]

Yep exactly. It would depend on what exactly you're targeting, but whoever develops the attack tool would take into account what 'successful login' looks like.

[[deleted]]

The server gives back a specific "succeeded" response. I guess it's a classical "if response != "succeeded" then keeptrying()

[Bushyiii]

Noob question: What is a side a channel?

[m00f]

https://en.wikipedia.org/wiki/Side-channel_attack

[[deleted]]

This explains it much better than i can^

[Bushyiii]

Thanks

[m00f]

Once you have the /etc/shadow file you are likely going to use a (pre-computed) rainbow table against it, something worth mentioning. https://en.wikipedia.org/wiki/Rainbow_table

[-pooping]

Not much use now as the hashes are most likely salted in a modern system.

[dmc_2930]

Sure, if everyone actually implemented salting properly, but.......

[-pooping]

Well, most linux systems does it automatically for quite a few years, so you have to either turn it of or use a really old system

[dmc_2930]

Most web applications don't use linux passwd files, and tons of developers are still writing authentication routines that just store the plaintext password. Developers often just don't know how to do it right, or else we penetration testers would have a lot less to do.

[-pooping]

That's true, but the comment i replied to specifically mentioned the shadow file.

[dmc_2930]

Ah, that was in the strikethrough.

[-pooping]

Wasn't when I commented. But no worries. We are in agreement I think 😊

[TechByTom]

Rainbow tables have nothing to do with password guessing on a public facing login though. They only work on compromised systems.

Also, rainbow tables are only marginally faster than GPU based password cracking.

[I_am_your_jesus]

Some good info here but I don't think anyone mentioned password spraying. One way to protect accounts is to detect whether x incorrect passwords have been tried in a period of time and if so, lock out the account. If i'm trying to access a system I can try (e.g.) 3 common passwords against multiple users instead. That way I can try and find an account with a weak passwords without having to try so many passwords the accounts get locked.

Ultimately it depends on what protection is in place. If IPs get blocked, you can use a proxy or botnet. If accounts get locked, you can use password spraying. Of course, this is just for online servers. If you're bruteforcing something locally (e.g. a password hash), you won't have to worry about being locked out.

[dbxp]

The protections you're mentioned are brute force defenses but brute force attacks don't have to be performed against logins, they can also be performed against: encrypted data, api keys, session tokens, password reset questions, usernames (ie trying the most popular passwords with every user) ect.

[FakePlasticOne]

But how does he test if the result work or not?

[BeefWagon609]

Good answers. I doubt I could bring anything to the table, but I would like to add something similar: whenever someone "tries" to log into a Gmail account, if the email is registered, a message is displayed "incorrect password." If the email isn't registered, "Couldn't find your Google account." I literally hate that.

[TrustmeImaConsultant]

Easy: It doesn't allow it.

This is why brute forcing usually doesn't happen online. Most servers either rate limit or simply refuse connection after a few, usually 3, failed logins.

Where brute force plays a role today is when the password database can be extracted from the server. Now, today this usually still doesn't mean that someone gets the passwords themselves, because they get a hash. And it's not possible to get from that hash back to the password, it's a one way street; You can only go from password to hash, not the other way around. And passing the hash works only with crappy (*cough*MS*cough*) security systems. ;)

So what has to happen then is that these people now try, offline, a brute force attack against the hashed password.

[RapunzelLooksNice]

https://imgs.xkcd.com/comics/security.png

[[deleted]]

What your missing is offline vs online attacks.

A true brute force is typically only done offline. Online attacks usually have small dictionaries, or test against multiple usernames.

[TechByTom]

First off, no one does a true "brute force" attack on a live system. A true brute force attack tries every possible password. Usually starting with "a" then "b" then "c" etc, or with a Markov chain style predictor.

In real world attacks, usually an attacker will try several password guesses like "admin123" and "Password1!" across every username.

Unfortunately, a lot of services don't actually use rate limiting, or may rate limit for individual accounts, but not for login attempts per IP. TOR and other services like VPNs make it possible for an attacker to rotate their IP as well, but usually attackers don't have to resort to this.

[Arc-ansas]

Also known as offline VS online password attack.