Php.net goes on lockdown after malicious code is found hosted on site servers.

Maintainers of the open-source PHP programming language have locked down the php.net website after discovering two of its servers were hacked to host malicious code designed to surreptitiously install malware on visitors' computers.

Eventually, the site was moved to a new set of servers, PHP officials wrote in an earlier statement. There's no evidence that any of the code they maintain has been altered, they added. Encrypted HTTPS access to php.net websites is temporarily unavailable until a new secure sockets layer certificate is issued and installed. The old certificate was revoked out of concern that the intruders may have accessed the private encryption key. User passwords will be reset in the coming days. At press time, there was no indication of any further compromise.

"The php.net systems team have audited every server operated by php.net and have found that two servers were compromised: the server which hosted the www.php.net, static.php.net and git.php.net domains and was previously suspected based on the JavaScript malware, and the server hosting bugs.php.net," Thursday night's statement read. "The method by which these servers were compromised is unknown at this time."

According to a security researcher at Kaspersky Lab, Thursday's compromise caused some php.net visitors to download "Tepfer," a trojan spawned by the Magnitude Exploit Kit. At the time of the php.net attacks, the malware was detected by only five of 47 antivirus programs. An analysis of the pcap file suggests that the malware attack worked by exploiting a vulnerability in Adobe Flash, although it's possible that some victims were targeted by attacks that exploited Java, Internet Explorer, or other applications, Martijn Grooten, a security researcher for Virus Bulletin, told Ars.

Grooten said the malicious JavaScript was served from a file known as userprefs.js hosted directly on one of the php.net servers. While the userprefs.js code was served to all visitors, only some of those people received an additional payload that contained malicious iframe tags. The HTML code caused visitors' browsers to connect to a series of third-party websites and eventually download malicious code. At least some of the sites the malicious iframes were pointing to were UK domains such as nkhere.reviewhdtv.co.uk, which appeared to have their domain name system server settings compromised so they resolved to IP addresses located in Moldova.

"Given what Hacker News reported (a site serving malicious JS) to some, this doesn't look like someone manually changing the file," Grooten said, calling into question an account php.net officials gave in their initial brief statement posted to the site. The attackers "somehow compromised the Web server. It might be that php.net has yet to discover that (it's not trivial—some webserver malware runs entirely in memory and hides itself pretty well.)"

In an e-mail, PHP maintainer Adam Harvey said PHP officials first learned of the attacks at 6:15am UTC. By 8, they had provisioned a new server. In the interim, some visitors may have been exposed.

"We have no numbers on the number of visitors affected, due to the transient nature of the malicious JS," Harvey wrote. "As the news post on php.net said, it was only visible intermittently due to interactions with an rsync job that refreshed the code from the Git repository that houses www.php.net. The investigation is ongoing. Right now we have nothing specific to share, but a full post mortem will be posted on php.net once the dust has settled."

This post was updated at 10:23pm PT to include new information provided by the php.net server team.

Promoted Comments

I thought the PHP.net site was relatively simple! No Adobe Flash, no Java, no real need for Javascript... What is this, maliciously crafted HTML/CSS? I thought we'd beaten that with toughened, sandboxed browsers? Or is PHP.net using scripting that it doesn't need to?

Looking at the transmitted JS files I can see the following functionality provided by JS:

Light boxes (probably not so common, I think I have ever only encountered one on the php.net sites)Comment voting (similar to what we have here on Ars)Langauge pickerSome cookie handlingBeta site on/offScroll To TopUserVoice feedbackPing/analytics/tracking

I know it's non-trivial to do especially when reporting breaking news, but it would be awesome if Ars would update these types of articles with information about whether patched systems are at risk or not. Sometimes these outbreaks are using zero-days that are real risks to sophisticated users; at the other end is the exploit that affects XP Service Pack 1 (which is probably half of corporate America, but I digress).

