Drupal SA05 aka drupalgeddon

and other Drupal Security related topics

Michael Hess

Michael Hess

Current Drupal Security Team Lead.

Solutions architect lead at the University of Michigan.

Supports around 900 Drupal sites at the University.

Supports around 500 sites not related to the University.

Twitter: @mlh407

Agenda

Overview of Drupal security and the Drupal security team

Overview of SA05/Drupalgeddon

Overview of best practices

Do You Brush Your Teeth Daily?

Please text: 734-821-5212

We will discuss this later.

Security in Drupal

Drupal has a dedicated Security Team of 42 people around the world.

The Security Team is a volunteer group.

We:

• Resolve reported security issues in a Security Advisory
• Provide assistance for contributed module maintainers in resolving security issues
• Provide documentation on how to write secure code
• Provide documentation on securing your site
• Help the infrastructure team to keep the drupal.org infrastructure secure

Security Process

Subscribe to the Security Team newsletter via "my newsletter" under edit on www.drupal.org/user.

Common Web Vulnerabilities

From Open Web Application Security Project

Using Components with Known Vulnerabilities

Do you use third-party libraries?

Common Drupal Vulnerabilities from 2014

SA05/drupalgeddon

Was a site you work on compromised by SA05/drupalgeddon?

Please text: 734-821-5212

Was a site you work on compromised by SA05/drupalgeddon?

What is SQL Injection?

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.

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.

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) {
                           

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

Code Examples

From Acquia

                                update users set name='admin' , pass = '$S$CTo
                                    9G7Lx2rJENglhirA8oi7v9LtLYWFrGm.F.0Jurx3aJAmSJ53g' where uid = '1';
            

                                set @a=(SELECT MAX(uid) FROM users)+1;INSERT IN
                                    TO users set uid=@a,status=1,name='n0n0x' , pass = '$S$CTo9G7Lx2jmHrpHDdKDR0R8X/
                                    q4H9PXo02REYap3z2t8UE3F0DfC';INSERT INTO users_roles set uid=@a,rid=3;
            

                                update {users} set mail='[EMAIL_ADDRESS]' where uid=1;
            

                                INSERT INTO `menu_router` (`path`, `load_functions`, `to_arg_functions`, `description`, `access_callback`, `access_arguments`)
                                    VALUES ('mziogj', '', '', 'mziogj', 'file_put_contents',’[TROJAN]’);
            

Example:

Please be respectful and don't exploit this server while I am doing the demo.

I will leave the server up this weekend, for educational purposes. Do not engage in illegal activities.

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's.

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

Best Practices

Do You Brush Your Teeth Daily?

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.

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

Other Security Vulnerabilities

While XSS/CSRF/access bypass may be harder to mass attack, but an attacker can still compromise a site with them. The security team releases SA's on Wednesdays, set time aside to update your sites (or pay someoene to do it for you).

Details on these vulnerabilities are outside the scope of this talk.

Questions?

Thank you for your time!