Blogs & Stories

SpiderLabs Blog

Attracting more than a half-million annual readers, this is the security community's go-to destination for technical breakdowns of the latest threats, critical vulnerability disclosures and cutting-edge research.

PHP.Net Site Infected with Malware

Earlier today, users attempting to access the www.php.net site were met with malware warnings from Google's Safe Browsing plugins in Chrome/FireFox and other browsers -


So, what was the problem?

Malware Redirection Details

Google's SafeBrowsing currently lists the following for the site:

Screen Shot 2013-10-24 at 5.47.41 PM

The malware was tied to the javascript call on line 21 of the main index.php page:

Screen Shot 2013-10-24 at 6.45.39 PM

When clients accessed this page on the static.php.net server, there was a conditional injection of obfuscated javascript code appended to the end of the file:

Screen Shot 2013-10-24 at 6.51.15 PM

This javascript data decodes to a new hidden Iframe:

Screen Shot 2013-10-24 at 9.02.09 PM
The "stat.htm" page returned the following html code:

Screen Shot 2013-10-24 at 10.55.07 PM

The PluginDetect_All.js is used to identify installed browser software and the page initiates a form POST back to the stat.htm page indicating the screensize and if Java and Acrobat are installed. It then returns with a 302 Redirect:

Screen Shot 2013-10-24 at 11.05.42 PM

The clients gets redirected to a number of different temp domains and served with various exploit payloads:

hxxp://zivvgmyrwy.3razbave.info/?695e6cca27beb62ddb0a8ea707e4ffb8=43 -> which attempted a SWF exploit:

Screen Shot 2013-10-24 at 11.23.24 PM

Another instance tried to send down a PE file similar to this one on Malwr while another attempted to exploit CVE-2013-2551.

Initial Compromise Vector

The initial attack vector is not currently confirmed. What we do know at this point is that the conditional malware was executing on the "static.php.net" domain and appending data to the userprefs.js file. At the time of these infections, the IP address for static.php.net was and was running a lighttpd/1.4.28 web server version where as today the IP address is and is running nginx/1.4.1 so some changes were obviously made.

Mitigation Options

It is not confirmed that the attackers were able to install a malicious module such as Darkleech or Cdorked.A but it is not out of the realm of possibility. In these cases, when attackers have that level of access to install a malicious web server module, there isn't much you can do locally to prevent these attacks. What would be possible, however, would be to use an external WAF such as ModSecurity to dynamically add in new Content Security Policy (CSP) response headers or alter the HTML itself with a meta tag. Using this type of topology, even if attackers were able to compromise the web server and send out malicious JS code, the WAF would add the CSP data on a separate system on the way out to the intended victim's browser.

The following ModSecurity rules show an example of modifying the HTML to add in a meta tag which would only allow iframe sources from static.php.net:

SecContentInjection OnSecStreamOutBodyInspection OnSecRule REQUEST_FILENAME "@endsWith .php" "chain,phase:request,t:none,nolog,pass"   SecRule STREAM_OUTPUT_BODY "@rsub s/<head>/<head>|00|<meta http-equiv=\"Content-Security-Policy\" content=\"frame-src static.php.net\"<\/>/"

This is how the HTML would look to the browser:

Screen Shot 2013-10-25 at 12.09.03 AM

In this scenario, even if Google Chrome received the malicious JS code, it would not execute it due to this CSP policy:

Screen Shot 2013-10-25 at 12.08.27 AM

Applying security policies such as CSP externally to your normal website has value as it prevents them from being disabled or modified in the event of a local compromise.