Hacker News Reader

Comment by bhldr | Hacker News Reader

Say hypothetically if a got my Drupal site for cheap and now I'm hacked. I pay someone another $100 to install the patch and get rid of the malware, I still come out ahead.

What's my incentive to do things differently?

View on HN

> and get rid of the malware

This is the catch. Depending on what was done to your site, there's no "getting rid of the malware" for $100.

Those cheap hosting providers don't provide automated backups of your database. You probably have a backup of your site's files -- that's probably not perfectly current, but close enough maybe -- but I bet you haven't got regular backups of your database.

Drupal is one of those many CMSs that stores tons and tons of code in the database, including executable PHP. So how do you go about ensuring that all of that is clean, and changing all the passwords that may've been compromised, and making sure there are no other backdoors or shells left behind, for $100?

> Drupal is one of those many CMSs that stores tons and tons of code in the database, including executable PHP.

This is horrifying. Why was this ever done?

As with the majority of security issues it was done for convenience. Not every user has access to the hosting provider so it was done out of convenience.

Thankfully they removed this option in Drupal 8, the latest version. You could also restrict users from accessing the functionality so it wasn't that terrible. In practice few sites actually use the option, but when they do it can make troubleshooting a giant pain in the ass.

The fact that php.module ever existed in the codebase is a downright travesty. As soon as any privileged user was compromised (i.e. someone with "administer users" or "administer site configuration" permissions) the attacker had arbitrary remote code execution.

My projects had a patch to remove that entire module from core on each build.

One example I did many years ago: I want to make this download page vary what it serves by user agent, providing instructions for any things they’ll need to install first (because .NET stuff used to go in the user agent string), and providing the appropriate download link for their platform. Most of this could be done in JavaScript, but there was at least one part of the mix that couldn’t be, but could still be detected from the server.

Now which is easier—make a new module to serve this page or filter the output of that page, or just enable PHP code for this page, and write it directly in PHP on this page only?

I've never seen someone make an informed trade-off decision like that and acknowledge it.

Instead they just believe that they are 100% secure then when they get hacked they act all surprised and with great hypocrisy say "security is our number one priority at shitshow.com. we take security extremely seriously.".

Otherwise I'm not suggesting that there's some great incentive. As we've seen with huge hacks like Equifax and many more companies we know right now they just get a slap on the wrist and so they continue to try to use "we are sorry" PR statements after the fact as their strategy.

That's like asking, what's the worstcase of my email account being hacked?

There's a spread between your life is ruined and nothing happens at all and it entirely depends on what you've done with the account/site.

Defacement of your site, Google delistment for hosting malware, email blacklist for spam

I've seen plenty of sites survive these types of exploits just fine.

Still, I for one wouldn't want to be on a receiving end.

Reply on news.ycombinator.com