Category Archive: Reverse engineering

Jul 06 2016

An insight in Knox

Samsung provides for its Galaxy devices an enterprise mobile security solution Knox. Among the features, Knox offers Workspace that compartments the mobile device in two spaces: user space and Knox space. Of course, the Knox space is running in a TrustZone™ and executes only authenticated trusted applications. There is not much public information about the actual implementation of Knox.

Uri Kanonov and Avishai Wool have lifted a part of the veil by reverse engineering Knox 1.0. Their paper provides an interesting in-depth description of some secure mechanisms such a compartmentalization (based on SELinux) or encryption file system. They also disclose some vulnerabilities. The last section describes some enhancements available in Knox 2.3 as well as some remaining issues.

An interesting element of the paper is the list of lessons:

  • Component reuse is welcome, provided a proper protection for the added attack surface.
  • Protect the software code of secure components
  • Validating the application authorized to run in the Trust Zone is key for security
  • Hardware Root of Trust should be at the root of any secure container system
  • Avoid resource sharing; it increases the attack surface.
  • Check the integrity of the secure container periodically; only checking at boot time is insufficient.

If you want to learn more about Knox, this paper is a good reading.

Kanonov, Uri, and Avishai Wool. “Secure Containers in Android: The Samsung KNOX Case Study.” arXiv, May 27, 2016. http://arxiv.org/abs/1605.08567.

Nov 23 2015

Attackers are smart

In 2010, Steven MURDOCH, Ross ANDERSON, and their team disclosed a weakness in the EMV protocol. Most Credit / Debit card equipped with a chip use the EMV (Europay, MasterCard, Visa) protocol. The vulnerability enabled to bypass the authentication phase for a given category of transactions. The card does not condition transaction authorization on successful cardholder verification. At the time of disclosure, Ross’s team created a Proof Of Concept using an FPGA. The device was bulky. Thus, some people minored the criticality.

The team of David NACCACHE recently published an interesting paper disclosing an exemplary work on a real attack exploiting this vulnerability: “when organized crime applies academic results.” The team performed a non-destructive forensic analysis of forged smart cards that exploited this weakness. The attacker combined in a plastic smart card the chip of a stolen EMV card (in green on the picture) and an other smart card chip FUN. The FUN chip acted like a man in the middle attack. It intercepted the communication between the Point of Sales (PoS) and the actual EMV chip. The FUN chip filtered out the VerifyPIN commands. The EMV card did not verify the PIN and thus was not blocked in case of the presentation of wrong PINs. On the other side, the FUN chip acknowledged the PIN for the PoS which continues the fraudulent transaction.

Meanwhile, the PoS have been updated to prevent this attack.

This paper is an excellent example of forensics analysis as well as responsible disclosure. The paper was published after the problem was solved in the field. It discloses an example of a new potential class of attacks: Chip in The Middle.

Law 1: Attackers will always find their way. Moreover, they even read academic publications and use them.

Oct 15 2015

iOS 9 is jailbroken

The official release date for iOS 9 was 16 September 2015.  It did not take long for the Chinese Pangu team to set-up a jailbreaking exploit (here).   Since iOS 7, Pangu team released jailbreak exploits.

The exploit requires a Windows computer. 

 

Mar 13 2015

RowHammer: A powerful new attack

In 2014, a group of researchers from Carnegie Mellon University and Intel published a new kind of disturbance attack on DRAM: rowHammer [1]. At the difference of SRAM (static), DRAM (dynamic) need regular refreshing to keep their memory. DRAM are organized by rows. Indeed, when reading or writing to an address, the circuit access the full row rather than only one specific cell. Cells are susceptible to inter-cell crosstalk (like any electronic elements). The researchers discovered the fast, repetitive reading of two rows they could generate a high rate of disturbances that produce errors in the memory. The actual code to produce errors is simple and short. It is a simple loop that reads two addresses, flushes the registers and the instruction cache. A typical 1 million iterations takes less than one second. The code does not need to be root. They tested 129 different DDR3 DRAM commercial modules. They induced errors in 110 modules.

Thus, they demonstrate that with simple software, it was possible to wreck DRAM memory.

This month, Google researchers went one step further. They used the rowHammer technique to create actual fault injection. On a standard x86-64 bit machine, they demonstrated two exploits [2].

  • Native Client (NACl) is a sandboxing system that allows only a limited subset of instructions. They were able to have ‘blacklisted’ instructions to execute in the NACl environment.
  • They succeeded to escalate the privilege to Kernel privilege on a standard Linux.