The problem is a story like this it not always known at press time all the details such as which OSes are at risk or if it relied on zero-day exploit. Obviously Windows users are at risk but I am not certain about others. As far as zero-day exploit, the information may not be known for several days though the article seems to imply a zero-day exploit is not involved.

PHP, JavaScript, Flash, Java applets, Internet Explorer: this story is like a game of crap-technology-that-should've-died-a-decade-ago bingo.

You may want to rework that statement.

Flash and Java applets need to go, okay.But Javascript is the language of choice nowadays, and it's spreading more and more even outside the web. And Internet Explorer can be finally considered a decent browser.PHP is a mess of a language but it's server side, and it is possible to use it safely anyway.

I encountered this over the last few days when attempting to reach PHP.net resources via Google: "This website will harm your computer." - or such like. Thank you, Google!

I thought the PHP.net site was relatively simple! No Adobe Flash, no Java, no real need for Javascript... What is this, maliciously crafted HTML/CSS? I thought we'd beaten that with toughened, sandboxed browsers? Or is PHP.net using scripting that it doesn't need to?

It's obvious why some sophisticated cyber-criminals or national governments would want to attack PHP.net: it's a "watering hole" for developers who control internet servers. It's the fastest & easiest way to attack massive numbers of people, by installing malware on hundreds of thousands of web sites.

For a few months, my wife was complaining that our computer ran slowly for her. We're running Chrome with Javascript, Flash etc. on a whitelist, and with Java not allowed in the browser. I wonder what we could have done? Flashed the BIOS and reinstalled Windows, and this seems to have solved the problem for now.

When are we going to get some permanent solutions to these kinds of problems?

I know it's non-trivial to do especially when reporting breaking news, but it would be awesome if Ars would update these types of articles with information about whether patched systems are at risk or not. Sometimes these outbreaks are using zero-days that are real risks to sophisticated users; at the other end is the exploit that affects XP Service Pack 1 (which is probably half of corporate America, but I digress).

The article mentioned the exploit tried to install a trojan using a client-side vulnerability in Flash (or Java). I am curious if that did the trick for Chrome browsers? The Chrome browser is supposed to be a complete sandbox (with the Flash now also running in a sandbox mode).

I thought the PHP.net site was relatively simple! No Adobe Flash, no Java, no real need for Javascript... What is this, maliciously crafted HTML/CSS? I thought we'd beaten that with toughened, sandboxed browsers? Or is PHP.net using scripting that it doesn't need to?

Looking at the transmitted JS files I can see the following functionality provided by JS:

Light boxes (probably not so common, I think I have ever only encountered one on the php.net sites)Comment voting (similar to what we have here on Ars)Langauge pickerSome cookie handlingBeta site on/offScroll To TopUserVoice feedbackPing/analytics/tracking

Seems like this was targeting Windows machines according to the virus total website.Is this correct, I just assumed that cuz I saw .dll and a .exe. If so, it would be handy if the article included this too.

As the news post on php.net said, it was only visible intermittently due to interactions with an rsync job that refreshed the code from the Git repository that houses www.php.net.

It was amusing when I found out about it. Basically, the malware would be uploaded, and very quickly replaced automatically with the correct code, then re-uploaded again, and replaced again, ad infinitum.

Dear Dan, Next time, just say "It's a picture of 'geographic tongue'" rather than leaving a Wikipedia link where I have to sift through a pile of gross mouth disease pictures to find out why the fuck the person has swirlies on their tongue. Then I can just find a nice, picture-free article to explain the condition.

I have no idea what your article was about, lost interest after seeing rotted out facial cavities.

First, the code packages are hosted on mirrors. They might be compromised too, but php.net is mainly a documentation site.

Second, this has nothing to do with the merits of PHP. I appreciate valid points on both sides of that debate, but this could happen to any site.

Third, the only interesting part of this incident is the aspect we don't know about, that is, how the exploit occurred. There is a lot of talk about the consequences such as serving malware, etc., but it is hardly newsworthy that attackers use their access for one thing rather than another when they have free reign. There is no new or unknown vulnerability on the client side in this situation.

