Just because WP and Drupal could be breached doesn't necessarily mean that all those emails that were leaked would be similarly accessible, right? So the main vulnerability is in this specific plugin?
> 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.
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.
If you're the client, you need to store the password in a way such that you can send it to the SMTP server. Storing it in any other way than plain text is just security theater, because if WP can read it to send the emails, so can the attacker who takes over WP.
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.
Ah that's the obvious detail I was looking for. I guess my other question would be...is there any reason why a front-end site like WordPress has to have mailing functionality built-in? I mean I know WP is more than just a blogging platform...but...I'm trying to think of a situation in which a company has so many clients and client interactions that it's just convenient to bake email functionality into the homepage/news site...but that it's apparently not worth the effort to invest in a proper CRM? I know they're a law firm and not a tech company and CMS architecture is not their specialty, but they're not also running a site to manage the church bake sale. What kind of IT people could such a wealthy firm hire that wouldn't have enough experience to worry about this kind of thing?
A CMS would need to send email so that it can reset passwords, just as an example. Again, as the parent has said, the failing here is not that the CMS is provided with email credentials - that's very common for all but the simplest CMS, but that it didn't separate and limit the accounts properly
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.
libpurple2, surprisingly, gets that incorrect. The correct thing to do is use the OS-provided mechanisms. On Windows, that's CryptProtectData. That way the data, at rest, is inaccessible to anyone without the user's password.
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.
Well, the blog post presupposes you can get remote code execution on the WordPress server. There's very little you can do to secure yourself if the opponent already has RCE, because at that point the attacker has at least as much privilege as the application itself. In that case you have to fall back on limiting the amount of damage that can be done by respecting the principle of least privilege.
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.
As others have mentioned, if you need to login to the SMTP server to send, WordPress needs to have access to that login and password to be able to send email. And CMS need to send email to send out password resets, notifications of software needing manual updates, content update notifications, etc.
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.
Exactly, the correct solution is to utilize a transactional mail system for in-application sending that's not tied to your physical mail servers used for personal/business email. Amazon SES, MailGun, SendGrid, etc are all excellent tools to use if you do not wish to run/maintain your own system.
I really have to question why anyone uses Drupal, especially if security is even a slight concern. There are just so many ways in which it is insecure by default (eg CHANGELOG.TXT), and the rate at which serious security vulnerabilities appear (and the nature of those vulnerabilities) seems like a huge red flag.
I agree it would be good to make the changelog unreadable but what are the numerous other ways it's insecure by default? As for the rate at which vulnerablities appear, Drupalgeddon was a very rare case. I haven't noticed Drupal having security issues noticeably more often compared to other software, what are you basing that claim on?
Insecure by default might be slightly unfair... but insecure by design might be more accurate.
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.
Thanks for giving an example. I'd say that you can definitely take advantage of the functionality provided by views without having accounts that are able create and modify them on your production site. In fact it's accepted as the right way to do things.
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.
I completely agree but some people don't want to admit what a huge failure Drupal is after they've spent years of their lives working on it, with it, promoting to clients and defending it.
Running your own Wordpress install is a massive corporate anti-pattern. If you're broke, stick it up on Bluehost and back it up well for when you get compromised. If you're not broke, WPEngine or similar.
I don't think you would run such a site on a shared or managed hosting, unless they're also placed in Panama and there is no other jurisdictions that could require them to hand over to any government. Granted, off-shoring is not something which is illegal in most countries but a judge could still order them to hand over their data to investigate of their hosting company were placed in any other country.
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.
Content management is very much a domain specific problem which generic CMSs like Wordpress and Drupal solve poorly. For example, have a look under the hood at Wordpress's database schema and you will find that it is ill-equipped for anything more than basic blogging (which is its main intention in the first place). Building a custom CMS that meets a company's business requirements does not mean writing everything from scratch. High quality frameworks exist in just about any language you can imagine which provide abstractions for handling user authentication, prepared statements, XSS mitigation, session handling and a whole host of other items. As with any software development, the quality of your software is tied directly to the quality of your developers. The "big CMSs" will not stop a poor development team from making bad decisions.
>The "big CMSs" will not stop a poor development team from making bad decisions.
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.
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.
If you are in the business of content and your mission objective is entirely driven around delivering content to your users, you will have a dedicated development and operations team. Your users are the customers and they demand content delivered to them in any number of ways and means. WP's shortcomings increase exponentially when you operate at scale.
> 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.
>If you are in the business of content and your mission objective is entirely driven around delivering content to your users, you will have a dedicated development and operations team. Your users are the customers and they demand content delivered to them in any number of ways and means. WP's shortcomings increase exponentially when you operate at scale.
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.
> 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.
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.
> 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.