Death By 1000 Cuts Case Study
This is a story of a penetration test I did against medium sized enterprise. Using only web based vulnerabilities I was able to compromise a company's security. The names have been changed and some of the events are slightly ficticious as I was not authorized to actually penetrate the company. I am writing this to prove that with a number of seemingly minor issues a company can be completely compromised. I was not authorized to DoS, and I was not authorized to attack the network or the underlying server/OS since it was hosted by Rackspace.
My task was to find as many significant issues with the corporate website (anything at that domain name) as possible in a realistic amount of time that an attacker would spend attacking the system. The company had many other websites, but this one in particular was the most critical to them and thus I was contracted to provide an external blackbox security assessment of the application.
This case study shows how 10 mostly innocuous security issues were used together to leverage a major attack against a company.
The Security Issues
First thing was first, I needed to see what was actually on that domain. I began by performing a number of web-queries to determine what servers were availible. The most interesting search I performed was actually using Alexa. This yielded the first issue: #1 - webmail is easily located.
company.com - 91% webmail.company.com - 9%
The reason webmail showed up, I later found out, was because the company had a number of professional SEO people on contract, who used webmail (Outlook Web Access). They had the Alexa toolbar installed (which is essentially spyware) and ultimately allowed disclosure of that URL to the world. Since that time I wrote a tool called Fierce that would have yielded the same results, but with far less luck. Here's the results from a Fierce scan:
Trying zone transfer first... Fail: Response code from server: NOTAUTH Okay, trying the good old fashioned way... brute force: DNS Servers for company.com: ns.rackspace.com ns2.rackspace.com Checking for wildcard DNS... Nope. Good. Now performing 359 test(s)... 18.104.22.168 www.company.com 22.214.171.124 ftp.company.com 126.96.36.199 support.company.com 188.8.131.52 webmail.company.com 184.108.40.206 mail.company.com 220.127.116.11 smtp.company.com 18.104.22.168 pop.company.com 22.214.171.124 pop3.company.com 126.96.36.199 blog.company.com 188.8.131.52 vpn.company.com Subnets found (may want to probe here using nmap or unicornscan): 184.108.40.206-255 : 6 hostnames found. 220.127.116.11-255 : 4 hostnames found. Done with Fierce scan: http://ha.ckers.org/fierce/ Found 10 entries across 10 hostnames. Have a nice day.
Sure, it seems like a small issue, most companies have webmail servers, but should they be known to the rest of the world? Theoretically a brute force attack could have yielded some results, but that's noisy. But just on the safe side, I decided to see if I could uncover some email addresses. This leads me to the second minor issue: #2 - easily discoverable and plentiful email addesses.
After a handful of web-searches and playing around with some social networking sites I was able to uncover several dozen email addresses of company employees. But brute force is so blase. I decided to leave that one alone for the moment - especially because one of my mandates during the penetration test was to avoid any potential of denial of service.
At this point it was time to start attacking the application directly, looking for holes. I created an account and then looked at the forgot password policy. This leads me to the next minor issue: #3 - forgotten passwords are sent in plain text.
I think everyone would agree that sending your password in plaintext format is bad, but most people don't really understand why it's bad. It's not just dangerous because the an attacker could sniff the password, but it's also bad because the password is stored in plaintext (or otherwise recoverable). If the server were ever compromised the entire list of usernames and passwords would have been compromised. There are other issues as well, but I'll get to that later.
Upon inspecting the functionality of the site it becomes clear that a user can modify their email addresses to anything they want with no verification that they are in fact the owner of the account. That may not seem that bad, but it can be, not to mention it could allow for spamming. That brings us to our next seemingly minor issue: #4 - system will allow users to change email address to any email address they want (with no verification).
Next I began looking at the application for cross site scripting (XSS) vulnerabilities. I did end up finding a number of XSS vulnerabilities in the application. Some might not consider this a minor issue, but in the relative scheme of things, the XSS vulnerability is not a method to compromise a server by itself. So for the time being let's list it also as a minor issue: #5 - XSS vulnerabilities in the application.
I realized at some point that the application uses email addresses as usernames. Many websites do this for ease (users remember their usernames easier, and there is no chance of overlap/conflict). Still, it's a way to trace users back to their email accounts, and as email addresses are often used as a factor of authentication I still list this as a minor issue and later on this will become very useful: #6 - usernames are email addresses.
Part of the function of the site is a recommendation engine to allow other people to see the same page you are seeing in case they are interested in it. Unfortunately the recommendation engine allows you to customize the content of the email you send, making it a perfect spam gateway. That's a minor issue but could get the whole site put on anti-spam lists if a spammer ever found it: #7 - recommendation engine sends custom emails.
A common function of many websites is to require authentication and then redirect the user to whatever page they originally intended to go to upon authentication. Although it's a minor issue the user is not necessisarily aware of the page they are going to. It's a very minor issue but can be used to the attacker's advantage as I'll show later: #8 - login redirects.
After some work I found a function that allows users to see if other users are valid. In this case it's the change email address function. The site is smart enough to know that two people cannot have the same email address and will warn you that the address is taken if there is a valid user on the system with that email address. These functions are common on websites, and most people don't see them as issues, but they do allow for information disclosure. However, it's a minor issue most of the time: #9 - function to detect valid users.
The last minor issue I found was that the change email function was vulnerable to cross site request forgery (CSRF). An attacker can force a logged in user to change their email address. Although this is an issue, typically sites are full of CSRF issues, and are often overlooked. This, however, was the final tool in my arsenal by which to initiate the attack: #10 - change email function is vulnerable to CSRF.
Now, let's combine the issues and initiate an attack. First, I take my list of corporate email addresses (#2) and check to see which ones are also user accounts (#6) using the function to detect valid users (#9). This shows us which users have corporate email accounts as well as legitimate user accounts on the site in question.
Now I change my email address to one of the email addresses of a corporate user (#4) that's NOT a user on the system. I found these users at the same time as I found valid users using the change email function (#9). It is still an email address of an employee of the company (#2) though. Then I send an email to one of the valid users on the system (#2) using the recommendation engine (#7). The email looks like it's coming from one of their co-workers (since I changed my email address to one of the corporate email address) and contains a link, asking them to see if they like the recommendation or not.
The link is a link to the login function (#8) that redirects the user to an XSS hole (#5). Now the user has logged in and their browser is under our control. While showing the user some page that they are probably not interested in, I forward the user invisibly to the change email function and force them to change their email address through CSRF (#10) to another email address that I've got control over. Then I have their browser submit the forgot password function (#3) which delivers their password to my inbox.
Now I know their email address since I know which email addresses I sent the original message to (a one to one mapping of email addresses I've got control over to email addresses I want to compromise helps with this) and I know their password (#3). Since most users tend to use the same password in multiple places there is a high probability of the user having the same corporate email password as corporate website password. I quickly log in, and change their email address back to their own account, to cover my tracks. Then I log into the webmail server (#1) with their username and password. I have now completely compromised a legitimate user's corporate email.
Often minor issues are overlooked but even in some cases the smallest issues can mount into huge compromises in security. Of course I could have used the XSS to scan the corporate intranet, and compromise internal machines, but I wanted to prove that through only minor issues alone (no direct exploits against any servers) I was able to steal corporate email - send email on the user's behalf from their account and uncover other users of the system. Not to mention enabling corporate espionage, usernames and passwords sent over email and access to the helpdesk who can give me further access through social engineering.
Even minor issues that are regularly dismissed in security assessments can be leveraged by a determined attacker to compromise a corporation.