Tag: infosec

INSIGHTS | February 3, 2012

Solving a Little Mystery

By Ruben Santamarta

Firmware analysis is a fascinating area within the vast world of reverse engineering, although not very extended. Sometimes you end up in an impasse until noticing a minor (or major) detail you initially overlooked. That’s why sharing methods and findings is a great way to advance into this field.

While looking for certain information during a session of reversing, I came across this great post. There is little to add except for solving the ‘mystery’ behind that simple filesystem and mentioning a couple of technical details.

 

This file system is part of the WindRiver’s Web Server architecture for embedded devices, so you will likely find it inside firmwares based on VxWorks. It is known as MemFS (watch out, not the common MemFS) or Wind River management file system, and basically allows devices to serve files via the embedded web server without needing an ‘actual’ file system since this one lies on its non-volatile memory.

 

VxWorks  provides  pagepack, a tool used to transform any file intended to be served by a WindWeb server into C code. Therefore, a developer just compiles everything into the same firmware image.

 

 

 

 From a reverser’s point of view, what we should find is the following structure:
 
 

 There are a few things  here worth mentioning:

 

  • The header is not necessarily 12 but 8 so the third field seems optional.
  • The first 4 bytes look like a flag field that may indicate, among other things,  whether  a file data will be compressed or not (1 = Compressed, 2 = Plain)
  • The signature can vary between firmwares since it is defined by the constant ‘HTTP_UNIQUE_SIGNATURE’ , in fact, we may find this signature twice inside a firmware; the first one due to  the .h  where it is defined (close to other strings such as the webserver banner )and the second one already as part of  the MemFS.
Hope these additional details help you on your future research.

 

INSIGHTS | January 17, 2012

A free Windows Vulnerability for the NSA

By Cesar Cerrudo

Some months ago at Black Hat USA 2011 I presented this interesting issue in the workshop “Easy and Quick Vulnerability Hunting in Windows,” and now I’m sharing it with all people a more detailed explanation in this blog post.

In Windows 7 or Windows 2008, in the folder C:WindowsInstaller there are many installer files (from already installed applications) with what appear to be random names. When run, some of these installer files (like Microsoft Office Publisher MUI (English) 2007) will automatically elevate privileges and try to install when any Windows user executes them. Since the applications are already installed, there’s no problem, at least in theory.

 

However, an interesting issue arises during the installation process when running this kind of installer: a temporary file is created in C:UsersusernameAppDataLocalTemp, which is the temporary folder for the current user. The created file is named Hx????.tmp (where ???? seem to be random hex numbers), and it seems to be a COM DLL from Microsoft Help Data Services Module, in which its original name is HXDS.dll. This DLL is later loaded by msiexec.exe process running under the System account that is launched by the Windows installer service during the installation process.

 

When the DLL file is loaded, the code in the DLL file runs as the System user with full privileges. At first sight this seems to be an elevation of privileges vulnerability since the folder where the DLL file is created is controlled by the current user, and the DLL is then loaded and run under the System account, meaning any user could run code as the System user by replacing the DLL file with a specially-crafted one before the DLL is loaded and executed.

 

Analysis reveals that the issue is not easily exploitable since the msiexec.exe process generates an MD5 hash of the DLL file and compares it with a known-good MD5 hash value that is read from a file located in C:WindowsInstaller, which is only readable and writable by System and Administrators accounts.

 

In order to exploit this issue, an attacker needs to replace the DLL file with a modified DLL file that contains exploit code that can match the valid MD5 hash. The attacker DLL will then be run under the System account, allowing privilege elevation and operating system compromise. The problem is that this is not a simple attack—it’s an attack to the MD5 hashing algorithm referred to as a second-preimage attack for which there are no practical attacks that I know of, so it’s impossible for a regular attacker to generate a file with the same MD5 hash as the existing DLL file.

 

The reason for the title of this post comes from the fact that intelligence agencies, which are known for their cracking technologies and power, probably could perform this attack and build a local elevation of privileges 0day exploit for Windows.

 

I don’t know why Microsoft continues using MD5; it has been banned by Microsoft SDL since 2005 and it seems there has been some component oversight or these components have been built without following SDL guidance. Who knows on what other functionality MD5 continues to be used by Microsoft, allowing abuse by intelligence agencies.

 

Note: When installing some Windows updates, the Windows Installer service also creates the same DLL file in the C:windowstemp folder, possibly allowing the same attack.

 

The following YouTube links provide more technical details and video demonstrations about this vulnerability.

References.

INSIGHTS | October 3, 2011

Windows Vulnerability Paradox

By Cesar Cerrudo
For those who read just the first few lines, this is not a critical vulnerability. It is low impact but interesting, so keep reading.

 

This post describes the Windows vulnerability I showed during my Black Hat USA 2011 workshop “Easy and Quick Vulnerability Hunting in Windows”.

 

