6 ms·

Panama Papers: Email Hackable via WordPress, Docs Hackable via Drupal

126 points by mmaunder 11y ago

peteretep 11y ago
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.
- Matt3o12_ 11y ago
  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).
  - Roritharr 11y ago
    I have been to places where that road was taken. 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.
    - mtbcoder 11y ago
      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.
      - Roritharr 11y ago
        >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. 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 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.
  - deleted 11y ago
    [deleted]
  - zodiakzz 11y ago
    > go with your in house solutions Yeah I know how much more secure that would be.. thanks for the chuckle.
- jonpaine 11y ago
  WPEngine, who were just recently compromised and only finally announced 2FA less than two weeks ago... Other than that, I don't disagree with your point. :)
  - peteretep 11y ago
    But who gives a shit? You're not providing an entry in to your own networks if they get compromised, and they'll clean up the mess.
kevin_thibedeau 11y ago
I guess there's some good to come out of web 2.0.
danso 11y ago
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. This appears to be that plugin's homepage: https://wordpress.org/plugins/wp-smtp/ 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.
- TheOtherHobbes 11y ago
  If I was running an infosec corp I would be cold calling every lawyer on the planet around about now to sell them an audit and security update.
  - Cshelton 11y ago
    Just the fact that the credentials are sitting there in plain text would fail audits...
    - eeeeeeeeeeeee 11y ago
      Gimme a break. At some point the credentials need to be exposed to the client.
    - icebraining 11y ago
      Serious question: how would you store them? 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. See https://developer.pidgin.im/wiki/PlainTextPasswords https://developer.pidgin.im/wiki/PlainTextPasswords
matthewowen 11y ago
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.
- ajsalminen 11y ago
  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?
  - matthewowen 11y ago
    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.
    - ajsalminen 11y ago
      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.
zhte415 11y ago
Something perhaps relevant, small companies tend to have a small admin function, who use the same password for everything. 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.

126 points by mmaunder 11y ago

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.

Matt3o12_ 11y ago
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).
- Roritharr 11y ago
  I have been to places where that road was taken. 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.
  - mtbcoder 11y ago
    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.
    - Roritharr 11y ago
      >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. 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 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.
- deleted 11y ago
  [deleted]
- zodiakzz 11y ago
  > go with your in house solutions Yeah I know how much more secure that would be.. thanks for the chuckle.
jonpaine 11y ago
WPEngine, who were just recently compromised and only finally announced 2FA less than two weeks ago... Other than that, I don't disagree with your point. :)
- peteretep 11y ago
  But who gives a shit? You're not providing an entry in to your own networks if they get compromised, and they'll clean up the mess.

kevin_thibedeau 11y ago

I guess there's some good to come out of web 2.0.

danso 11y ago

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. This appears to be that plugin's homepage: https://wordpress.org/plugins/wp-smtp/ 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.

TheOtherHobbes 11y ago
If I was running an infosec corp I would be cold calling every lawyer on the planet around about now to sell them an audit and security update.
- Cshelton 11y ago
  Just the fact that the credentials are sitting there in plain text would fail audits...
  - eeeeeeeeeeeee 11y ago
    Gimme a break. At some point the credentials need to be exposed to the client.
  - icebraining 11y ago
    Serious question: how would you store them? 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. See https://developer.pidgin.im/wiki/PlainTextPasswords https://developer.pidgin.im/wiki/PlainTextPasswords

matthewowen 11y ago

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.

ajsalminen 11y ago
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?
- matthewowen 11y ago
  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.
  - ajsalminen 11y ago
    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.

zhte415 11y ago

Something perhaps relevant, small companies tend to have a small admin function, who use the same password for everything. 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.