The document discusses the Drupageddon security vulnerability that affected Drupal 7 sites in 2014. It describes how the vulnerability worked by allowing arbitrary PHP code execution through POST parameters. It then provides best practices for Drupal site security, such as keeping core and modules updated, using secure hosting platforms, writing secure code, properly configuring permissions and authentication, using tested versions, and reviewing custom code for security issues. The presentation aims to help users learn from Drupageddon and better prepare their sites for future vulnerabilities.

1. © Ibuildings 2014/2015 - All rights reserved
#DrupalDaysEU
Drupal Security: How to survive Drupalgeddon and
prepare for future

2. #DrupalDaysEU
© Ibuildings 2014/2015 - All rights reserved
Gold Sponsors

3. #DrupalDaysEU
© Ibuildings 2014/2015 - All rights reserved
Media Sponsors
Silver Sponsors

4. DRUPAL SECURITY
HOW TO SURVIVE DRUPAGEDDON AND
PREPARE FOR FUTURE
Created by Kristian Polso / @kristian_polso

5. ABOUT ME
Kristian Polso
CTO at Vaiste Productions
Been working with Drupal since version 5
Earlier PHP background
@kristian_polso

6. ABOUT VAISTE PRODUCTIONS
Drupal solutions company
Based in Turku, Finland
Focus on more customized Drupal
solutions & integrations
http://vaiste.com / @vaisteprod

7. PURPOSE OF THIS PRESENTATION
What was Drupageddon and what happened
How to prepare for similar vulnerabilities
Best practices

8. WHAT WAS DRUPAGEDDON?
A vulnerability found in Drupal 7's database abstraction API
Drupal Security Team was informed of it in September 2014
Update released on October 15 2014 (Drupal 7.32)
Biggest vulnerability in Drupal's history
Name given by twitter (#drupageddon)

9. HOW DID DRUPAGEDDON WORK?
// includes/database/database.inc
foreach (array_filter($args, 'is_array') as $key => $data) {
foreach ($data as $i => $value) {
$args are GET parameters from the user
$i are supposed to be keys, as in integers
SUPPOSED to be...

10. <input type="text" name="email[email1]" value="email1@address.com">
<input type="text" name="email[email2]" value="email2@address.com">
$_POST = array(
'email' => array(
'email1' => 'email1@address.com',
'email2' => 'email2@address.com',
)
);

11. <input type="text" name="email[email1]" value="email1@address.com">
<input type="text" name="email[0;UPDATE node SET title='uh­oh'; ­­]" value="email2@address.com">

13. ANY ANONYMOUS USER CAN GET ACCESS TO YOUR SITE'S
DATABASE

14. GO UPDATE YOUR DRUPAL SITE
NOW
SERIOUSLY, NOW

16. THE AFTERMATH
BBC: "Up to 12 million websites may have been
compromised"
Some hosting partners were really quick to patch
Drupal Security Team was super useful

17. CRAWLING THE TOP 15,000 DRUPAL
WEBSITES
goo.gl/NPr20o (polso.info)
Done in November 2014

18. IF YOU GOT HACKED
Recover from backups
drupal.org/project/drupalgeddon

19. HOW TO BE SAFE FROM SECURITY
VULNERABILITIES
Keep Drupal core & modules updated
Use managed hosting platforms (Acquia, Platform.sh,
Pantheon)
Writing secure code (drupal.org/writing-secure-code)

20. BEST PRACTICES

21. PERMISSIONS
Are all roles necessary?
Auto-grants
Review manually

22. XSS
Text formats
Adding nodes (titles, body)

23. AUTHENTICATION
Weak passwords
Autologout (d.o/project/autologout)
SSL

24. COMMON SECURITY
MISCONFIGURATIONS
Admin password? "admin"
Never use PHP input
Avoid FTP, use SFTP/SCP

25. VERSIONING
Try not to use dev versions in production
Thoroughly test

26. CUSTOM CODE

27. OPEN SOURCE IS AWESOME
Modules can have hundreds users
Easy issue tracking

28. COMMON PITFALLS IN CUSTOM
CODE
Not properly checking permissions
You don't notice your own mistakes

29. CONCLUSION
Update your modules
Try not to use dev versions in production
Review your custom code

30. THANK YOU
Kristian Polso
@kristian_polso