Showing posts with label Pen Testing. Show all posts
Showing posts with label Pen Testing. Show all posts

Sunday, August 16, 2015

Using Burp Suite with Cluster Bomb to Brute Force a Web Login

Of course you only are going to attempt a brute force login against something that you:

(A) Have permission to attack in the first place
(B) Know you won't affect the client's environment in a negative fashion including:
      (1) Lock out users
      (2) Knock over servers
      (3) Clog the network

Brute forcing is the kind of the thing that, if you know you aren't going to hurt stuff, makes sense to do while you are away getting lunch or otherwise have it going in the background. After all, you never know what you might find.

Choosing a good password list is a topic all to itself, and one I may cover at a later date. But for now let's assume that you have a list of users and some passwords. Cluster bombing always makes sense even if some of the passwords go with a specific user. For example, let's say that Joe has a password of Seahawks for his ssh login, but not for the web application in question. Let's also say that Susan has a password of Orioles for her FTP login but not for the web application.

What if Susan's password for the web application is Seahawks?

This might seem far fetched, but it happens, and if you include all the passwords that you have (or think as likely) and run them against all the user names that you have (or think as likely) and you are using Burp Suite, then you want to run a cluster bomb attack on the application.

So how to do it? First we need to set up our proxy for burp with the browser we are using so that we can capture login information...


Then we ensure that intercept is on for burp and enter our data on the web page. Notice that our username of 'foo' and password of 'bar' are captured. This information is held by burp and will be used over and over again in the attack.


Specifically, the parameters indicated will be replaced by contents of files - a list of user names and a list of passwords. The next step is to right click this screen and send it to intruder. Notice that, with the intruder tab selected, the sub tabs of Target, Positions, Payload and Options present themselves. Target won't have to be altered as we are using http or port 80, but our Positions will need to be specified. Remove the unwanted foo and bar - we only put them there so that were could easily identify where they were on the form.



On the next tab, Payloads, we will indicate what usernames and passwords will be plugged in for the attack. As we are using a cluster bomb attack every username will be tried with every password, which is what we want.

Then on the options tab you want to make certain that you handle redirections and start the attack.


Lastly, as you watch the attack in the background you can sort by length of results to see if you have any hits. For very little set up time these kinds of attacks may give you some level of additional access that you can leverage from information that you may already have.




Sunday, July 12, 2015

Damn You \xC2 ...

I was working on putting some code down in hex in a place it didn't belong. You can see in the image below a bit of the shell code and the code used to place it there. Not tremendously exciting stuff. But in particular you can see I have my initial buffer overflow filler on line 150, followed by a reliable address on line 151, a bit of a sled on line 152 and the shell code payload lastly on 153. Notice that nowhere is there a \xC2 or \xC3.



There are plenty of \x41 to be sure and several \x90s but no \xC2 or \xC3. Perhaps you may think that some got there within the shelled, but that isn't the case, and as you can clearly see there aren't any between the bytes that the NOP sled is composed of...


So where did they all come from? At first I thought maybe it was some DEP thing that I didn't know about (because there really is a LOT that I don't know about). But after experimenting a bit I realized, initially, it started with any bytes higher than \x7F - the limit of the ASCII range.

And that made it an encoding problem. Specifically line 163 encodes regular ASCII as UTF-8 which is fine but at line 165 when we hit hex outside the ASCII range we start to have problems in python 3. Python 2 took care of this seemingly automatically because the default encoding is "latin-1" which works for the range \x00-\xFF but UTF-8 doesn't and python 3 defaults to that. In any event I called out on line 165 for it to be UTF-8 which was not up to the task.

The story ends happily though. Changing line 165 to 'latin-1' results in the following...



Thursday, April 30, 2015

Network Penetration Testing - A First Glimpse

Two years ago I went to Defcon 21 and had my mind blown. I was taking an introduction to C++ course and looking for a career change. On a lark I decided to go to Defcon because it sounded pretty cool, and I love Vegas. While I was there I went to a ton of talks, met a lot of interesting and intelligent people, and didn't hit the tables once. It was definitely unusual.

While I was there I saw some guy on stage talking about pen testing - that is how a company will pay you to break into their network or their web application. I honestly thought that was the coolest thing around. Who wouldn't want to do that? I also thought that maybe someday I would even know enough or be lucky enough to get a job doing that.

A few weeks ago I just got back from a two week gig where the team I was part of worked a lot of 12 hour days breaking into everything we could at a client site - at the client's request. I even got to do a little social engineering and physical security penetration testing too. It was, of course, different than the movies: there were actual long hours, thousands of IP addresses, a million screenshots, and mountains of text to process and sift through with sed, awk, grep, cut, tr and python - a rigorous exercise in automation. It wasn't some color coded, graphical representation of a shape of virus that we manipulated by waving our hands with a flashing pop-up window at the end saying "access granted".

And there were the three weeks following that was all word documents. Tell them what you were supposed to do, tell them what you did, tell them you told them. And have an executive summary that says the same thing only with bullet points. Include pictures, everyone loves pictures.

But in some ways it was like a movie. There was a critical do or die moment when we clandestinely gained physical access to supposedly secured space. There were hours of failed attempts at accessing systems that ended with a 'Hail Mary' pass in the final moments of the deadline resulting in success. There was a password that was broken by guessing it Harrison Ford style from Clear and Present Danger. It wasn't quite "children's birthdays in reverse" but close enough for real life.

The best part besides being paid to do it of course, is that really you are a good guy. Your goal is to help the other good guys by showing them what they missed. Having done some sysadmin stuff it can be hard enough just to get things up and running as the technology and the business requirements are always changing - and not every sysadmin has been doing it for years, is created equal, or remembers everything every time. They are mostly underpaid, under staffed and overworked from what I have seen. So now, I get to help them when I can by showing them the things that I find and hope that it makes their jobs easier in the long run.



Figure 1 - Unauthorized physical access gained to secured workspace environment.


Take only pictures, leave only footprints no trace.