On the other hand these compromises of *n*x/Apache servers have been going on for a couple of years, more or less, including on professionally maintained sites, and no one has publicly explained how they're happening. (php.net is Apache on BSD, according to the headers.) If it were solved in one case and the analysis published that would be helpful for other admins to better secure their servers.

Aside from the OWASP-type code errors, which web devs should know to avoid, candidates would seem to include some tools used by site admins; credentials from compromised developer devices; a plethora of possible configuration issues.

I know it's non-trivial to do especially when reporting breaking news, but it would be awesome if Ars would update these types of articles with information about whether patched systems are at risk or not. Sometimes these outbreaks are using zero-days that are real risks to sophisticated users; at the other end is the exploit that affects XP Service Pack 1 (which is probably half of corporate America, but I digress).

The problem is a story like this it not always known at press time all the details such as which OSes are at risk or if it relied on zero-day exploit. Obviously Windows users are at risk but I am not certain about others. As far as zero-day exploit, the information may not be known for several days though the article seems to imply a zero-day exploit is not involved.

PHP, JavaScript, Flash, Java applets, Internet Explorer: this story is like a game of crap-technology-that-should've-died-a-decade-ago bingo.

You may want to rework that statement.

Flash and Java applets need to go, okay.But Javascript is the language of choice nowadays, and it's spreading more and more even outside the web. And Internet Explorer can be finally considered a decent browser.PHP is a mess of a language but it's server side, and it is possible to use it safely anyway.

I saw it with my own eyes. I take it the malware infects Windows users that use either Flash or Java or Internet Explorer? Any instructions to check for the malware?

I take it you didn't read the article where it said what the attack vectors were. Although it sounds like IE might be getting thrown under the bus for no reason. IE has its problems, but security is pretty good on 10 and 11. It is clear that the infections that were detected initally were not in IE since it was caught by google's safe browsing service, which doesn't include IE (MS has smartscreen filter).

Dear Dan, Next time, just say "It's a picture of 'geographic tongue'" rather than leaving a Wikipedia link where I have to sift through a pile of gross mouth disease pictures to find out why the fuck the person has swirlies on their tongue. Then I can just find a nice, picture-free article to explain the condition.

I have no idea what your article was about, lost interest after seeing rotted out facial cavities.

Sincerely,Me

Geographic tongue looks unsettling, but the condition is entirely benign.

PHP is a mess of a language but it's server side, and it is possible to use it safely anyway.

PHP isn't so bad nowadays and most of the problems are historic. PHP was originally just a templating language but it was added to over time. I think at one stage the language developers had the attitude of "Kitchen sinks are popular? Then throw it in!". It's at this point I think PHP developed its bad reputation.

In recent years they've done a lot to sort out this mess despite the baggage it carries. The documentation is improving too and I think helps a bit to steer people toward using PHP well. However many bad examples and tutorials still turn up on google which doesn't help.

I know it's non-trivial to do especially when reporting breaking news, but it would be awesome if Ars would update these types of articles with information about whether patched systems are at risk or not. Sometimes these outbreaks are using zero-days that are real risks to sophisticated users; at the other end is the exploit that affects XP Service Pack 1 (which is probably half of corporate America, but I digress).

The problem is a story like this it not always known at press time all the details such as which OSes are at risk or if it relied on zero-day exploit. Obviously Windows users are at risk but I am not certain about others. As far as zero-day exploit, the information may not be known for several days though the article seems to imply a zero-day exploit is not involved.

I appreciate your comment, starglider. It typically takes days and sometimes weeks for researchers to analyze attacks like this one and determine precisely what exploits were used and what systems were or were not vulnerable. I understand rockforbrains' desire to know more, most of the details s/he is looking for weren't available.

While the VirusTotal information suggests the malware targeted Windows machines, there's no indication other OSes weren't targeted too. Keep in mind that (1) the exploits that targeted Apple, Facebook and Twitter exploited Macs and (2) well-written exploits have the ability to tailor exploits based on the target's specific OS and configuration.

