The Tale of the Red Ribbon Hacker

Our first tale is about a little online shoe store run by a kind woman named Myrtle.

From her little online store, she mails shoes around the world, and each shoe box comes tied up in a red ribbon like a box of candy.

Because Myrtle is no dummy, her website takes customers’ orders and then redirects them to a third party for payments. This keeps her site PCI-compliant. And gives Myrtle more time to tie red ribbons into bows — she has nothing to worry about!

Or does she?

Background

Myrtle’s Shoe Store website first launched on Nov. 15, 2012.

The site receives about 3,000 orders per month — that’s a lot of ribbons!

The dev shop that built the site did not provide support after the site went live. The shoe store also does not have a full-time web person on staff.

One Day …

The date was March 11th, 2013

Myrtle noticed that the shoe store was not receiving any money into its account. Yet, the order volume had not changed.

She called the credit card company. The company told her they had not seen any orders come through in the past 2 weeks.

That couldn’t be right.

She went online and placed an order. All seemed to work as it should.

Myrtle was so confused, Where was all the money?

The Next Day …

Myrtle got the help of a website security expert named Jordan Baker, a Drupal detective.

He found that the shoe store’s payment gateway URL configuration was not pointing to its payment gateway.

Author’s Note:

In a proper configuration, the customer goes to the checkout -> the customer is redirected to the payment gateway on the third-party site -> the customer pays -> and then the customer is redirected back to the merchant site.

What Happened Next…

Somehow the URL for the payment gateway had been changed in the Ubercart configuration.

Jordan lit a cigarette, narrowed his eyes, and began reviewing the server logs.

There was a POST request on the page to change this URL by someone at the company's IP address.

And the IP address belonged to Myrtle’s computer!

What Really Happened …

But something was still bothering Jordan. He dug some more and discovered:

Someone had used a security vulnerability in Ubercart and added Javascript into a field.

Normally the Javascript would be escaped, but since the site was not patched for SA-CONTRIB-2013-020 - Ubercart - Cross site scripting (XSS), the Javascript executed!

Poor Myrtle had been framed — by the code.

Jordan took out his notebook and noted down the Case of the Red Ribbon Hacker. Here is what he wrote.

Lessons Learned

