CitectSCADA vulnerability 90's Style

Does the SCADA community get interested in security? I think they not because they always say "don't touch those things, you could hurt people" to avoid moving their asses to secure their networks so with this bug and the previous about Wonderware DoS they will probably start to really secure their products and do better things during the development process.

Some people asked me how I found the vulnerability and the answer is simple:

1) Download and install the soft, duh!!!!
2) Select a process with a port listening for incoming connections (I just selected the first one I saw)
3) Start your favorite debugger
4) Set a breakpoint on recv() function (the one that receives info from TCP connections)
5) Use your favorite programming language (mine is python) and create a script to send a bunch of A's.
6) When the breakpoint hits, start debugging. You'll usually see that a byte of two are read from the socket and that is processed as the length of the rest of the packet so you could adjust your script to send a packet with those bytes at the beginning representing the length.
7) If you step out a function or two, you'll see the function that processes the packet content according to the length specified.
8) In those parser functions, you'll usually see that a byte or two are read from the packet and interpreted the field type (That is usually a huge switch-case).
8) According to the operation selected by the byte read, a byte or two are read as the size of the field to process (like Tag-Length-Value).
9) The field is copied into a fixed-size buffer on the stack by the length specified in the packet... OUCH!!! Eip = 0x41414141 ??? That's not good (for them... ahhaha)

peace!!!!!!!!!!!!!

IOS rootkit technical paper

Finally! The technical (in my humble opinion) paper called 'Killing the myth of Cisco IOS rootkits' that I wrote about the subject is available at CORE Security site here.
Enjoy... and send feedback ;)

CISCO response on IOS rootkits

'Rootkits on Cisco IOS Devices' is a document published by CISCO in response to my presentation on IOS rootkits.
It talks about several security measures to take to detect binary image modification but I think that there are some things that are worth mentioning:
1) System Administrators don't read logs very often.
2) Implementing AAA is not easy task for every company (specially small-med sized corps).
3) Using the 'verify' or any other CLI command can easily be hooked by DIK and return whatever it wants instead of the real values.

Ohh come on! You cannot rely on any information given by IOS because this is equivalent than diagnosing an infected Windows machine from within the infected OS.

Let's analyze the case of the verify command.
If you execute that command on any IOS you get an output like:

router#verify /md5 disk0:c7301-jk9s-mz.124-10.bin 0c5be63c4e339707efb7881fde7d5324
.....

.....Done!

%Error verifying disk0:c7301-jk9s-mz.124-10.bin
Computed signature = ad9f9c902fa34b90de8365c3a5039a5b
Submitted signature = 0c5be63c4e339707efb7881fde7d5324

router#

So, now we know the strings used by this command, and if we go to IDA and take a look at the strings list (View->Open Subwindows->Strings) we could find any of those strings like '%Error verifying ' (which is obviously located next to the previously seen strings 'Computed signature = ' and 'Submitted signature = ') which will take us directly to the function that displays the verify command output.
Now that the function is located, we can do the known procedure of intercepting it's call and check if the filename to verify is the router image and just display the output we want (previously obtained printf() memory address, right?).
A different approach could be to intercept open_file() to check if the IOS filename is opened and set a flag inside the rootkit so that any call to read_file() with the FD (File descriptor) of the previous call to open_file() must be monitored to return the original bytes of the image at it's corresponding locations. But this is more difficult and some other things have to be taken into consideration.
So this sounds difficult? How about intercepting the function that received a char* with the calculated MD5 and overwrite it with the correct value previously stored inside the rootkit? That sounds way too easy, right? Well, it is! ;)

Now what do you think about verify /md5 command? Useful? Yeah right...

CISCO IOS rootkits presentation slides

The slides of my presentation at EuSecWest 2008 in London and at PH-Neutral 0x7d8 are online on CORE's website but those are not exactly the ones I showed because there were some typos and the ASCII graphics were also changed so the presentation with the original (cool) graphics and without errors is here.
Bellow is the slides show if you want to take a quick look: