Finding alphanumeric jump addresses for buffer-overflow exploit development

Buffer-overflow exploit-development can sometimes be challenging for services which use protocols that have restricted character-sets.

In a previous blog on bad-characters, I talked about ways to encode payloads so that problem special characters can be avoided in exploit payloads.

Whilst that is fine for "introducing" code to the target system, an attacker also needs to hijack code execution to run the malicious payload. This is done by controlling EIP through putting a jump address within the buffer. This jump address perfectly overwrites EIP, (either directly as part of the function epilogue, or via a Structured Exception Handler) to redirect code execution to the malicious payload.

For very restrictive protocols (text-only for example) finding a working jump address in memory can be challenging.

Here is one approach to finding useable jump addresses, using a couple of Metasploit tools (and a bit of grepping).

Please remember to use these techniques only for legitimate educational and testing purposes and not maliciously.


Dumping memory

In this example, I am experimenting with a Windows application crash.

We can dump all the accessible memory for the target process, using memdump.exe, which is available in the MSF included with Backtrack 5 in the following directory:

/pentest/exploits/framework3/tools/memdump/

This tool needs to be transfered to the target Windows system and run on the target process in its crashed state, as follows:

memdump.exe <process id> <output dir>

This produces a directory full of files which can then be zipped, and transferred back to the Backtrack 5 system and unpacked.


Scanning the dump

To scan this process dump, we can use msfpescan to extract the jump addresses, from the memory locations which were available to the process.

This example would find a pop, pop, ret, for a SEH exploit:

/pentest/exploits/framework3/msfpescan -p -M ./dumpdir > scanresults.txt

Or here for example we look for the classic "jmp esp":

/pentest/exploits/framework3/msfpescan -j esp -M ./dumpdir > scanresults.txt

We can then sort through the results to remove addresses with characters that cannot be used in a restricted buffer


Removing unusable addresses


Grep can be used to filter these results in various ways.

Here we grep to remove addresses that contain null bytes, or 0x0a, and 0x0d (CR/LF characters).

cat scanresults.txt | grep ^0x | grep -v "^0x00\|0a\|0d" | grep -v "^0x..00\|0a\|0d" | grep -v "^0x....00\|0a\|0d" | grep -v "^0x......00\|0a\|0d" | sort




Here we grep for addresses which don't have any non-alphanumeric in any of the 4 octets:

cat scanresults.txt | grep ^0x | grep -v "^0x[0-2\|8-9\|a-f]\|3a\|3b\|3c\|3d\|3e\|3f\|40\|5b\|5c\|5d\|5e\|5f\|60\|7b\|7c\|7d\|7e\|7f" | grep -v "^0x..[0-2\|8-9\|a-f]\|3a\|3b\|3c\|3d\|3e\|3f\|40\|5b\|5c\|5d\|5e\|5f\|60\|7b\|7c\|7d\|7e\|7f" | grep -v "^0x....[0-2\|8-9\|a-f]\|3a\|3b\|3c\|3d\|3e\|3f\|40\|5b\|5c\|5d\|5e\|5f\|60\|7b\|7c\|7d\|7e\|7f" | grep -v "^0x......[0-2\|8-9\|a-f]\|3a\|3b\|3c\|3d\|3e\|3f\|40\|5b\|5c\|5d\|5e\|5f\|60\|7b\|7c\|7d\|7e\|7f" | sort

(That last one looks a bit horrible. There may be a shorter way to grep this,  but this is effective as a cut'n'paste hack)


The results look like this:

0x74723956 pop esi; pop ebp; retn 0x0004
0x74724a6b pop esi; pop ebp; retn 0x0004
0x74734e36 pop esi; pop ebp; retn 0x000c
0x7473526c pop esi; pop ebp; retn 0x000c

etc...

As you can see, these addresses contain only the usable characters.

So it would then be just a question of cross-referencing these addresses with the dlls you want to use (based on various criteria such as portability and protection bypass) and choosing ones that will work for the exploit.

Easy Nessus scan for a beginner with Backtrack 5

I have got to say that the inclusion of Nessus in Backtrack 5 is great. This makes performing a basic vulnerability scan easy.

UPDATE: - In Backtrack 5 R1 you will need to additionally download and install Nessus, which I have briefly described in the following post

http://insidetrust.blogspot.com/2011/08/setting-up-nessus-in-backtrack-5-r1.html


The rest of the setup


1) Get a free home-use key on the Tenable/Nessus website


2) Enter the key as follows


/opt/nessus/bin/nessus-fetch --register xxxx-xxxx-xxxx-xxxx


3) Create a user and password (and hit enter to skip the rules)

/opt/nessus/sbin/nessus-adduser


4) Start the service

/etc/init.d/nessusd start


5) Start the scan, and view the report

https://localhost:8834/


The Nessus user-interface is so straight-forward that don't think there is any point in me describing where to click or what to put in. Just play with it for a minute or two and you should see how it works.

Using Nessus to scan a set of machines really is a no-brainer. Here is a sample report (This XP systems needs patching ;o)

Whilst this is no substitute for a Penetration test, a basic vulnerability scan can certainly help identify computers that are missing patches, or have poor configurations.

Overcoming problems installing Backtrack 5 on a system

I had a challenging couple of hours today getting Backtrack 5 running on my main Desktop system.

Having tried the VMs, and and also installed the 32bit KDE version on one of my laptops (both of which were very straight forward) I thought I would bite-the-bullet, backup the data from my main research system, blow it away, and install Backtrack Linux 5 on that as well.

Unfortunately I ran into a few issues, with installation drives, and graphics drivers.

So here are some notes on solutions (more for me to remember than anything, but may be helpful to someone else?)

Boot-loader issues

