The story of one backdoor

Background

Once upon a time there was one old-old site. Parents refused him, and in the second ten years of existence, he came to us. It was a jungle of PHP code scattered across folders. All this was written at different times, using different crutch patterns , in different encodings (up to 3 encodings within the same file). MVC then, probably, was not yet known, and the developers did not hear about template engines, so do not be surprised at the sudden

in HTML markup. I spent more than one hour in an exciting search for the right

The developers did not forget about backups: in the root you could find index.php, index_old.php, index.php.bak. But no matter what, this miracle worked. And do not touch what works.

Tie

This story began when a promotion specialist was surprised to find links to foreign sites in the footer on a sunny December morning. A little digging revealed 2 things:

1. this is glanders ;
2. the customer is perplexed.

You can understand the perplexity of the customer: he does not see these links.

Investigation

They set the task - to find, sort out and destroy. Finding the desired place in the HTML markup of the included PHP file, we got the name of the function that does good for someone. The search result in ~ 60k code files did not bring a positive result - such a function has not been announced anywhere. Enumeration of all files connected at the desired entry point was used. In the process, the eye clings to a file as follows:



Nothing is clear, but sincere thanks to the person who did not remove the annotation in the header. I'm starting to google `` Zend Optimizer '', rightly believing that it will lead to the decryption of this trash. The search for a working decoder ends here . Particularly pleased with the captcha:



With some hemorrhoids associated with the prohibition of copying the result, I got the following:



I am distrustful of complex regular expressions , but here it is completely extinct. I'm starting to remember how preg_replace () works . And the more I read, the more perplexed I am. The regular expression itself must go with the first parameter, and in the second, with what it is replaced. I looked again at what was given. it turns out, in the string "x" is replaced "# x # e" with that long piece. Moreover, the preg_replace () function uses x and e modifiers . But let's not confuse ourselves: everything that is placed between # is escaped, so x  is actually what should be replaced on the line “x” , i.e. that’s all, and the e modifier allows you to execute the resulting expression as PHP code. A close look at the replacement string makes it clear that most of it is noise.



If you remove the comments, it turns out

@eval(base64_decode($I0));

At this point, I had to google the "@" value before calling the function . Next, thanks to the online decoders , I got the next batch of puzzles.



Here I first saw the chr () function . Got on

$ll = @explode(chr(187) , @implode('', @array_map('trim', @file($ll))));

Googled array_map () . In general, a piece from the same original file encrypted by Zend Optimizer is used here. I don’t know what kind of algorithm there is, but after performing a permutation of the characters and taking the already familiar base64_decode (), I got a crypto function:



Then the com began to grow exponentially, and after several iterations the file reached 2k lines. After all this investigation, I left the file structure for tomorrow, but for now a couple of funs:


it allows you to go unnoticed from the terminals of the internal subnet.


Interestingly, they immediately do such an encryption there, or is it someone already tried a specialist for us?

Instead of an afterword

If you believe the time it took to create the files - it was a harsh 2009 in the yard. But I’m even a little sorry for the time of those people who sewed it all so hard, because I’m sure that this process took them more time than the reverse. And after all, all this would have been impossible if only the annotation about Zend Optimizer had not remained.