Friday, October 9, 2009

The Louisville Metro InfoSec Capture the Flag

Just returned last night from the Louisville Metro Information Security Conference in Kentucky. I typically stay clear from the Capture the Flag events as I'm usually networking with people or presenting. This year I decided (with a little nudge from a couple friends) to participate in the Louisville InfoSec capture the flag. This years CTF was designed and put on by Irongeek (http://www.irongeek.com) which your always in for a blast with him.

Our team came in first place and everyone on the team did an amazing job contributing. I have to give a shout out to Irongeek and his time and dedication to the CTF. It was truly a great experience. Some of the ideas, twists, vulnerability linking, and creativity of the overall CTF was a unique experience in itself. The hack with the rotating web cam to see a password written on the computer is just a taste of the creativity Irongeek put into the CTF.

Overall, it was truly a great time and a great experience at the Louisville InfoSec Conference, would highly recommend it next year!

Quick outline of how we got first place:

Machine 1:
MS08-067 with Meterpreter payload, dumped hashes, and performed rainbowtables to crack passwords. Fast rainbowtables didn't work, ended up using CUDA cracking power to get the password.

Second machine: Directory traversal to /etc/passwd, found user account that was on the windows box, with same password on *nix box. Pulled off encrypted TrueCrypt volume. Found a robots.txt with a disallow on a config file that contained the MySQL db username and password. Connected to the mysql machine and extracted a table that had the truecrypt password in it. Inside that file was a password protected 7zip file.

Third machine: Web based camera web interface, not a default password, no published vulnerability, no apparent easy way in. Performed arp cache poisoning, obtained the credentials passed in the clear of view/view. This got us access to a web cam that could rotate. Rotating it from left to right, it revealed a piece of paper with a handwritten password that ultimately allowed us access to the 7zip file.

Thanks again guys was a blast, nice job Pure-Hate, Archangel, and Titan. Bang up job team.

Irongeek's post about the CTF: http://www.irongeek.com/i.php?page=videos/louisville-infosec-ctf-2009

Read more!

Thursday, October 8, 2009

What’s the Value of Your Mobile Phone’s Address Book?

Being a consultant, I travel a good amount around the United States for various engagements. While at airports, hotels, and other public places that offer opportunities for wireless communications, I often find myself in amazement of the information at large.

Approximately 4 months ago, I sat at the airport gate awaiting my incoming flight and a woman sitting next (2 seats down, or about 6 feet away) to me was talking on her cell phone about her travel reservations. Whomever she was speaking with apparently had Internet access as she gave them instructions on how to open up Internet Explorer, navigate to www..com, and login with a username of and password of . She proceeded to instruction this person how to search for a hotel, and book a reservation, also giving her credit card number, expiration date, and CV2 code. After she hung up from the call, I thought to myself that it would be very amusing to go thank her for her information and paying for my flight/hotel. Of course, I did not, but thought to myself how clueless must this lady be.

From airports to hotels, it is no surprise that there are always open file shares, shared iTunes libraries, and similar things readily available to people via Bluetooth or wireless communications. This is nothing new, however the sensitivity of the information people purposely or inadvertently have shared varies. When doing a penetration test for a large health care organization, a coworker and I gained access to a Web site that was indexed in Google that provided us with a complete employee directory listing. This client was alarmed at what we found, as we could couple this gold mine of internal information with some XSS flaws to perform a large scale phishing attack.

I pose this question: How important to your organization is your mobile phone’s phonebook?

More specifically, the Apple iPhone’s use for the corporate world has been a topic of debate for some time. With the number of applications in the AppStore, how well do you think Apple is doing screening them all for rogue code? Just as an organization has that fear of a time bomb planted by and ex-developer in one of its code bases, should iPhone users and enterprises be worried about your information on their iPhone? The answer is yes.

Code showing how to read not only your iPhone’s number, but also your entire address book as well has been published online for some time now. Additionally, the article claims that applications can obtain personal information from most of the iPhone’s file system despite Apple having a developer sandbox in place. We’ve already seen the $999.99 “I am Rich” app that tricked 8 people into its $1,000 price tag, so what else might exist in the thousands of other applications available? Do your C-level executives use an iPhone? Has your address book or theirs already been compromised? You may never know…

