08 Jun 2012
This Linkedin security breach has put me in a foul mood. I can't decide if these developers were lazy or stupid. Right now, I'm inclined to believe they are both. The dangers of unsalted password hashes have been known for many years. A quick Google search will show you this article from 2004 that explains why salting is important and even gives you code to do the salting. There is absolutely no excuse for any web developer anywhere in the world to store plaintext, or unsalted password hashes, period.
The best part of this breach is LinkedIn's own blog. My favorite quote:
It is worth noting that the affected members who update their passwords and members whose passwords have not been compromised benefit from the enhanced security we just recently put in place, which includes hashing and salting of our current password databases.
It's not enhanced security. It is the most basic thing you can do to protect your customer's data. It costs next to nothing to add salted password hashes to a database. If LinkedIn can't be trusted to protect your data at such a low cost, what can they be trusted with?
I also love this line:
To the best of our knowledge, no email logins associated with the passwords have been published...
Don't get too excited about the email addresses not being published and lose sight of the fact that they were stolen in the first place.
Here is another gem:
...nor have we received any verified reports of unauthorized access to any member’s account as a result of this event.
Just thinking out loud here, but if someone broke into LinkedIn's database months ago and stole the passwords and LinkedIn didn't know about it until the passwords were published, do you think LinkedIn is qualified to determine if any unauthorized access has taken place? Let that sink in for a minute.
I don't usually rant like this but I'm so tired of seeing stupid security mistakes. Everyone worries about advanced persistent threats (APT), which account for maybe 1 in 100 data breaches. The other 99 data breaches occur because people aren't doing Information Security 101.
28 May 2012
When people demonstrate penetration testing they always show the easy exploits like MS08-067 or the Apache Tomcat WAR upload, both of which are in Metasploit. While I still see these exploits available in the networks I pentest, most of the time exploitation is a lot more difficult than simply "popping a shell." One of my recent pentests shows this clearly.
Unauthenticated NFS Access
First, I scanned the network with Nessus and did not find any easily exploited vulnerabilities but I did find a medium-risk vulnerability showing unauthenticated access to multiple NFS shares (Nessus ID 42256). Browsing the shares I found a backup copy of the client's public web site, which was developed using Visual Studio. Visual Studio stores database connection strings, including plaintext passwords, in .config files. Using the command grep -r connectionStrings= * at the root of the source directory, I found multiple connection strings that used three different database passwords.
Windows SMB Null Sessions
The Nessus scan also identified two machines that allowed unauthenticated user enumeration using the host security identifier (SID) (Nessus ID 56211). Using this medium-risk vulnerability, I determined the local administrator account had been renamed.
Password Reuse
Next, I used Metasploit's smb_login auxiliary module, use auxiliary/scanner/smb/smb_login, along with the local administrator account and the three passwords identified in the web application source code to identify any instances of password reuse. Luckily, there were two machines that allowed local administrator access with one of the passwords I found.
Complete Trust in AV
Next, I used Metasploit's psexec exploit module, use exploit/windows/smb/psexec, along with the local administrator username and password to attempt to get meterpreter access to the box. When I tried to run the exploit, I lost the network connection to the box. After a few minutes, the network connection was restored and I was able to try to exploit the box again. I determined the client's AV was flagging my attack and temporarily blocking my network connection.
For my second exploit attempt, I created a custom executable using msfvenom, this was also caught by the client's AV. Since I was unable to bypass the AV with msfvenom, I resorted to using a custom Python shell that I keep for such occasions. I modified the script to fit my situation and used PyInstaller to compile the script to an executable. Then I used the EXE::Custom option with the psexec module to run my executable on the machine. First, I had to setup a netcat listener to catch my reverse shell, nc -l -p 4445. My custom executable ran successfully and I had shell access to the box, but I wanted meterpreter access. So, I disabled the AV on the system and ran the psexec module again with the default meterpreter payload.
Lessons Learned
For Pentesters
- Rooting a box often requires more than running a Metasploit/Core Impact/$Vendor module.
- Sometimes you need custom code to bypass AV, learn to write some code or become friends with someone who can.
For Defenders
- Unauthenticated access gives an attacker a foothold into your network, eliminate it anywhere you can.
- Antivirus is not a silver bullet, it is too easy to bypass AV software.
In the interest of offering solutions and not merely pointing out problems, I would love for some of the defenders that read this blog to leave comments describing the techniques used to catch and/or stop these types of attacks.
04 May 2012
I was working on a social engineering engagement recently and wanted to try to gather usernames and passwords from the victims. The Social Engineering Toolkit (SET) has a credential harvesting attack option that is designed specifically for this purpose. There was a small catch, the client's web site did not have a login form. I was able to use some custom HTML and CSS to get around this issue.
The credential harvester attack can use either a template built into SET, a cloned site, or a custom site stored on the SET machine. Typically, you would clone the client's site, which would include a login form. Since my client didn't have a login form on their site I decided I would need to make one. I created an index.html file that imports the victim site in an iframe and uses CSS to create a popup login box. I saved the file to my pentest machine and imported it into SET when prompted. The custom HTML file can be downloaded here.
To use the custom HTML file start SET, choose option option 1 for Social Engineering Attacks, then choose option 2 for Website Attack Vectors, then choose option 3 for Credential Harvester Attack Method. Next, choose to import a custom website by selecting option 3. You will be prompted to enter the path to the custom index.html file and the URL of the victim site you are impersonating. After that, SET will start up the web server and serve up your custom HTML file.
set:webattack>3
[-] Email harvester will allow you to utilize the clone
capabilities within SET
[-] to harvest credentials or parameters from a website as
well as place them into a report
[!] Example: /home/website/ (make sure you end with /)
[!] Also note that there MUST be an index.html in the
folder you point to.
set> Path to the website to be cloned:/path/to/index_html/
[-] Example: http://www.blah.com
set> URL of the website you imported:www.secmaniac.com
The best way to use this attack is if username and password
form fields are available. Regardless, this captures all
POSTs on a website.
[*] I have read the above message. [*]
Press {return} to continue.
[*] Social-Engineer Toolkit Credential Harvester Attack
[*] Credential Harvester is running on port 80
[*] Information will be displayed to you as it arrives below:
The attack page should look like this. If the victim enters their username and password, SET will record it and generate a report for you.
13 Apr 2012
Update
Marc Wickenden also found this bug a while back and did an excellent write up on it. He also built a metasploit module to exploit the bug.
Splunk has this nifty feature that allows you to upload custom applications that include Python scripts, which are used for custom searching. In Splunk Free this feature becomes a vulnerability because anyone can access the web interface without authenticating. This means you can upload and execute arbitrary code in the context of the Splunk user. If the Splunk user has admin access to the server then the server can be completely compromised.
If you are using Splunk Free, make sure the web server is not running under an administrative account and if possible, configure a web server such as Apache or IIS to sit in front of Splunk and force users to authenticate. Here's an article showing how to do this with Apache.
The Rest of the Story
During a recent pentest I stumbled upon a Splunk server that allowed access to the administrative interface with no authentication. While trying to figure out how to run queries on the server I came across this article. The article says you can create a custom Python script to query data in Splunk. I already had a Python shell script, now I needed to figure out how to create a custom application.
More searching turned up this article and an example application on github. Splunk provides users with an example application called custom_search and in the bin directory you will find a usercount.py file. All I had to do was replace the contents of this file with my Python shell and I had a malicious application.
To create the custom application, use git to clone the splunk-sdk-python repository, then copy the custom_search directory to another location. Replace the contents of usercount.py with your Python script, make sure you inlcude the #! line. Next tar gzip the custom_search folder and use the management interface to upload an application from a file. Once the application is uploaded, you can launch it.
Once the application is running you can execute the custom search using the following command: | usercount __EXECUTE__. When the search executed my shell started and I used netcat to connect to it. This instance of Splunk was running as root, game over.
Side Note
What I don't mention in this article is that it took me a few hours to go from identifying the Splunk server to executing code. I don't use Splunk and I am not familiar with how it works so I stumbled around for a long time and almost gave up number of times. If you are new to pentesting and are struggling, don't give up because your hard work will eventually pay off.
12 Apr 2012
The other day @jwgoerlich posted the following on twitter:
Forbes: 7 in 10 IT departments need to expand their skills base to keep up with cloud trends. http://onforb.es/HIXNQE
to which I replied:
Let me fix that-> 7 in 10 IT departments need to expand their skills base to keep up.
So the question arose, "What's the hold up on IT departments and skills development?". I don't have experience with large IT shops, so my opinion may be way off base (feel free to correct me in the comments) but I'll give it to you anyway.
- IT departments are viewed as a cost center and the obvious thing to do is to cut costs by minimizing or eliminating training.
- Most business owners do not realize how important IT is to their business and how important it is to maintain equipment and skill sets. I worked with a small community bank whose disaster recovery plan included processing transactions manually for two or three days until they could get the core system up and running. While this is an extreme case, it is obvious this bank was out of touch with the importance of IT and the IT budget reflected this.
- It's 2012 and IT staff across the country still spend a large portion of their time teaching user basic computer skills and fixing problems that users should be able to solve on their own. By the time they finish training users and doing routine maintenance there is no time to spend on learning new skills. When I was a sysadmin, by the time 5:30 hit I was completely shot. I didn't want to go home and learn something new.
- If a lack of budget and time were not enough, IT staff are forced to deal with technology that was once only available in large IT shops. Ten years ago the IT department had to know how to deal with Windows 2000, Windows XP, and Active Directory; an MCSE would take you a long way. Now the typical IT department is dealing with Server 2008, VMware, Linux, storage networks, and information security; an MCSE is only the beginning.
If we want our IT departments to expand their skills we need to recognize the importance of the IT department and the importance of training. We also need to expect every user to have a certain level of computer knowledge and troubleshooting skills.
I threw this together in a hurry so I hope it makes sense. Feel free to tell me I'm crazy in the comments.