Creative DRAM Abuse With Rowhammer

March 13, 2015 by Adam Fabio 70 Comments

Project Zero, Google’s security analyst unit, has proved that rowhammer can be used as an exploit to gain superuser privileges on some computers. Row Hammer, or rowhammer is a method of flipping bits in DRAM by hammering rows with fast read accesses. [Mark Seaborn] and the rest of the Project Zero team learned of rowhammer by reading [Yoongu Kim’s] 2014 paper “Flipping Bits in Memory Without Accessing Them:
An Experimental Study of DRAM Disturbance Errors” (PDF link). According to [Kim], the memory industry has known about the issue since at least 2012, when Intel began filing patents for mitigation techniques.

“Row hammer” by Dsimic – Own work. Licensed under CC BY-SA 4.0 via Wikimedia Commons.

The technique is deceptively simple. Dynamic RAM is organized into a matrix of rows and columns. By performing fast reads on addresses in the same row, bits in adjacent rows can be flipped. In the example image to the left, fast reads on the purple row can cause bit flips in either of the yellow rows. The Project Zero team discovered an even more aggressive technique they call “double-sided hammering”. In this case, fast reads are performed on both yellow rows. The team found that double-sided hammering can cause more than 25 bits to flip in a single row on a particularly vulnerable computer.

Why does this happen? The answer lies within the internal structure of DRAM, and a bit of semiconductor physics. A DRAM memory bit is essentially a transistor and a capacitor. Data is stored by charging up the capacitor, which immediately begins to leak. DRAM must be refreshed before all the charge leaks away. Typically this refresh happens every 64ms. Higher density RAM chips have forced these capacitors to be closer together than ever before. So close in fact, that they can interact. Repeated reads of one row will cause the capacitors in adjacent rows to leak charge faster than normal. If enough charge leaks away before a refresh, the bit stored by that capacitor will flip.

Cache is not the answer

If you’re thinking that memory subsystems shouldn’t work this way due to cache, you’re right. Under normal circumstances, repeated data reads would be stored in the processor’s data cache and never touch RAM. Cache can be flushed though, which is exactly what the Project Zero team is doing. The X86 CLFLUSH opcode ensures that each read will go out to physical RAM.

Wanton bit flipping is all fine and good, but the Project Zero team’s goal was to use the technique as an exploit. To pull that off, they had to figure out which bits they were flipping, and flip them in such a way as to give elevated access to a user level process. The Project Zero team eventually came up with two working exploits. One works to escape Google’s Native Client (NaCL) sandbox. The other exploit works as a userspace program on x86-64 Linux boxes.

Native Client sandbox escape exploit

Google defines Native Client (NaCL) as ” a sandbox for running compiled C and C++ code in the browser efficiently and securely, independent of the user’s operating system.” It was designed specifically as a way to run code in the browser, without the risk of it escaping to the host system. Let that sink in for a moment. Now consider the fact that rowhammer is able to escape the walled garden and access physical memory. The exploit works by allocating 250MB of memory, and rowhammering on random addresses, and checking for bit flips. Once bit flips are detected, the real fun starts. The exploit hides unsafe instructions inside immediate arguments of “safe” institutions. In an example from the paper:

20EA0: 48 b8 0f 05 EB 0C F4 F4 F4 F4 movabs $0xF4F4F4F40CEB050F,%rax

Viewed from memory address 0x20EA0, this is an absolute move of a 64 bit value to register rax. However, if we move off alignment and read the instruction from address 0x20EA02, now it’s a SYSCALL – (0F 05). The NaCL escape exploit does exactly this, running shell commands which were hidden inside instructions that appeared to be safe.

Linux kernel privilege escalation exploit

