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:
The malware was tied to the javascript call on line 21 of the main index.php page:
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:
This javascript data decodes to a new hidden Iframe:
The "stat.htm" page returned the following html code:
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 screen size and if Java and Acrobat are installed. It then returns with a 302 Redirect:
The clients get 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:
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 69.147.83.201 and was running a lighttpd/1.4.28 web server version where as today the IP address is 72.52.91.12 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:
In this scenario, even if Google Chrome received the malicious JS code, it would not execute it due to this CSP policy:
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.