Compromised sites

The article "Modern Internet attacks" is provided by Sophos Plc and SophosLabs.

August 2007

Users trust the web services they use. They connect to sites to use their services (from Internet maps and news to weather forecasts), allowing their browsers to display the pages accordingly. Users are usually advised to have lists of reliable sites to be able to tune the browser according to the site reliability. This way users can turn on such features as scripts, ActiveX and Java if they are necessary for viewing a certain site. The idea of applying stricter rules to the content that comes from an unknown area is reasonable.

Still recently the number of compromised sites has grown significantly [31]. What is the reason? Hackers don't do their job just for the sake of defacing a site [32, 33]. Compromising a site and loading malicious content to the pages serves as a barely noticeable tool to achieve the goals considered in this article — spreading and implementing the threat. Moreover, if a compromised site has many regular users who consider it reliable, the potential number of victims will also be very high. Hacking the Miami Dolphins team site before the Super Bowl cup 2007 proved that attacks using compromised sites can be exceptionally large-scale [34].

The HTML language provides many convenient ways to load additional content. Most often compromised sites use the tag <IFRAME> [35], which allows loading additional content to the page without being noticed. This tag is widely used in peaceful purposes on many sites. Using this method for compromising a site that was considered reliable is very convenient for malware creators, because they can attract users to the site without using social engineering, and no user actions are needed to download malicious content. Statistics for the first half of 2007 showed that almost 50% of malware on the Internet uses iframe tags [36]. This tag supports several attributes. Most often the attacks use width and height attributes with which you can set the frame size on the page where the content is loaded. To compromise a site without being noticed, most malicious iframe tags have quite small width and height values (0-10 pixels). Such tags lead to creation of numerous small fields on the page. These fields can become quite visible in case of repeated infection.

Despite the fact that malicious iframe tags contain these attributes, proactive identification of compromised pages is a difficult task, because these attributes are used on many ordinary pages as well. Attributes that set the size can serve only as an indirect sign — to ensure detection you need to check the src attribute of the iframe tag. Interestingly, several recent attacks used extra large size (for example 1500 by 1500 pixels) instead of extra small one. Obviously, this is an attempt to prevent compromised pages from being detected by suspiciously small attribute values.

Fig. 8. A screenshot of repeatedly infected site. You can see several small fields (one for each of the 23 inserted malicious tags)

Similar result is usually achieved by compromising a page with malicious script that inserts an iframe tag when the page is viewed. Although the end result of such attacks is essentially the same (downloading malicious content from remote server when the page is viewed), the prevention methods are different. To detect pages infected this way you need to find the added script. Checking the page for malicious iframe tags is not enough (unless the checking technology allows you to interpret or emulate JavaScript). С учетом того, что вредоносную операцию document.write ('<iframe... >')в JavaScript можно замаскировать множеством способов (см. рис. 9), early detection becomes even more challenging.

Fig. 9. A page infected with a malicious script that inserts a malicious iframe tag in the code (top: an iframe tag inserted in the page; bottom: a malicious script added to the page as a result of infection).

A recent attack called Pintadd [37] infected many sites with a script that used a slightly modified way of loading malicious content with an iframe tag. Instead of just calling document.write(), the script uses the createElement () function [38] that creates an iframe element. Then the necessary attributes are set for the tag and the tag itself is added to the current page with the appendChild () method [39]:

From the victim's point of view, the result will be the same as if the iframe tag was inserted directly. However, it is a new problem for security software.

Virtually all infected sites detected by SophosLabs download additional malicious content from remote servers. In fact compromised sites are used for downloading malicious scripts and launching the infecting mechanism (see Section 3.3). Some attacks (for example, Dorf) use spam messages to attract users to malicious site. Other attacks use compromised sites to achieve the same goal. The users don't even know they are connected to the remote attacking site.

Theoretically, once the attackers bypass security system and get remote access to the site they can place all components needed for the attack on the compromised site. Modified pages can run malicious scripts and install malware hosted on the same server. However, usually it isn't the case. There are two main reasons for this. Firstly, redirecting the users from compromised sites to a single attacking site provides a single control point over attack. Secondly, adding small scripts or tags to the compromised site pages is less noticeable than loading large binaries and scripts. Apart from visible marks of infection (fig. 8) the source code can often contain signs of infection. You can often see several iframe tags or malicious scripts surrounded with special markers (HTML comments).

Fig. 10. The beginning of an infected page that shows added scripts and iframe tags separated by infection markers ().

News about big sites that are compromised can spread very widely. Still most of the compromised sites are small and attract relatively small traffic. Separately, they do not pose any particular threat, but the cumulative effect leads to very significant risks. In addition, small weakly managed sites usually stay infected for a longer time because the site is impossible to clean, or the problem is ignored, or administrators lack experience. An obvious problem is outsourcing of web development. Once the site is created, little attention payed to its support and there isn't enough qualified personnel to deal with such a problem as site infection. Removing added scripts and tags from pages isn't enough. To prevent repeated infection, you need to contact the hosting provider and examine the server log files to understand how the site was infected. Writing emails to the administrators of infected sites is inefficient. Even big companies often provide minimal response.

If hackers infect a server hosting several sites (for example, a server farm of a hosting provider), a single attack can lead to infecting all sites hosted on the computer [40]. Earlier this year, SophosLabs company revealed an attack on a polish provider. Several servers were infected with EncIfr. Infection was detected on more than 13,000 URLs that were hosted a few servers. All pages were infected with the JS/EncIfr-A malicious script. This example shows that the scale of attack should be assessed not only by the number of infected pages but also by the number of infected servers.

Some attacks using compromised sites apply a more targeted approach, infecting a certain popular site instead of many sites. A good example is two recent attacks on the MySpace social network. To create a worm running on MySpace, Ofigel used QuickTime video clips (with embedded JavaScript support) [41]. When users opened an infected profile, it downloaded a vieo clip, which in turn downloaded a malicious script from a remote site. This script used cross-site scripting, to which the MySpace site was vulnerable. It added a similar QuickTime video clip to the victim's profile. The next attack with SpaceStalk [42] also used QuickTime video clips to download malicious script. The script collected user credentials and passed them to the remote server [43]. Such targeted attacks use vulnerabilities in popular sites to infect their users. Protecting users from methods that exploit site vulnerabilities (for example, cross-site scripting) can be quite difficult. One of the best ways is to classify URLs and apply stricter security policy when viewing less reliable sites (see section 4).

Next