My next class:
Network Monitoring and Threat Detection In-DepthSingaporeNov 18th - Nov 23rd 2024

PHP.net compromise aftermath: Why Code Signing Beats Hashes

Published: 2013-10-25. Last Updated: 2013-10-25 16:04:06 UTC
by Johannes Ullrich (Version: 1)
5 comment(s)

Yesterday, it was discovered that the php.net website had been compromised. At this point, the php.net team believes the servers were compromised for several days, and at least one file was altered to deliver malware. The current summary suggests that the attacker may have had access to the servers secret SSL key, which suggests the attacker had root access. [1]

Probably the most valuable asset present on the php.net site and it's mirrors is the PHP source code distribution which is used by sites worldwide. At this point, there is no indication that the attacker modified the file. But I want to focus on the user downloading a file, like the php source code. How to you verify that the file is authentic and didn't get tampered with?

PHP.net publishes MD5 hashes on its site, that a user may use to verify the binary. Never mind that MD5 isn't the strongest hashing algorithm. It is probably good enough for this purpose. But the real problem is that there is no digital signature. An attacker could swap the source code AND the md5 hash if the attacker has access to the server, and as in this case appeareantly is able to alter files. A digital signature would be created using a secret key FAR removed from the server, maybe even kept offline. This way, an attacker would be able to change the signature, but not using the authorized key, and an end user bothering to verify digital signatures would have a fighting chance to detect the compromise. Sadly, too many projects only use hashes (again: Doesn't matter WHAT hash you use. The can all be replaced).

[1] http://php.net 

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter

Keywords: code signing php
5 comment(s)
My next class:
Network Monitoring and Threat Detection In-DepthSingaporeNov 18th - Nov 23rd 2024

Comments

A further update on php.net
- http://php.net/archive/2013.php#id2013-10-24-2
24-Oct-2013 - "... The method by which these servers were compromised is -unknown- at this time...
Two php .net servers were compromised, and have been removed from service. All services have been migrated to new, secure servers... We will provide a full post mortem in due course, most likely next week..."
.
A wise user may use the checksum from another website (eventually through archive.org).

Some linux distributions also use the checksum from the same site harbouring the packages.
They should at least download checksums from other mirrors.
Dr. "J" Ph.D. This is a good write-up.... however please fix this.

Doesn't matter WHAT hash you use. The(y) can all be replaced).

Regards
- http://community.websense.com/blogs/securitylabs/archive/2013/10/25/php-net-compromised-serving-up-obfuscated-content.aspx
25 Oct 2013 - "... The ultimate goal of this injection was to redirect users to the Magnitude Exploit Kit (MEK), which attempts to exploit Adobe and Java platforms, among others, in order to serve up generic Ransomware..."
.
- http://blog.malwarebytes.org/online-security/2013/10/php-hack-redirects-to-magnitude-exploit-kit/
Oct 29, 2013 - "... it was determined that the site contained a modified JavaScript page called “userprefs.js” that eventually led users to the landing page for the Magnitude exploit kit..."

.

Diary Archives