PhpMyAdmin Project Successfully Completes Security Audit

https://www.phpmyadmin.net/news/2016/6/13/phpmyadmin-project-successfully-completes-security-audit/

by pyprism • 10 years ago

210 109 10 years ago

phpmyadmin.net

smaili• 10 years ago

Does anyone still use this? I didn't realize this was still actively maintained.

donjh• 10 years ago

Countless people maintaining WordPress sites do.

drzaiusapelord2• 10 years ago

Every Drupal dev shop we've worked this insisted this was installed on the server. Its just firewalled off/tunneled/whatever for safety.

creshal5• 10 years ago

If you are using MySQL, and need to manually fuck around with tables for whatever reason, it's really useful and beats most other options.

For us it sees plenty of use with poorly developed legacy software (e.g. Wordpress).

martinczerwi• 10 years ago

You might like this: https://www.dbninja.com/

pinum• 10 years ago

I can't think of much reason to use it over Workbench or Sequel Pro.

onion2k2• 10 years ago

If you need to make a manual database change then Adminer is often a better option[1].

It's doesn't have the featureset as PHPMyAdmin but it has a huge advantage in that it's a single PHP file you can upload, make the necessary changes, and then delete. If you're interested in maintaining a secure server but you don't have any better options than using a script, then it's better to upload something when you need it than trying to secure an online admin tool.

[1] https://www.adminer.org/

overcast2• 10 years ago

MySQL Workbench works fine though?

waterphone• 10 years ago

Anyone using shared hosting (e.g. most people who do web development for small businesses) does.

toxican• 10 years ago

I think many (most?) web developers get their start on some shared hosting provider where your only obvious option for managing MySQL databases is phpmyadmin. You have to dig a little deeper to realize you cna use MySQL Workbench, but even then a lot of them disable remote MySQL and SSH so you're SOL.

So for me, at least, it's ingrained in my head that phpmyadmin is the best tool for the job given the limitations of what I've got. Although I recently switched my company's reseller hosting account to a provider that actually allows remote MySQL or SSH, so that's exciting.

20years• 10 years ago

I personally use Workbench when I can but a lot of clients with shared hosting use it. It still gets the job done for the most part.

blowski• 10 years ago

It usually comes by default with CPanel and Plesk on web servers, as well as MAMP / WAMP / XAMPP for development environments. In my experience it's still used a lot by junior devs who haven't yet learned any different, and people with absolutely no idea what they're doing.

23andwalnut• 10 years ago

What are some good alternatives? I've been using DataGrip the last couple of months, but prior to that I used phpMyAdmin all the time because I just couldn't find anything else as useful for MySQL. And even with DataGrip, I sometimes have to log in to phpmyadmin because there's stuff DataGrip doesn't do....

acomjean• 10 years ago

Yes. A lot of times its available on shared hosting behind some login. Esp, if you don't have shell access on inexpensive hosts.

Its been available at places I've worked. It was locked down by IP. The database was restricted to access by ip too, in theory making outside access more difficult.

I used it a lot (less now) and honestly, I kind of like it. The interface is a little kludgy, but it gets the job done. Queries are editable, exportable in various formats. You can construct a search via gui then edit the SQL it generates . It seems to have a lot of functionality built in, user/table management etc..

For local instances I use sequel pro too (the ssh login function it has is nice and works well).

hackaflocka• 10 years ago

PHPMyAdmin is a lifesaver for newbies and those who are intimidated by the Command Line. It was for me, and I still prefer to use it when possible.

I can't thank the people who created it and maintain it enough.

callesgg2• 10 years ago

I think it is one of the best mariadb/mysql gui's out there.

But to get the good stuff one has to configure it properly, and generally people don't bather configuring it. They just place the files in a folder.

No other web based tool for any database that i have tried even comes close.

sync• 10 years ago