The Project Zero team used rowhammer to give a Linux process access to all of physical memory. The process is more complex than the NaCL exploit, but the basic idea revolves around page table entries (PTE). Since the underlying structure of Linux’s page table is well known, rowhammer can be used to modify the bits which are used to translate virtual to physical addresses. By carefully controlling which bits are flipped, the attacking process can relocate its own pages anywhere in RAM. The team used this technique to redirect /bin/ping to their own shell code. Since Ping normally runs with superuser privileges, the shell code can do anything it wants.

The TL;DR

Rowhammer is a nasty vulnerability, but the sky isn’t falling just yet. Google has already patched NaCL by removing access to the CLFLUSH opcode, so NaCL is safe from any currently known rowhammer attacks. Project Zero didn’t run an exhaustive test to find out which computer and RAM manufacturers are vulnerable to rowhammer. In fact, they were only able to flip bits on laptops. The desktop machines they tried used ECC RAM, which may have corrected the bit flips as they happened. ECC RAM will help, but doesn’t guarantee protection from rowhammer – especially when multiple bit flips occur. The best protection is a new machine – New RAM technologies include mitigation techniques. The LPDDR4 standard includes “Targeted Row Refresh” (TRR) and “Maximum Activate Count” (MAC), both methods to avoid rowhammer vulnerability. That’s a good excuse to buy a new laptop if we ever heard one!

If you want to play along at home, the Project Zero team have a rowhammer test up on GitHub.

Combination Lock Made Out Of Paper

March 8, 2015 by Bryan Cockfield 9 Comments

Most projects we feature are of the metal/wire/wood variety, but there is an entire community devoting to making very interesting and intricate things out of paper. Imgur user [Criand] has been hard at work on his own project made entirely out of paper, a combination lock that can hold a secret message (reddit post).

The motivation for the project was as a present for a significant other, wherein a message is hidden within a cryptex-like device and secured with a combination that is of significance to both of them. This is similar to how a combination bike lock works as well, where a series of tumblers lines up to allow a notched shaft to pass through. The only difference here is that the tiny parts that make up the lock are made out of paper instead of steel.

This project could also be used to gain a greater understanding of lock design and locksport, if you’ve ever been curious as to how this particular type of lock works, although this particular one could easily be defeated by a pair of scissors (but it could easily cover rock). If papercraft is more of your style though, we’ve also seen entire gyroscopes and strandbeests made of paper!

Decoding ZeuS Malware Disguised As A .DOC

March 6, 2015 by Rick Osgood 30 Comments

[Ronnie] recently posted about his adventures in decoding malware. One of his users reported a phishy email, which did indeed turn out to contain a nasty attachment. The process that [Ronnie] followed in order to figure out what this malware was trying to do is quite fascinating and worth the full read.

[Ronnie] started out by downloading the .doc attachment in a virtual machine. This would isolate any potential damage to a junk system that could be restored easily. When he tried to open the .doc file, he was presented with an error stating that he did not have either enough memory or disk space to proceed. With 45GB of free space and 2GB of RAM, this should not have been an issue. Something was definitely wrong.

The next step was to open the .doc file in Notepad++ for analysis. [Ronnie] quickly noticed that the file was actually a .rtf disguised as a .doc. [Ronnie] scanned through large chunks of data in an attempt to guess what the malware was trying to do. He noticed that one data chunk ended with the bytes “FF” and D9″, which are also found as the ending two bytes of .gif files.

[Ronnie] copied this data into a new document and removed all new line and return characters. He then converted the hex to ASCII, revealing some more signs that this was actually image data. He saved this file as a .gif and opened it up for viewing. It was a 79KB image of a 3D rendered house. He also found another chunk of data that was the same picture, but 3MB in size. Strange to say the least.

After finding a few other weird bits of data, [Ronnie] finally started to see more interesting sections. First he noticed some strings with mixed up capital and lowercase letters, a tactic sometimes used to avoid antivirus signatures. A bit lower he found a section of data that was about the size of typical shellcode. He decoded this data and found what he was looking for. The shellcode contained a readable URL. The URL pointed to a malicious .exe file that happened to still be available online.

