> I am currently dealing with a similar problem for a customer with Moodle ...
If you don't mind me correcting you, it is not similar. It is the same!
The injected content is coming from the first line in your PHP files (atleast one will have it, could be thousands depending on your site). The line starts: <? /**/eval(base64_decode('aWYoZnVuY3R...
The string 'aWYoZnVuY3R...' is generated for your site's infection. It contains the directory of your infection. In your case it is moodledata\1\moddata\forum\42\224.
This directory is the destination for all uploaded files that arrive through the 'GET /ddd/sss.php?fff=nnn' requests; where ddd=a script directory (not the target directory, just one that contains an infected PHP script), sss=an infected PHP script, fff=the parameter chosen for your site (it could be anything), and nnn=a number which will become the filename for the data in the request which will be save into the target directory. So, for example, (I don't know your chosen parameter, so I am using 'vehicle' in the example), GET /moodle/login/signup.php?vehicle=234 will upload a file to the directory moodledata\1\moddata\forum\42\224 and save it as '234'. The size of the file will correspond with the size of the data in the request, which will be about 12K.
I have written to Yahoo and asked them to confirm that requests of this form (I have given them the details for my site, the chosen parameter etc.) are actually coming from their site. Many hundreds of requests have come from IPs in these ranges:
- 18.104.22.168 to 22.214.171.124
- 126.96.36.199 to 188.8.131.52
- 184.108.40.206 to 220.127.116.11
- 18.104.22.168 to 22.214.171.124
If the requests are actually coming from those actual IPs, then Yahoo is severely infected (or somehow being proxied through). If not, then there is a significant spoof attack occuring, which I'm not sure how they could achieve, which makes me think that Yahoo, and also Google, and Microsoft, and ... have all been compromised, which makes me think that's pretty severe, and maybe it is a spoofing thing. Most requests for my site have come from Yahoo, but there are many others ranging from big sites to anonymous ones. I am inclined to ignore the identification information provided in the requests (e.g. the referrer, the browser, etc.). I think they are bogus, which the IPs could be bogus too, but that's harder to make bogus. Analyse the packets coming in. Check their TTL's and sequence numbers, oh and also their src ports. If there are any inconsistencies, then you'll know the IP's are spoofed. E.g.
126.96.36.199: SPT=35123, TTL=46, ID=27519
188.8.131.52: SPT=35123, TTL=46, ID=27520
I haven't found any inconsistencies yet, but the malware requests are coming from many many different IPs. So, it could be very wide spread and coordinated because all the requests from all these different IPs all have the chosen parameter for my site! And, they are all loaded with those spam email bodies.
I know of two Linux installations infected and two Windows installations infected, which means that it must be a PHP hole (e.g. see http://www.linuxsecurity.com/content/view/144327/170/
). Also, one Linux system was invaded through a joomla script and the other a Moodle script.
My assumption is that the hole will be closed by upgrading PHP. Note though that one invaded system was using PHP 5.2.6-r2, and the most recent version available is a fledgling 5.2.7. I don't actually know if that closes the hole used by this malware. Someone should name it or find the name of it.
I haven't analysed the s.php code yet. The mdl_utf.php is the main routine. The csi file records an IP with a timecode (e.g. now is 1229070566, number of seconds since Thu Jan 01 10:00:00 +1000 1970). I don't know the purpose of the data yet. The cnf file stores the configuration of the malware for your site, such as the upload parameter variable. The swf file is a Macromedia Flash data (compressed), version 9. The t file is a HTML spam template.
This malware deserves(?) no needs analysis and attention. At first look, it looks like a page hack which inserts some spam type info and links. At a second look, it looks like a spam generator. However, I think there needs to be a third look to reveal it's true purpose. The first look, the page hack, seems to have failed because the place the data in a div which is 70000 pixels to the left. Why would a coder write such an elaborate program only to stuff up in the output? If you look at the links in the div they all have the same form of those upload requests, which makes me think that the real purpose of the div is feedback to "the enemy", because the links are not evaluated and are not visible for clicking on. The second look, the spam generator, seems to have failed because the system has not been sending emails and seems to only be uploading files instead of sending stuff. This makes me think that all of this is just a cover to its real purpose, which I suspect is mainly information gathering (passwords?, vulnernable sites?, ...?).
The coder has gone to significant lengths to obfuscate the code, e.g. the cnf file. Why obfuscate the configuration variables, when their discovery is connected to the removal of the code. Obfuscation of the cnf file doesn't hide the spam generator because it is in the same directory! I assume it means that the coder doesn't want you to know what it has done when you delete it. If it was just generating spam, then that looks obvious, so why try so hard to hide that by obfuscating the code?
I think the s.php file is the key. Decode that to determine it's purpose, I think.