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.

Feb 05 2015

IoT, Security and energy

Trappe, Howard and Moore, three researchers from the University of Rutgers, have published an interesting paper in the latest issue of IEEE Security & Privacy.   The title is ‘Low-Energy Security: Limits and Opportunities in the Internet of Things’

IoT will not only be connected phones, TVs, or fridges, it will also be myriads of tiny sensors (the famous concept of smart dust).   Whereas the big devices have reasonable access to energy and calculation, these sensors  do not have access to energy and calculation.  They will have two issues:

  • A very low energy consumption;  You do not expect to charge every day a thermal sensor.  You will rather install it and forget about it for many years.
  • As they are low cost and low energy consumption, the calculation capabilities will be drastically reduced.

Unfortunately, the collected data will serve to major decisions by applications or may leak private information. They will need to be protected in integrity, and confidentiality.  With the hardware constraints, conventional cryptography is out of reach.   Moreover, poor security is not an option (it is useless), there is a major challenge for the security of IoT.

They present some of the potential new methods to secure the communication.  For instance, the receiver that has serious calculation power could authenticate the sensor by fingerprinting the analog characteristics of the transmission.  This would not put any burden on the sensor.   To reduce the encrypted data which burns energy, they propose to encrypt only major variations.  This may open interesting side channel attacks.  For confidentiality, they propose to revisit the concept of ‘wire-tap channel’ disclosed by Wyner in 1975.

The paper is worthy to read as it clearly states the problems and highlights some potential research topics.

 

Jan 26 2015

Opportunistic Security

Under the lead of Dukhovni (2 sigma), IETF issued an interesting concept:  Opportunistic Security (RFC 7435).  Currently, communications are either cleartext or authenticated and encrypted.    Unfortunately, wide scale deployment of ‘inter-operable’ authentication schemes is difficult.  The internet is a good example with hundreds of certification authorities with not all them trustworthy.

With current protocols, if the authentication fails, then either the communication fails or falls back to clear text.  Opportunistic security proposes a new approach.

  • The default state is clear text.
  • If ever encryption is available between peers, then communication uses the encrypted service.   This communication is protected against passive attacks, but still vulnerable to active attacks such as man in the middle.
  •  If ever authentication is also available between peers, then the protocol attempts to authenticate.  if successful, it would use encryption with a negotiated session key.  This communication  is protected against both passive and active attacks.  If the authentication fails, then communication falls back to encrypted communication.

The announced concept is that encryption alone, even with deprecated algorithms,  is better than clear text.   The wide use of encryption would thwart , at least, information collection by sniffing.   The claimed purpose is to boost the deployment and use of encryption technologies to prepare the later proper deployment of authenticated protocols.

The idea is interesting.  Nevertheless, I believe that a mandatory component  would be to indicate clearly to the user in which mode his communication is currently: clear, encrypted, authenticated and encrypted.  This would be an indicator of the level of trust associated with the transfer.  Unfortunately, the distinction may be difficult for laymen.

 

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)

Jan 08 2015

Tribler: a (worrying) P2P client

triblerTribler is a new P2P client that made the headlines last month.   It was claimed to make bitTorrent  unstoppable and offer anonymity.   I had a look at it and played with.

This is an open source project from the University of Delft.  It has been partly funded by the Dutch Ministry of Economic Affairs.  The project started in January 2008.  Tribler is worrying to both content owners and users.

To content owners, Tribler is worrying with its features.

  •  Tribler is more convivial than other P2P clients.   It integrates in the client several functions.  First, it allows to search torrents from the client user interface within its currently connected clients.  In other words, it does not need a central tracker to keep the torrents pointers.   Thus, it is more robust and also easier to use than other clients.  If the expected content is popular, the likelihood to find it within the connected community is high.  Thus, it is unnecessary to leave the application to find torrents on trackers. Of course, it can import torrents from any external trackers such as mininova.  Thus, when content is not available in the community, the user may use traditional trackers.
    The second interesting feature is that it emulates video streaming using standard torrents.  In this mode, it buffers the video and starts to play it within the application after a few seconds.  From the user point of view, it is similar to streaming from a cyberlocker (with the difference that, once viewing completed, there is a full copy of the content on the user’s computer).
    These features are not new (emule allowed to search within it, Bittorrent Pro offers an HD player inside it…).  However,  Tribler nicely packages them.  The user experience is neat.
  • Tribler promises anonymity.  It uses a Tor-like onion structure to access the different peers.  Or at least, it should do in the future.  With the current version, it is clearly announced that it is still beta.   Furthermore, all the current peers were directly connected.  Only an experiemental torrent used the feature.  However, once validated and activated, it should become harder to trace back the seeders.

To users,Tribler is worrying for its security.  Tribler promises anonymity.  Unfortunately, this is not the case.  “Yawning angel” analyzed the project.  Although his analysis was not thorough, it highlighted several critical flaws in the used protocol.  As it is possible to define circuits of arbitrary length, it would be possible to create congestion and thus create a kind of DoS.  More worrying there are several severe cryptographic mistakes such as improper use of ECB mode, fixed IV in OFB…  His conclusion was:

For users, “don’t”. Cursory analysis found enough fundamental flaws, and secure protocol design/implementation errors that I would be reluctant to consider this secure, even if the known issues were fixed. It may be worth revisiting in several years when the designers obtain more experience, and a thorough third party audit of the improved code and design has been done.

Lessons:

  • P2P seems not yet dead.  Streaming emulation may change the balance with streaming cyber lockers.
  • Be very cautious about claimed anonymity.  Developing a robust Tor-like solution requires an enormous effort and deep knowledge of cryptography and secure protocols.  Tor is continuously under attack.
  • Universities may finance projects that will facilitate piracy.  “Openess of the Internet” to fight censorship does not mandate to watch content within the client.  The illustrating screenshot of Tribler on the Delft university page clearly shows some copyrighted movies offered to sharing.

Older posts «