Full disclosure: multiple critical security vulnerabilities (including a backdoor!) in PHP File Manager

In July 2010 I was looking for a web based file manager that I could use on my own web server. After some research I found the PHP File Manager from Revived Wire Media. A basic, but good looking web based file manager for just $ 5. I bought it and installed it on a test server to see how it worked and if it was safe.

After looking at it, I did some shocking findings which I’ll disclose in this article. This commercial off the shelf software product contains several critical security vulnerabilities that can be easily unauthenticated remotely exploited. On top of that, it even includes a poorly secured backdoor, leaving this web based file manager completely open.

I’ve contacted Revived Wire Media three times but got no response of them, so I’m going full disclosure.

At this moment, confidential files can be be easily downloaded from Eneco, Nintendo, Danone, Nestle, Loreal, EON, Siemens, Vattenfall, Oxford, Hilton, T-Mobile, CBS, 3M and also a couple of banks and quite a lot of other companies (lesser known to me).

One company in America that uses the file manager is active in youth care and provides mental health and substance abuse services. It has 250 mental health professionals who are probably sharing all kinds of very confidential patient information via PHP File Manager.

I did almost forget about it
A couple of months ago I had a talk with a friend of mine, who is also a security penetration tester. We exchanged stories about all kinds of scary security vulnerabilities we had discovered in the past. While we were talking, it brought back my memories about the PHP File Manager case from around five years ago. Did almost forget about it.

I was curious if the security was improved in the past years, so I ordered a new copy of the software to review its security again. It appeared that nothing had changed in all those years (!). I felt that something needed to be done. Quite a lot of companies are probably storing their internal documents completely unsecured on the internet.

This couldn’t last any longer. People need to know about this.

Back to 2010

I just bought PHP File Manager and wanted to use it immediately. A private cloud to store and privately share files with colleagues was something I was in need for. It was advertised as:

A web-based file manager that is easy to configure for a novice yet easily customized for the more experienced user. The built-in login system provides a secure environment. It can create, rename and delete folders; create, upload, rename, download and delete files; edit text files; view image files; sort by name, size, mode and date modified; and more.

Did I just read it provides a secure environment? That’s really thoughtful of them. Cool!

Performing a quick security review
Before I wanted to deploy the software to production, I performed a quick security review to see if it was safe to use. My eye felt immediately on the ‘db’ directory that the software package contained:

That directory sounded sensitive, so I looked into it to see what it contained: just one file named valid.users which had the following contents:


Apparently a text based user database, which contained user names, password hashes, binary based authorization configuration and web server paths where users may store their files in.

A password hash is a measurement so software can safely store a user’s password in a database. A hash is a one way transformation of a readable password to an unreadable format. A properly generated hash cannot be returned back into a readable password without using a time consuming brute force attack.

Curious first line in user database
The user database contained a curious first line about not removing that entry. Strange. I wondered if the administration panel reflected this line so I logged in with user admin to view the current defined users:

Default users in admin panelJust three users, while the user database contained four lines. I wondered what the purpose was of the first line of the user database:


It was a well formatted first line including a password hash, so it just could be a fully functional user. I reviewed the PHP source code of the application, but couldn’t find any reason for the need of this first line.

Cracking the code
It didn’t served any purpose. It didn’t feel right. I had to find a way to figure this out, so I started cracking the MD5 password hash to see if I could reverse it back to its original password. That didn’t take long: the password was instantly cracked.

My hearth was beating rapidly. I thought it was unlikely, but could the user name just be ****__DO_NOT_REMOVE_THIS_ENTRY__****? Filled that user name in into the login screen with the password I just cracked:

Login screen trying backdoor

And hit the ‘Log In’ button:

Logged in with backdoor account

Wait, what? It worked! I was logged in!

Did I just found a backdoor?

Reflecting the situation
Giving the benefit of the doubt, I thought for a minute that this was some kind of support account, so that Revived Wire Media could help their customers in case of a software defect. But then again: why give this support account such an obscure name? If it’s legitimate you would name that account support, not ****__DO_NOT_REMOVE_THIS_ENTRY__****, and you would also expect a support account to be publicly documented. That was not the case.

And why would such a simple web based file manager need a support account? Never seen a feature request for that kind of functionality in a web application.