First, the code packages are hosted on mirrors. They might be compromised too, but php.net is mainly a documentation site.

The servers that got hacked were serving among other things also git.php.net. PHP source code allegedly didn't get compromised, but people alleging that are the same people who a day ago were saying that Chrome warning is a false positive.

Quote:

Second, this has nothing to do with the merits of PHP. I appreciate valid points on both sides of that debate, but this could happen to any site.

Of course it does have to do with PHP, as it's very obvious attack vector with terrible security track. PHP.net got hacked before. For example in 2011 wiki.php.net was hacked. In 2012 MySQL.com, hosted using PHP got hacked using SQL injection (oh, the irony).

The sheer number of vulnerabilities discovered in PHP is jaw-dropping: 92 DoS, 91 remote execution, 83 overflow, 60 checks bypassing, 12 XSS, 12 memory corruption, 7 SQL injection and many more. A total of 346. These are vulnerabilities in the PHP itself, not counting vulnerabilities in any PHP apps.

By comparison, Python had a total of 21, the serious ones: 10 DoS, 1 remote execution, 6 overflows, 1 XSS.

First, the code packages are hosted on mirrors. They might be compromised too, but php.net is mainly a documentation site.

The servers that got hacked were serving among other thins also git.php.net. PHP source code allegedly didn't get compromised, but people alleging that are the same people who a day ago were saying that Chrome warning is a false positive.

Quote:

Second, this has nothing to do with the merits of PHP. I appreciate valid points on both sides of that debate, but this could happen to any site.

Of course it does have to do with PHP, as it's very obvious attack vector with terrible security track. PHP.net got hacked before. For example in 2011 wiki.php.net was hacked. In 2012 MySQL.com, hosted using PHP got hacked using SQL injection (oh, the irony).

The sheer number of vulnerabilities discovered in PHP is jaw-dropping: 92 DoS, 91 remote execution, 83 overflow, 60 checks bypassing, 12 XSS, 12 memory corruption, 7 SQL injection and many more. A total of 346. These are vulnerabilities in the PHP itself, not counting vulnerabilities in any PHP apps.

What would the statistics be if we put your Operating System and current web browser of choice through the same test? Would the numbers be any better?

First, the code packages are hosted on mirrors. They might be compromised too, but php.net is mainly a documentation site.

The servers that got hacked were serving among other thins also git.php.net. PHP source code allegedly didn't get compromised, but people alleging that are the same people who a day ago were saying that Chrome warning is a false positive.

Quote:

Second, this has nothing to do with the merits of PHP. I appreciate valid points on both sides of that debate, but this could happen to any site.

Of course it does have to do with PHP, as it's very obvious attack vector with terrible security track. PHP.net got hacked before. For example in 2011 wiki.php.net was hacked. In 2012 MySQL.com, hosted using PHP got hacked using SQL injection (oh, the irony).

The sheer number of vulnerabilities discovered in PHP is jaw-dropping: 92 DoS, 91 remote execution, 83 overflow, 60 checks bypassing, 12 XSS, 12 memory corruption, 7 SQL injection and many more. A total of 346. These are vulnerabilities in the PHP itself, not counting vulnerabilities in any PHP apps.

What would the statistics be if we put your Operating System and current web browser of choice through the same test? Would the numbers be any better?

By comparison, Python had a total of 21, the serious ones: 10 DoS, 1 remote execution, 6 overflows, 1 XSS.

Shit! I saw the google warning for that site while doing a search and didn't go at first. Though I was amused that php.net would be flagged. I thought it was some sort of error. While browsing later, I waltzed right on to that site via a question thread on stack overflow. Now I'm worried if I infected my machine. Wish there was a way to check.

P.S. - Java, Flash and PDF - some of the coolest pieces of softwares and some of the worst pieces of software at the same time, all bundled into a neat little handy bundle. I wish they'd hire a bunch of nasty nasty hackers, pay them tons of money, and find all the loopholes and close them before they even think of coming up with new features.