Reversemode
Home
Wednesday, 23 April 2014
 
 
BYTES & WORDS
Project Basecamp - Attacking ControlLogix PDF Print
Written by Rubén   
Thursday, 19 January 2012

You can download my contribution to the Digitalbond's project basecamp by clicking on the image.

Extracted from the report "One of the most time consuming tasks I came across during this research was reading all the technical documentation gathered. Initially this fact may sound weird but it is nothing unusual at all; while researching into industrial devices, which commonly suffer from a lack of strong security measures implemented by design, the hardest part is not learning how to break things but understanding how it really works.

Therefore, the key point behind attacking this PLC was not how to circumvent its security but monitoring how the legitimate software performed valid operations in order to mimic them, in addition to the usual dose of reverse engineering and fuzzing to discover the ‘secrets’ behind the scenes. To sum up, any legit functionality supported by the controller could also be used by a malicious user in a malicious manner.

During this ‘journey’ we have identified problems that can be used to cause a DoS, load a trojanized firmware or leak information. Actually it’s not a bug, it’s a feature."


I'd say the underlying problem is that some of these 'attacks' are actually features documented in the CIP protocol, so again "any legit functionality supported by the controller could also be used by a malicious user".Within this context, the following article worths a read DHS Thinks Some SCADA Problems Are Too Big To Call "Bug"

Congrats to Reid and to all the researchers involved as well as thanks to Dale for counting on me for this project.


You can watch the following video, showing the results of the "Deep fried controller" exploit.

Last Updated ( Friday, 20 January 2012 )
Reversing Industrial firmware for fun and backdoors I PDF Print
Written by Rubén   
Monday, 12 December 2011

Update:ICS-CERT alert http://www.us-cert.gov/control_systems/pdf/ICS-ALERT-11-346-01.pdf

Update:Schneider alert http://www.global-download.schneider-electric.com/85257563005C524A/All/0C7358A0825BD0D2C1257966001F1B90?Opendocument


Hi

Everybody knows I'm commited to hack into the LHC and then blow up the world, my first try was 4 months ago, as you can see below this post, I published “The power of reading: the CERN case” where I explained the method used to obtain confidential information about the LHC that lead me to 'hack' into the CERN (not really). Anyway, if you carefully take a look at the picture that contains some PLCs modules, you'll distinguish their names; one of them was “NOE 771”.

Last Updated ( Thursday, 19 January 2012 )
Read more...
The power of reading: The CERN case. PDF Print
Written by Rubén   
Thursday, 18 August 2011

First of all my respect and admiration to the people working at CERN and to scientists in general. Humanity has evolved thanks to minds like theirs. I guess we all would agree that the most useful advice commonly received, or given, in this sector is: read, read everything that you can, and more...and that's how this story begins.

Some time ago, I spent a few hours compiling all the documentation/software I could find about UNICOS (Unified Industrial Control System ), which is the SCADA system of the CERN's Large Hadron Collider. Finally I managed to grab +2 GB of related stuff. Yes, there are quite a few information and software available, it's the good thing about the academic world, on the other side some of that information shouldn't be publicly available. This is a problem inherent to the academia: a lot of people accessing a lot of systems from a lot of places. A security nightmare for network administrators. I.e Did you ever try to navigate public AFS folders? oh boy...

Last Updated ( Monday, 12 December 2011 )
Read more...
Reversing DELL's DRAC firmware PDF Print
Written by Rubén   
Monday, 15 August 2011

Update #1 http://twitter.com/#!/reversemode/status/103372506869661696
Update #2 http://twitter.com/#!/reversemode/status/103386457707782144 pam_local_manager.so != pam_unix.so so /etc/shadow is not being used to authenticate users :(

Hi,

Firmware reversing is really interesting, better said not only interesting but mandatory when you are researching into SCADA devices.

However, this time I'm going to explain how to discover vulnerabilities on embedded systems, without needing the device at all. In this case, our target is the latest version of DELL's out-of-band management system: iDRAC 6.