The Windows security update for Visual C++ 2005 SP1 Redistributable Package (MS11-025) is a security patch for a binary planting vulnerability. This kind of vulnerability occurs when someone opens or executes a file and this file (or the application used to open the file) has dependencies (like DLL files) that will be loaded and executed from the current folder or other folders than can be attacker controlled. This particular vulnerability allows an attacker to execute arbitrary code by tricking a victim user into opening a file from a network share. When the victim user opens the file, the application associated with the file is executed, and an attacker-crafted DLL file is loaded and executed by the application.

 

It’s either funny or scary (you choose) that the Windows security update meant to fix the above-described vulnerability is also vulnerable to the same kind of vulnerability it fixes, and it can be exploited to elevate privileges.

 

When installing the security update on 64-bit Windows 7, the file vcredist_x64.exe is downloaded and then executed under the System account (the most powerful Windows account, it has full privileges) with some command line options:

 

C:WindowsSoftwareDistributionDownloadInstallvcredist_x64.exe” /q:a /c:”msiexec /i vcredist.msi /qn
After being run, vcredist_x64.exe tries to launch the msiexec.exe process from theC:WindowsTempIXP000.TMPtemporary folder, which is where the vcredist.msi used in the command line option is located, but because msiexec.exe doesn’t exist there, vcredist_x64.exe will fail to run it. Then vcredist_x64.exelaunches msiexec.exefrom C:WindowsSysWOW64, where msiexec.exe is located by default on 64-bit Windows 7.

 

There is an obvious vulnerability and it can be exploited by low-privilege Windows users since theC:WindowsTempIXP000.TMP temporary folder DACL has write permissions to the Users group, so any Windows user can place in that temporary folder a file named msiexec.exe and execute arbitrary code under the System account when they attempt to install the vulnerable security update.

 

While this is an interesting vulnerability, it’s not critical at all. First, to be vulnerable you have to have the vulnerable package installed and without the security update applied. Second, for an attacker to exploit this vulnerability and elevate privileges, the option “Allow all users to install updates on this computer” must be enabled. This option is enabled on some systems, depending on configuration settings about how Windows updates are installed.

 

This presents an interesting paradox in that you’re vulnerable if you haven’t applied the vulnerable patch and you’re not vulnerable if you have applied the vulnerable patch. This means that the patch for the vulnerable patch is the vulnerable patch itself.

 

The following links provide some more technical details and video demonstrations about this vulnerability and how it can be exploited:
References
INSIGHTS |

Easy and Quick Vulnerability Hunting in Windows

By Cesar Cerrudo

I’m glad to start this new blog for IOA Labs by publishing the video demonstrations and updated slides of my Black Hat USA 2011 workshop. I hope you like it, please send me your feedback, questions, etc. We will continue posting cool materials from our researchers very soon, keep tuned!

INSIGHTS | March 20, 2011

Blackhat TPM Talk Follow-up

By Cesar Cerrudo

Since speaking at BlackHat DC 2009, there have been several inquiries in regards to the security of the SLE66PE series smartcard family.

Here are some issues that should be pointed out:

We have heard, “..it took 6 months to succeed..“

The reality is it took 4 months to tackle obsticles found in any <200nm device such as:

  1. Capitance/load of probe needles when chip is running.
  2. Powering the device inside the chamber of a FIB workstation.
  3. Level-shifting a 1.8v core voltage following what we learned in #1 above.
  4. Cutting out metal layers without creating electrical shorts.
  5. Other more minute issues regarding the physical size of the die.

Upon overcoming the points above,  the actual analysis required no more than approximately 2 months time.

In addition, these techniques listed above apply to all devices in the <200nm category (SecureAVR, SmartMX, ST21, ST23).

We have heard, “…you said the Infineon SLE66 was the best device out there in the market…“

The Infineon SLE66PE is a very secure device however, it (as do it’s competitors) all have their strengths and weaknesses.

Some examples of weaknesses are

  1. Layout of all Infineon SLE50/66 ‘P’ or ‘PE’ are very modular by design
  2. Lack of penalty if active shield is opened
  3. Begin runtime from a CLEAR (unencrypted) ROM which is ‘invisible’ to the user
  4. CPU core is based on a microcode/PLA type implementation
  5. Power-on-reset always begins running from the externally supplied clock
  6. Current design is based on a previous 600nm version designed around 1998
  7. 3 metal layer design for “areas of interest” (4th layer is the active shield)

Some examples of strengths are:

  1. ‘PE’ family used bond-pads located up the middle of the device.
  2. ROMKey must be loaded before begin attacked (else you just see their clear ROM content).
  3. MED is quite powerful if used properly for EEPROM content.
  4. Mesh is consistent across the device and divided into sections.
  5. Auto-increment of memory base address.
  6. Mixing of physical vs. virtual address space for MED / memory fetch.

No device is perfect.  All devices have room for improvement.  Some things to consider when choosing a smartcard are:

  • Does CPU ever run on external clock?
  • What is the penalty for an active-shield breach?
  • What is the fabrication process geometry?
  • How many metal layers is the device?
  • List of labs who might have evaluated this device and their capabilities.