A lack of filtering on user CSV output that could allow an attacker to run arbitrary code on an administrator's computer.
Improper cookie invalidation that could allow an attacker to unset internal global variables.

Those don't count as serious issues? Props to them for making the report public though.

creshal5• 10 years ago

> A lack of filtering on user CSV output that could allow an attacker to run arbitrary code on an administrator's computer.

Iff the user has Excel, and explicitly allows it to run macros in a CSV file. It's already a stretch to call this a phpMyAdmin vulnerability, much less a "medium severity" one.

> Improper cookie invalidation that could allow an attacker to unset internal global variables.

From the PDF report:

Note: Because of the large amount of global variables, and the relatively short nature of this assessment, NCC Group was unable to fully determine the impact of this vulnerability.

It might be serious, but they didn't have enough budget to make a proper analysis.

Rangi42• 10 years ago

Because of the large amount of global variables... NCC Group was unable to fully determine the impact of this vulnerability.

In other words, "This project is too full of potential security holes to find the definite ones."

wglb2• 10 years ago

I would venture that to do so would devolve into a full source audit, which seriously increases the scope of the test. Full source audits are likely to consume ten times or more calendar effort.

Performing a full source audit is going to result in sticker shock for all but the most well-funded.

sciurus2• 10 years ago

Interestingly, Google specifically excludes CSV vulnerabilities like that from their bug bounty program.

CSV files are just text files (the format is defined in RFC 4180) and evaluating formulas is a behavior of only a subset of the applications opening them - it's rather a side effect of the CSV format and not a vulnerability in our products which can export user-created CSVs. This issue should mitigated by the application which would be importing/interpreting data from an external source, as Microsoft Excel does (for example) by showing a warning. In other words, the proper fix should be applied when opening the CSV files, rather then when creating them.

https://sites.google.com/site/bughunteruniversity/nonvuln/cs...

dsacco6• 10 years ago

To add a bit of color here, Google is correct to exclude CSV vulnerabilities. There is no way (through this vulnerability) to compromise a Google host, a user account managed by a Google host or sensitive data associated with a user account.

As framed, this is kind of similar to using a Google web tool to edit an XML file, export it and compromise someone using external entity injection. In that context, you're not really compromising Google, and you're not using Google as a medium to automatically compromise many Google users at once. Google is only peripherally involved in the process.