Of course [Ronnie] downloaded the .exe and monitored it to see how it acted. He found that it set a run key in the registry to ensure that it would persist later on. The malware installed itself to the user’s appdata folder and also reached out repeatedly to an IP address known to be affiliated with ZeuS malware. It was a lot of obfuscation, but it was still no match for an experienced malware detective.

Bypassing The Windows Lock Screen

February 28, 2015 by Rick Osgood 87 Comments

Most of us know that we should lock our computers when we step away from them. This will prevent any unauthorized users from gaining access to our files. Most companies have some sort of policy in regards to this, and many even automatically lock the screen after a set amount of time with no activity. In some cases, the computers are configured to lock and display a screen saver. In these cases, it may be possible for a local attacker to bypass the lock screen.

[Adrian] explains that the screen saver is configured via a registry key. The key contains the path to a .scr file, which will be played by the Adobe Flash Player when the screen saver is activated. When the victim locks their screen and steps away from the computer, an attacker can swoop in and defeat the lock screen with a few mouse clicks.

First the attacker will right-click anywhere on the screen. This opens a small menu. The attacker can then choose the “Global settings” menu option. From there, the attacker will click on “Advanced – Trusted Location Settings – Add – Add File”. This opens up the standard windows “Open” dialog that allows you to choose a file. All that is required at this point is to right-click on any folder and choose “Open in a new window”. This causes the folder to be opened in a normal Windows Explorer window, and from there it’s game over. This window can be used to open files and execute programs, all while the screen is still locked.

[Adrian] explains that the only remediation method he knows of is to modify the code in the .swf file to disable the right-click menu. The only other option is to completely disable the flash screen saver. This may be the safest option since the screen saver is most likely unnecessary.

Update: Thanks [Ryan] for pointing out some mistakes in our post. This exploit specifically targets screensavers that are flash-based, compiled into a .exe file, and then renamed with the .scr extension. The OP mentions these are most often used in corporate environments. The exploit doesn’t exist in the stock screensaver.

Stumbling Upon An Uber Vulnerability

February 27, 2015 by Rick Osgood 30 Comments

[Nathan] is a mobile application developer. He was recently debugging one of his new applications when he stumbled into an interesting security vulnerability while running a program called Charles. Charles is a web proxy that allows you to monitor and analyze the web traffic between your computer and the Internet. The program essentially acts as a man in the middle, allowing you to view all of the request and response data and usually giving you the ability to manipulate it.

While debugging his app, [Nathan] realized he was going to need a ride soon. After opening up the Uber app, he it occurred to him that he was still inspecting this traffic. He decided to poke around and see if he could find anything interesting. Communication from the Uber app to the Uber data center is done via HTTPS. This means that it’s encrypted to protect your information. However, if you are trying to inspect your own traffic you can use Charles to sign your own SSL certificate and decrypt all the information. That’s exactly what [Nathan] did. He doesn’t mention it in his blog post, but we have to wonder if the Uber app warned him of the invalid SSL certificate. If not, this could pose a privacy issue for other users if someone were to perform a man in the middle attack on an unsuspecting victim.

[Nathan] poked around the various requests until he saw something intriguing. There was one repeated request that is used by Uber to “receive and communicate rider location, driver availability, application configurations settings and more”. He noticed that within this request, there is a variable called “isAdmin” and it was set to false. [Nathan] used Charles to intercept this request and change the value to true. He wasn’t sure that it would do anything, but sure enough this unlocked some new features normally only accessible to Uber employees. We’re not exactly sure what these features are good for, but obviously they aren’t meant to be used by just anybody.

ChipWhisperer Hits Kickstarter

February 27, 2015 by Brian Benchoff 13 Comments

Even the most well designed crypto algorithms can be broken if someone is smart enough to connect an oscilloscope to a processor. Over the last 15 years or so, an entire domain of embedded security has cropped up around the techniques of power and side channel analysis. The tools are expensive and rare, but [Colin O’Flynn] and the ChipWhisperer are here to bring a new era of hardware security to the masses.

