Slide 1

Slide 1 text

Database Passwords Everywhere! Feross Aboukhadijeh feross.org

Slide 2

Slide 2 text

CMSploit Definition: Security scanner that tests websites built with content management systems for temporary files that contain sensitive information.

Slide 3

Slide 3 text

No content

Slide 4

Slide 4 text

0 1,250,000 2,500,000 3,750,000 5,000,000 18,819 334,408 1,656,021 4,485,142 Number of sites Data from BuiltWith (http://trends.builtwith.com/cms/)

Slide 5

Slide 5 text

Vulnerable sites

Slide 6

Slide 6 text

perezhilton.com

Slide 7

Slide 7 text

indianapublicmedia.org

Slide 8

Slide 8 text

lsc.org

Slide 9

Slide 9 text

su.pr

Slide 10

Slide 10 text

marginalrevolution.com

Slide 11

Slide 11 text

futuremark.com

Slide 12

Slide 12 text

openculture.com

Slide 13

Slide 13 text

scobleizer.com

Slide 14

Slide 14 text

rovio.com

Slide 15

Slide 15 text

How CMSploit works

Slide 16

Slide 16 text

1. Config files 2. Text editors

Slide 17

Slide 17 text

1. Config files 2. Text editors

Slide 18

Slide 18 text

Typical config file

Slide 19

Slide 19 text

Typical config filenames • wp-config.php // Wordpress • config.php // phpBB, ExpressionEngine • configuration.php // Joomla • LocalSettings.php // MediaWiki • mt-config.cgi // Movable Type • settings.php // Drupal

Slide 20

Slide 20 text

Big mistake • Config files sit in a publicly accessible folder • Easier to set up this way, but less secure • All sensitive info is between tags • Demo: http://feross.net/wordpress/wp-config.php

Slide 21

Slide 21 text

1. Config files 2. Text editors

Slide 22

Slide 22 text

1. Config files 2. Text editors

Slide 23

Slide 23 text

Recipe for disaster + Text Editor Config files

Slide 24

Slide 24 text

Temporary Files • For a file wp-config.php, text editors will create: • Backup files • wp-config.php~ // Vim, Gedit • #wp-config.php# // Emacs • wp-config.php.save // Nano • Swap files • wp-config.php.swp // Vim • wp-config.php.swo // Vim

Slide 25

Slide 25 text

1. Config files 2. Text editors

Slide 26

Slide 26 text

What’s wrong here? • There may be temporary files which contain sensitive info floating around in publicly-accessible folders. • If temp file gets requested, most servers will return the plaintext, skipping the PHP pre-processor. • .php Content-Type: text/html; charset=UTF-8 • .php~ Content-Type: text/plain • etc... Content-Type: text/plain

Slide 27

Slide 27 text

Temporary Files • For a file wp-config.php, text editors will create: • Backup files • wp-config.php~ // Vim, Gedit • #wp-config.php# // Emacs • wp-config.php.save // Nano • Swap files • wp-config.php.swp // Vim • wp-config.php.swo // Vim

Slide 28

Slide 28 text

How prevalent is this problem?

Slide 29

Slide 29 text

What I did • Wrote program to test top 1 million websites • It issues GET requests to a site to test for the presence of temporary backup files with common CMS config filenames

Slide 30

Slide 30 text

Results: • Tested the 216,391 most popular websites (according to Quantcast). • Found 230 config files visible in root of site. • Thus, 230 / 216391 = 0.11% of all websites are vulnerable. • Latest stats say that about 13.8% of the top 10,000 websites run CMSs. If we just focus on CMS-powered websites (and extrapolate), then the percentage of vulnerable sites is: • Thus, 230 / (216391 * 0.138) = 0.77% of websites running a CMS are vulnerable.

Slide 31

Slide 31 text

230 config files total • E-commerce (cc #s) • Churchs • Fire department in a really large U.S. city • Porn sites • Lots of WordPress blogs...

Slide 32

Slide 32 text

What would you do?

Slide 33

Slide 33 text

No content

Slide 34

Slide 34 text

What I did • Didn’t try logging in with any of the passwords. • Responsible disclosure to top sites. • Submitted a vulnerability report with US- CERT. (They ignored it)

Slide 35

Slide 35 text

Email to top sites To whom it may concern: I believe that I have discovered a security issue with the ________.com website. If you'd like to know more, I can disclose the full details of the issue to an engineer or software developer on your website team so the issue can be fixed. Respectfully, Feross Aboukhadijeh Stanford University, Computer Security Lab

Slide 36

Slide 36 text

.htaccess rule Order allow,deny Deny from all

Slide 37

Slide 37 text

Complaints From: ****@us.pgds.com To: abuse@stanford.edu To whom it may concern, Our organization has detected suspicious traffic originating from boxxy.stanford.edu (128.12.188.246) against the web site of one of our affiliated companies. The request URL for some of that traffic was to /wp-config.php~ The traffic occurred at 5 Oct 2011 11:48:26 GMT and 5 Oct 2011 12:22:50 GMT. We would appreciate it if you would investigate and resolve this matter. Thank you, ******** ******* Senior IT Security Administrator Prudential Global Data Services (PGDS-US)

Slide 38

Slide 38 text

From: Information Security To: feross@stanford.edu We're forwarding a complaint about a machine registered to or administered by you. Unless you're aware of this, it indicates the machine has been broken into or otherwise compromised. When a system has been compromised at the system privilege level, rebuilding the system, applying current patches, and setting good passwords on all accounts, is the recommended way to repair the machine.

Slide 39

Slide 39 text

from: security@stanford.edu to: nettrouble@rescomp.stanford.edu, security-nr@stanford.edu, feross@stanford.edu cc: mirrielees-rcc@rescomp.stanford.edu Hi there, I first alerted you to miscreant behavior coming out of boxxy on 10/6. Please let me know that you have either remedied the problem or disconnected the machine today. If we continue to get abuse complaints, I will have the machine disabled. I've copied your RCC in case you need help cleaning the machine. Thanks,

Slide 40

Slide 40 text

from: security@stanford.edu to: nettrouble@rescomp.stanford.edu, security-nr@stanford.edu, feross@stanford.edu cc: mirrielees-rcc@rescomp.stanford.edu Dear res-net folk, We are continuing to receive complaints against boxxy. Please disable the machine until it can be cleaned. Thanks,

Slide 41

Slide 41 text

from: ***@stanford.edu to: security@stanford.edu cc: nettrouble@rescomp.stanford.edu, security- nr@stanford.edu, feross@stanford.edu, mirrielees- rcc@rescomp.stanford.edu All: Changed Netdb record to 'vile' state for host 128.12.188.246.

Slide 42

Slide 42 text

Lesson learned • When scanning / attacking 200,000 websites, don’t do it from your own IP address • Use Tor (https://www.torproject.org/) • Or a VPN / server in another country

Slide 43

Slide 43 text

Passwords • Tons of people used “wordpress” or the name of their site as DB name, username, AND password. • Lots of 1337speak p@ssw0rds

Slide 44

Slide 44 text

Worst offenders “dbdbdb” for an online magazine “patrick” for an online newspaper “Summ3r” for a summer camp program “FuckYou4231” for a horror movie site “c0d3b3tt3r” for a site about coding better “usernamehere” “yourpasswordhere” “abc123456” “root” “root” <-- probably disallow remote DB connections

Slide 45

Slide 45 text

Final thought • Lots of sites put their CMS in a subfolder/ subdomain • /blog/, /wiki/, /forums/ • blog.mydomain.com

Slide 46

Slide 46 text

Other resources • Original blog post (feross.org/cmsploit) • Reddit discussion (goo.gl/3kAI2) • DEFCON: Pillaging distributed version control system repos for fun and profit (goo.gl/IevyF) • Attack against wp-config.php~ (goo.gl/i381Q) • WordPress security thoughts (goo.gl/0K8Bg)

Slide 47

Slide 47 text

Thanks! Feross Aboukhadijeh feross.org