What would qualify for a bounty is code/script execution on a Google host using a CSV file, maybe through something like Google Trends Correlate (https://www.google.com/trends/correlate). Either reflect the CSV contents in a publicly accessible location with a mismatched content-type or leverage an arbitrary file upload error to execute a malicious payload disguised as a CSV on the server. But just exporting a CSV from a Google host is not really a vulnerability in Google.

By the way, for people who are interested in bug bounties, it looks like the page I linked hasn't been updated since 2011. Might want to check it out.

igravious• 10 years ago

Secure Open Source has completed[1] the following audits.

    - PCRE v2 audited by Cure53[2]
      1 Critical
      5 Medium
      20 Low
      3 Informational

    - libjpeg-turbo audited by Cure53
      1 High
      2 Medium
      2 Low

    - phpMyAdmin audited by NCC Group[3]
      3 Medium
      5 Low
      1 Informational

[1] https://wiki.mozilla.org/MOSS/Secure_Open_Source/Completed

[2] https://cure53.de/

[3] https://www.nccgroup.trust/uk/

creshal5• 10 years ago

And in the PDF, the auditors complain that they didn't have enough time to even fully analyze the impact of the vulnerabilities found.

I wouldn't read too much into it.

Johnny_Brahms• 10 years ago

That is misleading. They said they had the ability to unset global variables. Looking at the PHPMyAdmin codebase, I understand they didn't have the time.

Ded7xSEoPKYNsDd• 10 years ago

If fixing the bug is less work then determining exploitability, fixing it and moving on is just economical. Digging in further would only have distracted from looking for other vulnerabilities.

baby• 10 years ago

This is not relevant. An audit cost a substantial amount of money, you wouldn't expect your consultants to spend a lot of time exploiting or building Proof-of-Concepts. If you have a time-boxed assessments, you want the consultants to cover the most ground and not spend too much time on a finding.

fauria• 10 years ago

Does anyone know how much (approximately) this audit could have costed?

dsacco6• 10 years ago

Given that the assessment occupied two weeks with two consultants, between $25,000 - $35,000.

I don't have intimate knowledge of NCC Group's pricing structure because I don't work there. But I have friends who do, and similarly situated consultancies that I've worked for are in the $10,000/week range for a one-off assessment with non-senior staff. This is also somewhat close to what I charge through my own smaller consulting practice.

Now, if there was specialty work (like crypto), particularly comprehensive work, more consultants billed on the assessment than usual or senior/principal consultants billed on the assessment, the total fee would go up. This is why I added a $10,000 premium to my estimate; the source code analysis detailed in this report might qualify as "non-standard."

That said, NCC might have worked on a discount for the opportunity to advertise that they were involved in the audit. But I don't see this assessment having costed anything less than $20,000 even in a charitable situation.

zhte4152• 10 years ago

$10,000/week range seems low for a week long audit, but depends on time charged.

Most audits I've worked on, while a week long, have a 2 week pre-audit familiarization period for the audit team, and a 1 week long post-audit report-writing period. This means a 1 week audit is an actual week of investigation, and for $10,000 this sounds low.

Via the article, it seems like a leading client / lead of future potential client, so discount works on many levels.

And from TFA: Conservancy and the phpMyAdmin project are proud of the results and thank Mozilla for funding and initiating the audit.

tptacek2• 10 years ago

You can usually add a pretty significant premium to an audit if it includes a public statement, like this one apparently did. But since Mozilla funded it as part of a block grant, the rate might be significantly lower.

CiPHPerCoder3• 10 years ago

I wish NCC Group had been given more time, since phpMyAdmin is nigh-ubiquitous in legacy PHP apps.

For example:

https://github.com/phpmyadmin/phpmyadmin/blob/4cd8ab8a957a23...

Despite setting several security-related session configuration values, they don't touch the cookie entropy fields, which means a potential session fixation vulnerability.

This might not be a concern for most users: typically your distro ships a php.ini configured to read at least 16 bytes from /dev/urandom. But not always! Many projects set cookie.entropy_length and cookie.entropy_source just to be sure.

arrmn2• 10 years ago

Stupid question, how does a security audit work? Do the consultants just read through the code? Do they try to find security bug like they do on bug bounty programs?

sb8244• 10 years ago

I'm not an expert in this field, but we recently did a security audit. The auditors get access to the code in order to evaluate it for vulnerabilities. In our ruby application, they also check gems that we are using (through open source tools albeit).

They also did an in-app audit where they tried to break the application however they might see that. Having access to the code helps with this.

When you get audited by potential customer, it usually involves not having code access and trying to penetrate the app without that access.

BinaryIdiot2• 10 years ago

When you get audited by potential customer, it usually involves not having code access and trying to penetrate the app without that access.

Is this in reference to on-prem / enterprise software and is this typical? I haven't heard of customers doing this but it certainly makes sense (might as well invest thousands to test before spending magnitudes more on the product itself only to find it having a huge security hole). Then again I'm not sure I've worked with potential customers who have access to do something like that.

dsacco6• 10 years ago

Good question. It can be all or none of the above. Here's what happens at a high level:

Once a company decides it needs a security assessment performed on an application, it engages with a consulting firm. Consulting firms generally offer a variety of services, from web and mobile application penetration tests, to cryptanalysis (implementation and design), to reverse engineering and binary penetration testing, with source code audits sprinkled throughout (or as standalone assessments). Let's assume they move forward with a web application assessment.

The company decides if it wants a source code audit, a penetration test or both. The most comprehensive assessments will include source code and unmitigated access to a staging environment that the consultants do not have to worry about destroying. However, they could also decide they don't want to hand over the code (common in things like sensitive financial applications or in applications with protective developers). I've worked on many assessments where I had no source code - this is called a "black-box" assessment.

Conversely, an assessment might consist of a source code audit with no penetration test! This is less common, but it's particularly suited for engagements where the developers are fairly sure they've eliminated the most common issues and they are really focused on obscure errors, logic flaws and race conditions.

It really depends on the type of security audit. You can have more exotic ones, like black-box cryptanalysis where a company hands Riscure a proprietary payment mechanism and there is heavy reverse engineering and side channel analysis. It can also be very vanilla, like the web application penetration tests that bug bounty programs attempt to simulate. Companies decide what they are going to do based on their application's profile and their goals.

Putting this all together, these are the stages of a traditional security audit from a high-quality firm:

Step 1: A company receives several proposals and decides which company to move forward with based on which statement of work most closely matches their security goals, timing, budget and desired expertise. Then they decide on a start date.

Step 2: Representatives from the company (generally a technical manager, a security engineer or manager if the company has one and at least one developer) have a conference call with representatives from the security firm (generally, the security consultants performing the assessment, an account executive and a technical manager) to "kick off" the assessment with technical and logistical engagement planning. Things like "How will we access the staging environment?" and "Is there anything off-limits" are fleshed out here as well as reminders about scope and scheduling.

Step 3: Things like source code, infrastructure/application/API documentation, PGP keys, etc. are securely exchanged and verified. This comes out of a list of mutual action items from the kick-off call.

Step 4: The actual assessment happens, generally in a period of one to three weeks. I've never been involved in an assessment less than one week long, and assessments longer than four weeks usually need to re-scope or they become monolithic and difficult to coordinate. Progress reports with findings and testing data are securely sent to the company from the security firm.

Step 5: The assessment is finished and a final deliverable is securely sent to the company from the security firm. An optional re-test assessment might happen a few weeks or months later to confirm if the findings have been satisfactorily resolved.

This is based on my knowledge of having worked in security consultancies, engaging with them as an in-house security engineer and running my own consulting firm.

CiPHPerCoder3• 10 years ago

I can't upvote this comment enough. That's an excellent answer to the question.

arrmn2• 10 years ago

Thanks for your response, great to see how it works from a business side. I'm going to use this opportunity and ask you another question.

What happens if after 2-3 weeks of consulting you don't find any "high impact" issue? Are your customer angry, happy?

opinion1• 10 years ago

Yes. The way it works is that two smart hackers go into the office each day and spend eight hours trying to think of as many creative ways of tapping on the target application as possible. Nothing is off-limits except what is agreed up front, but you're obviously expected not to interfere with production operations. The client is generally expected to set up a testing environment substantially similar to production, but usually consultants just have to muddle through with whatever the clients give, which may not (and usually isn't) populated with production data. As long as consultants are given the ability to enter in data themselves, i.e. admin accounts, this is fine, because data entry is their job. Hacking is basically large-scale data entry, and it's as boring as it sounds: very tedious, interspersed with excitement when you see an XSS popup window or figure out a clever way to get a reverse shell.

