|=--------------------------------------------------------------------------------------------------=| |=------------------------------=[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. --------------------------------------------------------------------------------------------------------- Attach 2: .Htaccess. SetEnvIf Request_URI "^/tmpdir/tempfile\.php$" dontlog order deny,allow deny from all allow from 127.0.0.1 (or the remote ip of the server). 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