Of course, these exploits have some limitations. The escalation was done only on a Linux machine without some sandboxing mechanisms. Nevertheless, they highlight that rowHammer may become a powerful fault injection tool. The interesting part of rowHammer is that it is purely software.

Currently, they have only experimented rowHammer on standard DRAM commercial modules. This may be an interesting way to bypass some trusted execution environment that isolate the DRAM space.

DRAM for servers should be more resistant to rowHammer as Error Correction is embedded in the chip. Nevertheless, error correction can only correct a limited amount of simultaneous errors. It may be possible perhaps to also overflow the correction. If rowHammer would be possible on DRAM for servers, then it may be a potential interesting attack vector in the public cloud. The attacker may either bypass the sandbox or impair the memory of another user of the same server.

We may see in coming months more studies and exploits around rowHammer. Will it have the same impact than side channel attacks? To be surveyed…

The two papers are worthwhile to read. Read them in the chronological order.

[1]    Y. Kim, R. Daly, J. Kim, C. Fallin, J. H. Lee, D. Lee, C. Wilkerson, K. Lai, and O. Mutlu, “Flipping bits in memory without accessing them: An experimental study of DRAM disturbance errors,” in Proceeding of the 41st annual international symposium on Computer architecture, 2014, pp. 361–372.

[2]    C. Evans, “Project Zero: Exploiting the DRAM rowhammer bug to gain kernel privileges,” Project Zero, 09-Mar-2015.

 

Feb 23 2015

Lenovo, Superfish, Komodia: a Man In The Middle story

Lenovo has made this week the headlines with the alleged malware: superfish.   Lenovo delivered  some PCx loaded with “bloatware” Superfish.  Superfish provides solution that performs visual search.  Seemingly, Superfish designed a software that allowed to place contextual ads on the web browsing experience.   To perform this highjacking, superfish uses a software stack from Komodia:  SSL Digestor.  According to the site of Komodia:

Our advanced SSL hijacker SDK is a brand new technology that allows you to access data that was encrypted using SSL and perform on the fly SSL decryption. The hijacker uses Komodia’s Redirector platform to allow you easy access to the data and the ability to modify, redirect, block, and record the data without triggering the target browser’s certification warning.

How does Komodia do the decryption without triggering the certificate validation of the browser?   The CERT has disclosed on Thursday the trick with its vulnerability note VU#529496.

Komodia Redirector with SSL Digestor installs non-unique root CA certificates and private keys, making systems broadly vulnerable to HTTPS spoofing

Komodia install stealthily its own root certificate within the browsers’ CA repository.   The stack holds its private key. This allows to ‘self-sign’ certificate to forge SSL connection.  The software then generates a typical Man In The Middle.   Despite the private key was encrypted, it was possible to extract some corresponding private keys (easy to guess the password; komodia).  This means that as long as the root key is not erased from browsers’ repository, an attacker may use the corresponding private key.  The attacker may sign malware that would be accepted by the machine, and generate phony certificates for phishing.   In other words, other principals than Superfish may use the hack for infecting Lenovo computers.

Lenovo provided a patch that removed the Superfish application.   Unfortunately, the patch does not erase the malicious certificate.  Microsoft provided such patch, and Mozilla should soon revoke it.

This is a perfect example of supply chain attack. The main difference is that the supplier voluntarily infected its product.    Do never forget law 4: Trust No One.

PS:  at the time of writing, the Komodia site was down, allegedly for a DOS.  It may also be because too many people try to visit the site.

Feb 13 2015

Does your TV set watch you?

Benjamin Michele and Andrew Karpow presented a scary Proof of Concept  using two Samsung Smart TVs.  They used the integrated media player of these Smart TV set.  For the most recent one, they discovered that the TV set used a 2011 version of the open source FFMPEG’s libavformat library. This library identifies the type of content to be played and demux it before the content is transmitted to Samsung’s proprietary media player.  The libavformat library supports many containers.  It is a complex piece of software, and as such as many new discovered bugs. By scanning the bug-tracking database of this open source library, the researchers selected one vulnerability that was not patched in the version used by the TV set.  This vulnerability allowed them to execute arbitrary code when playing a forged content.  As the player executes in root shell, the forged payload also executes in root shell.  This means that the payload has full access to the platform.  As the Smart TV had an integrated camera and microphone, they wrote an exploit that captured the video of the camera and the sound from the microphone.  The captured information can then be sent to a remote server.  As the payload is encapsulated in a real movie, the consumer is not aware that his TV set is being infected and that he is spied.  The researchers found a way to flash the Smart TV set and thus make the infection permanent.

