Case #4: Blast from the past

In 2017 you don't see that many sites running PHP, but recently I stumbled on this site of classical PHP vulnerabilities.

Published: Mon, September 4, 2017, 07:25
Category:
Security
Tags:
Security Monday
PHP
File inclusion
OWASP 2013 A1

tl;dr 🔗

A small Norwegian company is using a completely broken and open amateur PHP CMS. The site is open for (at least) local file inclusion and it's possible to completely take over the CMS.

Summary 🔗

Who: Anonymous, let's call them Acme2
Severity level: Critical
Reported: August 2017
Reception and handling: Poor
Status: Not fixed
Reward: Not even a thank you
Issue: Completely broken PHP web site

Background 🔗

I actually can't remember why I landed on the web site. Someone asked me to read something on this or a linking web site. Having seen a lot of bad sites over the years you can sometimes tell just from looking at the front page that you'll find some issues there.

The site is for a very small Norwegian company doing some kind of training programs for other companies. It has some public facing login for editing the content inline and is written in the server-side scripting language PHP. There was a time when PHP was very popular, but I guess those days over.

Approach (technical stuff) 🔗

Once in a while I take a quick peek at web sites' source code. I was expecting to find something on this particular one, but I didn't expect to find it that quickly:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title>[name of company]</title>
...
<link rel="stylesheet" type="text/css"
    href="merge.php?css[]=%2Fcss%2Fstandard.css&css[]=%2Fcss%2Fcustom.css" />
...
</head>
...
</html>

Can you spot the opening? Obviously the CSS was produced by some PHP script combining separate CSS files into one. Could it be that it would work for other files and directories?

Well, first I had to find the name of some other PHP files. I didn't see any, so I logically guessed on index.php: http://example.com/merge.php?css[]=index.php
But then it responed something like /* File is not a CSS or JavaScript file. */
Good, maybe there was some sort of security in place after all?

As you might know, PHP is built mainly using the programming language C. And C uses null bytes to terminate strings. So the next natural step is to try a URL like http://example.com/merge.php?css[]=index.php%00.css where the script will still check for the .css file ending, but when using the input string to include a underlying file it'll only use the part up to the null byte (URL encoded as %00).

This was bulls eye. I got the source of the index.php file back. At this point you know that you are golden.

Normally I would just provide a URL like http://example.com/merge.php?css[]=../../../../../etc/passwd%00.css just to prove the point to the site owner. Not that /etc/passwd contains any passwords any longer, but it will typically reveal usernames and shows that one can retrieve almost any file from the file system. However, this was a Windows machine and the index.php was not containing anything fun in itself.

index.php did however point me towards other scripts files and moments later I got hold of this PHP file that actually defined the username and hashed version of the password of the admin user. Given the state of the site I'd be surprised if there even was some random salt per user. So what you do you do when you have a hash? Well, you search for a online rainbow table site.

I got an immediate hit for the hash. Not surprisingly the hash function used was the no longer recommended SHA-1 and the password itself was so short and simple that you probably won't find it on lists of the most common passwords. Using the username and password you'd get full access to the content management system for the site.

At this point I stopped looking any further. I had enough info to report the issue and give a sense of the severity of what I saw.

What I overlooked 🔗

In my eagerness to find the security holes in the web app (and due to lacking branding) I didn't notice that this was actually not a homemade PHP site like I first thought. I didn't see it until writing this post, but there was a very interesting HTML meta tag:
While I couldn't easily find the full history, it seems like gpEasy CMS is an old version of Typesetter CMS. I couldn't find the file inclusion among the issues on CVE details, though there was another site with quite a few issues listed.

Security issue 🔗

This is a completely broken PHP CMS. It's possible to retrieve about any file on the server, and you can change any contents of the site.

This is only speculation as I didn't look further after finding the file inclusion issue, but when you find a site like this you most probably also will find other types of holes like remote code injection.

Reception and handling 🔗

Day zero 🔗

I sent an e-mail to the contact address. 8 minutes later I got a response. That's a new record. But the answer wasn't that uplifting. Apparently the site hadn't been of much in use the last years (though I would definitely guessed otherwise looking at the public accounting and taxation figures..). It didn't seem to be of any interest doing anything with the site or server. So hopefully there isn't anything of value there and hopefully no one makes the server into some kind of zombie.

Anonymous you say? 🔗

This is a small company, possibly not in any real operation. They haven't fixed - and probably won't fix - the issue. I don't think it's right naming them. Let's just hope no one else finds the site and that they don't have any important or customer data on the server.

Conclusion 🔗

This was a blast from the past for me. It's been quite some time since I last saw an amateur PHP site like this. PHP once was very hot as the scripting language, partly because it is very easy to get started with, but it had a lot of pitfalls and it was so easy to make a site insecure. As the language matured the usage has gone down. Today most issues I see are HTTP service endpoints with lacking authorization checks.

Get notified when there are new posts! :-)