The whole hidden IFRAME vulnerability has been going on for some time, only a few of our client have been effected by this. The net is still buzzing with this issue and while some are saying that the injection are results of php insecurities, mysql injection or cross site scripting, while others point to key loggers and hijacked ftp credentials. In our case the exploit was not due to an application vulnerability but rather to hijacked ftp login information. Brute force password guessing attacks were not performed on this account nor any other accounts on the same server. In this particular type of attack, at the very end of index.php/index.html an IFRAME statement was appended overwriting page closing tags.
1 2 3
Some of the index.php files had multiple IFRAME statements appended to the end. Knowing the username of affected account and affected filename I searched in /var/log/messages for any related entries and hit jackpot:
1 2 3 4 5 6
What’s interesting to note here is that even though downloading/uploading of index.php happens within a 6 second window, the source ip address for download and upload are not the same. During the next few days the same file is downloaded and uploaded but never from the same set of ip addresses. During the few days that I was allowing this to happen as I was monitoring said activity and collecting the IP addresses to see if a pattern emerges:
1 2 3 4 5 6 7 8 9 10 11 12 13
Seeing that no clear pattern is evident here and considering that the IP address was different for each connection it is my rationale that the computer’s at these IP addresses were a part of a botnet. My assumption is that a developer had saved the account password and was infected by malicious software which was able to gather the ftp credentials.
Cleanup included restoring files and changing all account/ftp/email and database passwords.