The ChipWhisperer was the second place winner of last year’s Hackaday Prize. It’s an interesting domain of security research, and something that was previously extremely expensive to study. If you’re looking for a general overview of what the ChipWhisperer does, you might want to check out when we bumped into [Colin] at DEFCON last year.

While the original goal of the ChipWhisperer was to bring the cost of the tools required for power and side channel analysis down to something a hackerspace or researcher could afford, this was still too expensive for a Kickstarter campaign. To that end, [Colin] designed the ChipWhisperer Lite, a cut-down version, but still something that does most of what the original could do.

There are two parts to the ChipWhisperer Lite – the main section contains a big microcontroller, a big FPGA, and a high gain, low noise amplifier. This is the core of the ChipWhisperer, and it’s where all the power analysis happens. The other part is a target board containing an XMega microcontroller. This is where you’ll run all your encryption algorithms, and where you’ll find out if they can be broken by power analysis. The main board and target board are held together by a break-away connection, so if you want to run a power analysis on another board, just snap the ChipWhisperer in half.

[Colin] is offering up a ChipWhisperer Lite for around $200 USD – far, far less than what these tools cost just a year ago. We’re looking forward to a successful campaign and all the neat findings people with this board will find.

Hacking Oklahoma State University’s Student ID Cards

February 25, 2015 by Rick Osgood 39 Comments

[Sam] took an information security class at Oklahoma State University back in 2013. For his final project, he and a team of other students had to find a security vulnerability and then devise a theoretical plan to exploit it. [Sam’s] team decided to focus on the school’s ID cards. OSU’s ID cards are very similar to credit cards. They are the same size and shape, they have data encoded on a magnetic strip, and they have a 16 digit identification number. These cards were used for several different purposes. Examples include photo ID, physical access to some areas on campus, charges to an online account, and more.

[Sam] and his team analyzed over 100 different cards in order to get a good sample. They found that all cards started with same eight digits. This is similar to the issuer identification number found in the first six digits of a credit card number. Th analysis also showed that there were only three combinations used for the next two digits. Those were either 05, 06, or 11. With that in mind, the total possible number of combinations for card numbers was mathematically calculated to be three million.

OSU also had a URL printed on the back of each card. This website had a simple form with a single field. The user can enter in a 16 digit card number and the system would tell the user if that card was valid. The page would also tell you if the card holder was an employee, a student, or if there were any other special flags on the card. We’re not sure why every student would need access to this website, but the fact is that the URL was printed right on the back of the card. The website also had no limit to how many times a query could be made. The only hint that the university was aware of possible security implications was the disclaimer on the site. The disclaimer mentioned that usage of the tool was “logged and tracked”.

The next step was to purchase a magnetic card reader and writer. The team decoded all of the cards and analyzed the data. They found that each card held an expiration date, but the expiration date was identical for every single card. The team used the reader/writer to copy the data from [Sam’s] card and modify the name. They then wrote the data back onto a new, blank magnetic card. This card had no printing or markings on it. [Sam] took the card and was able to use it to purchase items from a store on campus. He noticed that the register reached back to a server somewhere to verify his real name. It didn’t do any checks against the name written onto the magstripe. Even still, the cashier still accepted a card with no official markings.

The final step was to write a node.js script to scrape the number verification website. With just 15 lines of code, the script will run through all possible combinations of numbers in a random sequence and log the result. The website can handle between three and five requests per second, which means that brute forcing all possible combinations can be completed in roughly two days. These harvested numbers can then be written onto blank cards and potentially used to purchase goods on another student’s account.

[Sam’s] team offers several recommendations to improve the security of this system. One idea is to include a second form of authorization, such as a PIN. The PIN wouldn’t be stored on the card, and therefore can’t be copied in this manner. The primary recommendation was to take down the verification website. So far OSU has responded by taking the website offline, but no other changes have been made.