
Panama Papers: Email Hackable via WordPress, Docs Hackable via Drupal - mmaunder
https://www.wordfence.com/blog/2016/04/panama-papers-wordpress-email-connection/
======
danso
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.

~~~
icebraining
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.

[https://developer.pidgin.im/wiki/PlainTextPasswords](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.

~~~
danso
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?

~~~
mediumdeviation
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

~~~
danso
Right, but...in this specific situation, their WordPress homepage doesn't
appear to be the client-serving portal...That's what Drupal is for:

[https://portal.mossfon.com/](https://portal.mossfon.com/)

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.

~~~
icebraining
The Wordpress blog editors would need to reset their own password
occasionally.

------
matthewowen
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
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
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
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.

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

------
zhte415
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.

------
peteretep
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_
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
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
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
>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.

~~~
mtbcoder
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.

~~~
Roritharr
>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.

~~~
mtbcoder
> 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.

