Well this is great. I'm doing a talk tomorrow at OWASP London[1] on Wordpress Security. Interestingly while sorting out google dorks for the presentation I found 27,000 references to PHP Shell backdoors. If you're going, I look forward to seeing you there. Please don't laugh at me every time I mention wordpress and security in the same sentence.
Not UK based or anywhere close, but I don't think you need to go through all the trouble to redo it.
I will take you up on your offer of slides though, I only asked about the recording because I remembered seeing that Samy Kamkar talk online (though it might not have been at OWASP).
I always feel uncomfortable speaking when my talks are being recorded. I have a particular style that's a little unorthodox to speaking. I get all professional when a camera's around, this also means that I feel less comfortable talking freely about issues that may have wider implications.
I guess that's not so important for wordpress, but I'm talking at DC4420[1] next week on evading antimalware defences and that's not something I'd really want to see put up on youtube for obvious reasons.
Big trust betrayal - happy to set up an equivalent webex for the HN group. I understand that Wordpress is particularly useful for landing pages though, so I'm happy to do something and actually spend more time on it making it better for the wider HN community.
As an off-topic request, I prefer links to the original source, not to intermediate sources. Yesterday TechCrunch got love for an announcement made on Google Blog; today for an announcement made at Wordpress. In neither case did they add any value.
Really sparse on the details. Were the servers accessed due to a vulnerability in WordPress, other PHP or world-accessible code, a server misconfiguration, an "inside job", or what? I think it's important to have a bit more information about the nature of the attack, so that we know if independent WordPress installations are vulnerable and if/when we should reset keys and passwords.
These days it isn't just about making sure you have good passwords and a decent firewall.
If you run a site that has valuable information you will end up being a target. That's just a fact. How you respond to these types of security incidents is what will set you apart from the pack. Sadly most breaches are covered up. They are bad for PR and most people don't understand them.
Always make sure you have a plan in place. Even if it is just shutting down a list of servers incident response can go a long way.
TechCrunch indicates that hacker got access to source code of WordPress.com VIP sites and "only" Twitter and FB API keys are leaked.
Does anybody know how WordPress.com saves MySQL passwords? Does it differ from Wordpress installations? Vanilla Wordpress installations have them among the rest of the code and thus those might have leaked too.
I'm not sure I follow. If you have root access on a machine that runs PHP web apps that connect to a MySQL server, you have, at a minimum, access to the databases those web apps relied upon. The web app MySQL credentials have to be supplied somewhere in the code.
True. But the MySQL servers have layers of access control beyond passwords. The unauthorized access has been closed. So even if the attacker saved the passwords, they don't have the other factors for a MySQL connection.
If they have root access on the PHP servers they still access all the data in MySQL by writing code like this:
<?php
$pwnd = mysql_select_or_whatever_it_is('select * from sensitive_tables');
?>
Like most LAMP applications Wordpress uses only one connection with total access to all tables. It's the same unavoidable design issue that causes plugins and themes to be a security issue.
Possibly, the machines that got rooted were just the nodes running PHP code. Each 'site' may have database user/pass for their respective tables and not the DB root. However, if the servers that got rooted were the DBs then that would be very bad. You could dump, crack etc... There are other vectors to consider, such as 'workers/jobs' doing 'db cleanup' where they would need some 'dba' access.
You can set it up such that the PHP app uses up all the available connection to the database and you can't connect unless you stop the PHP app (which people may notice).
If you're thinking of limiting to the PHP worker process then all I have to do is wrap my SQL in PHP statements. I can still use SQL queries using the PHP worker which is a bit long winded but scriptable.
I can then use LOAD_FILE and SELECT INTO to read and write to files, but I won't be able to execute arbitrary code.
If the application user has access to mysql.user though I can then SELECT host, user, password FROM mysql.user; to get the credential details and password hashes, which can then be fed through a password cracker of my choice. Once I've done that I can reconfigure the worker to use the root mysql account, restart the PHP worker process and start sucking the database down or modifying it.
Of course, in theory you'd have some access to the database server beyond port 3306 such as SSH, in which case I'd look at grabbing mysql account info from /etc/passwd, then dropping ssh keys into that user's home directory so I can use key-based auth to get onto the box. This may or may not work (there's many variables) but I'm just writing that here to illustrate that breaking in as is with perl, there's more than one way to do it.
Considering few recent cases of this kind, what's the best way to store passwords/keys/other credentials? Can I avoid leaking sensitive information even if an attacker gains root access to my app machine?
For passwords, my method is individually salted and one way hash will eliminate most attempts, pretty much leaving brute forcing the most efficient way. However, it's known that people use common passwords like 'password1'. For more paranoid security, read documentation, discussions and even black discussions regarding the technology you use if you really want to lock down everything. Eventually it'll be a performance/usability vs security compromise in some cases.
I suggest a failure plan to prepare for security failures including several PR messages depending on severity of failure even if you do not know if you're compromised.
It's highly unlikely that you will be able to avoid potential leaks.
Hashed password are pretty obvious, but what if your app needs to talk with something that needs original password (database, external system of some sort)?
If you are using something like app -> db calls to be done automatically on a server, hashed passwords won't help since the script usually requires a stored non-hashed key unless it accepts hashed keys. Even then, if the password or hashed password is exposed, the hacker can still use it to access the database via your app.
Maybe you want decentralised permissions of multiple database users? They can't quite get or do most things.
Or centralised and/or put into a locked down file that can only be accessed by the OS user for parsing scripts eg www-data.
And low-level access (to me) means root access. The only lower level access I can think of would be if someone broke into the datacenter and stole the server ;)
The concept is synonymous with how close you can get to 'system' where there is no additional abstraction.
A dinky example say is for instance you may need a password for X, but if you have access to disable the need for the password in X, you have lower level access. In the case at hand, with root level access you can read all the keys, passwords, settings in all the WP config files, otherwise you wouldn't be able to. You could also quietly add an additional password to the database allowing a bad application to run behind the scenes doing bad things with the data.
This makes for a very good simple CS test question.
[1] - https://www.owasp.org/index.php/London#Next_Meeting.2FEvent