3

I opened one of our webapps yesterday in Chrome and it threw up the big red "WARNING this site contains content from URL which is bad". I double checked the url I typed in and immediately viewed source and searched the file. Sure enough, at the bottom was a script tag with a encoded url that when decoded was the offending URL that Chrome had spotted.

I'm curious how this was done and how I can avoid it in the future. The steps I took are below, but not sure if they are the solution.

I looked in IIS and saw that the site allowed write access for IUSR_ComputerName and IIS_WPG users to the entire webroot, which was originally done to write upload and log files. I limited this to the specific areas that needed to be written to and only for IIS_WPG.

Thanks in advance.

4 Answers4

3

It's a start. IUSR_ComputerName is what IIS uses for permissions of anonymous users by default. That means they will have been able to do an anonymous HTTP PUT, overwriting any file.

IIS_WPG is a group used for permissions under which your application pool runs. The way I understand it, raising the permissions of the .NET user for certain directories should be enough for you. IUSR_ComputerName should only need read permissions.

What is your application pool set to use? Instead of giving permissions to the IIS_WPG group, making a specific user account would provide some additional security if you run multiple sites.

Thorarin
  • 201
  • 2
  • 6
2

This actually happened to me, and the culprit was FTP.

Check your IIS web logs on the day of the last modified date of one of the infected files. If you have FTP enabled to your site, check the FTP logs as well on this date. That was the only way we were able to figure out what happened.

In the end, we discovered that a machine on the network got infected with malware that ran through a specific list of FTP clients, and downloaded the FTP settings files that contained unencrypted passwords to several FTP sites.

Tim S. Van Haren
  • 163
  • 6
0

Can you find the offending code in any of your web pages? Perhaps this is an injection attack where someone is performing a man-in-the-middle attack and injecting the code on the fly...

This was outlined in an article on Neil Carpenter's blog:

Looking back at the network trace, we saw a large number of gratuitous arp packets for the IP address of the default gateway. The MAC address that is being returned as corresponding to the default gateway is for a Compaq NIC(); however, the default gateway is a Cisco device with a different MAC address. Based on this, we determined that this machine was mounting an ARP cache poisoning attack (*) to perform a man-in-the-middle attack and inserting the iframe into HTTP communications where the response was an html doc.

Dscoduc
  • 1,095
  • 2
  • 8
  • 15
0

Yes, the code was actually in the file, so we knew it wasn't SQL Injection or man-in-the-middle