Skip to content.

Scott Arciszewski

Software, Privacy, Security, Innovation

PHPUnit — A Lesson in Good Incident Response

January 19, 2015 2:26 AM • Development, Open Source, Opinion, PHP, Security

Earlier this year, I wrote a post detailing the terrible incident response of EC Council after they were hacked. They were ineffective for several days, then tried to cover up the incident with silence, and posted a vague, misleading, and probably dishonest press release on their Facebook profile (and deleted all of my pointed questions and criticism, might I add). Consider this post a follow-up with a twist: How to do it right.

Let me first state that as far as I know, PHPUnit has not been hacked. Understood? Okay.

Earlier this month, I discovered that the instructions to install PHPUnit were as horrendous as the install instructions for Composer:

  1. Download this .phar from our website (which thankfully doesn't bareback over unencrypted HTTP)
  2. Immediately execute it without verifying or inspecting the package

So if PHPUnit's webserver was hacked, the attacker could silently replace the .phar with a trojan and nobody would have noticed.

When ever I see a security concern like this one, I immediately sound the alarm and attempt to escalate it to whomever is responsible. Since PHPUnit is open source, I decided to open an issue on their GitHub repository.

Within 24 hours, Sebastian Bergmann (the author of PHPUnit) signed all of the .phar files with a PGP key, uploaded all of the signatures and SHA1 checksums, and updated the documentation to make it obvious that verifying the .phar is easy to do (and almost certainly a good idea).

This story has a happy ending. I would, however, like to raise some concerns that arose out of this discovery (and others similar).

Always Listen to Security {Researchers,Enthusiasts}

Whenever I raise the alarm, it's because I believe I know something that could cause a lot of damage if a jerk had the same knowledge. Many vendors refuse to work with researchers (ZPanel in 2013, vBulletin this year) and many companies just blow us off.

To wit: I've spent the past few weeks trying to contact the Huffington Post's technical team so I can share a concern about their infrastructure (which I will not be disclosing until they fix it), and they've completely ignored my every attempt to reach out to them. It's frustrating, and unacceptable for a website in the Alexa Top 100.

A Brief Open Letter to Test-Driven Development Enthusiasts

Professional PHP Developers:

Why did YOU not catch this? This is such an incredibly obvious security threat
that could have led to each of your developer workstations being 0wned and your
million-dollar proprietary software being leaked to blackhats to peruse at their
will to find 0day. How many of you earn six-figure salaries and claim to 
understand security, enforce rigorous unit testing methodologies, embrace 
Continuous Integration, yet never thought to verify the PGP signature of a
.phar file blindly downloaded from a remote server?

Did your software engineering education teach you that blindly executing code you
found over the network without checking it is a good idea? If so, demand a refund.

Either learn2security, or pay me a buttload of money to teach you security.
Because as it stands, that was an incredibly stupid oversight on all of your

Take this as a learning opportunity.

Scott Arciszewski

Secure Software Delivery Remains an Open Challenge

I can't close this without simultaneously attaching the disclaimer that "secure software delivery is, by and large, still an unsolved problem" and giving a shout-out to Taylor Hornby who succinctly framed the challenge. Code-signing is utterly essential, but it's not the whole solution. Reproducible builds from source code and being able to verify that you're receiving the same package as everyone else to prevent targeted attacks (either via the Bitcoin block chain, a protocol similar to Certificate Transparency, or something new) must also be satisfied to be able to fully trust software.

It should go without saying, being open source is a prerequisite for any basis of trust.

BONUS: — with GnuPG Verification


## CONFIG ##
clean=0 # Clean up?
bstrap="src/bootstrap.php" # PHPUnit Bootstrap File
tdir="tests" # PHPUnit tests directory
## /CONFIG ##

gpg --fingerprint D8406D0D82947747293778314AA394086372C20A
if [ $? -ne 0 ]; then
    echo -e "\033[33mDownloading PGP Public Key...\033[0m"
    gpg --recv-keys D8406D0D82947747293778314AA394086372C20A
    # Sebastian Bergmann 
    gpg --fingerprint D8406D0D82947747293778314AA394086372C20A
    if [ $? -ne 0 ]; then
        echo -e "\033[31mCould not download PGP public key for verification\033[0m"

if [ "$clean" -eq 1 ]; then
    # Let's clean them up, if they exist
    if [ -f phpunit.phar ]; then
        rm -f phpunit.phar
    if [ -f phpunit.phar.asc ]; then
        rm -f phpunit.phar.asc

# Let's grab the latest release and its signature
if [ ! -f phpunit.phar ]; then
if [ ! -f phpunit.phar.asc ]; then

# Verify before running
gpg --verify phpunit.phar.asc phpunit.phar
if [ $? -eq 0 ]; then
    echo -e "\033[33mBegin Unit Testing\033[0m"
    # Run the testing suite
    php phpunit.phar --bootstrap $bstrap $tdir
    # Cleanup
    if [ "$clean" -eq 1 ]; then
        echo -e "\033[32mCleaning Up!\033[0m"
        rm -f phpunit.phar
        rm -f phpunit.phar.asc
    chmod -x phpunit.phar
    mv phpunit.phar /tmp/bad-phpunit.phar
    echo -e "\033[31mSignature did not match! Check /tmp/bad-phpunit.phar for trojans\033[0m"
    exit 1

In conclusion, I'm pleased with Mr. Bergmann's response and disappointed with the industry. There's a lot of work to be done, both on the innovation frontier as well as teaching developers how to not carelessly risk getting their entire network compromised.

Blog Archives Categories Latest Comments

Want to hire Scott Arciszewski as a technology consultant? Need help securing your applications? Need help with secure data encryption in PHP?

Contact Paragon Initiative Enterprises and request Scott be assigned to your project.