netifera beta 2 is out!

If you are a lazy bastard who didn't contact us to receive notification about netifera then move your lazy ass and and download it HERE.

This version doesn't include any new exciting eye-candy feature but it does have something new. If you like developing security stuff then you'll probably love this release cause you will be able to develop sniffing modules by following the Sniffing Module Tutorial in the documentation section of netifera home page.

This is just the first one of a series of articles about how to create your own sniffing modules and integrate them into netifera either by using a your favorite text editor and a script or using Eclipse (which is now the number one IDE in my list). you may think that it's more comfortable not to use Eclipse but I promise you that once you try it, you love it and you want to keep using it every time.

If you are interested in the changes/bug fixes done for this beta 2 then take a look at the changelog.

netifera beta was released at XCON2008

A couple of the guy and I came to Beijing, China to talk about netifera.
For those who has been living under a rock, netifera is the next generation, ass-kicking platform for security tools done in Java supporting multiple OS's and remote tools execution with an awesome piece of code called 'peludo' and it's partner called 'the probe'.

If you are interested in reading the presentation you can take a look at it here at the end of this post and also I'd recommend to download netifera and try it.

At this moment netifera beta builds for Linux and Mac OS X are available for download HERE (yes, dumb-ass, click here!) and also you will find a startup guide explaining some interesting aspects of it along with it's installation process which is really simple. In a future we'll have the windows version available also, but not yet :)

All the feedback will be very appreciated and if you are interested on seeing something implemented on netifera for the next release, let us know. I cannot make promises but we'll surely appreciate everyones opinions (if they match our opinions... ehehehe).

There are some interesting posts at the netifera blog here so you should take a look at it.

Here are the slides of the presentation.. have fun:

New dreams, new challenges, old friends... Netifera

What am I talking about? It's about something that I've been waiting for long time. It's the opportunity to create something from scratch, being able to do something awesome and share it with others, working with incredible intelligent people, creating a cutting edge security related stuff which will blow everyone' head off ... all this things I've described and more are the things I feel about working on Netifera, the next generation multi-platform security framework.
We all have bunch of experience in the security field but saying it is one thing and proving it is another so we'll try to probe the last one by creating the ultimate security platform.
If you are interested on what I talking about then stay tuned and also checkout Netifera website to see the news about this kick-ass tool :)

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:

The sky isn't falling yet, but it will

I was talking to Nico Fischbach about the IOS rootkit during PH-Neutral 0x7d8 while drinking some beer... A few after that, he sent me an email with a summary about the rootkit stuff and all the noisy. The mail was sent to some mailing lists like Full Disclose and here is a link to it for those who didn't have the chance to read it.
The email is a good overview about the rootkit PoC and takes into consideration lot's of security measures to detect an attack vector like image binary modification... but what about using the same technique (find strings to find important functions) is applied on-the-fly or by a shellcode?
He mentions that TCL scripts can be easily detected in startup/running configuration but what if the functions that read the startup file and display running processes are manipulated?
I don't want to start enumerating counter measures to the detection measures because this is the same as the virii & AV race where one creates a new way to infect a machine and the other creates a new way to detect it and so on. Besides Nico is right that it is a 'noisy' to perform that kind of rootkit deployment but like said before, what if this is performed using a shellcode via a remote exploit?
Don't get me wrong, I really liked what Nico wrote but just want to say that there is always a way to enhance 'things' to bypass security, right?

Another important thing is to follow Cisco security guidelines... just in case because you never know if some inside user gets pissed off and installs it before leaving the company? :/

PH-Neutral 0x7d8 Soccer World Cup finals

Italian table soccer team (Igor - twiz) beats Argentinian team (shadown - topo) :(
Next year we'll have a rematch after some practice, of course... hahahaha
Here is a link to the YouTube video uploaded by a friend of mine (thanks Mario) in case you can't see the video bellow.

Rootkits on routers... uhm

Pretty noisy topic, right? Well, this is definitely not a new thing. Rootkits for IOS existed for quite a few years and that is what i told Sean when we talk about my presentation on EuSecWest among some other things.

Remember the news about stolen IOS source code? That definitely helped the bad guys cause reversing and entire IOS image was not necessary anymore... so what do you think the bad guys did with this source code? :P

printf("Hello World\n");

Every nerd makes it's first blog post with a 'hello world' reference, right?
I can't help it...
Anyway, this is a blog created to dump all sort of crazy ideas that get inside my head and share them with everyone interested.
I'll also put some code here that made my life easier when I was reversing some crappy code :P

see ya!