Comment by danso | Hacker News Reader

Comment by danso | Hacker News Reader

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/

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.

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.

Ideally you could have a send only password. I know gmail has app specific passwords but unfortunately they don't seem to have specific permissions

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

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/

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.

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

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.

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.

Just the fact that the credentials are sitting there in plain text would fail audits...

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

Serious answer: you don't store them at all.

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.

An API key is a password. That said, I fully agree that you shouldn't use your main password, but of an account with reduced permissions.

Gimme a break. At some point the credentials need to be exposed to the client.

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.

Reply on news.ycombinator.com