It all didn’t make sense and I immediately knew that this was something big: an intentionally created security leak. Not something you see every day as a security researcher.

Permissions of backdoor user
I dumped the PHP session variables to see which permissions the backdoor user has in the file manager:


The user isn’t allowed to create, download, rename, upload, delete, view or edit files on the system. But, it has user administration rights: because AllowAdmin is set to 1, the user can create another user which could have all permissions that are available in the system. So, it has all the rights a backdoor user needs.

Why doesn’t it have those other rights? It’s way more stealth to have all kinds of zero’s in the user database file for the backdoor user; it’s less suspicious that way.

File manager installation location is leaked to vendor 
You could argue that Revived Wire Media can only use the backdoor if it knows where the file manager is installed. And this installation location isn’t disclosed to them after the purchase of the software. This is true, however, there is a HTTP referrer leak in the code via which they can retrieve the installation path.

PHP File Manager contains a banner in the footer that contains an advertisement link to Revived Wire Media:

[..] <a href=”http://www.revivedwire.com/products/” title=”Revived Wire Media – Web Design, Web Development, Web Hosting, Corporate identity, Search Engine Marketing and more [+]” class=”PoweredBy_”><img class=”opaque” src=”gfx/PoweredBy_RevivedWire.gif” alt=”Powered by Revived Wire Media” width=”168″ height=”24″ border=”0″></a> [..]

This link doesn’t contain the HTML5 attribute noreferer, so browsers will sent the location of the PHP File Manager installation to the vendor when visitors click on the link.

Another security researcher had found the backdoor

I googled the backdoor user name to see if someone else also noticed it. Apparently security researcher Stefan Horlacher from CSNC also found it in 2012, two years after I found it initially. He contacted Revived Wire Media three times, but got no response from them:

# http://www.csnc.ch/en/downloads/advisories.html
# Product:  php File Manager [1]
# Vendor:   Revived Wire
# CVD ID:   CSNC-2012-008
# Subject:  Backdoor Account
# Risk:     High
# Effect:   Remotely exploitable
# Author:   Stefan Horlacher <[email protected]>
# Date:     09/17/2012

php File Manager is a file management solution written in PHP by Revived Wire. The script is shipped without a database and all needed files are stored locally on the web server. The default installation comes with a hidden user ****__DO_NOT_REMOVE_THIS_ENTRY__**** which isn't displayed in the application's user list. The password is stored as a MD5 hash, is identical on all script installation and can be trivially cracked on the Internet.

Therefore, every installation may be accessed using this default credentials. The account itself only has the rights to create new users but any access rights can be attributed. This allows an attacker to:
1. Create an administrator user on vulnerable installations
2. Upload and execute his own PHP script files

php File Manager 4.5

Workaround / Fix:
Remove the ****__DO_NOT_REMOVE_THIS_ENTRY__**** user from the valid.users files.

03/29/2012, Vulnerability discovered during a pentest
09/18/2012, Vendor contacted #1
09/24/2012, Vendor contacted #2
10/01/2012, Vendor contacted #3
10/10/2012, Full Disclosure (No response from vendor)

[1] http://www.revivedwire.com/products/File_Manager/

Three years after this responsible and also full disclosure nothing has happened. This is bad.

Apart from the backdoor, PHP File Manager contains several other critical security vulnerabilities.

Arbitrary and unauthenticated file uploads are possible
One of those vulnerabilities is within Uploadify, a software library that is used in the application. Via this severe security vulnerability PHP code can be uploaded and then executed; compromising security completely. It’s unauthenticated, so it’s even not necessary to log in.

As you can see, uploads handled by Uploadify aren’t checked at all if they’re safe (in file /uploader/uploadify.php):

PHP code uploaden en uitvoeren

Curious if the vulnerability was already known, I began searching on Google for more information. Apparently I was not the only one who found it, and nowadays it’s fixed in the latest version of Uploadify.

Another security vulnerability in Uploadify makes it possible that you can check if arbitrary files exist on the server (via file /uploader/check.php):

Check if files exist on the server

I have no idea if this vulnerability is already known within the Uploadify community.

Uploading and executing code via another way
The default installation of PHP File Manager includes demonstration files that show what kind of files could be uploaded and thus shared via the system. Apparently it’s also possible to upload PHP files:

