I must admit, I think the last step was a little. uhm... well I just think its funny how you used Hacker News to decrypt a script then posted about that on Hacker News.
It's an XOR encryption, with a largish key - 12 bytes if I make the old hacker news comment correctly. If you do the standard known-text XOR key finding algorithm, you need a 24-byte known text.
But you're just looking for the text being in a certain range of characters. The first stage is determining the key length, you can do this by looking at the number of different character values in positions 1,2,3... then 1,3,5,... and 2,4,6,... then 1,4,7,... etc.
The stand out line from that is keylength=12 as it provides a local minima for the number of different characters.
Having a good idea of the key length you can look at which of the possible 256 values for each position of the key produce the top numbers of printable characters. A quick perl script to do this gives:-
OK, next pick a word you think will be in the output (it's php code so I'll guess the word "function" might be common). You then XOR each 8 character substring with "function", taking note of the position of the substring within the 12 character groupings, and count the resulting characters:-
Note that the correct key in each position is usually either the first or second possibility, but there are some times when it isn't there at all.
(It's better if you give it a longer string, if I give it "function " with the trailing space then it gets 9/12 as the most popular, 2/12 as second most popular and the remaining one as the third most popular. There are even better choices, see below, but I chose to go with this as it helps show how to continue with non-perfect information).
Next I knocked up a quick program to allow me to try different keys to decrypt it, it prints out the code in blocks of the appropriate keylength so it's easy to see if a specific character position is correct or not. The program takes various commands from stdin (k = print key, S = set key, s = set individual key character, p = print in keylength sized blocks, P = print entire decrypted block):-
$ ./5.pl 12
k
key is aaaaaaaaaaaa
S SjLVmE6ukR_j
key is now SjLVmE6ukR_j
p
/)abjutt uy
stcm&vauiadl
es\12i`(!Gisue
t("_UERQER/)
{$YCIOKNE= $
HTRPYCOHKIC_
VATS=$_WOSR=
&$NTRP_WOSR_
VATS=$_@ET;&
$HRTV_GBT_PA
RS=}\12//cie&w
itn crrhr
`u
ncriin \127_doe
($k)}@hbadcr
('NTRP/6.1&5
...
Getting there, but still a way off. There are a few strings like COIKOE[#n]= which could be COOKIE, so we fiddle with the 3rd column and see some interesting things in the output:-
s 2 J
p
...
elseof(oasYp
...
COOKOE[#n]=
...
systcm(#c)=}
...
Neither of the other two choices for column 4 produce the right string, but it's simple enough to find the ciphertext and find what is needed to make elseof -> elseif, COOKOE -> COOKIE and systcm -> system. It's k:-
s 4 k
k
key is SjJVkE6ukR_j
p
...
elseif(oasYp
...
COOKIE[#n]=
...
system(#c)=}
We carry on doing this based on more clues like this (it gets easier and easier!) and we end up with:-
k
key is SjJVkE6rkRYj
p
//adjust sy
stem variabl
es
if(!@isse
t($_SERVER))
{$_COOKIE=&$
HTTP_COOKIE_
VARS;$_POST=
...
And printing out the entire decrypted buffer without extra linebreaks every 12 chars gives:-
P
//adjust system variables
if(!@isset($_SERVER)){$_COOKIE=&$HTTP_COOKIE_VARS;$_POST=&$HTTP_POST_VARS;$_GET=&$HTTP_GET_VARS;}
//die with error
function x_die($m){@header('HTTP/1.1 500 '.$m);@die();}
//check if we can exec
define('has_passthru',@function_exists('passthru'));
define('has_system',@function_exists('system'));
define('has_shell_exec',@function_exists('shell_exec'));
define('has_popen',@function_exists('popen'));
...
Interestingly, trying known plaintext of "define" gives us the entire key as the most probably c...
This is roughly what I was imagining doing in my head when I brashly wrote "obviously bruteforce." Hooray! Apparently I've still got it, at least to some small extent.
Not sure, "define" only appears 10 times but "function" appears 19 times. It's probably because 'e' is more popular in the code and "define" has two of them. Looking at the decrypted code there are much better strings to try; "function_exists" gives the right key first time too.
It could have been made a lot harder by using comments at the end of each line to pad the code with extra characters to equal out the frequency distribution and make this kind of frequency analysis impossible.
Oh yes, although too many "alias" commands will mean that it's possible to search for the known plaintext of 'alias'. But the more non-ascii bytes there are the more it will put off my analysis which dependeds on isprint().
I'm letting the above comment stand, so that the rather cogent reply will make sense in the future.
It just so happens that I have a sample of that same malware. A read through shows that the XOR key actually arrives in the HTTP request made on the original (first level) PHP code. The 2nd level code looks for a 'key' in $_COOKIE, $_POST and $_GET.
A few months ago, I removed an almost identical piece of malware from a client's account. Looking through the server logs, I noticed that the script was still being accessed on a fairly regular basis. I dropped a simple script to dump the contents of the cookies and request variables to a file when accessed. It didn't take very long to obtain the key.
15 comments
[ 2.9 ms ] story [ 41.4 ms ] threadEDIT: obviously bruteforce, but still.
That's some brute forcing, if you ask me.
Having a good idea of the key length you can look at which of the possible 256 values for each position of the key produce the top numbers of printable characters. A quick perl script to do this gives:-
You'll note that the actual key (SjJVkE6rkRYj) is present in this output. I'll carry on with this if I get a chance tomorrow.(It's better if you give it a longer string, if I give it "function " with the trailing space then it gets 9/12 as the most popular, 2/12 as second most popular and the remaining one as the third most popular. There are even better choices, see below, but I chose to go with this as it helps show how to continue with non-perfect information).
Next I knocked up a quick program to allow me to try different keys to decrypt it, it prints out the code in blocks of the appropriate keylength so it's easy to see if a specific character position is correct or not. The program takes various commands from stdin (k = print key, S = set key, s = set individual key character, p = print in keylength sized blocks, P = print entire decrypted block):-
Getting there, but still a way off. There are a few strings like COIKOE[#n]= which could be COOKIE, so we fiddle with the 3rd column and see some interesting things in the output:- Neither of the other two choices for column 4 produce the right string, but it's simple enough to find the ciphertext and find what is needed to make elseof -> elseif, COOKOE -> COOKIE and systcm -> system. It's k:- We carry on doing this based on more clues like this (it gets easier and easier!) and we end up with:- And printing out the entire decrypted buffer without extra linebreaks every 12 chars gives:- Interestingly, trying known plaintext of "define" gives us the entire key as the most probably c...Thanks for your writeup!
Why does define work so well? Chance?
It could have been made a lot harder by using comments at the end of each line to pad the code with extra characters to equal out the frequency distribution and make this kind of frequency analysis impossible.
eg this kind of nonsense:
It just so happens that I have a sample of that same malware. A read through shows that the XOR key actually arrives in the HTTP request made on the original (first level) PHP code. The 2nd level code looks for a 'key' in $_COOKIE, $_POST and $_GET.
I tidied up the code I used to analyse it and uploaded it here:-
xor.pl: http://pastebin.com/NBhmSu1k
(Focus was on a quick hack not code quality or documentation!)