An Explanation

Discussion in 'Admin Talk News' started by AWS, May 4, 2012.

  1. AWS

    AWS Administrator

    Feb 1, 2010
    Likes Received:
    Joliet, IL U.S.A.
    First Name:
    So many of you came here and the page didn't render correctly or certain things didn't work correctly. Then the next day you noticed the site was flagged as a badware site by Google. Many of you sent me PM's, Twitter messages, emails or contacted me in other ways to let me know what was happening. Thanks to all of you that did this.

    Let me tell you exactly what happened.

    Sometime in the afternoon of May 1ST an old Wordpress site that I had forgot about was hacked.As part of this hack a a shell script was uploaded. That site was hacked and in the process all index.php on all 6 sites on this server had an iframe added. I caught this right away, did a security audit on the server, found the exploit, cleaned all sites and upgraded the WP site. I thought everything was good.

    The next day and this site were hacked. This time a vulnerability in IPB which a patch was released for in March was used. My bad for not applying the patch on either site. Now this was 2 separate hacks with 2 different exploits of the same hole. The hack of RZ hijacked a session of one of the admins. The session was used to log in to the admin and add an iframe to the forum names which redirected users to a site that would drop malware on them if they used a vulnerable browser while viewing a page on the site. This was an an easy cleanup. I upgraded the site and after doing another security audit on the server to make sure no backdoors were dropped in I told all staff to change their passwords right away. I also removed all permissions of the admin account that was hijacked until he changed his password.

    At the same time this site had an iframe injected into the index.php file. Since the audit turned up nothing I removed the iframe and thought the problem here was a byproduct of the RZ hack.

    Yesterday all hell broke loose. This site was hit when a user registered and uploaded an avatar that was actually a php shell script. This user first registered on April 1ST. The malicious avatar was uploaded April 23RD. The shell script had been sitting in the upload/profile dir since then. For this site the upload directory as well the cache directory reside on another server so this was missed when I did the 2 previous security scans.

    The user executed the shell script and injected his malware into the templates. He tried to dump and delete the database, but, because the database is on another server he wasn't successful. While he did get the db username and password he couldn't get access to the db because I use named pipes to connect the 2 servers. By doing it this way you can not access the db server unless you are connecting from the db server IP.

    While the user had shell he tried to do various things to other sites. A plus for Windows which also hindered him is the way I have PHP configured. I have each site running in it's own app pool and PHP is configured to run as a different user for each site. So he was only able to work in the AA dir. Any attempt to traverse into other parts of the server were met with permission denied errors.

    I fixed the damage he did, ran a scan on the server that has the uploads and cache directories. It found the shell script and I removed it. I was pissed at myself since this was first uploaded April 23RD. I take security seriously and I had been lax and hadn't run any scans on the servers for a few months. That will happen no more.

    Anyway we're back, we're clean and new measures have been put in place to make sure we remain clean. I will not go into the exploit further except to say keep an eye on your php and server error logs. If you see any errors about a malformed session or any eval() errors on any script start checking your upload or cache directory.
    2 people like this.

Share This Page