Lastly, just because the device has been Common Criteria certified does not mean much to an attacker armed with current tools.  This is a common-oversight.

There is an ST23 smartcard device which has recently been certified EAL-6+ and the device has an active-shield with almost 1 micron wide tracks and a 1-2 micron spacing!!!  This makes a person scratch there head and say, “WTH????”

We have some new content to post soon on the blog.  Be sure and tune in for that.  We will tweet an alert as well.

INSIGHTS | August 9, 2010

Atmel ATMEGA2560 Analysis (Blackhat follow-up)

By Cesar Cerrudo

At this years Blackhat USA briefings, the ATMEGA2560 was shown as an example of an unsecure vs. secure device.  We have received a few requests for more information on this research so here it goes…

The device did not even need to be stripped down because of designer lazyness back at Atmel HQ.  All we did was look for the metal plates we detailed back in our ATMEGA88 teardown last year and quickly deduced which outputs were the proper outputs in under 20 minutes.

Atmel likes to cover the AVR ‘important’ fuses with metal plating.  We assume to prevent the floating gate from getting hit with UV however the debunk to this theory is that UV will SET the fuses not clear them!

For those who must absolutely know how to unlock the device, just click on the, “Money Shot!”

INSIGHTS | August 7, 2010

Parallax Propeller P8X32A Quick Teardown

By Cesar Cerrudo

Parallax has a really neat 8 core 32 bit CPU called the ‘Propeller’.  It’s been out for a few years but it is gaining popularity.  There is no security with the device as it boots insecurely via a UART or I2C EEPROM.  None the less, we thought it was interesting to see an 8 core CPU decapsulated!

One can clearly see 8 columns that appear almost symmetric (except in the middle region).  The upper 8 squares are each ‘cogs’ 512 * 32 SRAMs as described in the manual.  The middle left 4 and right 4 squares are the ROM’s Parallax describes.  The 8 rectangular objects are the 32KB SRAM as described.  The 8 cores are basically the 8 columns above the middle ROM’s to include the 512 * 32 SRAMs because they describe each cog as having it’s own 512 * 32 SRAM :).

Last but not least is the logo by Parallax.  Nice job Parallax on this beast!  We have one favor-  implement some flash on the next generation with a security bit ;).

INSIGHTS | August 6, 2010

Echostar v NDS appellate court ruling update

By Christopher Tarnovsky

Normally, I would not mix non-technical with the blog however I thought this deserved a little more attention that it has received.

The ruling which states that NDS has won the lawsuit, vindicates myself and puts Echostar owing NDS almost 18,000,000.00 USD has come down as of 2 days ago.

As well I thought it nice to mention that neither Flylogic nor myself works for/or with Echostar, Nagra, NDS or any other conditional access company in any way or form.

I wish all persons whom this lawsuit  effects the best (yes even you Charlie),

Christopher Tarnovsky

INSIGHTS | February 14, 2010

Infineon / ST Mesh Comparison

By IOActive

Given all the recent exposure from our Infineon research, we have had numerous requests regarding the ST mesh architecture and how Infineon’s design compares to the ST implementation.

Both devices are a 4 metal ~140 nanometer process.  Rather than have us tell you who we think is stronger (it’s pretty obvious), we’d like to see your comments on what you the readers think!

The Infineon mesh consists of 5 zones with 4 circuits per zone.  This means the surface of the die is being covered by 20 different electrical circuits.

The ST mesh consists of a single wire routed zig-zag across the die.  It usually begins next to the VDD pad and ends at the opposite corner of the die.  The other wires are simply GND aka ground fingers.  On recent designs, we have caught ST using a few of the grounds to tie gates low (noise isolation of extra, unused logic we believe).

Zooming in at 15,000 magnification, the details of each mesh really begin to show.  Where at lower resolutions, the Infineon mesh looked dark and solid but as you can see, it is not.

In the Infineon scheme above, each colored wire is the same signal (4 of them per zone).  Each color will be randomly spaced per chip design and is connected at either the top or bottom of the die via Metal 3 inter-connects.

The ST simply has the single conductor labeled in red.  All green are the fingers of ground which can be usually cut away (removed) without penalty.  The latest ST K7xxx devices have a signal present that appears analog.  A closer look and a few minutes of testing proved it to simply need to be held high (logic ‘1’) at the sampling side of the line.  Interesting how ST tried to obscure the signal.

Infineon does not permanently penalize you if the mesh is not properly repaired and the device is powered up.

ST will permanently penalize you with a bulk-erase of the non-volatile memory (NVM) areas if the sense line (red) is ever a logic low (‘0’) with power applied (irrelevant of reset/clock condition).

You tell us your opinion what you think security wise.

INSIGHTS | February 12, 2010

We are now on Twitter too!

We probably should have been tweeting (sic?) for some time now but we are finally doing it!

You can join/follow us here: https://x.com/semiconduktor

As well, you can always get to Flylogic through Semiconduktor.com or Semiconduktor.net :).