Possible solution to brute force password hacking our member area's (code inside)
 

OK, my server where under heavy attack again last night, so this morning i did some thinking...

i wrote this document, maybe a possible solution to stop the fuckers :

http://www.kimhollandcash.com/bforce.php


Let me know what you think ...

B.

Hi,

While this would stop some brute force attackers, it won't prevent them all. A lot of times an attacker will use a parser and not just rely on the status code the server provides. It will stop a lot of attackers, I do give you credit for that, but parser based sniffers won't be fooled.

Either way, this is a good and inexpensive solution to at least cut down on brute force, not eliminate it but to at least cut back on server hits.

WG

sounds good... I'll give it a try

and I have this 50k attempts every day... always within two hours

great script...gotta give you credit...it is nice...but there is a problem with it...it works when using a browser right?

no cracking programs use a browser......

my last bit of advice....learn how to crack...and no-one will ever be able to get into your server


Kyree

No not true, it works with everything that access the server through http . Like online brute force password crackers and webbrowsers :)

And... I think 80% of the peeps here are or were hackers ...

But any "cracking" program *needs* to read the response via the socket in order to determine if the attempt was a success or failure. If you don't know the HTML returned on a success, and just look for an error code on a failure, how would you determine that the crack attempt failed? It has nothing to do with using a browser, but parsing the data returned via the socket.

again...there is a major difference between hacking and cracking...if there are so many..then why was this even a topic for discussion....and why is it so hard for them to see the most obvious of solutions? Not trying to be critical...but people are not always what they appear to be...if they were crackers, the problem would be solved already....I'm not trying to put anyone down...and that was not my intentions earlier today...but if people took the time to learn,they would become 100% better webmasters...providing quality content, along with a guarantee that their members would not have their username:password available to the public.....that's where the lists come from....5or6 webmasters allow people into the .htpsswrd file and boom there is a list that will work on tons of sites...the philosophy behind that is....people are creatures of habit....they will use the same U:P at every site they go to...so...the consequences of having a passfile comprimised has vast effects on all the others out there


as I've said before...learn before you earn...cuz if you fail...you fuck others in the business....learn how to crack and you can make your server virtualy uncrackable


Kyree

and with most of the programs running brute force...you can adjust what server replies are hits and what are not...making them adaptable for the site

Kyree

even sites using https aren't safe from bruteforcing

Kyree

honestly, i just don't see much of a problem. i've been running paysites for over 6 years, have well over 15000 members to the largest - and the bandwidth leak to password sites is very minor. certainly doesn't affect the bottom line much at all in terms of percentage cost.

*shrug*

but do you host a bunch of movies? someone earlier had spoke of losing 200 gigs of traffic...that's alot


Kyree

the large site i spoke of, is nothing but movies. all exclusive. loads of them. i use over 70 terabytes/month in bw (mostly promotional costs).

OUCH...then I would definately learn how to keep from losing bandwidth
alot of info on server security is at www.icefortress.com
this is the same place that ibill tried to close down..but then ended up paying an undisclosed settlement to for their false allegations
http://www-2.cs.cmu.edu/~dst/IBILL/

another great place to learn is www.deny.de

best of luck to all who wanna learn...and to hell with the rest that don't care and continue to leave their shit exposed


Kyree

For every smart webmaster, there is even a smarter cracker. What's stopping the cracker from checking the actual html produced, instead of the response code?

The obvious solution to prevent brute force, would be to "block" IP and/or username after X unsuccessful attempts. Even if the cracker has access to 1000s of proxies, it will make his job more difficult, especially if he doesn't know that his IP and/or username is getting "blocked."

The other solution is to display a random error page each time incorrect password is provided. This will make detecting whether the password is correct or not more difficult.

There are of course many other methods that can be used to protect from brute forcing, but if the cracker knows which protection method is used, he/she can usually go around it.

not sure if you are directing that at me, but what gave you the idea i'm lax on security?

you don't become successful, for a long period of time - without the ablility to cover your ass. i'm simply saying that bw leakage is a minor issue, in my experience - in comparison with more serious problems. copyright infringment (for instance) being number one.

Quite true. Thus, only someone with a successful login can know exactly the HTML that will be returned by a successful login. With some creative scripting, I can make sure that each valid account gets a unique yet perfectly valid looking "main" page after login. Since each account thus has it's own unique "main" page that is created with a credit card, testing crack attempts by returning those rotated unique looking pages (but non-functional since I'm tracking a bogus login behind the scenes), I can track the crack attempt by credit card number (any bogus name/pass that is used in that attempt is in my database... if it's used again, we have a hit by a cracker who thought it was valid). How many links deep do you want to test for? Depends on how long you want your proxy to stay up, and how big my database is :)

BTW, why did you think that the original post's solution, returning HTML, would only fool a browser and not a script? Same thing to both of them (bogus login is an error and is obvious to both).

BTW2, It sounded like you mainly exploited security flaws to gain root, not cracking to get user/pass. Personally, I'm more worried about those security flaws than massive proxy crack attacks.

Sorry fo rnot being more specific..I was speaking in general to anyone that cared :glugglug

another idea would be to make your 404 page give a 200 reply....a cracker gets enough fake replies he will move on to another site


Kyree

very good point indeed...another way would be to assign cookies to someone that has a legit password...but then again there is a program (not used by many due to the lack of need) that will find out what the cookie needs to be and fools the server...but since so few servers use this method...this cracking method is not well known....

Kyree

Faking cookies... in a non-brute-force manner? Remember, cookies can be traced to a specific account, with a specific credit card attached to it. *I* create the cookie code, and it can be so complex that you can't crack it for years, even with multiple credit-card frauded accounts. All bogus attemps will be in my database, remember (and you don't know if and when they succeed). I'd be really curious how that is circumvented... though I don't use that method. Does this script bypass that? If so, I'm curious.

I never trusted cookies entirely, however; I use a Session ID client-server dialogue to verify any requests I want to be secure (to negate any bogus IP requests). Finally, SSL != secure, only encrypted from a potentially untrusted source.

Read the article here..Might be of some help..

http://www.hackinthebox.org/article.php?sid=3149

And one for the unix servers out there..

http://www.itworld.com/Comp/2378/swol-1295-sysadmin/

To stop a hacker, you must first become one..capice..?

listen, i am a security expert. At least it was my job for over 7 years before i started in tha porn biz. These articles have nothing to do with brute force password hacking. This article is about network layer security. Ofcourse usefull for others but not for my problem ...

i got 500.000 attempts in less than 3 hours! you know thats almost 47 new connections a second. Its not about the BW but more about server load...

Not to get into all the "my dick is bigger than yours" security shit, the actual code that's listed at the top, brute force hackers will never make a request without supplying a username and password. So they'll always get the 200 OK response. Watch your sessions and just start whacking an IP address that makes more than X number of 401 requests inside X number of minutes. You'll build up a nice big list of proxy IP's.

... and the cracking program will move on the the next user/pass combination ...


the attack of last night where 500000 requests in less than 3 hours! i filtered out all the unique ips. a list of 712 unique numbers! Well, i;m not gonna put all of them in my iptables scripts, because that'll eat cpu as well.


If anyone is interested in that list contact me ...

An other attack is going on right now, this is the result of the above script :

209.74.231.237 - don [01/Oct/2002:19:51:04 +0200] "GET /members HTTP/1.0" 200 387 "-" "Mozilla/4.75 [en] (Win98; U)"
209.74.231.237 - dwight [01/Oct/2002:19:51:04 +0200] "GET /members HTTP/1.0" 200 387 "-" "Mozilla/4.75 [en] (Win98; U)"
209.74.231.237 - elizabeth [01/Oct/2002:19:51:05 +0200] "GET /members HTTP/1.0" 200 387 "-" "Mozilla/4.75 [en] (Win98; U)"
209.74.231.237 - forest [01/Oct/2002:19:51:05 +0200] "GET /members HTTP/1.0" 200 387 "-" "Mozilla/4.75 [en] (Win98; U)"
209.74.231.237 - forrest [01/Oct/2002:19:51:05 +0200] "GET /members HTTP/1.0" 200 387 "-" "Mozilla/4.75 [en] (Win98; U)"
209.74.231.237 - freddie [01/Oct/2002:19:51:05 +0200] "GET /members HTTP/1.0" 200 387 "-" "Mozilla/4.75 [en] (Win98; U)"
209.74.231.237 - franky [01/Oct/2002:19:51:05 +0200] "GET /members HTTP/1.0" 200 387 "-" "Mozilla/4.75 [en] (Win98; U)"
209.74.231.237 - fredrick [01/Oct/2002:19:51:05 +0200] "GET /members HTTP/1.0" 200 387 "-" "Mozilla/4.75 [en] (Win98; U)"
209.74.231.237 - german [01/Oct/2002:19:51:05 +0200] "GET /members HTTP/1.0" 200 387 "-" "Mozilla/4.75 [en] (Win98; U)"
209.74.231.237 - glen [01/Oct/2002:19:51:05 +0200] "GET /members HTTP/1.0" 200 387 "-" "Mozilla/4.75 [en] (Win98; U)"
209.74.231.237 - herbert [01/Oct/2002:19:51:05 +0200] "GET /members HTTP/1.0" 200 387 "-" "Mozilla/4.75 [en] (Win98; U)"
209.74.231.237 - israel [01/Oct/2002:19:51:05 +0200] "GET /members HTTP/1.0" 200 387 "-" "Mozilla/4.75 [en] (Win98; U)"
209.74.231.237 - jackie [01/Oct/2002:19:51:06 +0200] "GET /members HTTP/1.0" 200 387 "-" "Mozilla/4.75 [en] (Win98; U)"
209.74.231.237 - josh [01/Oct/2002:19:51:06 +0200] "GET /members HTTP/1.0" 200 387 "-" "Mozilla/4.75 [en] (Win98; U)"
209.74.231.237 - kermit [01/Oct/2002:19:51:06 +0200] "GET /members HTTP/1.0" 200 387 "-" "Mozilla/4.75 [en] (Win98; U)"
209.74.231.237 - khan [01/Oct/2002:19:51:06 +0200] "GET /members HTTP/1.0" 200 387 "-" "Mozilla/4.75 [en] (Win98; U)"
209.74.231.237 - kurt [01/Oct/2002:19:51:06 +0200] "GET /members HTTP/1.0" 200 387 "-" "Mozilla/4.75 [en] (Win98; U)"
209.74.231.237 - lisa [01/Oct/2002:19:51:06 +0200] "GET /members HTTP/1.0" 200 387 "-" "Mozilla/4.75 [en] (Win98; U)"
209.74.231.237 - ron [01/Oct/2002:19:51:06 +0200] "GET /members HTTP/1.0" 200 387 "-" "Mozilla/4.75 [en] (Win98; U)"
209.74.231.237 - matt [01/Oct/2002:19:51:06 +0200] "GET /members HTTP/1.0" 200 387 "-" "Mozilla/4.75 [en] (Win98; U)"
209.74.231.237 - tom [01/Oct/2002:19:51:07 +0200] "GET /members HTTP/1.0" 200 387 "-" "Mozilla/4.75 [en] (Win98; U)"
209.74.231.237 - torey [01/Oct/2002:19:51:07 +0200] "GET /members HTTP/1.0" 200 387 "-" "Mozilla/4.75 [en] (Win98; U)"
209.74.231.237 - tracy [01/Oct/2002:19:51:07 +0200] "GET /members HTTP/1.0" 200 387 "-" "Mozilla/4.75 [en] (Win98; U)"
209.74.231.237 - will [01/Oct/2002:19:51:07 +0200] "GET /members HTTP/1.0" 200 387 "-" "Mozilla/4.75 [en] (Win98; U)"
209.74.231.237 - emily [01/Oct/2002:19:51:07 +0200] "GET /members HTTP/1.0" 200 387 "-" "Mozilla/4.75 [en] (Win98; U)"
209.74.231.237 - zack [01/Oct/2002:19:51:07 +0200] "GET /members HTTP/1.0" 200 387 "-" "Mozilla/4.75 [en] (Win98; U)"
209.74.231.237 - sarah [01/Oct/2002:19:51:07 +0200] "GET /members HTTP/1.0" 200 387 "-" "Mozilla/4.75 [en] (Win98; U)"
209.74.231.237 - jessica [01/Oct/2002:19:51:07 +0200] "GET /members HTTP/1.0" 200 387 "-" "Mozilla/4.75 [en] (Win98; U)"
209.74.231.237 - ashley [01/Oct/2002:19:51:07 +0200] "GET /members HTTP/1.0" 200 387 "-" "Mozilla/4.75 [en] (Win98; U)"
209.74.231.237 - samantha [01/Oct/2002:19:51:07 +0200] "GET /members HTTP/1.0" 200 387 "-" "Mozilla/4.75 [en] (Win98; U)"
209.74.231.237 - jennifer [01/Oct/2002:19:51:07 +0200] "GET /members HTTP/1.0" 200 387 "-" "Mozilla/4.75 [en] (Win98; U)"

Dude, seriously, look at ProxyPass.. I'm a programmer myself, I had a pretty kick ass solution homegrown, but theres is much better. 500k attempts in 3 hours? Damn.

Cheers,
Backov

Hi Folks,

Backov is right... even if you can pass a 200 OK message they will catch on in a few minutes that every response you're sending is 200 OK. Cookies can be spoofed, etc.., blah blah blah, but the biggest problem is what Boldy and the others are describing:

The sheer quantity of requests in a short time frame.

Look, all of these guys are using proxies and distributed attacks to brute force. We have built a solution, and for 50 bucks it's at least worth a try:
http://www.proxypass.com

Backov will atest as will our other clients that your userload will go down considerably. We do something better than 200 OK responses during blitz attacks: we just stop responding altogether to proxy requests. The result: timeouts and other problems for the crackers.

If you are being brute forced, please get in touch with us and we'll show you a way to stop this.

PXG

*bump* recent password lists found *bump*

try it, it really works, hey its free ... :thumbsup

Not a bad solution, however first of all requires PHP to be installed and this will still cause large server load. Not only are you forking off an Apache but you're also running a PHP up as well.

The issue mainly with password brute forcing I think is the bandwidth/server load issue. What you really need is to find some way to block out the IPs that are executing failed requests. However this is problematic, considering there is no simple way to differentiate between attacker and user.

I can't think of any real PLAUSIBLE solution that will totally secure a server without causing downtime for the user.

ProxyPass - doesn't sound like a very good idea to me. Obviously this will be checking for open 80/8080/1080 or what not ports on the incoming host. This poses many problems. For starters, clearly you need a timeout to verify the ports are open/closed. This will drastically slow down your response time for servers which I wouldn't consider a good thing AT ALL especially in this industry.

Secondly, if it were just open ports, then that's a very poor method of checking if the server is an open proxy (I doubt it would be done like this). Some sort of verification (especially for port 80) would have to be done - again, taking x amount of time to do.

"(4) Detection and denial of requests from multiple (non-proxy) IP addresses sending high numbers of unsuccessful authentication requests for the same username. This implies a distributed network attack."

I would very much like to know how you could ever possibly hope to protect against something like that and not give users downtime.

"In addition, the authentication portions of Apache were written in relatively poor manner. "

I'd like to see info that could back that up =P

There is no real protection against brute force attacks like this that I can see that will guarantee your users uptime.

Anyone interested in an automated brute force solution (PHP/Mysql/ip_filter), feel free to contact me: eric AT wildwebmedia.com

I'm just putting the finishing touches on it now, but it's working like a champ.

why not return the contents of your members "home page"? none of the images will load (theyl'l be prompted for a u/n :) ) but they will think that they got in.

chances are pretty good unless you're using some form of protection, you have leaked passwords. a site i know of that does ~30Mbit, over half of its hits are people trying to crack passwords. (not half the traffic, of course, but once they get in, they're quick to try to download the whole site).

One solution I used previously, was a modified mod_auth_mysql in apache.
With a few changes to the module, it would disallow access for 5 mins on an invalid password.
Basically, if someone tried to login with username=foo, with an incorrect password, ANY attempt to login with username=foo for 5 mins would be denied, even if it was right.
Worked very well for stopping brute force password cracking.
Downsides to this method include no real bandwidth saving other than keeping them out of the members area, and if someone knows how it works, they could brute force with tons of usernames and possibly lockout paying members.

I prefer other authentication methods to http auth generally, slightly more work to setup, but harder to find something to brute force them on your average script kiddie site.

Nice, simple drop in solution. Me like!

However, it still can bring a server to it's knees (I've seen 500 requests/sec "DDoS" brute force attacks on our clients before).

A solution you might want to think about (whether linux or BSD) is to parse logfiles for an undue number of invalids from a given IP. Say 10. Then firewall off that IP using iptables/whatever to stop the requests from hitting apache at all.

The biggest problem there is to not process logfiles through your script when there is no attack going on (eats uneeded cycles)... Since this is a solution we give to all our customers that buy it from us I'll leave how you determine when to process a logfile as an excersize to the reader. Just think KISS.

It works EXTREMELY well. Rarely ever do we get any "false positive" logfiles being parsed for invalid logins, yet we take no more than 5-10 minutes of brute force before it's essentially shut 100% down with no further effect on the webserver. Most of the time we don't even notice other than the automated e-mail telling us so.

peace,

-Phil

http://www.wmcgi.com/protector/

REAL bruteforce protection

boldy, modify your script so that it gives a 200 about 1% of the time or less, that works much better in keeping them out. they will get a list of passwords that don't work, and the bad crackers won't know what to do with that or won't even find out (many just crack and post to their sites or boards, without even checking out the sites).


and just for the record: most crackers are complete and utter idiots. I once made a little cracking tool that also contained a trojan-like thingy, and managed to seriously piss off several hundreds of lame-ass wannabe script-kiddie crackers :glugglug

Yup Phil.. we've got the same thing going. Automation is beautiful..

Just block by excessive source IP.

Tried your solution, nice idea but for me at least it doesn't work. Under Windows XP, once the 200 is sent back, I can't EVER get a password prompt again. Closing browser windows doesn't help - I'd have to REBOOT!

I too have about 500,000 break in attempts today. None of the solutions I have heard about appeal to me.

I started writing a PHP custom login page today, and I was able to authenticate a user but got hung up. Turns out there is no way to pass the credentials on with a redirect; the user just gets asked for the username/password again.

Almost considering doing that anyway; it would solve the problem.

There are plenty ways to pass the credentials on with a redirect - for instance:

header(Location: http://user:[email protected]/page.html);

Just an example though (and a bad one at that).

I believe that is incorrect. I tried exactly what you said many times today, and it didn't work. I then read an article that is is not possible to pass credentials in the header, at least not this way??

Here is a snip of what I tried - doesn't work, browsers still prompts for password:
<?

$directory = "/members/" ;

$uname = $_POST["name"] ;


$upassword = $_POST["password"] ;

// first, is this a good password???
// just testing here, later the "real" directory will be a random number

$file = @ fopen ("http://$uname:$upassword@www.mysite.com$directory", "r");

if (!$file) {
echo "<p>DEBUG Unable to open remote file.\n";
exit;
}

// if good password, just redirect to the section as expected
header("Location: http://$uname:$upassword@www.mysite.com$directory/index.html");


?>

Ok, here is how Boldy's original idea worked great for me:

// Range of numbers
$min = "1"; // Min number
$max = "10"; // Max number

mt_srand(time()); // mt_srand() is used to seed mt_rand()

$RandomValue = mt_rand( $min, $max);

if ($RandomValue == 10) {
header("HTTP/1.0 200 OK");
//echo ( "fooey" ) ;
}

What this does now is only return the 200 OK 10% of the time. The other 90% of the time the user can hit the back key after they see a nice error page. I think I am going to change this to say, 1 ouf 20 and put in production now. Looks great in test...

Educate yourself.

This is not a port scanner. It's a huge db of proxies that is updated and added to.. A centralized db.

We have it, we use it, it works great with no noticable server lag and no noticable extra cpu load.

This is a good solution, and if you don't even bother to read how it works - how well have you evaluated it?

Making assumptions is the mark of a newbie programmer.

Cheers,
Backov

Could someone please brute force try to hack me? :mad: :mad:

I have implemented the "200 OK" idea (only 5% of the time though) and am dying to see it in action....:ak47:

Uhm, I'd like to see on their page where it says they use a database of proxies.

Note that that won't give you a 10%. For all you know you could get RandomValue equaling 10 every single time. Unlikely, but possible. Doesn't really matter tho.