As any regular reader of security industrynews will tell you, over the past few years the quality that is mostprized by malicious coders is stealth. Loud, reputation-enhancingattacks are strictly for the teenage malcontents of a previous century.Today’s malicious coders are professionals who prefer a more commercialmodel, which aims to compromise as many machines as possible, asquietly as possible, with the minimum amount of effort—and they areadopting increasingly diversified tactics to this end.
Older malicious code tended to rely on the static hosting of themalicious payload and this was always susceptible to filtering andtargeted action from law enforcement. Consequently a trend developed totry and keep the payload moving and hard to shut off using fast fluxDNS techniques, or to store it on "bullet proof" hosting from providersthat usually ignore complaints. However, the Security Response team hasrecently noticed a simpler approach that can be utilized by lesssophisticated and/or well resourced attackers. The technique canloosely be described as "hit-and-run" and the key to its profitabilityis the fact that it attacks busy or high profile sites, hitting andcompromising large numbers of vulnerable targets before the infectedsite can be shut down or cleaned.
A case in point is the attack that recently came to the attention ofthe Symantec Security Operations Centre (SOC) in Reading, UK. A managedsecurity service (MSS) customer had visited a Web page and triggered analert on their Manhunt IDS system. The alert was passed to the analysisteam at the SOC where it was then analyzed. The two alerts generated byManhunt were for "HTTP VB Unsafe Objects Instantiation" and "HTTP MDACRDS Dataspace Rem Code Exec." These are triggered by an attempt toexploit a vulnerability in the Microsoft Data Access Components (MDAC)that could allow an attacker to create files and run code on vulnerablesystems browsing the site. The exploit is an old one and had alreadybeen patched by Microsoft.
However, our analysts quickly realized that the user in question hadnot been exposed to this infection by travelling the less salubriousbackwaters and swamps of the Internet. The source of the trouble turnedout to be www.tata.com, which is the main site for the $61 billion Tatagroup, one of India's largest companies and the owner of Tata Motors,whose aggressive takeover bids have been widely reported recently.Tata's Web developers claim this site receives 400,000* visitors amonth.
Fetching the front page of this site with Sam Spade revealed asection of VBscript and two blocks of encoded data that had been addedto the end of the page after the closing tag. When this infectious pageis viewed by a vulnerable Windows machine the VBScript embedded in thepage uses the MDAC vulnerability to create executable files and set upa service on the newly infected machine. This is a "drive-by install"that is invisible to the user and the entire executable payload iscontained within the HTML file, which makes the exploit self-containedand ideal for this type of hit-and-run attack.
This VBscript/MDAC exploit method is used by several different bitsof malicious code and the executable payload can be more or lessanything the attacker chooses. In this case, once the service is up andrunning it searches for HTML files on the compromised machine and addsthe original exploit code to them, making those files infectious.
Although this code exploits a vulnerability that has been patchedfor some time and is currently rated as a low threat the Tata sitereceives over thirteen thousand visitors a day*, all of whom are allpotential targets. With a site this popular the odds are in favour thatthere will be at least some visitors who will succumb to the attack.Once we had analyzed the event, we produced a warning message for thecustomer and informed other analysts of the problem. We then tried tocontact the administrators of the Tata domain so that they could cleanthe site.
Contrary to what we are frequently told in the business press, theworld is not as flat as it could be. Tata is not an MSS customer and wehad no internal agreement in place to warn them. It was after 10 p.m.in India and it proved impossible to contact anyone by phone. Of thethree phone numbers available (taken from the domain record and thecontact number for the Web site maintainers), one was no longer inservice, one was not answered and the last one was answered by someonewho seemed unwilling or unable to escalate our call to the appropriatepeople. Eventually we sent an email to all the contact addresses wecould find. This appears to have been received because the site wasupdated and the malicious code removed early the next morning.
Lessons to be (re)learned from this attack:
1) Just because an exploit is old doesn't mean everyone is immune, ifthe pool of victims is large enough then someone will be vulnerable.
2) Fairly unsophisticated or outdated exploits planted on highlytrafficked sites can attack many visitors in a short time period beforethey are detected and cleaned up.
3) Attacks like this are easy for attackers to share, adapt, or stealfrom each other because the VBscript is available from any infectedpage and the payload can be anything the attacker wants.
4) Browser attacks aren't easy to spot because they piggyback onlegitimate traffic that doesn't exhibit many obvious warning signs,such as unrequested incoming connections or communication on unusualports or to dubious IP addresses.
5) Accurate domain and site contact information is very important.Critical sites or those with high volumes of traffic need some kind ofcover outside business hours. In this case it might have reduced thetime the server was compromised by twelve hours and six thousandpotential victims.
6) High profile sites are valuable distribution channels for browserexploits and they need to be protected from malicious code that mayalready exist inside the company as well as attacks from the outside.
7) Any company with a high traffic site needs to be aware of this kindof smash-and-grab tactic and the effect it may have on their customersand reputation.
*The visitors per day/hour figures are based on an even division ofthe 400,000 visitors a month figure claimed by the site maintainers.