Default files including a PHP file When clicking on the sample.php file, a download pop-up is shown:

Onclick on PHP file triggers download popup

This pop-up is triggered because the file is routed via a download script that makes sure the PHP code isn’t executed and thus can be downloaded:


Because all file uploads are directly stored in the web root (which is a very bad idea), those file uploads can also be called directly, resulting in the fact that the uploaded PHP code can also be executed:

Uploaded PHP files can be executed

All users who have access tot PHP File Manager can run arbitrary programming code on the server (under the privileges of the web server user). That’s a huge leak, compromising the entire security of the web site.

Unprotected user database
Remember the valid.users file in the db directory which contains all the user names and passwords? I wondered if I could open it from my web browser:

valid.users opened via web browserIt’s possible! The whole user database can be remotely viewed! That’s quite bad! An attacker can see all password hashes and retrieve their corresponding clear text equivalent via cracking. That’s like leaving the keys of your house under your doormat.

Insecure password hashing
In file /inc/admin.php it’s visible that passwords are stored insecurely:

[..] fwrite($fd, md5(stripslashes($pass))); [..]

The deprecated MD5 hashing algorithm is used without applying a salt. They should have used salted SHA2-512. Nowadays unsalted MD5 hashes can be cracked very easily.

So, the password hash database is unprotected and those hashes can be cracked almost instantly. Not something I would advertise as a “secure environment” 😉

Finding other PHP File Manager installations

Via a couple of specially crafted Google queries (Google Dorks) I could easily find quite a lot of PHP File Manager installations. I found out that the software is used by the following high profile companies:

  1. Eneco
  2. Nintendo
  3. Danone
  4. Nestle
  5. Loreal
  6. EON
  7. Siemens
  8. Vattenfall
  9. Oxford
  10. Hilton
  11. T-Mobile
  12. CBS
  13. 3M

… and also a couple of banks and quite a lot of other companies (lesser known to me).

One company in America that uses the file manager is active in youth care and provides mental health and substance abuse services. It has 250 mental health professionals who are probably sharing all kinds of very confidential patient information via PHP File Manager.

At this moment, confidential files of all those companies can be easily downloaded (!). I’ve contacted Revived Wire Media three times, the vendor behind PHP File Manager, but got no response.

I haven’t used the backdoor on those installations and I haven’t downloaded any file, but imagine what someone could do who is less ethical then me. You could do it even completely anonymous if you would use the simple to use Tor Browser. Nobody could even find out that you did it (if used properly), not even high tech crime cops.

Overview of all identified security vulnerabilities

During the quickly performed security review, I’ve identified the security risks below. Please be advised that these are certainly not all security risks that this application has.

If security is important to you, then let a professional security test be performed by a specialized company to let you inform yourself about all security risks that this software has.

Identified critical security vulnerabilities:

  1. Poorly secured backdoor user that compromises all security measurements.
  2. User database is completely unprotected and can be freely downloaded via any web browser. Password hashes stored in the user database are unsalted and are generated via the deprecated MD5 hash algorithm. Most of these hashes can be instantly reverted back to their original password via online MD5 reversing services.
  3. Arbitrary and unauthenticated file uploads are possible because an old version (2.1.0) of the library Uploadify is used. PHP code can be uploaded and executed, compromising security completely.
  4. There is no configuration option available to restrict the file extensions that are allowed to be uploaded by authenticated users: you can upload and also execute PHP files.

Identified high security vulnerabilities:

  1. Multiple cross-site scripting vulnerabilities, making identify theft attack scenario’s possible.
  2. No authentication or authorization checks are performed on files that are uploaded by users. If you know the internet address of a file, you can download it without being logged in.
  3. Vendor that lacks complete sense for security. One that builds in a backdoor, doesn’t respond to responsible disclosure, doesn’t perform security testing itself and doesn’t maintain its own software, resulting in a complete insecure application.
  4. Cross site request forgery is possible.

