EH-Net

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.

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)

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.

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

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.

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

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.

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


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).

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."


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.

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...  ;)

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.

This is turning into an interesting thread.

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

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.


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.


Ah, a mastermind... ;)

Dynamik, it's all good. I think we were actually complementing each others comments now. I'm saying don't go running through like a grain thresher through a field, you're saying don't take 3 months to do the test. :)

I just have confidence issues. Probably because I keep interviewing for Security based jobs, and end up not getting hired. But that's been par for the course of my carrier over the last 4 years. Interview, interview, interview. Have things said (You're our top choice, the job is yours, we don't want you for this job, but we have another we want you to do, etc), but end up getting called by HR / Head Hunter and told they went with someone else (or they drag their feet for 3 months).

That's OK, chrisj...  For a while, I've gotten a lot of the 'overqualified' line.  Makes me feel good, on one hand, as the ones that say that HAVE truthfully acknowledged they feel that way, and not just that I'm asking for too much $$, etc.  But on the other hand, makes it tough to find something...  I feel your pain/

Really does make you feel like you're only choice after getting over 10 years IT related experience is to branch out and go you're own way. But that's not what I want to do.

I totally agree; I just wanted to make sure nothing was misinterpretted.

Also, three months is fine as long as they're willing to pay for it ;D

Have you listened to the PaulDotCom interview with Joe McCray? They were talking about long-term penetration tests where the goal was not only to get in but keep active over the course of weeks/months while trying to avoid detection. Those types of engagements sound amazing...


Do they give you a reason? Try and find out if they don't. You can address whatever (perceived) deficiencies once you have some direction.

Is the CISSP on your radar at all? It sounds like you'd qualify with your experience, and that might help give you a little extra momentum.


That's the route I'm gravitating towards. I don't think I'm ever going to be genuinely happy working for someone else.

What doesn't appeal to you? Sales, business administration, etc.? Those aspects of such a proposition are certainly not appealing to me...

dynamik,

CISSIP is on my list. Just probably not for a year or so. Want to do some other things first. OSCP, CCNA Security, etc. I think part of it is lacking a four year college degree.


After I got burnt out on IT, while I was living off savings and going to school (other thread), I started my own business.  I specialized in networking, mostly SOHO networks and wireless networks, and Unix / Linux builds and troubleshooting. Mostly, I had people coming to me to remove viruses and the like from their windows boxes.

AS for working for myself. I hate charging customers when I can't get something to work, or over charging them more hours because I found other things that had to be fixed first before what I was hired for. Or having things go horribly wrong and taking longer than I said I would need.

I hate dealing with Quarterly Taxes, where you have to Estimate your income for the year. The lack of health insurance when you don't know how often you're going to have money to pay it, the dead beat clients you have to sue and still get nothing from.

I hate the rubbing of elbows, self marketing, always having to be professional, having the regular staff hate you fore being the hired gun / specialized troubleshooter etc.

Just thought I'd let everyone know that I was able to successfully bruteforce the usernames on the site I was testing.  I was able to get 8 out of the 10 names in an hour using a dictionary list I hacked together.  For the remaining 2, it took me around 16 hours testing all possible combinations to discover them.  Looking at the traffic, my attempts looked to be a normal load... except that I did it at night, during which there is normally not much traffic at all considering we're a start-up still trying to get the word out.

I e-mailed off my findings today and we'll see if they want me to bruteforce the passwords as well, or if they'll just take my word for it and enable account lockout.

Thanks Seen for sharing your results with us, but when you say:

It looks almost too good to me. How many requests were you making per second? How did you ensure that there was no DoS? Maybe the passwords were weak, but usually, getting 8 out of 10 passwords means something was wrong with the passwords...

A suggestion might be to tell the developers to implement strong password controls...

Anyway, if you didn't cause a DoS, congrats!!

hitmonkey-

he said he got the usernames, not the passwords.

Oups sorry...  :P

I guess I bruteforce passwords and I enumerate usernames...  ;)

Yeah, sorry I "enumerated" them ;) 

Since I'm probably not going to bruteforce the passwords because obtaining the usernames scared the hell out of the rest of the people in the startup, I at least wanted to say that I bruteforced something... it sounds cooler than enumerating :)

Good job Seen!

It's usually quite hard to make people aware of security. It seems you just successfully did that!

Keep searching for other vulnerabilities on the web site. Even if you can't exploit them, it's always good to show you didn't stop at the first "victory".

Keep on the good work!