Always update your site when the security team releases an update. (https://www.drupal.org/security)

If you are dealing with sensitive data (such as credit card numbers), make sure you have the staff to do so, otherwise think about outsourcing everything.

XSS can do a lot of damage.

Always check your input filters as well

XSS is the most common vulnerability in Drupal

The Tale of the Ghost in the Website

Our second tale is about Harpers' LLC, a small web development company in upstate New York based out of a stately old house.

Harpers had just started work on a new site two days before. The site was provisioned at a brand-new domain. It was in maintenance mode.

Despite all this, the site was hacked. But how?

Background

The site was set up with a newly ordered domain name.

The site’s modules and core install were all up to date.

The site was a simple brochure-type site with only one admin account.

The site was set up on a new development server, dedicated just to Harpers’ dev sites

How It Began…

On the third day of developing the site, Jeremy, the content manager, was going to set up the content types.

He stopped in horror. The site had porn all over the front page.

Jeremy was not happy.

What’s Going On?

Jeremy called Jean, in-house IT person, who began looking at logs to see how an up-to-date Drupal site got compromised.

On a gray and windy day at the old Harpers’ house, Jean pulled the access logs for the site.

But she found only known and trusted IP addresses had accessed the site.

Jean had no idea what had happened, so she restored a backup.

Two Days Later…

Jeremy checked the site again. More porn spam.

And he lost all his work.

Jean searched the logs again — and found only the same trusted IP’s.

Only computers inside of Harpers' office had accessed the site.

Jean ran a virus scan on the computers that had accessed the site.

The scan was clean.

Jean had no idea what was going on.

Was the site haunted?

Jean did not know

By default apache on most OS's will run as a single user

That user has access to READ all the files for all sites on the system

What Happened…

So, it wasn’t a ghost.

Someone had compromised another site on the server.

Using that site, they were able to read settings.php and connect to the new Drupal site's database.

They were able to inject spam by updating the table directly. The attacker searched the entire file system for settings.php and then ran commands to update the database on any site they found.

Lessons Learned

Do not allow a single apache instance to access multiple sites. Configure privilege separation.

Apache config is outside the scope of this presentation, but look into suphp, php-fpm and mod-itk.

Be careful of using shared hosting without proper configuration.

Don't bring a site back online after a compromise unless you understand how it was hacked, and how to prevent future compromises.

The Tale of the Poisoned update

Our third tale is short.

It begins with a website for the nonprofit Friends of the Library.

This nonprofit raised money to buy books for its local libraries.

One Day…

The site got compromised, and a PHP shell script was uploaded.

All modules were up to date.

There were no known vulnerabilities in any of the modules that would have allowed for a PHP shell to be uploaded.

What Was Found…

Jack Merridew, the head of their webteam was able to see the php script was used to copy down the users table.

While the script may have been able to download more parts of the database, the attacker left behind only a copy of the users table.

The PHP script that was uploaded allowed the attacker to have file system access — the attacker could download any file, including files from Drupal's private file system.

It also allowed the attacker to run and display the results of SQL queries.

The Poisoned Library

A library from a module update was removed from the module. However, Jack only downloaded the new module, and did not remove the old module before updating.

Lessons Learned

Remove the library/module/theme before updating. This ensures that all old files are removed.

Configure PHP so it will not execute code from directories it should not (sites/*/files).

Prevent the webserver from writing to directories that are not (sites/*/files).

The security_review module can help with this.

The Most Familiar Tale

Due to a recent major vulnerability in Drupal Core, SQL injection was possible.

SA05

There was a large number of sites compromised due to SA05. Rather then a story, we will discuss common patterns.

SQL Injection is Easy to Exploit

Most of the time SQL injection is easy to exploit.

Other vulnerabilities may require different actors to engage in actions timed correctly.

SQL injection can be exploited most of the time, by just an attacker, without an admin's interfactions.

So?

SQL injection lets an attacker have the same access to your database that Drupal has.

Allows an attacker to add a user and modify users' roles.

Allows an attacker to change passwords and email addresses.

Allows an attacker to update URL's to payment pages.

Allows an attacker to change content.

Anything that can be done via the web interface, an attacker can do.

Common Attack Patterns

Changing password or email address on uid=1.

Adding files to the file system via the menu_router table and file_put_contents.

Adding a user and giving that user admin access.

Installing a PHP backdoor by enabling the PHP module and creating a node with PHP in it.

Patching the vulnerability.

Many, many more...

Drupal's Database API

When used correctly, the database API prevents SQL injection.

In the case of SA05/drupalgeddon, the database API is where the vulnerability was.

Oh, the irony.

The Patch

                                
- foreach ($data as $i => $value) {
+ foreach (array_values($data) as $i => $value) {
                                
                           

Some Perspective

This was a major vulnerability, but let's keep in mind that the last major issue was over 7 years ago.

This code has been in Drupal since Drupal 7 Beta.

Nothing is 100% sure, and nothing ever will be. We mitigate risk by using best practices.

Best Practices

a quick overview

Do You Brush Your Teeth Daily?

What is the lowest version of Drupal 7 running on ANY of your sites ?

Please text: 734-821-5212

What is the lowest version of Drupal 7 running on ANY of your sites ?

Brushing your teeth is a best practice.

For security, you can't check a list and be done.

You must keep working at it. It is a process, not a one-time task.

Which is why I hope everyone brushes their teeth.

Follow the Drupal Security Team

• On Twitter (twitter.com/drupalsecurity)
• Via email (on your drupal.org user edit page under newsletters)
• Via Web (drupal.org/security and drupal.org/security/contrib)

If you find a security issue...

Or think you find a security issue, report it to the team (security@drupal.org)

Site builders and module authors

Writing secure code: https://www.drupal.org/writing-secure-code

How to secure your site: https://www.drupal.org/security/secure-configuration

Security Process

1. A vulnerability is discovered in code.
2. An issue is reported to the security team.
3. An issue is confirmed to be valid in a supported release eligible for an SA.
4. The security team and the maintainer of the code fix the issue.
5. A Security Advisory is written and the fix is published. Notifications about the issue go out via Twitter/RSS/email.

Common Web Vulnerabilities

From Open Web Application Security Project

1. Injection such as SQL, OS, and LDAP injection.
2. Broken Authentication and Session Management.
3. Cross-Site Scripting (XSS).
4. Insecure Direct Object References.
5. Security Misconfiguration.
6. Sensitive Data Exposure.
7. Missing Function Level Access Control (access bypass).
8. Cross-Site Request Forgery.
9. Using Components with Known Vulnerabilities.
10. Unvalidated Redirects and Forwards.

Common Drupal Vulnerabilities from 2014

1. 61 - Cross Site Scripting.
2. 42 - Access Bypass.
3. 13 - Information Disclosure.
4. 4 - Cross-Site Request Forgery.

Some Best Practices

Only use encrypted protocols.

https/ftps/ssh/etc.

Every change you make might impact the security of your site. Therefore, security needs to be in your workflow.

Use supported versions (Soon time to update Drupal 6)

Take and verify backups.

Keep Your Site Updated

Always make sure you update after a security release comes out.

Know Your Risk Level

Blog vs. complex site. Your blog is likely to be compromised to send spam or to act in part of a bot net.

Your complex site might be compromised for the data it has.

Security is a balance.

Is your site a target?

Regulations

PCI, HIPAA, SCADA, XYZ, PDQ

You might have legal requirements imposed by the data you keep.

Do not use insecure hosting

Use a dedicated Drupal hosting provider.

Shared hosting normally runs the webserver as the owner of the file system (cpanel).

Multiple sites on a server often use a common account for all sites. (www-data, nobody, etc)

Do Not Use Multisite

Unless you have a deep understanding of apache/nginx and file permissions, multisite is insecure.

Use a Module that Enhances Security in Your Site

Paranoia: Locks your site down.

Security Review: Runs a checklist of items and confirm your site adheres to them.

Permissions Lock: Finer-grained permissions over what users with 'administer permissions' can do.

Two-Factor Authentication: Something you know, and something you have.

Hacked! Tells if code has been changed.

Password Policy: Enforces strong passwords.