Identified medium security vulnerabilities:

  1. No password strength policy is implemented. A user can generate a password of one character.
  2. A user if not forced to change the default passwords of all default installed users, such as the password for the administrator account.
  3. PHP session files are stored in the web root.
  4. Referrer leakages to Revived Wire Media: they have the ability to know where you installed PHP File Manager.
  5. File uploads are directly stored in the web root, not in a separate upload folder on the server out of the web root.
  6. Ability to check if arbitrary files exists on the system without having to log in.
  7. Default users (admin, User1 and User2) are installed which all got the same password set.
  8. No protection against brute force attacks on the login screen.
  9. Session cookie without HttpOnly and Secure protection.
  10. No HTTP Strict Transport Security support is implementation.
  11. No Content Security Policy implemented.
  12. Privilege escalation possible for authenticated users if PHP configuration option register_globals is set to true.
  13. Outdated jQuery library that is probably vulnerable for cross-site scripting attacks. The file /uploader/jquery-1.3.2.min.js is from February 20, 2009.

Identified low security vulnerabilities:

  1. Local path disclosure via installation support scripts (in /show_windows_path.php and /show_linux_path.php).

Other findings:

  1. Violation of GPL: removal of copyright information

Some vulnerability highlights

I won’t go into the details of all vulnerabilities found, but highlighted some of them below.

Multiple privilege escalation vulnerabilities possible
When an authenticated user performs an action in the system, it’s validated if this person is authorized. An example of such authorization routine looks like the following (in file /inc/create.php):

privilege escalation

The $AllowCreate variable is only set if the user is authorized. Otherwise it doesn’t exist. This creates an authorization bypass security vulnerability if PHP configuration option register_globals is enabled.

Password hash disclosure via open session files
The application saves its PHP session files in the web root. Unless you have a .htaccess file in that directory with deny from all in it, it is unsafe as everyone can view the contents of a user session if you know the session identifier.

When the following address is requested:


The web server will return the secret session contents:


As you can see, the password hash is disclosed.

Violation of GPL: removal of copyright information
After inspecting the source code and correlating it to various open source projects, I found out that the software was forked and based on PHPFM, a GPL based open source project started around 2002.

PHP File Manager is derived work of PHPFM and thus it inherits the GPL license. Nowhere a reference is visible in PHP File Manager that it’s based on PHPFM, so the author must have removed all copyright statements. That’s a violation of the GPL license.

Responsible disclosure timeline

I’ve contacted Revived Wire Media three times:

  1. July 19, 2015: Contact via a form on their web site.
  2. July 22, 2015: Contact via e-mail.
  3. July 24, 2015: Contact via e-mail.

They didn’t respond back to me. Not even when I informed them that I would go full disclosure. Oh well, not the first vendor that ignores security researchers on multiple occasions.

I think I’ll get their attention now in a very short time 😉

Update July 28, 2015: Yep, got their attention now: they removed the software from their web site around 30 hours after publication of this article. They still haven’t informed their customers yet.

Wrapping up

Hopefully Revived Wire Media will take their responsibility and take immediately action. At a minimum they should fix all critical and high security vulnerabilities and inform their customers about the fact that their file managers can easily be hacked.

Companies that use PHP File Manager should take it offline as soon as possible. It’s not a safe product!

News sites linking to this story

  1. SecurityWeek.com
  2. Threatpost.com
  3. ShieldJournal.com
  4. Golem.de
  5. Heise.de
  6. SecurityLab.ru
  7. BoanNews.com
  8. CERT-hungary.hu
  9. Allofus.de
  10. Bambawale.com
  11. SCmagazine.com
  12. Hakspek.com
  13. SecurityAffairs.co
  14. ProDefense.org
  15. ClickSSL.net
  16. Akati.com

About Sijmen Ruwhof

Independent IT Security Researcher / Ethical Hacker
This entry was posted in php security, responsible disclosure, security assessment. Bookmark the permalink.

36 Responses to Full disclosure: multiple critical security vulnerabilities (including a backdoor!) in PHP File Manager

  1. Dit is waarom mensen PHP nog steeds niet serieus nemen. Wat slecht!

  2. Felix says:

    Please don’t advertise SHA-512 for password hashing. See https://secure.php.net/manual/en/faq.passwords.php#faq.passwords.fasthash

  3. Ed Schouten says:

    Hi Sijmen,

    Though I agree with everything you mentioned in your article, don’t you think that doing a full disclosure only eight days after initially contacting the vendor is a bit short? It could well be a small company whose single employee happens to be on a two-week summer holiday.

    That said, considering that they even ignored similar reports in 2012, it might not matter.

    • Eight days is a bit short indeed and normally I would wait much longer. However, the vendor didn’t respond to a security researcher in 2012, and also not even when that researcher went full disclosure.

      It’s probably a small company and the owner could be on holiday, but if that would be the case, they should have configured an out of office message on their e-mail account.

  4. Jim says:

    Can you provide some of the google dorking strings so we can confirm if this exists in our environments? This looks like a product that a developer may have been tempted to use, even if not approved at a corporate level.

    • Because of the sensitivity of the matter, I’m not going to publish google dorks. Before we know, everybody is hacking those vulnerable file managers. Would give some companies a very bad day.

      If you e-mail me then I’ll lookup if your company is known to have it installed.

  5. user name ****__DO_NOT_REMOVE_THIS_ENTRY__****” is priceless 🙂

  6. I see a backdoor and I want to paint it black…

  7. jonnie says:

    Thx for this. Now these bastards just removed
    the Software. 404 error. Hide & seek…

  8. August says:

    Just out of curiosity: Have you tried to contacted the companies/institutions using the software? Or at least the ones where personal/medical information of individuals is involved?

    • Haven’t done that. I’ve did those kind of actions in the past, but not every company is friendly towards ethical hackers. Companies get very scared if you tell them out of the blue that you can get into their systems. If people get very scared, they want to defend themselves and sometimes, sadly, they threat with lawyers. I don’t have time for that.

      Contacting the affected companies is something that the vendor has to do. The vendor has all contact information and is a trusted party.

  9. G says:

    Haha.. they just renamed it to “php Content editor”
    > http://www.revivedwire.com/demos/Content_Editor/edit/

    Anyone else wanna play seek ‘n hide?

  10. Wegen solchen Flaschen werden wieder alle rumjammern wie schlecht PHP ist… Man man man…

  11. Manchmal kann man sich echt nur noch an den Kopf fassen.

  12. This is what you get for using legacy code.

  13. sysadmin says:

    The vulnerabilities that you have discovered directly affect number of sites hosted on our infrastructure. In order to protect our clients we apply web application firewall rules / virtual patching where possible.
    However such rules require proof of concept of the exploits that allows us to narrow down the criteria that are required to stop the attacks you mentioned.

    In your research PoCs are missing and we would like to request from you more information. We will be using your PoCs to build the waf rules that will protect our customers from being exploited.

    • It would be very hard to adequately protect the application via WAF rules. You could:

      1. Check the POST HTTP request and see if someone want to log in with the backdoor user.
      2. Check the POST HTTP request and see if someone wants to upload a PHP file (.php file extension).
      3. Check the GET HTTP request and see if someone requests ‘/db/valid.users’.

      These three checks would cover all critical security vulnerabilities.

  14. That is the worst hidden backdoor ever…

    backdoor user: ****__DO_NOT_REMOVE_THIS_ENTRY__****
    backdoor hash: da26c70fc120d803e24bff0c5e5f6bdd
    resulting password: [redacted]

    How to fix: remove the first line from phpFileManager/db/valid.users

    This won’t protect you from the other dozen security issues though..
    No one should be using md5 in 2015..

  15. – Knock, knock.
    – Who’s there?
    – ****__DO_NOT_REMOVE_THIS_ENTRY__****
    – Asterisk-asterisk-asterisk-underscore-who?
    – Shut up, just let me in.

  16. Jan Reilink says:

    Regarding their php Content Editor: parsing javascript in the preview isn’t a good idea either, wouldn’t surprise me if one found one or more XSS vulnerabilities in that product

    • I wouldn’t be surprised at all if the rest of the Revived Wire Media products are also very vulnerable. You should expect that the rest of their products is also backdoored.

  17. Stephan says:

    VERY interesting. You know what. Checkout this disclosure from 2013: https://www.exploit-db.com/exploits/25440/ .. You see what? 😉

  18. Abbu says:

    Can you please share the specially crafted Google queries you used to find the installations? Thanks in advance.

    • Sorry, I won’t release the Google queries I used. If I would do that, than I’ll make it too easy for black hat script kiddies.

Comments are closed.