If after two weeks of this you found no medium-or-higher security vulnerabilities, you were generally considered to not be doing a very good job.

The secret of the industry is that at the end of this process, you are deemed secure. That's the point of the security audit. But if it's not a repeating process, it doesn't work. It may work for that particular version of the application, and it may substantially improve the security in that old vulnerabilities are found and fixed. Let me abandon this train of thought and put it another way:

This post is a press release saying that phpMyAdmin is secure. But that's not how this works. High-severity vulnerabilities are often found near the end of an audit. This is because the consultants have had time to become intimately familiar with the application. But the late stages of an audit are exactly when the consultant's time is mostly spent writing reports for the existing findings, and not doing pentesting. This means that two weeks is often just long enough to start finding serious vulns, since week one can be devoted to pentesting and week two is mostly reporting from Tuesday onward. But that "mostly reporting" process gets the consultant thinking about the application as they're doing the writeups, which -- you guessed it -- leads to realizing that there's something clever they could try. And when they try that clever thing, sometimes it yields a high-severity vuln. It's the opposite of a mechanical, thoughtless process.

That means your results will vary depending on who, specifically, is doing the auditing. If you run your application through the consulting process twice -- same version, same staging data, same everything -- it's likely that you'll get wildly different results, because the pentesters are different people.

It has to be an on-going process in order to be effective. And it can be highly effective. It just costs so much that only the most massive companies can afford this.

