Panama Papers: Email Hackable via WordPress, Docs Hackable via Drupal
wordfence.com
wordfence.com
> MF are running the WP SMTP plugin which gives you the ability to send mail from your website via a mail server. This plugin stores email server address and login information in plain text in the WordPress database. The login information stored is a mail server SMTP login for sending email.
This appears to be that plugin's homepage:
https://wordpress.org/plugins/wp-smtp/
It hasn't been updated in a couple of years but it seems quite popular (60,000+ active installs)...but how it stores the email server credentials can't be best practice...right? Or is saving the server credentials as plaintext considered OK because the plugin assumes (or rather, hopes) that your WordPress install won't be compromised? I guess there's a certain logic to that, since wp-config.php itself is plaintext...but...losing WP probably shouldn't mean automatically losing everything peripherally connected to the site. At least in the HBGary hacking case, in which a front-end site had a SQL injection, the hackers had to use a bit of social engineering to get to the company's main server.
When you're the server, you can hash them, but when you're the client, you need to access the credentials in order to send them to the remote server, so you can't hash them. You could encrypt them, but you'd need the decryption key readable by WP anyway, so it'd just be security theater.
Transactional email services will usually give you a disposable API key that can only be used to send email. If the key is compromised, the worst that can happen is that your server will try to send spam and get blocked by the email service.
Many of the same services can also be configured to issue an HTTP request to a URL of your choice if an email bounces. You could write a WordPress plugin to handle that if you want. No need to keep POP/IMAP passwords in your database.
There is no need for your website to go anywhere near your regular, human-accessible POP/IMAP/SMTP mailbox.
https://developer.pidgin.im/wiki/PlainTextPasswords
The only way to secure this is at the email server itself, by limiting the permissions of those credentials; for example, the IMAP/POP server could have a filter to save the bounces to a specific folder, and then allow access to only that folder for those credentials.
Drupal was apparently where the CRM was handled, including the posting of documents and so forth. The use-case you mention seems to be something that should be handled by the Drupal site.
Though I guess this speculation is just moot. The severity of the Drupal flaw would seemingly allow access to whatever Drupal uses to talk to the email server. That the WordPress server used the same email server and had the same access is just coincidence, another example of careless IT by MF, not that MF was necessarily using WordPress as a client-serving site.
But this doesn't apply to server applications like SMTP. I guess with SGX + some trusted storage, you could work it to only release the password to a known-encrypted socket or something.
The issue here is that the login and password to send email is the same as the one to receive email. So, if someone gains access to WordPress and gets that, they can then hit the IMAP server and read all the email associated with that account.
The sending mail account for the server should have been separate form any used by any users. Realistically, it should have also had either a separate password for SMTP vs IMAP or, even better, used a mail spooler of some sort either self-hosted or third party to handle the actual mail sending. I use SendGrid for many of my Drupal installs, for instance.
A concrete example: the Drupal convention is to move as much behaviour as possible out of code and into configuration. This configuration is generally controlled by admin panels. Eg, if you have access to administer Views, you basically have access to export pretty much any content to anywhere in whatever format you want.
I think that's a pretty crappy design. If you believe that this sort of administration is useful, then you want to have user accounts with permission to do it. But then if you do that, any account with those permissions is an enormous vulnerability.
I get the benefit for some use cases. I just think that (like a lot of things in Drupal), it has pretty unpleasant implications for a lot of situations. Maybe not critical by itself... but it feels like at every layer of Drupal there's some shortsighted design decision that encourages insecurity.
Without more serious examples I can't really agree with your conclusion that it's full of design decisions encouraging insecurity. When it comes to serious security issues that have needed patching I'd say Drupal has a fairly decent track record. It certainly has better defaults and less serious security issues compared to WordPress. I admit that is not saying much but WP has been becoming more and more popular as a CMS and that is what Drupal often gets compared to.
Not everyone in the world knows much to change their password, especially if they're using a desktop client such as Outlook. It just connects.
So it is possible that everyone in the company was logging in with the same password as the exposed email.
There are also rumors that some some of the accounts were used for drug trafficking, so the FBI might be interested in it.
The best thing to do is probably not to run Wordpress at all and go with your in house solutions. It will most likely have more vulnerabilities but they is no unpatched version and finding these vulnerabilities would be a lot harder assuming that have the right people do the job (and I don't think money would be a problem here but judging how the operated their infrastructure, they did not have the right people).
At the best one it only took 3 separate SQL Injections which got their database dumped and two defacements to make them decide to go back to one of the big CMSes. If you go complete custom, you do it at the cost of repeating other people's mistakes.
The CEO of that company took it upon himself and put the custom dev budget, and then some, into an actual site security company.
They did nothing much but keep the cms and it's plugins updated and have the traffic filters coordinated with current best practices.
Of course they printed nice reports of all the updates that were installed and through that the threats prevented, in case the customer thinks that because the carpet is clean they can fire the cleaning lady.
Depending on the Project they absolutely will. Consider the economic context this is happening in.
There is a staggering number of companies that can harden and secure a WordPress or Drupal Installation. They have scalable workflows that allow them to keep the attack surfaces small, keep up to date with any security issues and even deploy countermeasures before any fix is released.
The market is just big enough for those services to exist. Now consider the same for a custom built Symfony or Laravel CMS.
You still have to trust Third-party code that has had security issues in the past, one just assumes that one crowd is more trustworthy than the others.(http://symfony.com/blog/category/security-advisories)
Besides that, the number of companies that are able to harden, maintain and host is much, much smaller, because their workflows can only scale so much.
So your gains are not really on the security side of things, rather on the implementation flexibility. Which CAN mean a much more Resource Intensive Project.
Drupal and WordPress both have their birthdefects which have ingrained so far into the community that you can't expect them to be ever worked out fully. This leads one to your conclusion that because they aren't doing some parts of their job particularly good, they shouldn't be considered.
Having worked on large WordPress, Drupal(just when Drupageddon happened) and Symfony Projects I can say that from the viewpoint of a customer, the CMS Win out simply because they make the chain of people working on the project more accountable, comparable and replacable. The risks of being technologiclly dependent on the few people that wrote your custom CMS just arent worth it for the customer. The Risk of Running the same Wordpress Code as millions of others sites is manageable in comparison. With Drupal you can go as far as just calling Acquia if all else fails, their customers were safe on Drupageddon since they could just Filter the malicious requests. You can't expect your Symfony Hoster to do something similar when their day comes.
> This leads one to your conclusion that because they aren't doing some parts of their job particularly good, they shouldn't be considered.
When it comes to content, your data layer is not just "some part". It is a fundamental component and critical aspect to get correct for sound, scalable content management. WP's database schema and abstraction layers fail miserably at anything beyond the context of a basic blog. I understand WP bills itself as a CMS, but its data handling and architecture says otherwise.
> The risks of being technologiclly dependent on the few people that wrote your custom CMS just arent worth it for the customer.
If your CMS is written in Django, RoR, Spring, etc, you aren't anymore dependent than when you are leveraging Wordpress. No WP installation is without heavy customizations to finagle it to become a poor man's CMS and some group will still have to manage/maintain the mountain of technical debt you've left behind by deploying WP in the first place. Furthermore, the landscape of quality software developers in WP land is bleak to say the least.
Have you looked at the Mossfon pages? They are barely more than sales pages, nothing outside of the scope of WP or Drupal. You can't expect everyone who wants a Website with Basic functionality to have dedicated ops Teams, that would make it unfeasible for the majority of companies to run their own websites.
For most businesses the page is not the business, even more so for a company like Mossack Fonseca.
I don't and the very first thing I mentioned is that content management is a very domain specific problem. In some cases, WP may fit the bill, in many cases it does not.
Yeah I know how much more secure that would be.. thanks for the chuckle.
Other than that, I don't disagree with your point. :)