There seems to be something odd about the partitioning and boot-loader installation in Backtrack 5. I have multiple drives, one of which is a striped-pair. It didn't seem to be writing the boot-loader to the correct drive. Not sure why, but to work around this, I popped out the cables for my RAID array disks, and installed on the single 500GB OS disk (with no other live disks in the chassis at the time) and that seemed to resolve it.


Graphics-driver woes

I have an on-board Nvidia card, which I know has produced some issues before, with my Backtrack 4 R2 install. No surprise, I needed to do some extra fiddling again to get this to work.

After the install, "startx" was crashing-out with various errors telling me that there were no suitable devices for X to run on.

(This was despite the fact that graphics drivers on the live DVD were working fine)

The solution to this was to use a proprietary Nvidia driver-installation script. This also requires the kernel-sources to be downloaded and unpacked as follows:

prepare-kernel-sources

(If you need to do this, go and make a cup of tea while this downloads and unpacks)

cd /usr/src/linux

cp -rf include/generated/* include/linux/

However, the configuration script I had previously used with Backtrack 4 R2 (NVIDIA-Linux-x86-195.36.24-pkg1.sh) did not work, but luckily a more recent script did (NVIDIA-Linux-x86-270.41.19.run).
(I hadn't been able to get that one working with Backtrack 4 R2)

I then ran the Nvidia driver install as follows, and bingo, it worked:

./NVIDIA-Linux-x86-270.41.19.run --kernel-source-path='/usr/src/linux'

You can get the latest drivers from here: http://www.nvidia.com/object/unix.html


Setting up the rest of my lab

The VMWare-player install went seemlessly (just using the "VMware-Player-3.1.4-385536.i386.bundle" script file from the VMware website) and I have copied on my archived virtual-victim-lab.

So now I have a working online Backtrack 5. Hurrah!

Here are a few extras I have installed:

apt-get -y install gns3 openoffice.org tftp vlc gimp vsftpd xchat kcalc mplayer kate okular uml-utilities ktorrent k3b kmag ksnapshot


Now it's just a question of getting used to KDE 4.5 (which seems quite different to KDE 3.x).


Missing things

There seem to be some other things that I am used to seeing on Backtrack 4, that are either not there, or have changed significantly, I guess I will figure those out my immersing myself with some exploit development over the next few days.

Anyway, time for some pwnage...

Nmap nse broadcast scanning in Backtrack 5

One of the more recent developments in nmap, over the past couple of years, is the addition of nmap nse scripts making nmap a much more flexible and expandable network-mapper and vulnerability-scanner (it seems like there are many more scripts being contributed with every release).

There are now over 170 different scripts included by default in nmap. (I've been playing with nmap version 5.51, which comes with Backtrack 5)

One of the more interesting new types of nse scripts are the broadcast discovery scripts, which I feel are certainly very interesting currently. To me, it looks like these new scanning techniques will become much more important in the future, as more IPv6 is deployed and used, and IPv4 gradually wanes. (though I do think some IPv4 could be around for another 15-20 years, these protocols will gradually decrease in importance)

IPv6-only networks mean a lot of changes in the way hosts can be discovered, as scanning entire net-blocks will become much more difficult due to the vast size of the address-space, but broadcast scanning, and passive sniffing can help identify IPv6 systems.

I've seen it reported that "nse broadcast-scans, are stealthy because they are passive". This is not true, they are still active scans. However, they are very low traffic scans, which attempt to discover network services using inbuilt ease-of-use functionality in the target network. (This type of scanning is perhaps something that could be done early in reconnaissance or discovery as a first network scan.)


What are broadcast scans?

Rather than UDP or TCP port-scans or network scans using ICMP or ARP, broadcast scans are a lot less intrusive. Think of broadcast scans as nmap saying:

"Hi there. I'm new on the network. Do any computers out there have any services I might want to use?"

Whilst this sounds a bit dumb from a security perspective, there are lots of computers and various protocols that could respond, even systems that have firewalls enabled with all ports blocked will respond in some cases.

From a network visibility perspective, we are also talking about only a very few packets per protocol, rather than the thousands required for a port-scan, and these "conversations" should be normal on the network, so this is much less likely to be detected by network security software.

I set up a couple of systems in my test network. Broadcast scans don't need an IP address range. They are simply run like this:

nmap -P0 --script=broadcast

..and here is one of my initial results

This shows Universal Plug and Play running on a couple of systems which lets us know of their existence. As you can see from a wireshark capture, this is not a passive scan, but is low bandwidth:

Here is another example with Web Services Dynamic Discovery responding (this is another Windows 7 system on my test network).

nmap -P0 --script=broadcast

Starting Nmap 5.51 ( http://nmap.org ) at 2011-05-18 05:23 EDT
Pre-scan script results:
| broadcast-wsdd-discover:
|   Devices
|     192.168.1.70
|         Message id: c6cf6b9b-834d-4320-85e1-e1a65299ee2f
|         Address: http://192.168.1.70:5357/9a36912c-3560-493e-82d7-eadd95271272/
|_        Type: Device pub:Computer
WARNING: No targets were specified, so 0 hosts scanned.
Nmap done: 0 IP addresses (0 hosts up) scanned in 40.08 seconds

The responses

So these responses for the target systems are basically telling us their IP address (in this case with its IPv4 address) the fact that the system has a HTTP service, and a service it might be running. Basically, following the broadcast, these systems are contacting the attacker to the him their addresses.

In both these cases Windows 7 has the firewall enabled (with default "secure" settings, so you be the judge of whether this is a good default behavior or not).

So, in short, I think we will be hearing a lot more about broadcast-based service scans, (and also passive data collection) as IPv6 rolls out in corporate infrastructure.