Read more!

Tuesday, October 6, 2009

How a simple python fuzzer brought down SMBv2 in 2 seconds.

If you haven't had a chance to check out the post by Laurent Gaffie (posted at the end of this blog), it's a really great read on how the latest SMBv2 zero-day got discovered.

Laurent used a simplistic packet reconstruction fuzzer in python to ultimately discover what is now a remotely exploitable zero-day within SMBv2 systems. Let's dissect the code a little bit:

from socket import *
from time import sleep
from random import choice

host = "IP_ADDR", 445

#Negotiate Protocol Request
packet = [chr(int(a, 16)) for a in """
00 00 00 90
ff 53 4d 42 72 00 00 00 00 18 53 c8 00 00 00 00
00 00 00 00 00 00 00 00 ff ff ff fe 00 00 00 00
00 6d 00 02 50 43 20 4e 45 54 57 4f 52 4b 20 50
52 4f 47 52 41 4d 20 31 2e 30 00 02 4c 41 4e 4d
41 4e 31 2e 30 00 02 57 69 6e 64 6f 77 73 20 66
6f 72 20 57 6f 72 6b 67 72 6f 75 70 73 20 33 2e
31 61 00 02 4c 4d 31 2e 32 58 30 30 32 00 02 4c
41 4e 4d 41 4e 32 2e 31 00 02 4e 54 20 4c 4d 20
30 2e 31 32 00 02 53 4d 42 20 32 2e 30 30 32 00
""".split()]


while True:
#/Core#
what = packet[:]
where = choice(range(len(packet)))
which = chr(choice(range(256)))
what[where] = which
#/Core#
#sending stuff @host
sock = socket()
sock.connect(host)
sock.send(' '.join(what))
sleep(0.1) # dont flood it
print 'fuzzing param %s' % (which.encode("hex"))
print 'complete packet %s' % (''.join(what).encode("hex"))
# When SMB Or RPC die (with TCP), sock get a timed out and die @the last packet, printing these things is more than usefull
sock.close()

Look at the #Negotiate Protocol Request portions, this is simply rebuilding a dump of a valid SMB request, easily obtainable through wireshark or other sniffers, the rest of the fuzzer simply substitutes every byte with a substituted value like most fuzzers do. The blog outlines how could something like this escape Microsoft's auditing and how easy it was for Laurent to find this bug.

Also if you haven't read the post on how this bug became exploitable using the trampoline method for reliable exploitation, take a read here: http://blog.metasploit.com/2009/10/smb2-351-packets-from-trampoline.html written by Piotre Bania.

Using three stages, some division to calculate a INC ESI, POP ESI, and RET (0x46, 0x5E, 0xC3) to our shellcode, the smbv2 exploit is now a living breathing remote exploit.

For more information and an explanation of how the exploit was discovered check out: http://g-laurent.blogspot.com/2009/10/more-explication-on-cve-2009-3103.html

Read more!

Sunday, October 4, 2009

Patrick Swayze- Roadhouse Ramblings

I have always liked the movie Roadhouse. Patrick Swayze is an amazing actor (and has more range than he gets credit for- remember Wong Fu?). Throw in Sam Elliot and I don’t see how you can go wrong. Before you decide that I have taken up blogging about cinema, let me say that in light of the recent passing of Swayze, I think we can learn a few things about information security from Roadhouse. And also, we can learn from the way that hackers have exploited the death of Swayze to spread viruses.



In Roadhouse, Swayze is called in to clean up a bar, and thus a town, ravaged by criminals. These criminals steal from honest people and legitimate businesses to enrich themselves. In information security, we come in and clean up servers and networks ravaged by, well, criminals stealing from honest people and legitimate businesses. Remember the bartender, the distant relative of the main antagonist in the movie, stealing money from the register? He can represent the threat organizations face from their own employees. Swayze threw him out. Swayze cleaned up the bar, and hardened it against attackers. While I don’t claim to look as cool as Swayze while neutralizing threats, we also spend our days identifying and removing threats. More about that in later blogs.


