So, we now know that we have a vulnerability with the update mechanism, using the HTTP protocol.

First thing we do is fire up Wireshark to see the data being sent to and from the Debugger. From everything that is sent via HTTP, the most interesting is the following request:

The reason this looks interesting is by looking at the response, we can see where a buffer overflow may occur when reading in strings.

Next, we want to redirect all traffic sent to http://auth.immunitydebugger.com so we can build a working exploit. This is easily done by editing out ‘hosts’ file to something like:

# Copyright (c) 1993-2009 Microsoft Corp.## This is a sample HOSTS file used by Microsoft TCP/IP for Windows.## This file contains the mappings of IP addresses to host names. Each# entry should be kept on an individual line. The IP address should# be placed in the first column followed by the corresponding host name.# The IP address and the host name should be separated by at least one# space.## Additionally, comments (such as these) may be inserted on individual# lines or following the machine name denoted by a '#' symbol.## For example:## 102.54.94.97 rhino.acme.com # source server# 38.25.63.10 x.acme.com # x client host

Sure enough, we have a our crash which shows that our list of ‘AAAA’s has had an effect on Immunity Debuggers run.

Digging into the disassembly, you can see that the vulnerable function is just a simple “rep movs” op which doesn’t do correct bounds checking.

To build a Remote Code Exec exploit for this program could well be possible, but not quite as easy as using a SEH overwrite. This is because only a finite amount of data is read during the retrieval of the HTTP data.

It may be possible by cleverly overwriting memory locations, but to be honest, the window of opportunity of pulling off a successful exploit is not worth the hassle, it’s just about having fun !

Today on my daily lurch around Bugtraq, I came across an interesting vulnerability. This affects the Logwatch program which is often used for parsing data in logfiles and emailing results.

To quote the advisory:

Dominik George discovered that logwatch did not properly sanitizelog file names that were passed to the shell as part of a command.If a remote attacker were able to generate specially crafted filenames(for example, via Samba logging), they could execute arbitrary codewith root privileges.

Interesting, a logparser with arbitrary code execution :). The vulnerable code is located within the perl script ‘logwatch.pl’ here:

The vulnerability occurs with the ‘system()’ call arguments which is unfortunately common. As the $Archive variable isn’t sanitised, we can pass shell commands to be executed.

The $Archive variable is under our control and points to an archived log file which will be processed. Lets see if we can exploit this vulnerability.

First we make our archive log file for the http daemon:

echo “fake” > ‘/var/log/httpd/fakee;who;access_log.2’

And now try running our logwatch script

logwatch -service http

And the result is:

cat: /var/log/httpd/aa: No such file or directoryxpn tty7 March 12 11:15 (:0)xpn pts/1 March 12 11:29 (:0:S.0)sh: access_log.2: not found

As we can see, we were able to run the ‘who’ command successfully.

Now, simply creating a logfile from the shell doesn’t pose much of a risk (because if you have access to run the above shell commands, then you have access to run an arbitrary command), but many daemons are nowadays setup to log by username, hostname, or any array of filenames as found out by Dominik George here.