Thursday, October 7, 2010

HTTP + Basic authentication

HTTP + Basic authentication
What about sites that require basic authentication? Basic authentication simply means that you have to provide a username and password to enter a site. Note that some sites might have usernames and passwords at application level - at "site" level - e.g. you must provide a username and password in a HTML based form. This is not basic authentication. With basic authentication, a extra window will be popped up in your browser and you will be prompted for a username and password. As is the case with telnet, the first step would be a get a valid username. Some implementations of basic authentication will tell you if you are using a valid username. Let us look at how Firewall-1 implements basic authentication. I go to the site http://196.xxx.151.241. At the BA (basic authentication) prompt I enter a username "test" and password "test". The server tells us that there is some problem, and responds like this:
Error 401
FW-1 at gateway: Unauthorized to access the document.
Authorization is needed for FW-1.
The authentication required by FW-1 for test is: unknown.
Reason for failure of last attempt: unknown user
Note that is says "unknown user" - the username "test" is thus not valid. If we try it with user "craig" however (we know that craig is a valid user) the response looks like this:
Error 401
FW-1 at gateway: Unauthorized to access the document.
Authorization is needed for FW-1.
The authentication required by FW-1 for craig is: FW-1 password.
Last message to user: FireWall-1 password:
Aha! Note that we don't see any "unknown" user response. How about other server - Apache and IIS? If we use an invalid user at the Apache BA prompt we get a response that says either the username or password is incorrect. IIS does the same thing. For these servers we need to guess usernames. On IIS "administrator" won't be a bad guess.
How do we go about to brute force sites that use BA? Whisker has the functionality to brute force attack BA sites. How do we do this? Let us set up whisker to brute force attack the site http://196.xxx.151.241 with username "craig". We build a file called "passwords" containing some common passwords and execute whisker as follows:
# perl whisker.pl -a craig -L / -P passwords -h 196.xxx.151.241
Let us have a quick look at the different switches. -a specifies the username, -L / says that we want to get to the main site - if the server protects a specific URL we would added it after the /. -P tells whisker that we use the file "passwords" as passwordfile (wow!). Please note - we had to make some minor changes to whisker.pl for this to work. Line 28 should read like this:
getopts("P:fs:n:vdh:l:H:Vu:iI:A:S:EF:p:M:UL:a:W", \%args);}
Line 1185 should read like this:
if($R!~m#^HTTP/[0-9.]{3} 40#){
When whisker find a valid username and password combination it responds like this:= Valid auth combo 'craig:xxx' on following URL:
= http://196.xxx.151.241
The idea would now be to run whisker with the correct username and password against the site:
# perl whisker.pl -a craig:testing -h 196.xxx.151.241
If you have an "133t" exploit you wish to run against a site that makes use of BA, and you do have the correct username and password - you still need to modify the 'sploit in order to use it with BA. The easiest way of doing this is to sniff the actual output of whisker, and look for the "Authentication: Basic" part. Add that then to your 'sploit. The more 'l33t' way is obviously to base64 encode the username:password, put "Basic" in front of it...

No comments:

Post a Comment

hacking tools