What I want to discuss here is how attackers use news events such as the death of Swayze to spread malicious software. E-mail claiming to contain photos of or links to stories about celebrities will often link to sites that install malicious software. The human element is regularly the weakest part of any security program. Rather than attack your hardened systems, attackers will work to gain the confidence of those who already have access to you your systems: your employees. To be secure, it is important to have a culture of security. Every employee must understand the importance of their role in protecting systems and information. And every employee must be educated as to the threats and techniques used by attackers. All the locks in the world won’t help keep your information safe if your employees open the door every time a sympathetic character comes knocking. Sure, anti-virus and e-mail filtering can help, but employees need to know how to recognize suspicious e-mail, and they need to be educated to never open it.


We have a lot of success exploiting the human element. People have a natural inclination to be helpful, and curiosity is a big part of human nature. There is software and processes that can help combat social engineering, but until all your employees understand the risks, it is difficult to be secure. That is another area where we help our clients. Just like Dalton (Swayze) showed the other bouncers at the bar how to handle problems, we can show you how to educate employees and keep your environment safe.


I don’t want to take the analogy too far, to the point of ridiculousness (if it isn’t too late already), but we have found that sometimes the best way to articulate threats to information security is to use analogies based on the bricks and mortar world. And in the electronic world, much like a roadhouse, there are all types of people, with all types of intentions. The first step in securing your information, or roadhouse, is an assessment. Then, we can get to work on cleaning it up.

Read more!

Monday, September 28, 2009

SMBv2 Exploit now in Metasploit as well as Screenshots!

As version 3.3 stable comes near, H.D. Moore and the crew from the Metasploit team has released a couple of great new features with the 3.3 dev version. Most notably last night was the commit for the latest SMBv2 remote code execution vulnerability that specifically targets Windows Vista and Windows 2008 and is still currently unpatched!!

The second awesome looking feature is the capability to take screenshots of an already compromised system through metasploit. When delivering the meterpreter payload you simply migrate to explorer.exe and type in screenshot /yourdir/screenshot.bmp, after that the victims machine will then be captured. Just another reason why the meterpreter console is one of the best post-exploitation swiss army knife out there.

Stay tuned for more Metasploit additions!

Read more!

Monday, September 21, 2009

Using SWOT to Evaluate Your Security Posture

Because the value of security is based on what is prevented, or doesn’t happen, it can be difficult to quantify. One simple way to evaluate your security needs can be with a SWOT analysis modified for security. Almost all of us are familiar with the SWOT analysis- it is business 101. For those who are not, it as an analysis of Strengths, Weaknesses, Opportunities, and Threats. When you are trying to get buy in and the resulting budget for security initiatives, the SWOT analysis lets you speak in the language that executives understand.

The exercise is most effective when combined with the systems approach. Without getting into the details, basically you need to clearly define the security objectives before completing the SWOT analysis.
Objectives can be anything from supporting the organization’s financial goals to protecting client information. If you can put dollar amounts to the categories, you are a step ahead.

Strengths
It is helpful to start with the good. What are the organizations security strengths? For smaller organizations, a strength may be the very fact that they are small, and thus fairly easy to secure. Maybe the organization already has a “security culture” with security embedded. Often, an organization’s strengths present an easy opportunity to increase security. By building on or positively modifying existing controls, security can usually be increased.

Weaknesses
Weakness can be broad or specific. A general lack of a security program or culture is a weakness, but is not defined enough to guide action. Look for specific areas. For example, not having a patch management program in place is a definite weakness. But organizations lacking a robust patch management process have a great opportunity to increase security. We see organizations fall prey to vulnerabilities that would not have been able to be exploited if they had a proper patch management program. Implementing a patch management program may involve spending some money, but it is a small price compared to remediating damage caused by an exploited vulnerability.

Many weaknesses are highly technical in nature. Lack of logging or change management are weaknesses that likely will take significant effort to fix. Articulating the weakness presented by not having systems like this in place and the strengths from implementing them is important to get management to approve the effort. Once again, putting dollar amounts on the costs of a successful exploitation of a vulnerability is paramount.

Another weakness that is especially common in today’s economy is a lack of funds. It can be tough to get buy in for initiatives without ample funding, but for organizations with cash flow problems, the expenses resulting from a security breach may be enough to put them out of business for good. That is a point that if properly articulated, should sway even the most security adverse executive.

Opportunities
Opportunities are generally fairly distinct. Does the organization have funds for security allocated, but not spent? Are logging systems in place, but not used? Do robust security policies exist, but have never been distributed? Think of driving around without buckling the seatbelt. Simply buckling your seatbelt costs nothing, doesn’t take much effort, and instantly and vastly improves safety. Opportunities are low hanging fruit that you can’t afford not to take advantage of. The best part is that taking advantage of most opportunities doesn’t require management approval or any significant spending.

Threats
Many threats, especially from a security perspective, are fairly easy to delineate. If the organization is subject regulations such as PCI DSS, HIPAA or SOX, the cost of non compliance can be astronomical. The costs of reputational damage often far outweigh the fines for non compliance. And the fines for non compliance are stiff.

How do I get started?
A good template in MS Word format for a SWOT analysis can be found here: http://www.zeltser.com/sans/isc/swot-matrix-template.doc

The best place to start is with an assessment. Many times organizations have trouble assessing their own security because they are too close to it, or lack the time or expertise. An experienced outside assessor will have seen countless situations and levels of security, and will be able to help with all four areas of the SWOT analysis.

If an assessment is not possible, a brainstorming session can be good for getting most of the fields started. The more people you can involve in the brainstorming sessions the better, and be sure to include front line employees if possible. They are often aware of the issues that exist in an organization, but lack the proper channels of communication to get to executives.

This is definitely an exercise worth your time and effort. The sooner you get started, the sooner you can approach executive management and get started on increasing security.

Read more!

Thursday, September 17, 2009

Information Security's Silver Bullet: There Isn't One

Back on June 27, 2008 ComputerWorld published an article "Web firewalls trumping other options as PCI deadline nears" just before the well known June 30, 2008 PCI 6.6 deadline. In February of 2008, the PCI Council published clarification on the PCI DSS section 6.6 and what the intent of it was. Over a year later, I frequently encounter Web applications that are far from compliant and this is no surprise. What is (sort of) surprising, is the false sense of security people have with PCI after completing their self-assessment questionnaire (SAQ) and dropping in a Web application firewall (WAF) thinking they are secure that is still ubiquitous.

Year after year I interface with individuals that think there is a single silver bullet to solve their information security concerns. Have they been misled somewhere in the past? Are they simply uninformed about security and the attacks out there? In a past web application review, my user ID was passed through the URL (example: http://www.website.com/index.php?uid=swhite) and I trivially changed it in my browser to "admin". This in turn allowed me to view over 11,500 files containing sensitive information on customers. A Web application firewall more often than not would not have caught this more than likely valid request, and allowed for identity theft with the information I was able to obtain.

ComputerWorld's article makes me nod my head, but at the same time, question the expertise of who is writing it. For example, they mention that web application firewalls can protect against things such as sql injection, buffer overflows, and cross-site scripting. The OWASP Top 10 list (2007 and 2004) doesn't mention buffer overflows and the PCI DSS section 6.6 specifically calls out Web applications. Buffer overflows in Web applications themselves are very unlikely to be exploited outside the capacity of a denial of service attack, but would more likely target a web server or other service running. As one who hosts web applications, I would worry about injection flaws and XSS before buffer overflows. I'm not sure why the author of the article included buffer overflows other than it is a buzzword for some people that makes them think security.

As a security professional, I commonly have to describe very technical issues in "normal people" terms. For information security, a field that has very techical aspects, non-technical individuals should understand that there is no single silver bullet to solve your security issues. Just as throwing up a WAF in front of your Web application that handles PCI data isn't the best (not necessarily least expensive) approach to complying with PCI DSS 6.6, that seemingly simply and one-time solutions to write off security concerns are not in accordance with industry best practices.

Defense in depth should be employed so that your resources are protected when preventative measures may fail, to ensure that you are protected from zero-day to patch day or until the controls are operating properly again. If at the end of the day, you learn one thing, let it be that there is no single solution to information security, or everyone would be doing it and the solution would be spreading like wildfire.

Read more!