We even have a sepcial guest this week: International man of mystery, and alleged double "agent" Ed Skoudis!
Don't forget to join in on the IRC channel during the stream - we can take live comments and discussion from the channel! Find us on IRC at irc.freenode.net #pauldotcom.
When active, the live stream(s) can be found at:
Ustream: http://ustream.tv/channel/pauldotcom-security-weekly
Icecast: http://radio.oshean.org:8000
Please join us, and thanks for listening!
- Larry & Paul
]]>There's nothing like walking in to a network that you must begin to perform incident response with little to no system documentation, patches or time. The team had no access to patches, a firewall that we could only examine logs on (with default ip permit any any rules), and every service under the sun running on the systems; Windows 2000, and an older version of Fedora. This is exactly what I would come to expect as a third party consultant taking over a customer's network during an incident response engagement.
It didn't help that we had to keep the "business" up and running while we responded either. It was also typical that Tim, our game host and "CE-Oh no" showed up immediately to demand that our e-commerce site be up; Did I mention that it was not up, or even configured when we walked in the door? Yeah, now time to learn MySQL and ZenCart on the fly.
In other words, this was an almost perfect real world scenario.
The first night only delivered us a few participants. We didn't even have enough folks to fully staff both teams - team 2 had one person. We made a decision early on to only focus our efforts on team one, and eventually we had some more help. With this strategy (and some more help) a few hours into the game, we were able to use team 2 as a "test" environment to see what worked, and take those lessons and apply them to team 1.
The first order of business; change those bad default passwords. Once we completed that, we started to harden systems; turn off unneeded services, change passwords, begin hardening, change passwords, discover an intrusion and mitigate, change passwords...
Then you begin finding more about the systems. Did I mention default usernames and passwords for the Asterisk web interface? Yep, they've re-routed all of the phone traffic. Change the password on the SCADA box? What password on the SCADA box! In fact, no authentication at all! No wonder the re-routed phones kept powering down.
At least we put up some "calling cards" handed out by some gentlemen on the street in front of the web cams.
The guys did a fantastic job dealing with all of my harassing on the status of the systems, while acting as incident commander. they developed some hardening guidelines, created some scripts to disconnect suspicious incoming sessions, and implemented some host based firewalling - most had to learn Windows ipsec policies and iptables rules in game.
Eventually, the folks at Fortinet came over and gave us the ability to manage our firewall. At that point the game turned a little bit, and we were fairly successful at keeping the attackers out, and restoring business services.
This night we already had some significant game plans form the previous night. We also had some more help, and alas, some defectors to the dark side. John Strand came by, and we put together a new strategy; take two of the team "leaders" from the night before, and make them incident commanders.
Why is this a big deal? The natural reaction for the two new incident commanders was to pull up a keyboard and start remediating. This is the wrong thing to do as an incident commander, and they, and the team quickly learned that having someone as the middle management and not being technical was a big help. The incident commanders could offer some limited technical advice, but they could spend more time with the "customers".
Enter social engineering. We had attempts to gain credentials to the system via phone asking for a password reset, and for a new account. Fortunately, the incident commanders responded appropriately, and the attacker (whom they recognized as the voice of the Lt. Col. from the Air Force) could not provide the appropriate information to validate the request. However, we had the tables slightly turned. During the day, one of the 560 students came to me to see if a mole on the attacker's side would be permitted. It was, and the mole was able to SMS text message me through the event that evening letting the teams know where attacks were originating from, what was compromised, and that they could hear us on the microphones. I'm still not sure why they didn't pick out the really big guy SMS-ing all night.
A few times the teams needed to enact their disaster recovery plan, and have some of the systems restored to a last known working point. they became so hosed by the attackers, or the defenders were no longer able to log in, that the only option was to "restore from tape".
This night also gave us a wireless access point. That was an easy reconfigure of the username and password, and a re-config of a known strong WPA2 key. The problem that we made was that we had a "remote" worker whom we appropriately reconfigured to utilize the new wireless settings. The attackers were able to gain physical access to the remote worker, and compromise that system to use as a pivot point. It just proves a point about needing to protect your remote workers...
On the third night, most of the teams had everything coming together pretty well. The typical scramble ensued in the beginning, however this 
time the defenders were given 5 minutes to disconnect form the network and begin locking down. We also assigned some different incident commanders, and had one of the star incident commanders from the previous night take on the role of upper management to manage the commanders.
Everything went well. The teams came together quickly, and the new commanders suffered the same problems and the previous ones, which was to be expected. The hardening scripts and firewall rules were easy to re-do from the knowledge gained. The configuration of the e-commerce site got easier. We also found us without a wireless network this time. Heck, we even got one of the teams (team 2, the former "lab" from night one) to do some serious poking at the webcams and phones, changing the passwords and such on the devices themselves.
From there, the game was pretty much the same.
Or was it?
The team members kept seeing attacks coming from an unusual network address range, but couldn't determine what it was. Upper management made some suggestions well into the exercise this night that may have been overlooked, and game progressed in the usual fashion.
Enter the rogue AP.
The teams made the assumption that because no hardware device for wireless was obviously present that it didn't exist. Except that it did. There was an AP deployed under the conference table, and no-one spotted it, either physically or via a wireless assessment. Soon, a call came in from Tim the "CE Oh-no", that there was a rogue AP and the game had ended.
Incident Response is hard. Don't expect everything to be working when you show up.
Overcoming the drive to do technical items while being incident commander can be detrimental. It is certainly something that can be uncomfortable, but is a skill that can be learned.
Remote workers need to be secured appropriately. This means physical access too.
Don't underestimate the power of the Rogue AP. Sure, your policies may say no wireless, but you can't be sure that it isn't there until you test for it.
Social Engineering can be defeated with the proper staff training.
Windows 2000, without any host based protection is almost impossible to defend, even behind a firewall. Go for the crunchy on the inside, crunchy on the outside security model. Once the attacker is inside without host based protection, the game is almost assuredly over.
A big thanks to Tim, Dwight, Joe, Justin, Alex, Anthony, and the sponsors (Immunity, CORE, Think Geek and Fortinet and all those who came out (both the attackers and defenders). I can't wait to do this one again!
- Larry "haxorthematrix" Pesce
Simcard Forensics, An Adventure in Information Gathering
Hosts: Larry "HaxorTheMatrix" Pesce, Paul "PaulDotCom" Asadoorian
Email: psw@pauldotcom.com
Audio Feeds: 
taught the one-day "Up and Running With The Metasploit Framework" course, participated in the SEC560 penetration testing course, and got to lead a team of attackers in a three night hacking challenge. More on all that later, as I also presented on how embedded devices continue to be a threat. The goal of this talk was to raise awareness about the inherent insecurities in embedded systems, understand some example vulnerabilities and associated "exploits", and identify defenses. I covered just how easy it is to "karmetasploit" the iPhone and some of the implications, an SSID script injection vulnerability in DD-WRT, and some interesting things I found on an Axis web camera.
As a side note, I was leaving Las Vegas early in the morning while people were coming out of the clubs, which was an interesting site to say the least. I happened to be standing next to Trent from www.i-hacked.com who stated how nice it would be run Karmetasploit as people were "under the influence" enough to click on anything (I suppose one could argue that people will click on anything even while not drinking). It got me thinking how interesting it would be to take over an iPhone and download all of the pictures stored on the phone, especially after a wild night in Vegas... In any case, you can download the latest (and final) slides here:
Things That Go Bump In The Network: Embedded Device (In)Security
Note: A previous version of this talk, including the audio version of the presentation, can be found here
The EeePC I was using seemed to pique the interest of many during the demo section of the talk. Below is some information about my EeePC setup:
* Madwifi drivers (I'm using this one) with the Karma patches from DigiNinja (I highly recommend these drivers over the ones in Backtrack, they seem to work far better)
* A copy of "evilap.sh" from the Backtrack CD with some modifications, primarily to make it work with dhcpd on Ubuntu (Example can be found in Episode 114's show notes)
I believe this talk served its purpose, many have commented that they were going to bring this knowledge back to their respective organizations and begin to think about embedded system security differently. Mission accomplished? I'm not quite sure, while I believe that many have taken embedded systems security more seriously as end-users of the products, the vendors still have some work to do. I'd like to see more of:
* Vendors allowing the user to create the initial password(s) and security certificate
* Doing their own security evaluations before the product is released to the market
* Using secure protocols for management (SSL, SSH, SNMPv3, etc...)
With respects to defense and active scanning/penetration testing of your internal network, well, more on that later...
PaulDotCom
]]>On the first night I was pumped. For the first hour of the exercise, we're given access to the networks completely exposed, 
no firewall and the defenders are only allowed to use operating system tools. This was so exciting! I had about 15 hackers the first night, including Justin and Alex from Immunitysec and Anthony from Core Security. I started organizing all 15 people, getting them networked, assigning tasks, having them Nmap, vulnerability scan, exploit, etc... That plan quickly fell apart and I realized I needed to add a layer of "middle management" and assign a leader to each table, then work through that leader. Things went smoother, however most people wanted to just come in and use remote exploits to pop boxes and do their victory dance. While this is fun, its only the tip of the iceberg. Once you compromised a machine, you had to have it update the scoring engine by running a python script. Many missed this step the first night, party due to logistics, and partly due to shells dropping before you had the chance to upload and run the script. I learned a lot on the first night about how not to organize a large team of attacks, the importance of keeping access, and proper testing of tools and automation.
The second night we were a bit more organized, I ran the recon efforts and put up the vulnerable hosts and open ports on the projector for the entire team to see. The defenders had access to the logs, so I ran an Nmap command to run interference and keep the Fortinet guys busy:
nmap -n --badsum -PN -T5 -f -D `cat 1128ips.csv` -sSU --packet-trace [ip or subnet]
The above command tells Nmap to send fragmented traffic (-f), with bad checksums (--badsum), really fast (-T5), and spoof 128 decoy IP addresses (-D), do this for both UDP and TCP (-sSU), and show me the packet trace while the scan is running (--packet-trace) . This worked fairly well as a >
distraction, however I believe Ftester would have been a much better option. The firewalls went in place in the second round and the defenders really locked things down, and managed to change the passwords to several systems. Unfortunately for them, they left the default password to the web cam, which also had a mic for us to listen to all their conversations. Turns out the joke was on us, as the defenders sent over a mole on our team, which turned only slowed us down a bit (all is fair in love and hacking). We spent some time analyzing the web apps and found several vulnerabilities, such as XSS and SQL injection. We were then given access to a wireless client on the defender network, and thought great we can use XSS and make some progress (Grab cookies, gain credentials, etc...). However, we were given physical access to the client, so we deployed an Immunitysec payload to the target system, and had it call back to us. We then used that machine to pivot and compromise machines on the defender network. While that was fun (we did the victory dance), I was still disappointed and wanted to cause mass destruction and pwnage...
I spent some time scripting some interesting things for night 3. The first thing I had to do was select the best tool to compromise 
the most machines, and do it the fast. I also wanted to score big (TWSS) on night 3 (most of my other nights were spent helping students, which was also great fun). The first thing I did was take the scoring engine script and convert it to a Core IMPACT module. I selected this tool because I didn't want to spend time converting it to Ruby, and I did not have CANVAS. Also, Core IMPACT has a "mini-shell" which allows me to interact with the command shell on the host and not end up in the process list on the compromise system (metsrv.dll shows up in a process listing). The "mini-shell" is a python program which interprets commands from the user and runs them directly via syscalls on the target system. Those paying close attention are probably saying that my sessions still show up in a "netstat" command output. Yes, its hard to hide on a system without a "rootkit" (Immunity has one, which worked well and is something I need to evaluate more). In any case, I wanted to make it hard for the defenders to find me. I had a way to compromise systems and score easily, however I needed to keep my access and continue scoring once the firewalls got in place. I wrote some scripts to kill common processes and applications that would lead to my detection:
:loop process -k "cmd.exe" process -k "taskmgr.exe" taskkill /F /IN taskmgr taskkill /F /IN cmd goto loop
A couple of things about this script. When I wrote it, I said to myself, "Wow, I would never run this on a customer's system". However, and evil bad guy would most certainly run this on a target system. So, the defense gets some real world experience, which I think is really neat. Just to clarify, I don't actually kill my own shell because I never run "cmd.exe" on a target system, the "mini-shell" lets me list files, upload files, download files, and execute programs. Once I have access to a system I use this shell to start executing commands. I change the administrator password, expose services like RDP, and various other nasty things to lock them out of the system. Then, things started falling apart. "cmd.exe" no longer existed, neither did sc.exe, the net command, or netsh. What happened? I took a quick walk around the divider to see fellow SANS instructor John Strand helping the defense (I am shaking my fist yelling, "Bastard!" as I type this). It was all in good fun and it turns out we were using similar techniques to both attack and defend. Wait, did I just say that? Yes, the defenders were killing processing, using scripts to look for new connections. So, they locked us out and hardened their systems and implemented a firewall. Game over? No way, this is an excerise that sets out to mimic the real world. Wireless enters the equation again, and we gain access to our wireless router which is plugged into the defender's internal network. Its using a hidden SSID and running WPA2-PSK. We associate to the network and manage to find one box to compromise with Metasploit and deploy a meterpreter payload. I'm able to use this payload to score in one of the later rounds, and grab password hashes, then use john to crack the administrator password. A fitting end to the evening for the attackers was to hand them their administrator password on piece of paper, to which they asked, "Which system is this for?", and I responded, "I dunno, you guys should be able to figure it out". An even more fitting end was when Tim from White Wolf Security, responsible for managing game play, called the defenders on their VoIP phones and told them about the access point. The red team gathered around to watch and cheer when they found it. Game over....
Thanks to Tim, Dwight, Joe, Justin, Alex, Anthony and all those who played in the games. Looking forward to next time!
PaulDotCom
Hosts: Larry "HaxorTheMatrix" Pesce, Paul "PaulDotCom" Asadoorian
Email: psw@pauldotcom.com
Audio Feeds:
That said, I've been reading California's legislation marked SB 31, which makes it illegal to read RFID without the possessor's prior consent and approval. This raises some very interesting questions to me...
How does this affect installed systems used for automobile toll collection? Does this mean that each time I drive through a tollbooth with this technology, the State of California has to ask my permission to read, and then I have to consent? Certainly, they can pre-authorize consent through the usage agreement, which they may need to change now. Until then (if it isn't already in the agreement), is the State of California currently engaging in an illegal act?
The same becomes true of those using RFID for access control or payment information. Does my employer need to ask me permission to read my RFID enabled badge every time I enter the building? Or, do they need to cover it with a blanket usage agreement?
In my opinion, I think that the legislators went about this a little backwards. I personally think that they should not have made it illegal to read without permission, but that they should have done the opposite; pass legislation that requires the RFID vendors to implement technology to prevent unauthorized, unencrypted reading of data from RFID. Sure, form a technological standpoint it is certainly a challenge, but consider making it a future rollout, such as the new digital TV rollout here in the US.
Certainly neither plan is perfect or foolproof. I just see this as going after the attacker, while really not fixing the problem.
When you outlaw reading RFID, only outlaws will read RFID.
]]>Hosts: Larry "HaxorTheMatrix" Pesce, Paul "PaulDotCom" Asadoorian
Email: psw@pauldotcom.com
Audio Feeds:
We made an attempt to stream the podcast live from NS2008 last night, but unfortunately there were some technical difficulties that were beyond our or SANS' control, with respect to some internet access.
Unfortunately, our handy little EVDO connection isn't able to handle the demands of the audio and video streams, so we had to punt last minute and not put them up.
We'll have the podcast out to you all as soon as we are able.
Thanks to all of our listeners that showed up, and for SANS for hosting us again!
The stream should be live at about 12:00 AM EDT (midnight!) and we'll begin the interview at about 12:15 AM EDT.
Please keep in mind that these times are all estimates, but we will try to do the best that we can.
Don't forget to join in on the IRC channel during the stream - we can take live comments and discussion from the channel! Find us on IRC at irc.freenode.net #pauldotcom.
When active, the live stream(s) can be found at:
Ustream: http://ustream.tv/channel/pauldotcom-security-weekly
Icecast: http://radio.oshean.org:8000
Please join us, and thanks for listening!
- Larry & Paul
]]>
For those of you who haven't heard already, friend of the show, Michael Santarcangelo (The Security Catalyst) had his mobile home robbed while he's on US tour with his family taking his security messages on the road. The thieves made off with his computing gear. I have to say that he's been very upfront about his predicament so that we can all learn from his situation; He did lose some data, but for the most part his backup and disaster recovery plan went well. He's deriving a great amount of inspiration for some more security training out of this as well. I have to applaud him on taking some lemons and making lemonade.
I have to admit that the incident has inspired me as well. It got me thinking about some possible issues with mobile workforces. I mean, we all (for the most part) do a pretty good job of securing our assets while they are in our corporate environment; Whole disk encryption, AV, Desktop and Network firewalls...the list goes on. We also have those locked doors, a security guard, alarm system and so forth.
But what happens when someone takes (with permission) that asset, such as a laptop, home to do some work in the evenings, work from home, or visit client sites? What do the employees have for protection? Do they have a network firewall, or do they plug directly in to their cable modem? Do they have a security guard (dog or alarm system at that)? Typically no. Unsecured wireless? Yikes, all of the same things that we've thought about as challenges in the corporate environment, we have think think about "on the road" I see these as some potential issues for security for both data on the machine, as well as a possible connection to the corporate network.
Let's set the scene. Intellectual property gets loaded on to a laptop with fill disk encryption. The employee takes the laptop home to telecommute (which is a regular occurrence), connects the laptop to the home network and initiates the VPN connection (with cached VPN credentials possibly) to the corporate network. the employee decides to take a breath of fresh air with a trip to the local coffee shop for an invigorating mocha-chino. While away form home, a burglar (or attacker in this case) breaks in and has a few minutes to play on the VPN, and so forth. Without full disk encryption, this situation looks like a disaster to me.
So, you are asking, how does the attacker find where the "target" lives to break in? A little Google searching (and maybe even some Maltego action), could turn up a photo sharing service account for the "target". Combine that with a Nokia N95 or iPhone with firmware 2.0 or later, and some nice, geotagged photos get uploaded (such as the one to the right, with output from a nice Firefox greasemonkey script to pull map info from google). Now you know where to search...
Protect your corporate assets on the move! It is hard to make unreasonable requirements of folks at home, so a little education needs to go a long way. Make those corporate assets as secure as possible, and design a policy framework that will appropriateley guard against the high risk areas; include screen saver locking with a short delay, workstation login timeouts, whole disk encryption, VPN activity timeouts and maybe even a good cable lock for good measure, amongst a myriad of other things.
Educate staff about what they share on the internet; in most cases it would be in bad form to restrict what folks do in their spare time.
Best of luck securing your mobile workforce, and Michael, best of luck to you and your family recovering from your ordeal.
- Larry "haxorthematrix" Pesce
]]>The live stream for the news portion of the show should be active about 5:00 PM EDT, Thursday, September 25th. We should begin recording the live show at about 5:10 PM EDT.
We even have a very special guest again this week, Alex Horan from Core Security Technologies (and some other distinguished guests from Core). The stream should be live at about 8:45 PM EDT and we'll begin the interview at about 9:00 PM EDT.
Please keep in mind that these times are all estimates, but we will try to do the best that we can.
Don't forget to join in on the IRC channel during the stream - we can take live comments and discussion from the channel! Find us on IRC at irc.freenode.net #pauldotcom.
When active, the live stream(s) can be found at:
Ustream: http://ustream.tv/channel/pauldotcom-security-weekly
Icecast: http://radio.oshean.org:8000
Please join us, and thanks for listening!
- Larry & Paul
]]>
Hosts: Larry "HaxorTheMatrix" Pesce, Paul "PaulDotCom" Asadoorian
Email: psw@pauldotcom.com
Audio Feeds:
The September Late-Breaking Computer Attack Vectors webcast this month will be held on:
Wednesday, September 24, 2008 2:00 pm EDT (GMT -04:00, New York)
Register Here For This Webcast
Summer is coming to a close (okay, I guess summer is over at this point) and we are moving into fall. The weather is a bit chilly, we're all still soaking in all of the juicy research from Blackhat/Defcon, and drinking Octoberfest and maybe even thinking about making some apple pie. So, while you're sipping on some of the finest Octoberfest Germany has to offer, join me while I discuss some of the latest attacks, including:
This webcast will run about 45 minutes and I will get excited, probably rant about a few more things, hopefully show you how to do something, and improve your defenses.
One of my rants may even include cable management :)
PaulDotCom
]]>
Hosts: Larry "HaxorTheMatrix" Pesce, Paul "PaulDotCom" Asadoorian
Email: psw@pauldotcom.com
Audio Feeds: