.

Bruteforcing Without Causing a DoS

<<

Seen

User avatar

Full Member
Full Member

Posts: 137

Joined: Mon Aug 30, 2010 1:05 am

Post Mon Apr 04, 2011 7:24 pm

Bruteforcing Without Causing a DoS

So I got my first job as a website pentester for a small startup.  I already found one hole, the web developer sent the username and password in plaintext.  Now I think I can bruteforce their usernames and passwords.  I have permission to pentest the site, so I don’t need to be covert, but I don’t want to cause a DoS while I’m bruteforcing.  What’s a safe number of requests per second to ensure I don’t have a problem?  40 or 30?  Is there anything else I need to consider besides the number of requests per second?

Thanks.
Sec+, eCPPT
<<

dynamik

Recruiters
Recruiters

Posts: 1119

Joined: Sun Nov 09, 2008 11:00 am

Location: Mile High City

Post Mon Apr 04, 2011 8:34 pm

Re: Bruteforcing Without Causing a DoS

Do you have a test system you can setup that's comparable to (or less powerful that) what they're using? If you're good on that, you will probably be ok on whatever they have. Keep in mind they are many other variables involved, other users, other services running on the server, etc.

If you're going to do anything you consider to be dangerous, considering doing it during off-hours, such as nights and/or weekends. Also, ensure that you have a contact that's available and can restore anything in the event of a problem.

I'd be more concerned about account lockout. If you're locking out accounts after a few invalid attempts, you can effectively disable hundreds or thousands of accounts in a very short amount of time. You may want to adjust your timing, so you're only trying one attempt per user every 11 minutes or so (in the case of three invalid attempts in 30 minutes; adjust to accommodate whatever the invalid attempts per time period is)
The day you stop learning is the day you start becoming obsolete.
<<

Seen

User avatar

Full Member
Full Member

Posts: 137

Joined: Mon Aug 30, 2010 1:05 am

Post Tue Apr 05, 2011 12:09 am

Re: Bruteforcing Without Causing a DoS

They don't have lockout enabled, so there's no chance of that happening.  That, combined with the fact that the web developer sent everything in plaintext, and that the error messages differ based on an incorrect username or password, thus allowing username enumeration does not give me much faith in the web developer they used.  Maybe it's my security background, but I find it hard to believe that any professional web developer would make all those mistakes.

I told them about these issues before they made the login system, but they seemed to ignore them, so I just want to bruteforce things to illustrate how serious not having lockout enabled is.

But yes, I have a contact who can reset the server, and I'm going to do it this weekend at night.  And I'll take your advice and try it on a VM webserver on my local network, that's a good idea.  Thanks.
Sec+, eCPPT
<<

jimbob

Post Tue Apr 05, 2011 3:58 am

Re: Bruteforcing Without Causing a DoS

You might consider monitoring the site you are attacking. If you can control the rate at which your brute force tool hits the site you can tune it, check your monitor to see if the site is working and returning pages in a timely fashion and ramp up. If you get a situation where there is a significant impact on the site throttle back.

A simple script to gather a page and measure the time taken for the response might suffice or you could set up a more complex user experience monitor.

Regards,
Jimbob
<<

rattis

User avatar

Hero Member
Hero Member

Posts: 1172

Joined: Mon Jul 27, 2009 1:25 pm

Post Tue Apr 05, 2011 9:41 am

Re: Bruteforcing Without Causing a DoS

Seen wrote: I have permission to pentest the site, so I don’t need to be covert, but I don’t want to cause a DoS while I’m bruteforcing. 
Thanks.



This response is colored by my personal bias.

I'm not a pen-tester, I'm a defender (although I'm taking pen-test classes right now). But

1) you always want to be covert. Part of what you should be doing is not making loud noises in the logs. Your not just testing their system access, but also testing the humans that interact with it.

2) If you don't have "permission" to test, then you shouldn't be testing. Permission is your get out of Jail Free card.
OSWP, Sec+
<<

yatz

Full Member
Full Member

Posts: 222

Joined: Tue May 25, 2010 2:58 pm

Post Tue Apr 05, 2011 9:51 am

Re: Bruteforcing Without Causing a DoS

My 2 cents - make sure to get this "permission" in writing, with signatures, just in case something does happen.

Also, pen-testing is more than just bashing against passwords.  There is potential to cause DoS with other tests as well.  Because of this I have to second this statement
1) you always want to be covert. Part of what you should be doing is not making loud noises in the logs. Your not just testing their system access, but also testing the humans that interact with it.
"Live as though you would die tomorrow, learn as though you would live forever."

CCNA, MCSA, MCTS, Sec+, Net+, Linux+, CEH
<<

Seen

User avatar

Full Member
Full Member

Posts: 137

Joined: Mon Aug 30, 2010 1:05 am

Post Tue Apr 05, 2011 4:39 pm

Re: Bruteforcing Without Causing a DoS

The server admin is going to give me access to their monitoring program, as well as past activity logs.  So I'm going to use those this week while testing on a local server to try to come up with a more normal traffic flow while bruteforcing before I try the actual test this weekend.

I'm actually a lot more cautious than I'm coming across here ;) (In fact, I made sure to get things in writing even when told it wasn't necessary!)  I would rather be cautious and send one request every few minutes as opposed to sending hundreds per second.  I think for this weekend I'm just going to try some username enumeration (which shouldn't take too long, I already randomly guessed 2 of the 10 accounts) and then go from there.

Like I said, this is my first real pentesting job, so I really appreciate everyone's suggestions.
Sec+, eCPPT
<<

WCNA

User avatar

Full Member
Full Member

Posts: 187

Joined: Wed Mar 02, 2011 8:05 am

Location: Florida

Post Tue Apr 05, 2011 6:46 pm

Re: Bruteforcing Without Causing a DoS

Sounds like you've got it under control.  :)

  I would rather be cautious and send one request every few minutes as opposed to sending hundreds per second.


If you're going to do that, I would make sure you sync your clock to the server's time so you can find your server responses easier in the trace, logs, etc (I'm assuming this is a production box that has other traffic).
ISC2 Associate, WCNA, CWNA, OSCP, Network+
<<

dynamik

Recruiters
Recruiters

Posts: 1119

Joined: Sun Nov 09, 2008 11:00 am

Location: Mile High City

Post Tue Apr 05, 2011 7:51 pm

Re: Bruteforcing Without Causing a DoS

Seen wrote:I told them about these issues before they made the login system, but they seemed to ignore them, so I just want to bruteforce things to illustrate how serious not having lockout enabled is.


Seeing is believing. I've known people who have had a pen test performed simply to demonstrate the risks associate with whatever weak configuration they were trying to convince management to change. It wasn't, "Try and breach our defenses;" it was, "Exploit this hole and show how easy it is to gain access information/systems/etc."

chrisj wrote:1) you always want to be covert. Part of what you should be doing is not making loud noises in the logs. Your not just testing their system access, but also testing the humans that interact with it.


While I generally agree on principle, I don't think it's correct to say "always." It comes down to the way the project is scoped. What is the ultimate objective? Is it to breach the defenses without drawing attention to yourself, or is it to perform a comprehensive review of the target systems/devices in a quick and cost-effective manner?

Remember, both parties have a finite amount of resources. It's going to cost a lot more/take much more time to cover the same amount of ground if you go about things in a covert manner. Now, there's obviously nothing wrong with that if that's the objective. However, if it's not, you're going to either be unnecessarily charging your customer a lot more, leaving items of potential interest unchecked because the time limit has been exceeded, or making much less money per hour to deliver the results you promised.

This is a service for a customer, and you want to provide as much value as possible while maximizing your earnings. If your goal is to demonstrate a problem with an authentication mechanism, hammering away on the service may be the best means to achieve that. If someone hires sil to covertly infiltrate a Fortune 100 company, he'll probably take a different approach.

I think this is especially important to keep in mind when starting out because your clients will typically be smaller and less technical. The 25-person small-town bank isn't going to have state-of-the-art controls with a team of experienced intrusion analysts keeping an eye on every packet. Their Security Officer / Head Teller will likely just delete the automated emails from whoever they hired to monitor their perimeter because an auditor told them to.

Any time spent on stealth in the aforementioned scenario would only decrease value for both parties. Some aspects of the test could probably be automated and performed in a noisy manner (I'm obviously not advocating being reckless and potentially bring down services -- no autopwn ;)) in order to simply obtain information quickly. Some of the time saved by taking this approach may be spent on educating personnel or helping better processes get put in place. There's more to a pen test than just trying to hack a network, and things like that can provide real value to some customers.

As you gain experience and work with larger and more complex networks, you can adjust your methods accordingly. I'd start scoping any project by discussing the pros and cons of each approach and then go from there.
The day you stop learning is the day you start becoming obsolete.
<<

caissyd

User avatar

Hero Member
Hero Member

Posts: 894

Joined: Thu Dec 31, 2009 11:20 am

Location: Ottawa, Canada

Post Wed Apr 06, 2011 7:33 am

Re: Bruteforcing Without Causing a DoS

This is a service for a customer, and you want to provide as much value as possible while maximizing your earnings.


I totally agree with dynamik.

Another point is sometime, clients ask you to perform a given task while they really need you to do something else. They just don't know. That's why they are hiring you to do the job, they can't do it themself! So like dynamik said, you have to adjust and maximize the client's value for your test.

I have recently been ask to pentest a web site. Having a web application development background, I know exactly what happens in the backend. So instead of "just" doing a pentest, I installed the web app in my PC (at work, not at home!) and started looking at it more closely. I found many vulnerabilities on the backend server that I could have never seen while doing a regular pentest because the frontend was very, very secure. Since I couldn't get a foot hole on their system through the web app (the only thing in the scope), I could not have seen these huge vulnerabilities. But what about hacking this old FTP server in the DMZ (out of scope)? If someone would successfully hac another server on the same subnet, they could easily download the entire database. The result was that the development team had to redesign part of the backend to make this application a lot more robust. The client was very, very happy that I found that.

So in this example, I was ask to do a specific job, but I ended up spending half of my time on something else (with the approval of the client, of course). I was able to maximize their gain by adapting myself to the situation.

So back to your original question: Don't brute force a web application. The response time of web apps is pretty slow, so a DoS is unavoidable. Unless you send on request per minute and you are ready to wait 2 years to get meaningful results...  ;)
OSCP, GPEN, GWAPT, GSEC, CEH, CISSP
(aka H1t.M0nk3y)
<<

rattis

User avatar

Hero Member
Hero Member

Posts: 1172

Joined: Mon Jul 27, 2009 1:25 pm

Post Wed Apr 06, 2011 9:57 am

Re: Bruteforcing Without Causing a DoS

dynamik I get your point. time is limited and have to get what you can done in the time you have.

I guess what I meant, was don't go running rough shod over things because they know you're there. Try not to be noisy enough that the skiddie down the street is missed in the logs, don't go filling the logs, don't purposely trip IPS/IDS because they know you're there, etc.
OSWP, Sec+
<<

sil

User avatar

Hero Member
Hero Member

Posts: 551

Joined: Thu Mar 20, 2008 8:01 am

Location: ::1

Post Wed Apr 06, 2011 1:24 pm

Re: Bruteforcing Without Causing a DoS

chrisj wrote:dynamik I get your point. time is limited and have to get what you can done in the time you have.

I guess what I meant, was don't go running rough shod over things because they know you're there. Try not to be noisy enough that the skiddie down the street is missed in the logs, don't go filling the logs, don't purposely trip IPS/IDS because they know you're there, etc.


Darnit, I have to disagree with a lot of the posts here. I documented this for my RWSP in the thesis: "Defending the Castle by Actively Abusing It." Here is my viewpoint on this matter, there are ONLY three factors to be placed into focus:

1) Ensuring whether or not you can get in.
2) Ensuring you are as covert as possible.
3) Ensuring your client gets their monies worth.

1 and 3 are synonymous or at least overlap and intersect one another. In ensuring whether or not you can get a foot in the door, your job is literally hack your way into that system, regardless of whether or not you cause a Denial of Service attack on the application.

No attacker has cared or worried about whether or not they end up DoSing a server in the course of trying to access the server. This is fact. As an attacker, you should think like one with your only goal being #1. This fact should be explained to your client and if in the event you "DO" create a DoS, you are documenting an altogether other security risk they are vulnerable to that needs fixing (the DoS itself). This does not mean you should seek to cause a DoS it simply means you need to find the proper verbiage to explain the potential for a DoS, how you will act responsibly, but also how "it goes with the territory, NO ATTACKER is going to stop and think: if I try to ennumerate this system I will cause a DoS."

This brings us into #2, alerting, etc., in your work you should ALWAYS make it a point to be as covert as possible. This could mean limiting the rate of requests you make, using decoys and so on. Your goal is to evade being blocked while you are performing your testing. If YOU are the only blocked, your test is skewed. You can no longer see results of potential risks while other attackers can. This can be overcome with proper education in fact, from the "white hat hybrid black hat attack." Let them know where you're coming from so they DON'T block you. Continue with your Blackhat testing.

Finally #3. "Washed" down testing does nothing but give clients a false sense of security. Because you're worried about little nuisances, you're not really performing the actions as that of an attacker. An attacker usually has no rules and no boundaries. Same needs to apply to you in a responsible manner. This is what wording, education and insurance is for.

Now, the reality is, most companies have failover capabilities. You could do your testing on the failover provided it is a carbon copy without worrying about taking out the production network. Something to think about as well.
<<

WCNA

User avatar

Full Member
Full Member

Posts: 187

Joined: Wed Mar 02, 2011 8:05 am

Location: Florida

Post Wed Apr 06, 2011 3:18 pm

Re: Bruteforcing Without Causing a DoS

This is turning into an interesting thread.
ISC2 Associate, WCNA, CWNA, OSCP, Network+
<<

Seen

User avatar

Full Member
Full Member

Posts: 137

Joined: Mon Aug 30, 2010 1:05 am

Post Wed Apr 06, 2011 11:02 pm

Re: Bruteforcing Without Causing a DoS

WCNA wrote:This is turning into an interesting thread.


This was all part of my plan when I started this thread ;)
Sec+, eCPPT
<<

dynamik

Recruiters
Recruiters

Posts: 1119

Joined: Sun Nov 09, 2008 11:00 am

Location: Mile High City

Post Sat Apr 09, 2011 2:04 pm

Re: Bruteforcing Without Causing a DoS

chrisj wrote:I guess what I meant, was don't go running rough shod over things because they know you're there. Try not to be noisy enough that the skiddie down the street is missed in the logs, don't go filling the logs, don't purposely trip IPS/IDS because they know you're there, etc.


Chris, I do want to make it clear that my response really wasn't directed at you specifically. I respect you a great deal, and that was just kind of a random trigger for getting on my soap box. I see a lot of people talking about being covert and stealthy simple because that's how they see an ideal attack, not because it's actually practical or beneficial to either party in the context of a professional service.

sil wrote:...typical awesomeness...


That was the exact response I was expecting from you. I'm sorry to make you type all that out; I should have had the courtesy to write that for you ;)

I don't think we're disagreeing as much as you think though. I think we agree that:
  • Stealth is ideal
  • Some actions can be noisy while simultaneously generally being considered "safe"
  • ANY SINGLE PACKET can result in a DoS condition regardless of how "safe" it is; weird/rare/untested/unsupported configurations can cause a service/system to shrivel up and die from a typically innocuous action (i.e. banner grab)
  • Do not be reckless, impersonate a script kiddie (or as you prefer, script kiddiot, which indeed has a much higher lol-factor), or intentionally cause a DoS condition (unless specifically requested)

I've been meaning to ask you this for awhile, but I am curious to know the scale of one of your typical penetration tests. I can tell it's (sadly, for me) worlds different than the work I've previously had the opportunity to do (a previous employer limitation that I'm actively remedying by branching out on my own).

For example, I remember the thread when someone asked where they should start. I responded with Windows targets since the majority of small-medium businesses use that, which would make it a good place to start and work your way up. You posted a link to NetCraft and essentially said, "Solaris and Oracle, obviously. That's what Fortune XXX companies use."

While that (obviously unintentionally) made me feel like a total noob, I'm still undecided if I completely agree. I certainly understand the argument, but at the same time, it'd also be difficult for someone with no, or little, experience to land such a gig. I'm still leaning in the direction I originally took for someone who's just starting out simply because it's the most available/accessible place to get your foot in the door and build from.

While I'm on the subject, I guess I'd like to also know where you started professionally and how you got to where you are now. I know you've been tinkering with everything forever, but how did you specifically go from a hobbyist to a moderately experienced professional to working on such massive projects (i.e. Solaris Admin to testing Solaris systems)?

Wow, tangent. Did I take my Concerta this morning? I honestly can't remember... not a good sign...

Getting back on track, I've worked with customers that I know either certainly do not have controls such as IPSes, or have explicitly created an exception for me because they want to genuinely test the underlying configuration and not risk something being omitted because it was blocked (which would be another interesting practice to debate another time), and in these circumstances, an obsessive level of stealth simply has no benefit.

To further exemplify the atmosphere of some of the other environments I've been in, I've also found about 200k SSNs on anonymous FTP (it's an easy backup server, right?) and a SQL Server (blank SA) within about 15 minutes of being on-site (separate occasions/customers).

I've also been stifled by IPSes while working externally (which is why a VPS is great for double-checking) and dealt with aggressive NACs while on-site. I totally appreciate the circumstances where stealth is valuable.

The point I was ultimately trying to get across is that I think you should discuss these types of things with your customer thoroughly during the scoping stage and agree on an approach that is the most beneficial for those specific circumstances. This may be irrelevant in the upper echelons, but I genuinely see it as worthwhile with smaller, less sophisticated customers (as I noted earlier, when you're starting out).

Back to the OP, I think his wanting to demonstrate a deficiency in the authentication system is a perfect example of where stealth is irrelevant. Now, we can argue semantics and say that's an application test and not a penetration test, which is a fair point. You may equate that more to something like fuzzing, which again, is rarely, if ever, stealthy and basically pounds on the target until it breaks.

There are two miscellaneous final points I want to make. First, if you're going in blind (black box), you should obviously assume such controls are in place and attempt to fly under the radar. Second, I highly encourage everyone to fully understand the impact of their actions and learn how to perform such activities in a covert manner. It will make you better, and even if that knowledge is not relevant to the specific task at hand, it most definitely will be in the future.

Seen wrote:This was all part of my plan when I started this thread ;)


Ah, a mastermind... ;)
The day you stop learning is the day you start becoming obsolete.
Next

Return to Web Applications

Who is online

Users browsing this forum: No registered users and 2 guests

.
Powered by phpBB® Forum Software © phpBB Group.
Designed by ST Software