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!
Friday, October 9, 2009
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!
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.
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!
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!
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!
Subscribe to:
Posts (Atom)
Posts