Of course, the payload could do other things.  The researchers could perform a thorough analysis of the TV set because they succeeded to get root access, and thus could explore the system and easily work on the exploit. The target were Samsung TV sets.  Most probably, any other smart TV of any brand could be attacked in a similar way but using another vulnerability.

This POC highlights several interesting points:

  • This exploit highlights an important issue of IoT.  Will devices in the field be upgraded and securely patched?  There are two issues that are not yet solved:
    • Will manufacturers do the security maintenance for the lifetime of the product?   Currently, the business model is to sell one device and not maintain it (unless there is a very serious bug that impact the behaviour).  How could the manufacturer finance this maintenance?  In the software world, maintenance is financed by either new version or maintenance contract for professional expensive applications.  This is not the case in the consumer domain.
    • Will consumers apply the patch?  The likelihood is low if we extrapolate from the computer world. Too many consumers’ computers are not patched.
  • The wide use of open source libraries has brought some benefits.  It is less expensive for companies and it is claimed to be more secure.  Unfortunately, it also has its downside.
    • This last claim is only true if all systems would be patched.  If it is not the case, then the use of widely deployed open source libraries may be an advantage for the attackers.  The attacker can experiment on his own system before trying on the targeted device.
    • Furthermore, the more a ‘common’ library is deployed, the more targets will be hit whenever a vulnerability is found in this library.  Heartbleed is a good illustration.
  • The more features a device has, the higher the risk to have vulnerabilities.

Reference:

Michele, Benjamin, and Andrew Karpow. “Watch and Be Watched:  Compromising All Smart TV Generations.” In Proc. of the 11th Consumer Communications and Networking Conference (CCNC). Las Vegas, NV, USA: IEEE, 2014.

Jan 08 2015

Thundertrike: the first bootkit for Mac OS X

At CCC 2014 winter session, Trammel Hudson disclosed the first known proof of concept of a bootkit for Mac OS X.   Bootkits are a special category of rootkits that stealthily infect the master boot record or volume boot record.  In other words, it is a rootkit that installs itself in the boot system of the machine.

His exploit uses several weaknesses in the boot system of Mac OS X.

  1. The integrity of the boot ROM (which is indeed an EEPROM, to allow an upgrade) is protected by a CRC32 rather than by a cryptographic signature.  Unfortunately, the purpose of CRC is to check whether the software is not corrupted (i.e. no mistake),  CRC does not verify whether a software was altered.  He knows now that he may alter the boot process software.  He now had to find a smart way to do it.
  2. The firmware, to upgrade with Extensible Firmware Interface (EFI), is RSA 2048 signed.  However, the check is done by the boot software that can be impaired.  EFI is the replacement of BIOS. At this point, he knows that he may load his own firmware at boot using EFI.  But how could it provide the firmware to the targeted machine?
  3. He used a trick that was demonstrated in 2012.  At boot time, EFI asks externally connected devices via PCIe if they have any Option ROMs to execute.  Thunderbolt port allows thus to load an arbitrary firmware from a connected device.
  4. He fooled the boot firmware by replacing Apple’s public key with his own public key letting Apple software taking care of checking his malware.   Later, this key is written down in the ROM thus preventing any Apple legitimate upgrade to occur . Only upgrades signed by his private key will be accepted.

The potential attack is to have a forged thunderbolt device with the malware as Option ROM.  The attacker needs physical access to the target, boot it with the connected thunderbolt device, and then the attacker owns the machine.  It is fast.

This only a proof concept and no field attack have been yet discovered.  Apple is preparing fixes that do not allow Option ROM during a firmware upgrade.  The patch is already available for new Mac Mini and Retina.  It will be available soon for all Thunderbolt models.

He mitigates the error of Apple for using CRC32 rather than crypto by stating:

In actuality, any software-only validation is doomed to fail since if an attacker can get code into the ROM, they can just skip that software validation. Either by always returning true or by returning a cached value computed over the boot  ROM. Without some sort of hardware cryptographic signature checks or an actual, unchangable mask ROM, this sort of software-only attempt is futile.

His presentation, which he retranscripted on his site, is an excellent description of the work of a reverse engineer.  He shows some tricks such as looking for strings (too often there are printf remaining in the code), look for hexadecimal sequences on the Net to find corresponding tool signature, …  An excellent reading.

Lesson:  Law 1: attackers will always find their way (even on Mac)

Older posts «