When facing a new software / hardware, first of all is to find as much documentation as possible about the system. By reading Wikipedia's entry about DRAC we come across the most important references, moreover simple google searches show a lot of interesting results.

Although the source code of certain components of DELL DRAC firmware are available, Dell does not provide neither the environment to create a functional firmware nor the code of a fully functional final version. Therefore, we do not have access to the more interesting part, reverse engineering comes into play.

Let's see how far we can go. You can download the latest version from Dell's support page http://support.us.dell.com/support/downloads/format.aspx?releaseid=R299265&c=us&l=en&cs=&s=gen

It's a self-extracting zip that unpacks two files, one of them is the firmware "firmimg.d6" (54mb).

Now, we can start by using binwalk to see how many info it can extract. We can not blindly trust this program, based on signatures, since sometimes it returns false positives and/or results that make nonsense. Anyway, it's a good starting point.

DECIMAL | HEX | DESCRIPTION
-------------------------------------------------- ------------

0x200 512 uImage header, created: Sat Mar 12 21:17:47 2011, image size: 4479904 bytes, Data Address: 0x8000, Entry Point: 0x8000, CRC: 0x1BB8BE08, OS: Linux CPU: ARM, image type: OS Kernel Image, compression type: none, image name: arm-linux
12424 0x3088 romfs filesystem, version 1 1,892,957,376 bytes, named \ 240 \ 324 <\ 300hsqs \ 324 \ 324 <\ 300 \ 177 \ 023.
12436 0x3094 ROM filesystem Linux Compressed data, little endian size 0xc03cd538 3225212064 CRC, edition 3225212264, 3225738208 blocks, files 3225738220
0x309C 12444 Squashfs filesystem, little endian, version 54632.49212, 4991 bytes, -1069755180 inodes, blocksize: 56288 bytes, created: Fri Aug 11 4:51:44 2006
103296 gzip compressed data 0x19380, from Unix, last modified: Sat Mar 12 21:10:25 2011, max compression

These are some results, mostly false postivies. The only valid result is located at 0×200. It is quite common to find an image of the bootloader u-Boot (both standalone and kernel image). We are not particularly interested in this image, although we could debug through qemu-system-arm compiled with gdb debugging stubs and gdb/IDA.

Taking into account the firmware file is about 54mb, it should contain much more than a kernel. Analyzing the file's entropy , for example by using one of the latest commits of radare2 (thx @trufae!) "rahash2 -b 512 -a entropy firmimg.d6" or just by taking a look at the file we'll see how at offset 0x45b0000 a big area of high entropy, which usually means compressed or encrypted data, can be observed Above that area we find

Last Updated ( Monday, 12 December 2011 )
Read more...
Silent bug is silent. PDF Print
Written by Rubén   
Wednesday, 10 August 2011

Hi there,
During the last months, completed in this Patch Tuesday, Microsoft has 'abruptly' changed a policy that was working for years: http://blogs.msdn.com/b/ieinternals/archive/2011/03/09/internet-explorer-9-xbap-disabled-in-the-internet-zone.aspx

I guess that XBAP apps were posing a risk level too high to get accepted. At the same price, they have silently fixed a blatant method to bypass IE protected mode I discovered long time ago...let me explain it briefly.

There are 3 main integrity levels: low, medium, high. IE8/9 launches two differente process.

-> Broker/Monitor (medium integrity) (parent)
-> Browser (low integrity) (child)

The low integrity instance is where those funny shellcodes are executed, so we should understand this flaw as the second stage within a client-side exploitation scenario. Therefore, a remote code execution is mandatory before taking advantage of this flaw.

A common scenario would be the following:

1. Ban Ki-Moon visits a malicious U.N website where a RCE vulnerability is triggered within the context of the low integrity IE
2. Local exploit is executed to bypass IE Protected mode.
3. VLC playing Nyan Cat video is launched as a medium integrity process.

Last Updated ( Monday, 15 August 2011 )
Read more...
<< Start < Prev 1 2 3 4 5 6 7 8 Next > End >>

Results 1 - 9 of 71