That's not to say this audit wasn't effective. It's possible that whoever did the audit found substantially everything. But it was interesting to discover how often this was not the case, in a "How'd they miss this last time?" sort of way.

eterm• 10 years ago

They're a very worthwhile process for SMEs and companies that haven't had one before. At one of my previous employers (I won't say which) they were marvelling at the ways in which the contractor was able to do privilege escalation by editing a form to change their user level from the "3" or "4" in the drop-down to "1".

The fact that they got full rights so quickly really drove home the need for security to be a feature and for code reviews.

Now the cynical would point out that standard pen testers would have found that, and maybe they would, but the speed at which a contractor could find these issues and then see the full breadth of the surface compared to pen testers was great. And the fact they could explain back what the problem was in terms of code and how it should be rewritten rather than just "found rights escalation in form x" leaving the client to perhaps improperly deal with that.

Overall I was far more impressed watching an auditor doing a few days work than any of the regular pen testing companies I've seen since who mostly seem to point fuzzers at any endpoints they find.

jquast• 10 years ago

The first few chapters of the book, "The Art of Software Security Assessment: Identifying and Preventing Software Vulnerabilities" outlines a very meticulous process of reviewing source code for vulnerabilities in a professional manner.

fideloper• 10 years ago

I really hate the idea of having a web interface to my database anywhere, no matter how secure they say it is. Social engineering (over direct "hacking") lends itself to circumventing technical security.

No matter their technical security (Although I'm super happy they test phpmyadmin!), I still wouldn't trust it on my servers.

Granted you can lock phpmyadmin down via ip restriction, vpn, etc - that's definitely good, but, if you can forgive a bit of generalization, those measure tend to be above people's head or too restrictive for those using phpmyadmin.

If we do connect to a database using a GUI (usually an app instead of phpmyadmin), however, my preference is through an SSH tunnel. This lets us connect securely (over SSH), and still allow MySQL to not be globally accessible from the outside world - meaning, you can still using MySQL's built-in network security features (bind-address and username hosts, along with firewall restrictions) to lock down MySQL.

labster• 10 years ago

I really hate the idea of having a web interface to my database anywhere,

Aren't those called "applications"? And yes, I hate them too.

ivanhoe• 10 years ago

Why do you presume that web app has to be run public? You can easily limit access to web app by IP, or you can put it on a private network that you will access through VPN. That would make it more secure than most web services that we trust regularly, like gmail or paypal...

CiPHPerCoder3• 10 years ago

If you're going to do this, go the VPN route.

dvt• 10 years ago

For a prospective hacker, I don't think there's much of a (functional) difference between a graphical interface or a shell.

tobltobs• 10 years ago

I think he is talking about unnecessary additional attack vectors, not about functionality.

developer2• 10 years ago

The attack surface for a web application like phpmyadmin is the entire codebase of that application. The attack surface for mysql over an ssh tunnel is basically only the sshd daemon and its authentication configuration.

I think most people would agree which one exposes a greater likelihood of being hacked. Of course you can secure a phpmyadmin installation against even being accessed by attackers (I've done this in the past myself), but there is still a chance of such security measures being accidentally botched compared to the sshd configuration.

I don't feel strongly either way, if you are confident that your security measures on a phpmyadmin installation are solid. I for one, security audit or not, would never expose a phpmyadmin installation on a publicly accessible URL.

Xeoncross• 10 years ago

I encourage people to google how to run phpMyAdmin, MySQL Workbench, or Sequel Pro locally, and use port forwarding over SSH. It's super simple.

Here is a command that forwards all traffic to localhost:3306 across the ssh tunnel to example.com:3306 (the mysql default port).

    ssh user@example.com -L 3306:localhost:3306

I would never run a DB admin application on the live server because it's just one more piece that might open a security hole.

xrstf• 10 years ago

On Windows, I recommend using HeidiSQL, which handles SSH tunnels for you using PuTTY's plink.exe.

jredwards• 10 years ago

I like some of the HeidiSQL tools so much that I run it via WINE on my mac.

voycey2• 10 years ago

Be wary of Heidi and SSH tunnelling on windows - I'm sure the bugs have been fixed but I first hand realised that it re-used the tunnel for subsequent connections meaning you were not making changes on the database you thought you were - definitely caused some problems! However it is such a good client that I now use it on Linux under Wine :)

kgdinesh• 10 years ago

Apart from security, are there any other benefits?

bdcravens• 10 years ago

I presume it'd be faster, since only remote data is MySQL data, as opposed to web server/PHP rendering.

paulannesley• 10 years ago

Sequel Pro (free open source, despite name) is a native application which is much nicer to use than phpMyAdmin. So, yes there's benefits other than security.

SeoxyS• 10 years ago

Or learn how to use the CLI client to connect. No need to install a awkward wrapper software layer.

coldtea2• 10 years ago

The "awkward wrapper software layer" has so many workflow enhancements and advantages over the ho-hum CLI client that it's not even funny.

smt882• 10 years ago

You seem to be a software developer who is advocating that people not automate something that's tedious (writing and running SELECT and UPDATE queries). Weird.

RhodesianHunter• 10 years ago

Take it a step further. Set up a locked down bastion server that can only be reached from your IP address, and disable all access to your DB from anything but your application and the bastion server. Then tunnel your local queries through your bastion server.

  ssh -fNg -L 3306:my-secure-db.com:3306 user@bastion-server.com

Shorel• 10 years ago

In that case I would add HeidiSQL to that list.

I use it with Wine in Ubuntu.

codedokode2• 10 years ago

Another option is to install these tools at a separate domain and setup HTTP authorization on a webserver. So automated bots scanning for vulnerable apps will not get even to the login page.

EGreg• 10 years ago

How can we get such audits done for our own open source projects?

oxguy3• 10 years ago

There are selection criteria listed at https://wiki.mozilla.org/MOSS/Secure_Open_Source , and, if you think you meet most of the criteria, you can fill out a form to apply.

shaunrussell• 10 years ago

10 years late.

oaf357• 10 years ago

I encourage everyone to use MySQL Workbench over SSH. For whatever reason people seem to not understand the concept of SSH and the inherent security it provides. But, once you explain to folks how to use it effectively it really is a good balance of security and usability.

homakov• 10 years ago

Is there much sense in auditing things that are usually used by the admin and are by design exposing a lot of control of the server? Sure it must not be exposed to an outsider, but if auth is done right, it doesn't matter how far the insider can get... IMO

sixhobbits• 10 years ago

"I'm not sure, what the guys did during the audit of phpMyAdmin, but it took me 3 minutes to find a persistent XSS in the latest version."

https://twitter.com/totally_unknown/status/74275332346864026...

scottydelta• 10 years ago

Software Freedom Conservancy congratulates its phpMyAdmin project on succesfuly completing completing a thorough

repetition of "completing" in first line.

PhpMyAdmin Project Successfully Completes Security Audit

Related Stories