PhpMyAdmin Project Successfully Completes Security Audit
phpmyadmin.net
phpmyadmin.net
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
Found my original ticket! And yes, I truncated a few production tables :(
ssh -fNg -L 3306:my-secure-db.com:3306 user@bastion-server.comTedium in a GUI is still tedium.
With a GUI, you can click 3 times and browse 3 tables. That's just not possible without a GUI.
If GUIs didn't save people (lots of) time, no one would have invented them and the software industry would be moving away from them.
Besides being way faster and more efficient, GUIs do things that CLIs don't:
- linting/error-checking/autocomplete for SQL
- checking query sanity (warn before an unconstrained DELETE for example)
- copy/paste data (within the database and between applications)
- jump from FK cell to the row it references
The list goes on.
- they can be stored in a version control system
- your coworkers can run them at their dev environment
- they can be used for automatic deployment
- you can test it in a dev environment before running at a production server. With GUI tools you have to remember and repeat exact steps you did before
- You can review the script or ask someone to look at it
I think GUI tools might be good for browsing and exploring database but not for making changes.
I use it with Wine in Ubuntu.
> 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.
> 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...
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.
If you work on a web application where users can generate reports that contain input from other users, and a common workflow is for users to download those reports and open them in Excel, they aren't going to be happy if your site is a vector for attacks. Saying "Oh, but it's an attack against your laptop, not against our servers; WONTFIX." is going to be tough to justify.
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.
In other words, "This project is too full of potential security holes to find the definite ones."
As for your other comments, there's this "burden of proof" thing.
Performing a full source audit is going to result in sticker shock for all but the most well-funded.
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.
Aren't those called "applications"? And yes, I hate them too.
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.
- 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
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.
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.
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.
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.
What's the difference between a contractor and a pen tester?
I consider one a function of how you are employed and the other a function of role. IE the two overlap and are not directly comparable.
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.
What happens if after 2-3 weeks of consulting you don't find any "high impact" issue? Are your customer angry, happy?
That said, I have had assessments where there were no findings. This is generally because there are informational observations that can't be escalated to vulnerabilities in the given assessment time, or because the application has a very security-conscious development team. If it happens, it might be a sign that the application is not sufficiently mature to require an assessment yet, or it's just too simple to really analyze. It can also mean that the consultant is not sufficiently competent to perform the assessment.
To give an example, I worked at a large consultancy where we had a giant public company hold us on retainer to perform assessments on "brochure websites" - they were not interactive at all. There wasn't even a login interface. The company wanted to check off that it had security assessments performed on all webpages it hosted, but realistically there were never any actionable findings. (This is about as much detail as I can give because it's NDA'd, but it's not the sort of thing I'd take on in my own practice).
A more recent example is a YC company I worked with a few weeks ago. Their development team is very well educated on security matters. While I found security vulnerabilities, there were no high severity findings because the quality of peer review and paranoid development was very high there. They were very familiar with every Ruby/Rails gotcha and pretty thoroughly avoided them.
To answer your question, I've never had anyone "angry" at me for not finding anything. They're not "happy", but as long as they can verify that the work they paid for was done, they aren't angry. It doesn't happen often, and when it has happened the consultant should provide enough information to demonstrate that competent work was done.
However, I personally don't feel very good about it. My understanding is that competent security engineers in general are not happy about it. It is much more likely that the assessment either shouldn't have happened (because the application is not mature or complex enough) or that the consultant was simply insufficiently competent than that the application is really completely secure.
As consultants, you are always very unhappy when your project ends with no sev:hi findings. That, too, is rare.
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.
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.
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.
I can understand the 2 week pre-audit familiarization period. How would you price this out instead? I was operating under the assumption that the pre-audit familiarization was priced into the first week as threat modeling and discovery. This would also lend credence to the report admitting that they did not have time to investigate as thoroughly as they would have liked.
I did forget to include the post-audit report-writing period, it's been a while since that was a thing for me. I've never billed for that in my own practice because I disagree with the idea of billing for five days of work that essentially boils down to "fill in findings and application details into a long-form, templated PDF." I've also never seen a consultant really need five days to complete one of those :). I'm sure folks like Tom will come in shortly to beat me over the head for not charging for this part of the assessment.
I don't understand what you mean by this though:
> And from TFA: Conservancy and the phpMyAdmin project are proud of the results and thank Mozilla for funding and initiating the audit.
I do agree it's likely that there is a discount here for future or publicly recognizable work.
I may have read the article wrongly, however. On second reading, it seems audit in the sense of check. Not audit as I assumed on an institutional level. In this case, certainly not everything is checked. Tires are kicked in the first couple of days, and if something seems like it has a leak, an extremely deep dive will be taken, for example checking thousands of records by hand (well, probably in Excel) looking for something missed - a signature, a verifier, etc. Non-cooperation results in the audit being extended in time until the auditor is satisfied with their findings.
I expect any competent firm to be able, in an afternoon, to look at the overall documentation of the web site, chat with me for an hour or so, and come up with a multi-point threat model that will guide the testing. I expect to pay for the actual week or weeks that the team is actually testing the system, and that the report after is a day or two and part of the price.
The scope of their work of course is what drives the total cost, but a single full-time week would usually range $15-20k.
For us it sees plenty of use with poorly developed legacy software (e.g. Wordpress).
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.
The days of painfully slow FTP servers are long gone where "it's one file" would count as advantage.
This leaves a massively worse UX and featureset.
(We are using adminer for postgresql databases, because there's no better alternative, and it makes me wish phpmyadmin supported postgres every time I have to use it.)
My favorite feature is generally the graphical database relation view. Without it i am something like 500% less effective.
The profiler (visual explain) of queries in MySQL workbench is a godsend.
Also, for general querying and table layout lookup in OSX (macOS, whatever) I recommend Sequel Pro. It has a slightly better UI when working with multiple databases (easier to switch).
Workbench - Massively unstable on linux. (Although I do like the visualizing tools assuming I'm willing to put up with it crashing every hour or so).
It seems like a really bad idea to place a web-based database tool on a public-facing host when technology exists to route MySQL through SSH.
Even shared hosts support SSH these days. If yours doesn't, maybe it's time to find another shared host!
I seem to remember installing it on my own workstation, setting up the ssh tunnel and then pointing PHPMA to localhost.
It's not my favorite tool and I've avoided it due to security concerns but I've set it up for others as described and I recall it worked fine. Like I said though it's been a while and I'm fuzzy on the details.
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.
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).
I can't thank the people who created it and maintain it enough.
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.
https://twitter.com/totally_unknown/status/74275332346864026...
repetition of "completing" in first line.
I wouldn't read too much into it.