Drupal SA05 aka drupalgeddon

and other Drupal Security related topics

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

Answer Choice	Text Code:
Yes	4483
No	2983
I don't have any.	6276

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

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

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

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

Using Components with Known Vulnerabilities

Do you use third-party libraries?

Common Drupal Vulnerabilities from 2014

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

SA05/drupalgeddon

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

Please text: 734-821-5212

Answer Choice	Text Code:
Yes	9361
No	8617
Unsure	5821

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

What is SQL Injection?

A SQL injection attack consists of insertion or "injection" of a SQL query via the input data from the client to the application. A successful SQL injection exploit can read sensitive data from the database, modify database data (Insert/Update/Delete), execute administration operations on the database (such as shutdown the DBMS), recover the content of a given file present on the DBMS file system and in some cases issue commands to the operating system. SQL injection attacks are a type of injection attack, in which SQL commands are injected into data-plane input in order to effect the execution of predefined SQL commands.

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!