Andrew Case discusses de-anonymizing Live CDs using analysis of the memory Then better than last week we have security news from the week only half drunk... Larry is sick at home but at least he has skype. Episode 241 Show Notes Episode 241 Direct Audio Download All the Pauldotcom Security Weekly episodes on our Bliptv archives. Hosts: Paul "PaulDotCom" Asadoorian,John Strand,Larry Pesce,Carlos Perez Audio Feeds:

 

Zero Day is a novel by Mark Russinovich, whose name is very well known to security professionals and system administrators that work with Microsoft systems alike. At some point, all of us have used the great set of utilities that he has written under his own company Winternals before being acquired by Microsoft and still available and updated as part of the Sysinternals suite of tools. Mark has used his experience in the Security field and community to write this novel in an action packed story "Tom Clancy style".

The story starts via a series of events caused by computer systems failing and data and information being altered with catastrophic events; this opens the story to the introduction of the main character, Jeff Aiken, a security consultant that is called to look at an infection that destroyed the systems of a New York law firm. The character is a bright security consultant driven by events in his past, a passion for the thrill of the chase of hackers, and for solving the complex puzzle of digital forensics.  As he delves deeper into the origins of the virus and the work of a bright determined woman (named Daryl Hagen that manages a US CERT team and is part CISU/DHS looking at the other cases), they discover that the infections are all connected and just the tip of the iceberg of a bigger attack that will hit western governments. The story appears to be the typical terrorist plot of vengeance against the corrupted west that has been seen in so many novels after 9/11 except this one presents the twist that this threat is a cyber attack with very dark consequences.

As as security researcher and professional I can relate to what Mark exposes in the book, especially the reality that our capacity to defend against a coordinated cyber attack is just not existent.  All of us in the industry that have found holes in systems have been frustrated many times with the speed of the response of private companies to address these holes and the lack of cooperation between them. Mark mentions how antivirus vendors are flooded with more samples of malware code than what they can handle. He covers the reality how we are losing the battle against malware writers but in this case the malware writers have a more deadly agenda than feeding their egos or making money like many out there in the real world. I certainly related to all the problems faced by the heroes in the story making it more real in my imagination as I read the book. I could even sympathize to the pain of some of the victims, having myself gone to clients to assist in recovering from security breaches and malware infections. I even related to the addictive nature that we in the security field have when we are faced with the hunt of an adversary while doing incident response and how that thrill of the chase consumes us in the process.

Mark also covered the problems that some of the bright women that are in this industry face with prejudice and lack of respect by their peers. I found this part of the story very interesting knowing myself women in the industry and in general that have had to face this prejudice and fought to be measured and valued by the quality of their work and knowledge.

I really liked the book and the pace of the story. My tactical side related to the accuracy of the depiction of the action and the weapons and my info sec side related perfectly with main characters and their frustrations with government and industry and the drive that pushed them. I even related with the Russian character personas and the choices that many starting in the security field are faced with in term of the direction our research takes and the consequences of those decisions and what may drive many to make the wrong ones.

I recommend this book to any security professional in the industry and to any person who likes the action and intrigue found in Tom Clancy and Alex Berenson books. I do hope that Mark writes another one like this and gives further life to the characters behind this book.

Book on Amazon

Many times we are faced with the situation of not being able to patch software in time and many times do to the way companies work and handle security vulnerabilities the time of exposure is a very long one. Microsoft has worked in to making it harder for attacker to exploit code by adding in to the operating system and to several of their products mitigating technologies, but sadly not all Microsoft products or third party products use these mitigating technologies. To help with this Microsoft released the Enhanced Mitigation Experience Toolkit. This toolkit include several pseudo mitigation technologies aimed at disrupting current exploit techniques, it is not a perfect solution in terms that it can make it harder for known techniques used out there, so this makes this toolkit very effective in managing risk. It provides 7 protections:

Structure Exception Handler Overwrite Protection (SEHOP)

• Dynamice Data Execution Prevention (DEP) Application Level
• Dynamice Data Execution Prevention (DEP) System Level
• Heapspray Allocations
• Null Page Allocation
• Mandatory Address Space Layout Randomization (ASLR)
• Export Address Table Access Filtering (EAF)

This options are not present on all Operation Systems

 

 

Also depends on the CPU

 

 

As it can be be seen from the table, the latest the OS the more protection can be used. The advantage of EMET is that many applications have to be compiled with proper flags and libraries to be able to use these protections, but with EMET they can be forced at the system and application level. With attackers moving more and more to client side attacks and with many companies dependent on applications that many times can not be updated do to the vendor not supporting them on newer versions of Windows, patches taking to much time or just plain quality problems from the company that programed the tool.

Once you install the tool the main screen is very Spartan in terms of information given:

You can see 2 configuration areas the top part for configuring the system settings and the lower part for configuring the application protection settings. The System configuration

You can select one of 2 recommended profiles:

• Maximum Security
• Recommended Security Settings

or you can set each of the protection settings.

You can also configure several protections per application:

You can push the tool to your servers and client systems thru any package manager that can automate the installation thru MSI. The configuration of the programs to add for protection can be automated very easily via the command line:

C:\Program Files (x86)\EMET>EMET_Conf.exe
Usage: EMET_Conf.exe [--list | --add path\program.exe | --delete path\program.ex
e | --delete_all]

I highly recommend this tools for anyone that run Microsoft Windows.

We have a special guest tech segment on Episode 241 tonight with Digital Forensics Solutions' Andrew Case forensically attacking live CDs through physical memory analysis.

You can follow along and watch the show live via the link below:

Let's see what we can do about that claim....

For interactive live video, audio, and chat during each episode you can visit PaulDotCom Live!, just hang out in our IRC channel, tune into PaulDotCom Radio for an audio only version of the show, or if you prefer, visit the Episode 241 show notes page.

- Paul Asadoorian, Larry Pesce, Carlos Perez, Darren Wigley, John Strand and Mike Perez.

"Oh, we got hit by an APT" so therefore, it’s okay. There was nothing we could do. Whaat? If you get some malware, it’s not APT. In fact, we've lost sight of what APT even really means, if the term ever meant anything at all. Here's the thing, it’s about integrity. If you've lost the integrity of your network and/or systems, you've lost. You can't strive to defend against malware, APT, or viruses. You have to defend your network and your data. Focus internally grasshopper, figure out what is important to your business, keep it running, and enforce integrity.

As far as focus, I think we are also missing the point when it comes to our purchasing decisions. Lately, we have had a number of our customers ask us what products we think are best to counter "the APT." Look, security is not about having the right products. When PDC does a penetration test we could care less what security products an organization is using. Many times we don't even know what products they are using until after the test and after we have compromised their networks. The thing that gets us nervous before a test is effective change management. Yep, sucks don't it? You see, effective change management shows that your organization has made a determination to actually know what is going on with your network. This is the key to security. It is not a product, it is not a test, it is about having the right processes in place to know when something is new or different.

PaulDotCom.. We are here to help!

We get called in on IR gigs and we see the same thing, but in reverse. We see organizations that have no idea what normal traffic, users and systems baselines actually are. If you cannot tell what is normal, there is no way you will be able to effectively tell what is abnormal. If you are in this category, APT- real APT, is going to kick your ass.

Unless you know APT Kung Fu!

Larry and John Strand

Originally discussed during episode 240

John Strand will be teaching Hacker Techniques and Incident Response June 25th-30th in Denver Colorado. This time he will do his best to not get kicked out of the hotel....

What follows is a special guest post from Chris Todd.

We've all heard plenty about the pwnage of HBGary in what has to be the security fail of the year (so
far!). Sure, there are plenty of runners-up and those deserving honorable mention like Comodo, RSA,
Epsilon, and most recently the State of Texas. There were no doubt basic security practices overlooked
in each of those fails. However, the lack of detail around most makes it hard to rank them ahead of
HBGary in the fail awards.

In HBGary we have a security company that sells its services to various three-letter federal agencies, but
then gets totally pwned for mouthing off at "the Anonymous hive." And because Anonymous was intent
on embarrassing them, detail of the attack was readily shared as seen in the excellent article by Peter
Bright at http://arstechnica.com/tech-policy/news/2011/02/anonymous-speaks-the-inside-story-of-the-
hbgary-hack.ars/. Granted, reading some of HBGary Federal CEO Aaron Barr's interactions with those
both inside and outside his organization, one can't help but think he was enough fail all on his own.
However, as you look through the various facets of this attack, one of the key lessons to be learned is
this: Everyone is on the security team.

As we walk through the attack, you can see at least 5 distinct groups who contributed to HBGary's epic
fail. And now, in the general order of fail, these groups are:

1. Management who decided on a custom-built CMS

The hbgaryfederal.com web site used a custom-built content management system (CMS) from a third-
party company. There are a plethora of COTS products used for blogging, news sites, and the like that
have the benefit of a large user base. This in no way makes them problem free, but it does mean they
are more likely to be thoroughly tested for vulnerabilities than a one-of, custom-built product. Even if
the vendor isn't the best at testing it themselves, there is still a better chance another user or security
researcher will find vulnerabilities, report them, and the vendor fix them before they hurt you.

Perhaps there was a good reason HBGary Federal management decided on a custom-built CMS, but the
fact remains that decision was the entry point for the Anonymous attack. Had they gone with a mature,
more secure product, this entire fiasco may have been avoided. Anonymous surely would have exacted
their revenge somehow, but perhaps not with ease or to the degree they did. Every application in your
environment, however seemingly insignificant, must be viewed as a potential target or entry point into
your environment and treated as such from product evaluation to production operation and everywhere
in between.

You are going to like where this is going!

2. Developers/DBAs who built the CMS

The custom-built CMS had a gaping SQL injection hole. The exact URL used to break in was:

http://www.hbgaryfederal.com/pages.php?pageNav=2&page=27

Not terribly complex. This allowed the attackers to grab the user database containing usernames, email
addresses and password hashes. Now the designers of the CMS were not totally clueless when it came
to security - the passwords were not stored in clear text. However, the password hashes were simple
MD5. No iterative hashing. No salting. Bring on the rainbow tables! More on passwords in a moment.

Developers/DBAs were combined here since it's entirely possible there were no actual DBAs involved.
It's pretty simple to just fire up a database and start dumping data in it. Whoever was involved, they
were not sufficiently trained in secure coding practices and database management, or were just
careless, or maybe a little from column A and a little from column B. As with the decision to use a
custom-built CMS, the attack could have been stopped before it started. There is no shortage of
guidance in this area – just check out OWASP. And send your developers there as well.

He has "developer" written all over him

3. Security or test team who didn't find the flaw first... or management again?

I'm actually not sure what the title of this one should be so perhaps this group is not so distinct. Was
it the security or test team that missed the SQL injection flaw in their testing? Did they lack the proper
training (even in a company that sells security)? Were they just careless? Or was it someone higher up
that didn't bother to ensure the work of this third-party was validated, i.e. no security or test team ever
looked at the CMS? Whatever it was, someone, or multiple someones, seriously messed up here.

I thought about also calling out the security team for not catching the attack in time. But let's be honest,
how many organizations actually have a security team that could detect and stop an attack like this
within the few weekend hours it took Anonymous to execute it? Now how about considering that after
the initial SQL injection the targets were in various locations and even in the cloud (ugh, can't believe
I just used that word) that is Google Apps? Steps 2-6 of the incident handling process – identification,
containment, eradication, recovery, and lessons learned – are crucial, but they’re not going to bail you
out if you skip step 1 – preparation.

4. CEO and COO

Pop quiz:
Question 1 - Your password should be kept short and simple so it's easy to remember. True or False?
Question 2 - That simple password should be used everywhere so you never forget it. True or False?

If you answered "true" to either of those questions, please stop reading now. It's time to shut down
your computer, pack it up, return it to the store, and never touch a computer again. It will be better
for all of us. Unfortunately, despite knowing what SHOULD be done with passwords, what IS done with
passwords is often a very different story. This was the case with both HBGary Federal CEO Aaron Barr
and COO Ted Vera. Password hashes taken from the CMS system were easily cracked for both users.

Why? Because they were short and simple - six lower case letters and two numbers. Longer, more
complex passwords are unlikely to be found in rainbow tables even if stored as a simple MD5 hash, but
eight simple alphanumeric characters? No prob! It gets worse. They both used the same password to
access their email, Twitter and LinkedIn accounts. Beyond that, Ted's password gave the attackers ssh
access to support.hbgary.com (more on this in the next item). Aaron's password, however, proved to be
the real jackpot. He was not only a user, but also an admin of HBGary's Google Apps email service. The
attackers could now reset any user's password and read their email. Or impersonate them in a social
engineering attack. Or download and torrent it all. Or all of the above which is exactly what Anonymous
did with HBGary CEO Greg Hoglund's email.

The lesson here is pretty obvious: use long, strong passwords and don't share them across systems!
Following those two simple rules may have limited the damage to simple website defacement.

5. System administrators

A couple of key fails on the part of the support.hbgary.com sys admins made COO Ted Vera's cracked
password more useful than it should have been. First, that password shouldn't have provided external
ssh access. Period. At a minimum, a public/private key pair should have been required for this type of
remote access. However, even this wouldn't have been so bad if not for the second fail - an unpatched
privilege escalation flaw. It's not that a patch wasn't available; it was released for most systems in
November 2010. But in February 2011 it still wasn't applied. Maybe the problem was the patch is only
rated as important? Many sys admins will read "important" as "not critical, got other stuff to do."
Important is a typical rating from vendors for privilege escalation flaws. Can we give an honorary fail to
the vendors here? I digress. Anyway, now with root, the many gigabytes of backups and research data
the attackers could access was promptly purged.

Another sys admin fail came courtesy of Jussi Jaakonaho, Chief Security Specialist at Nokia and an
admin for Greg Hoglund's rootkit.com web site. After a few social engineering emails (using Hoglund's
compromised account), the attackers had root access to this system as well, stealing email addresses
and password hashes (again simple MD5) for everyone who'd ever registered on the site.

The key fail term to remember here is two-factor. It applies to the two-factor authentication that could
have prevented access to support.hbgary.com and the two-factor (or one undisputable factor such
as in person) verification of a person requesting a password reset that could have prevented access
to rootkit.com. These are pretty simple to implement so neither of these compromises should have
happened. In fact, even the email compromise could have been limited if two-factor authentication
(offered to Google Apps customers since September of 2010) was in place for at least admin access to
the service.

Somehow.. We should have seen this coming.

Pwnage complete.

Did we miss anyone? Perhaps the janitor, but how he can be socially engineered into lending his
swipe card is a topic for a different day. We clearly see from HBGary's misfortune that security really is
everyone's responsibility. Had any one of the groups above done their job correctly, the damage could
have been limited.

Everyone having knowledge of basic security practices is necessary, but it's not enough. You all passed
the pop quiz, right? I'm sure Aaron and Ted would too.

Everyone needs to understand why what they do really matters to an organization’s overall security
posture. Ask the CMS developers or whoever decided to go with a custom-built CMS in the first place if
they believe this.

Everyone needs to appreciate that one careless or lazy move on their part, especially when combined
with careless or lazy actions of others, can have dire consequences. Configuring ssh to use public key
cryptography takes about 2 minutes per user. A phone call takes 1. Would that have been too much to
ask of the sys admins?

Everyone needs to act with the care and rigor of a finely tuned security team.

Everyone needs to appreciate that they play an integral part in securing their organization.

Everyone is on the security team.

Welcome to episode 240...

Here we have a tech segment on Web Labyrinth

While it was a quiet week we drink and do the news anyway.

Episode 240 Show Notes

Episode 240 Direct Audio Download

All the Pauldotcom Security Weekly episodes on our Bliptv archives.

Hosts: Paul "PaulDotCom" Asadoorian,John Strand,Larry Pesce

Audio Feeds:

There is a bug report requesting the installation of another root CA for Honest Achmed's Used Cars and Certificates with the purpose of: "The purpose of this certificate is to allow Honest Achmed to sell bucketloads of other certificates and make a lot of money." In response to Mozilla's CA practices? "Honest Achmed promises to abide by these practices. If he's found not to abide by them, he'll claim it was a one-off slip-up in procedures and that policies have been changed to ensure that it doesn't happen again. If it does happen again, he'll blame it on one of his uncles or maybe his cousin, who still owes him some money for getting the car fixed." Nice, now, I'm not sure why it was denied, as it seems just as legit of a practice as any of the other CA's, but Achmed is at least honest about it…

And if you cant trust Achmed... Who can you trust?

There seems to be a lot of swirl about SSL these days. From Moxies article to this one, I hope there is some sort of critical move as a community being reached that will start to get us thinking about how we are going to begin fixing this system. After all, it was a system that was thrown together by the fine folks at Netscape, but it is starting to see some strain. There have been a number of attacks against the implementation of the protocol and the people who run the CAs. Although, while it is fun to stand up and say this protocol is insecure and something needs to be done, look at the other protocols we depend on. ARP is still a huge security nightmare and has been for years. Sure, Dan found a massive hole in DNS and people fixed it, but Dan is one of the first people to say it is only a temporary fix and we need to move to something more secure fast. Wrights law is in play. Nothing gets fixed until there is an exploit available in a tool like Metasploit.

Larry and John Strand

Originally discussed during episode 240

John Strand will be teaching Hacker Techniques and Incident Response June 25th-30th in Denver Colorado. This time he will do his best to not get kicked out of the hotel....

Subtitle: Don't second guess Josh Wright & Scapy rocks

Tim Tomes (http://lanmaster53.com/) and I were asked to do a penetration test on a network with some 802.1X protection. I had a good bit going on at the time and Tim got to do all the hands on fun stuff (No.. I'm not bitter). We talked about attack strategies and bounced some ideas off each other on how to p0wn the network. While he did all the hands on, I got to write some code to help out.

Tim needed to do some brute force attacks against a 802.1X authentication packet that he captured, but there isn't a tool out there to do that.     xtest does dictionary attacks, but not brute forcing.  He mentioned that SANS SEC660 covers a technique for doing it using a modified version of xtest to read passwords from STDIN. I said, "You don't need to modify xtest.. just create a FIFO queue and read from there.". So I dropped to a terminal and did something like this...

root@bt:/pentest/passwords/jtr# mknod pwque p
root@bt:/pentest/passwords/jtr# ./john -i:ALL --stdout > pwque &
root@bt:/pentest/passwords/jtr# ~/xtest-1.0/xtest -w ./pwque -c ~/xtest-1.0/sample-pcaps/7971G-EAP_Success.pcap

It doesn't work. Lesson learned: Don't question Josh Wright. There is a reason he rewrote part of the code. Both Tim and I are chomping at the bit to take SEC660, but we haven't yet so we didn't have access to the Josh's modifications. Looking through the xtest code you can see a loop in "utils.c" in the password_discovery() function that looks like this...

/* Calculate Total Number of passwords for attack */
while( fgets(passwd, sizeof(passwd), in_file) != NULL ) {
wordcount++;
}
rewind(in_file);
printf("[+] Attempting Dictionary Attack with %d passwords of the dictionary %s\n",wordcount,dictFile);

while( fgets(passwd, sizeof(passwd), in_file) != NULL ) {

wordcount++;

}

rewind(in_file);

printf("[+] Attempting Dictionary Attack with %d passwords of the dictionary %s\n",wordcount,dictFile);

This loop reads the password file until it reaches the end and prints how many passwords it counted in the file. Then it does a "rewind" to start back at the beginning of the file with its guessing. That doesn't work if you are brute forcing something and there is no end to of file. Remove ALL those lines of code and recompile so you can use the FIFO file object to brute force as input. After making that change the commands above works properly.   (Note:  Alternatively, you can use Josh's patch.  Josh Wright was nice enough to email me his xtest patch.  You can download it here: xtest-stdin-warnfix.diff )

xtest can do more than just brute-force a EAP-MD5 hash in a packet capture and I kind of like having my password count in my output (the code we removed).  Tim said, "I bet SCAPY would make writing an EAP-MD5 brute-force pretty simple". He was right. With SCAPY parsing packets is trivial. Writing an EAP-MD5 brute-force tool only requires a few lines of code.

Submitted for your approval: eapmd5crack.py

The tools accepts a packet capture containing an EAP-MD5 challenge and response and does a dictionary attack to determine the password. You can also use a FIFO queue to brute-force passwords with JTR.

Here is a sample run using a dictionary:

Download it here: eapmd5crack.py

Paul and Larry spent The Ultimate Spring Break at SourceBoston, and have come back for a special report on the conference which you can catch this Thursday night April 21st on Episode 240 by watching live:

For interactive live video, audio, and chat during each episode you can visit PaulDotCom Live!, just hang out in our IRC channel, tune into PaulDotCom Radio for an audio only version of the show, or if you prefer, visit the Episode 240 show notes page.

- Paul Asadoorian, Larry Pesce, Carlos Perez, Darren Wigley, John Strand and Mike Perez.

Adrian "IronGeek" Crenshaw talks about his violation and penetration with his USB stick.

Then Security news... drunken style... cause there really is no other way.

Episode 239 Show Notes

Episode 239 part 2 Direct Audio Download

All the Pauldotcom Security Weekly episodes on our Bliptv archives.

Hosts: Paul "PaulDotCom" Asadoorian,John Strand,Larry Pesce

Audio Feeds:

Thanks to KJo for pointing this out to us. So, why is it important? Well, SQLmap is an awesome tool, but it takes some understanding to figure out all of your command line options. However 0.9 now has a command line driven WIZARD, that makes getting your feet wet much easier. I plan to check this out on some of my upcoming assessments.

We also thought it would be fun to go over some of the features that simply rock about this tool.

First is the support for blind, time-based and error based SQL injection. There are so few tools that get any one of these right, it is cool that it covers all three.

The second thing we like about this tool is that it kicks the ass of many of the commercial vendors when it comes to SQL injection capabilities. Because, you know, it is free. And, free is good.

Except when it is LIES!!!

I also like how it can parse targets from a Burp requests log file. Seriously, we have a perverse kind of love for Burp. It is kind of cool that now I can integrate two of my all-time favorite web testing tools.

Also, is supports user-agents. I know this seems boring to a number of you, but think of it like this; does the site you are testing have the same security features for an iphone accessing the site as a normal web browser session?

Who's the pimp who loves user agent strings? This guy!

Finally, it integrates with Metasploit. Seriously, this is awesome.

So, congratulations to the SQLMap team on a job well done.

Larry and John Strand

Originally discussed during episode 239

John Strand will be teaching Hacker Techniques and Incident Response June 25th-30th in Denver Colorado. This time he will do his best to not get kicked out of the hotel....

Here is what you have been waiting all week for episode 239 part 1. Dave Kennedy and Adrian 'IRON GEEK' Crenshaw, PureHate and SecMania all join us to tell us about derby con and why you all should go. And we have an actual girl with us live in studio. You should download this episode and find out who.

Episode 239 Show Notes

Episode 239 part 1 Direct Audio Download

Videos of all the Pauldotcom Security Weekly episodes are available on our Bliptv Channel and in iTunes.

Hosts: Paul "PaulDotCom" Asadoorian,John Strand,Larry Pesce

Audio Feeds:

Video Feeds:

What do you get when you combine PureHate, SecMania, and IronGeekery? You get tonight's episode with the founders of a new era of hacker con: DerbyCon! Then stay on to hear Adrian "IronGeek" Crenshaw's presentation "Malicious USB Devices: Is that an attack vector in your pocket or are you just happy to see me"?

Catch the PaulDotDerbyCon party tonight on Episode 239 by watching live:

For interactive live video, audio, and chat during each episode you can visit PaulDotCom Live!, just hang out in our IRC channel, tune into PaulDotCom Radio for an audio only version of the show, or if you prefer, visit the Episode 239 show notes page.

- Paul Asadoorian, Larry Pesce, Carlos Perez, Darren Wigley, John Strand and Mike Perez.

A 75-year old woman took a shovel to a fiber cable and took out Internet access to my home country of Armenia. Georgia, who provided the Internet access says, "We don't how she found the optic cable, which was secure".

Hint: She may have found it like this

Funny how people have a different view of what "secure" means. Physical security is important! Here's the thing, while it may be exploited less than attacks coming across the Internet, its typically far more damaging.

Also, it is rumored that they are going to press charges against the lady. What the hell? She was just a scavenger looking for copper to sell so she could feed her family. I think charges should be brought against the company for not burying the cable more the 4" deep. Because, burying it more then 4" is important.

Yea.. We know..

Thats what she said..

Speaking of disappointment. You should join us for the show tonight.

PaulDotCom and John Strand

Originally discussed during episode 238

John Strand will be teaching SANS 660 Advanced Network Penetration Testing and Metasploit for Penetration testers This April in Reston, VA April 15 - 23.

Security Onion is based on Xubuntu 10.04 and contains Snort, Suricata, sguil, Vortex IDS, Bro IDS, nmap, metasploit, scapy, hping, netcat, tcpreplay, and many other security tools.

What can it be used for?
-The Security Onion LiveDVD can be used for Intrusion Detection. Simply boot the DVD, double-click the Setup desktop shortcut, and follow the prompts. Once Setup completes, then double-click the Sguil desktop shortcut to launch the GUI and view/investigate the alerts. (This is fine for temporary or demo environments, but production environments should not run from the LiveDVD environment. See installation information below.)
-The Security Onion LiveDVD can be used to test an Intrusion Detection System. Simply boot the DVD and use the included tools (such as nmap, scapy, hping, metasploit, and others) to test your existing IDS or to test the included Snort and Suricata IDS/IPS engines.
-The Security Onion LiveDVD can be used to install an Intrusion Detection System. Simply boot the DVD and choose the Install option in the Boot Menu or boot into the full live Desktop and double-click the Install desktop shortcut. Once you've completed the installation process and have rebooted into your new installation, you will want to install any available Ubuntu updates and then double-click the Setup desktop shortcut to configure Security Onion.

How do I get it?
Download the ISO image from here.

How do I create a Sguil server?
You have three options:
1. Launch Setup and choose "Quick Setup". This will install a Sguil server AND create a Sguil sensor for each ethernet interface on the server.
2. Launch Setup, choose "Advanced Setup", and choose "Both". This will install a Sguil server AND create a Sguil sensor for each ethernet interface on the server, but will give you more options than "Quick Setup".
3. Launch Setup, choose "Advanced Setup", and choose "Server". This will just install a Sguil server.

How do I create a Sguil sensor?
Launch Setup, choose "Advanced Setup", and choose "Sensor". Enter the name/address of the Sguil server and a username that has sudo permissions on the server. A terminal window will appear prompting you to login to the server to complete the server configuration.

Demo
Download the latest ISO image from here.
Boot the Security Onion ISO and choose Install from the boot menu.
Standard Ubuntu installer appears. Follow the prompts to complete your installation.
Reboot into your new Security Onion installation and login using the username/password you specified in the previous step.
Double-click the Setup desktop shortcut.
Administrative password prompt appears. Enter your password and click OK.


Welcome screen appears. Press Enter.


Quick Setup screen appears. Press Enter.


Username screen appears. Enter your desired Sguil username and press Enter.


Password screen appears. Enter your desired Sguil password and press Enter.


Password confirmation screen appears. Confirm your desired Sguil password and press Enter.


Settings confirmation screen appears. Press Enter.


Setup creates the Sguil server and sensors and then starts all services.








Setup Complete screen appears. Press Enter.


Double-click the Sguil desktop shortcut. Login window appears. Enter the Sguil username/password you specified in Setup.


Sensors window appears. Click "Select All" and then click "Start Sguil".


Sguil main window appears. Simulate an attack by going to a terminal and typing "curl http://testmyids.com".


A new alert should appear in the Sguil window. Notice that the sensor is named server-eth0, where "server" is the hostname and "eth0" is the interface that saw the traffic.


We've now verified that the Sguil server is running correctly. Let's go to our second machine and build a sensor.
Boot the Security Onion ISO and choose Install from the boot menu.
Standard Ubuntu installer appears. Follow the prompts to complete your installation.
Reboot into your new Security Onion installation and login using the username/password you specified in the previous step.
Double-click the Setup desktop shortcut.
Administrative password prompt appears. Enter your password and click OK.


Welcome screen appears. Press Enter.


Quick Setup screen appears. Click "No, use Advanced Setup".


Components screen appears. Click "Sensor" and click "OK".


Server Hostname screen appears. Enter server hostname/address and press Enter.


IDS Engine screen appears. Press Enter.


Interfaces screen appears. Select your desired interface(s) and click OK.


Confirm Settings screen appears. Click "Yes, proceed with the changes!".


Terminal appears prompting to accept SSH key of server. Type "yes" and press Enter.


Password prompt appears. Enter password and press Enter.


Sudo prompt appears. Enter password and press Enter.


Setup creates the Sguil sensor(s).


Setup starts all Sguil services.


Setup Complete screen appears. Press Enter.


Simulate an attack by opening a terminal and typing "curl http://testmyids.com".


At this point, we can return to our server. In the Sguil window, click File and then click "Change monitored networks".

Sensor selection window appears. Notice that there are new sensors named sensor-eth0, sensor-eth1, sensor-eth2, and sensor-ossec. Select the new sensors and click "Start Sguil".


Click the "Agent Status" tab and verify that the the new sensors are checking in.


Notice that there is a new alert with a sensor name of sensor-eth0, where "sensor" is the hostname of the sensor and "eth0" is the interface which saw the traffic.


In this blog post, we've demonstrated how Security Onion can build an army of distributed IDS sensors in just a few minutes. For more information, please visit http://securityonion.blogspot.com.

-Doug Burks

Scapy is a library for python designed for the manipulation of packets, in addition we can forge or decode packets of a wide number of protocols, send them on the wire, capture them, match requests and replies, and much more. It is a Swiss army knife of packet manipulation in python. It can be ran interactively or as part of a script.

In this blog post I will cover how to use one of the new parsers  to parse CDP packets included in version 2.2 of scapy. Cisco Discovery Protocol (CDP) is a proprietary Layer 2 Data Link Layer network protocol used to share device information with devices connected on the same subnet. Even do most new networks are migrating to Link Layer Discovery Protocol (LLDP) the Cisco Discovery Protocol is in used by many, even both protocols are enabled at the same time on cisco switches and routers to provide interoperability with third party equipment from HP and Juniper.

In our case we will focus on CDP. The first thing to do is to make sure that we are running the latest version of scapy since during my experimentation with Scapy and CDP I summited several bug reports and they where quickly fixed after the release of version 2.2. So do make sure you are running the latest dev version by downloading and installing from the Mecurial repository used by the project at http://trac.secdev.org/scapy

Once install we can just run from the command prompt in Linux the command scapy an enter in to the interactive shell so we can see what info we can gain from a capture CDP Packet in a pcap file. Lets start the shell:

carlos@infidel01:~/Development/scapy$ ./run_scapy
WARNING: No route found for IPv6 destination :: (no default route?)
Welcome to Scapy (2.2.0-dev)
>>>

The next thing we need to do is list the contributed libraries that came with Scapy 2.2 this is achieved with the call list_contrib():

>>> list_contrib()
vqp                 : VLAN Query Protocol                      status=loads
cdp                 : Cisco Discovery Protocol                 status=loads
ripng               : RIPng                                    status=loads
skinny              : Skinny Call Control Protocol (SCCP)      status=loads
igmpv3              : IGMPv3                                   status=loads
ubberlogger         : Ubberlogger dissectors                   status=untested
dtp                 : DTP                                      status=loads
bgp                 : BGP                                      status=loads
rsvp                : RSVP                                     status=loads
wpa_eapol           : WPA EAPOL dissector                      status=loads
mpls                : MPLS                                     status=loads
ospf                : OSPF                                     status=loads
chdlc               : Cisco HDLC and SLARP                     status=loads
etherip             : EtherIP                                  status=loads
avs                 : AVS WLAN Monitor Header                  status=loads
ikev2               : IKEv2                                    status=loads
igmp                : IGMP/IGMPv2                              status=loads
vtp                 : VLAN Trunking Protocol (VTP)             status=loads
eigrp               : EIGRP                                    status=loads
>>>

As it can been support for several new protocols was added. we can also see that some of them load and others are untested. This protocols are contributions by external developers to the project. To load the support for CDP we just issue the command load_contrib()

>>> load_contrib("cdp")
>>>

I have a pcap file on the same folder with CDP packets in it so we can have a look at how they look, to read the packets we use the rdpcap() call to read them in to a variable.

>>> cdp_pkts = rdpcap("cdp.cap")
>>> len(cdp_pkts)
16

As it can be seen there are 16 packets in this capture. Lets take a look at the first packets:

 

>>> cdp_p = cdp_pkts[1]
>>> cdp_p
<Dot3  dst=01:00:0c:cc:cc:cc src=00:19:06:ea:b8:85 len=386 |<LLC  dsap=0xaa ssap=0xaa ctrl=3 |<SNAP  OUI=0xc code=0x2000 
|<CDPv2_HDR  vers=2 ttl=180 cksum=0xb0bd msg=[<CDPMsgDeviceID  type=Device ID len=10 val='Switch' |>, <CDPMsgSoftwareVersion 
type=Software Version len=196 val='Cisco IOS Software, C3560 Software (C3560-ADVIPSERVICESK9-M), Version 12.2(25)SEB4, RELEASE
 SOFTWARE (fc1)\nCopyright (c) 1986-2005 by Cisco Systems, Inc.\nCompiled Tue 30-Aug-05 17:56 by yenanh' |>, <CDPMsgPlatform  
type=Platform len=24 val='cisco WS-C3560G-24PS' |>, <CDPMsgAddr  type=Addresses len=17 naddr=1 addr=[<CDPAddrRecordIPv4  
ptype=NLPID plen=1 proto='\xcc' addrlen=4 addr=192.168.0.1 |>] |>, <CDPMsgPortID  type=Port ID len=22 iface='GigabitEthernet0/5' 
|>, <CDPMsgCapabilities  type=Capabilities len=8 cap=Switch+IGMPCapable |>, <CDPMsgProtoHello  type=Protocol Hello len=36 
val='\x00\x00\x0c\x01\x12\x00\x00\x00\x00\xff\xff\xff\xff\x01\x02!\xff\x00\x00\x00\x00\x00\x00\x00\x19\x06\xea\xb8\x80\xff\x00\x00' 
|>, <CDPMsgVTPMgmtDomain  type=VTP Mangement Domain len=7 val='Lab' |>, <CDPMsgNativeVLAN  type=Native VLAN len=6 vlan=1 |>,
<CDPMsgDuplex  type=Duplex len=5 duplex=Full |>, <CDPMsgGeneric  type=Trust Bitmap len=5 val='\x00' |>, <CDPMsgGeneric  
type=Untrusted Port CoS len=5 val='\x00' |>, <CDPMsgMgmtAddr  type=Management Address len=17 naddr=1 addr=[<CDPAddrRecordIPv4  
ptype=NLPID plen=1 proto='\xcc' addrlen=4 addr=192.168.0.1 |>] |>, <CDPMsgGeneric  type=Power Available 
len=16 val='\x00\x00\x00\x01\x00\x00\x00\x00\xff\xff\xff\xff' |>] |>>>>
>>>

We can see that each packet has I’s fields clearly defined. if we do an ls() on the packet we can get them in a more readable format:

>>> ls(cdp_p)
dst        : DestMACField         = '01:00:0c:cc:cc:cc' (None)
src        : MACField             = '00:19:06:ea:b8:85' ('00:00:00:00:00:00')
len        : LenField             = 386             (None)
--
dsap       : XByteField           = 170             (0)
ssap       : XByteField           = 170             (0)
ctrl       : ByteField            = 3               (0)
--
OUI        : X3BytesField         = 12              (0)
code       : XShortEnumField      = 8192            (0)
--
vers       : ByteField            = 2               (2)
ttl        : ByteField            = 180             (180)
cksum      : XShortField          = 45245           (None)
msg        : PacketListField      = [<CDPMsgDeviceID  type=Device ID len=10 val='Switch' |>, 
<CDPMsgSoftwareVersion  type=Software Version len=196 val='Cisco IOS Software, C3560 Software 
(C3560-ADVIPSERVICESK9-M), Version 12.2(25)SEB4, RELEASE SOFTWARE (fc1)\nCopyright (c) 1986-2005 
by Cisco Systems, Inc.\nCompiled Tue 30-Aug-05 17:56 by yenanh' |>, <CDPMsgPlatform  type=Platform l
en=24 val='cisco WS-C3560G-24PS' |>, <CDPMsgAddr  type=Addresses len=17 naddr=1 addr=[<CDPAddrRecordIPv4  
ptype=NLPID plen=1 proto='\xcc' addrlen=4 addr=192.168.0.1 |>] |>, <CDPMsgPortID  type=Port ID len=22 
iface='GigabitEthernet0/5' |>, <CDPMsgCapabilities  type=Capabilities len=8 cap=Switch+IGMPCapable 
|>, <CDPMsgProtoHello  type=Protocol Hello len=36 val='\x00\x00\x0c\x01\x12\x00\x00\x00\x00\xff\xff\xff\xff\x01\x02!\xff\x00\x00\x00\x00\x00\x00\x00\x19\x06\xea\xb8\x80\xff\x00\x00' |>, <CDPMsgVTPMgmtDomain  type=VTP Mangement Domain len=7 val='Lab' |>, <CDPMsgNativeVLAN  type=Native VLAN len=6 vlan=1 |>, <CDPMsgDuplex  type=Duplex len=5 duplex=Full |>, <CDPMsgGeneric  type=Trust Bitmap len=5 val='\x00' |>, <CDPMsgGeneric  type=Untrusted Port CoS len=5 val='\x00' |>, <CDPMsgMgmtAddr  type=Management Address len=17 naddr=1 addr=[<CDPAddrRecordIPv4  ptype=NLPID plen=1 proto='\xcc' addrlen=4 addr=192.168.0.1 |>] |>, <CDPMsgGeneric  type=Power Available len=16 val='\x00\x00\x00\x01\x00\x00\x00\x00\xff\xff\xff\xff' |>] ([])
>>> 

WE can see that as it is expected the destination of all CDP packets is '01:00:0c:cc:cc:cc'  so this will be the easiest way to identify this packets inside a pcap. The CDP fields are saved in the message, each containing a type and we can call each of the values in the type, they are following a TLV (Type Length Value) format.

With this information lets build a script to help us parse pcap files.

Lets start by making sure we have the proper libraries imported:

#!/usr/bin/python
import getopt
import logging
import re
import string
import sys

Each one will server a different purpose for the script:

• getopt – Manage the script options that we will use.
• logging – Control any warning or error messages generated by the scapy library.
• re – Regular expression library.
• strings – Manage string objects
• sys – Provides access system specific parameters.

Next we will import the scapy 2.2.0-Dev library and set the logging lever to errors only, this will eliminate the “No IPv6 Route” warning message that may show for those running the script on systems without proper IPv6 configurations.

# suppress the no route warning in scapy when loading
logging.getLogger("scapy.runtime").setLevel(logging.ERROR)
# import scapy
from scapy.all import *

I like the use of a usage function in my code so I can call it anytime a user enters a wrong parameter, no parameter or simply does –h for help on the script. We will create this function now:

def usage():
    """
    Function for presenting usage of the tool.
    """
    print "CDP Parse by Carlos Perez carlos_perez@darkoperator.com"
    print "Tool for printing to STDOUT information on CDP packets found capture"
    print "file. Will print all supported options.\n"
    print "cdp_parser.py <OPTIONS>"
    print "-F <dir>  Directory containing pcaps."
    print "-f <pcap> pcap file."

Now lets create our function to process each packet and print the info to standard out:

 

  1: def process_packets(pkts):
  2:     """
  3:     Function for processing packets and printing information of CDP Packets
  4:     """
  5: 
  6:     for p in pkts:
  7:         # Check if the packet is a CDP Packet
  8:         if Dot3 in p and p.dst == '01:00:0c:cc:cc:cc':
  9:            
 10:             print "\n*******************************"
 11:             
 12:             print "Source MAC:", p.src
 13:             # Process each field in the packet message
 14:             for f in p[CDPv2_HDR].fields["msg"]:
 15: 
 16:                 # Check if the filed type is a known one
 17:                 if f.type in _cdp_tlv_types:
 18: 
 19:                     # Process each field according to type
 20:                     f_type = _cdp_tlv_types[f.type]
 21: 
 22:                     # Make sure we process each address in the message
 23:                     if re.match(r"(Addresses|Management Address)", f_type):
 24:                         for ip in f.fields["addr"]:
 25:                             print f_type, ip.addr
 26: 
 27:                     elif f_type == "Software Version":
 28:                         print f_type+":"
 29:                         print "\t" + string.replace(f.val, "\n", "\n\t")
 30: 
 31:                     elif f_type == "Port ID":
 32:                         print f_type, ":", f.iface
 33: 
 34:                     elif f_type == "Capabilities":
 35:                         # Ugly but works :)
 36:                         print f_type, ":", "".join(re.findall(r"cap\s*=(\S*)", str(f.show)))
 37: 
 38:                     elif re.match(r"Native VLAN|VoIP VLAN Reply",f_type):
 39:                         print f_type, ":", f.vlan
 40: 
 41:                     elif f_type == "Duplex":
 42:                         print f_type, ":", _cdp_duplex[f.duplex]
 43: 
 44:                     elif f_type == "IP Prefix":
 45:                         print f_type, ":", f.defaultgw
 46: 
 47:                     elif f_type == "Power":
 48:                         print f_type, ":", f.power, " mW"
 49: 
 50:                     # Fields not yet implemented in the current version of the
 51:                     # contributed cdp module.
 52:                     elif f_type == "Power Available":
 53:                         # I know, this should provide the amount of power
 54:                         print f_type, ": POE Enabled"
 55: 
 56:                     elif f_type == "Protocol Hello":
 57:                         pass
 58: 
 59:                     else:
 60:                         try:
 61:                             # Make sure we do not have an empty value and print
 62:                             if f.val is not '\0' and len(f.val) != 0: print f_type, ":", f.val
 63: 
 64:                         except Exception, e:
 65:                             print "ERROR!!!!:", f_type
 66:                             print e
 67:                             print "Send error to: carlos_perez[at]darkoperator.com"
 68:                             pass

on line 1 we declare our function and we set the pkts variable as the input for the function. On line 6 we are going to iterate thru each of the packets found the in the packet list we give the function, next on line 8 we check the destination of each packet to see if they are '01:00:0c:cc:cc:cc' then they are CDP packets and we can proceed to parse them, on line 12 we will print the source MAC Address.

On line 17 we check if it is a know type that we can parse, if not we skip the type, In my testing I did not find any it could not do bust just in case Cisco adds one in the future or the packet has an error I added this line, specially since some vendors like HP had CDPv1 support and did some extensions. Next on line 20 we get from hex to text the type name of the field by checking against the _cdp_tlv_types dictionary that is part of the CDP library.

Now from line 22 to line 54 we parse each type for which we know the name of the field and do not follow the stand name of val like the rest.

From lines 56 and 57 we skip the Protocol Hello type since it just prints a bunch of garbage for this type, still working on how to dissect this type.

If the type is not known we try to parse the TLV data and if an exception occurs an error is raised and my email is provided to sent the error to so I can work on improving the script this happens from lines 59 to 68.

The next step is to create the main function that will handle options, open the pcap files and feed the packets to the function we just created.

 

  1: def main():
  2: 
  3:     try:
  4:         # Check version
  5:         if not re.match(r"2\.[2-9]\.\S*", config.conf.version):
  6:             print "You are not running the latest scapy release."
  7:             print "Please go to http://trac.secdev.org/scapy and follow the"
  8:             print "the instructions to download the latest versions."
  9:             sys.exit(1)
 10: 
 11:         # load the support for CDP Packets
 12:         load_contrib("cdp")
 13: 
 14:         # Set Variables for Options
 15:         folder = None
 16:         pcap_file = None
 17:         pcap_files = []
 18: 
 19:         # Check that options are given
 20:         if len(sys.argv) == 1:
 21:             usage()
 22: 	      sys.exit(1)
 23: 
 24:         # Set Options
 25:         options, remainder = getopt.getopt(sys.argv[1:], 'F:f:h')
 26: 
 27:         # Parse Options
 28:         for opt, arg in options:
 29:             if opt in ('-F'):
 30:                 folder = arg
 31:             elif opt in ('-f'):
 32:                 pcap_file = arg
 33:             elif opt in ('-h'):
 34:                 usage()
 35: 		sys.exit(0)
 36:             else:
 37:                 usage()
 38: 		sys.exit(1)
 39: 
 40:         # Process folder with pcap files
 41:         if folder:
 42:             if os.path.isdir(folder):
 43:                 for item in os.listdir(arg):
 44:                     fullpath = os.path.join(arg, item)
 45:                     if os.path.isfile(fullpath) and ('.cap' in item or '.pcap' in item or '.dump' in item):
 46:                         pcap_files.append(fullpath)
 47:             else:
 48:                 print "ERROR:", folder, "does not exists!"
 49:                 sys.exit(1)
 50: 
 51:         # Process single pcap file
 52:         if pcap_file:
 53:             if os.path.isfile(pcap_file):
 54:                 pcap_files.appemd(pcap_file)
 55:             else:
 56:                 print "ERROR:",pcap_file,"does not exist!"
 57:                 sys.exit(1)
 58: 
 59:         # Process all files selected and extract CDP Info
 60:         for f in pcap_files:
 61:             pcap = rdpcap(f)
 62:             process_packets(pcap)
 63:     except Exception, e:
 64:         print e
 65:         print "Send error to: carlos_perez[at]darkoperator.com"
 66:         pass
 67: 
 68: if __name__ == '__main__':
 69:     main()

In the main function at line 5 we do a scapy version check making sure we are running a version equal or above 2.2.x, if not we print a message indication that the wrong version is being used and to upgrade to the latest development version.

On line 11 we load the contributed CDP Parser. this has to be loaded before we read the packets since they will be ran against it when read.

In lines 14 to 17 we set the option variables that we will use for the script.

From lines 19 to 22 check that options are given, if none is given we print the usage message and exit.

From lines 24 to 38 we parse the options and set the variables, if an option does not match our list of options we exit with an usage message.

From lines 41 to 49 we check if the folder option is set, if it we check that the folder exists and if it does we list the content of the folder and save the full path of each capture file found in to a list for use.

From lines 52 to 57 we check if a pcap file is specified, if it is we check that the file actualy exist and we save the full path to it in to the the same list we we saved the files for the folder, so both options can be used at the same time.

From lines 60 to 62 we parse each file on the list of files collected, read the packets and pass those to the process_packet function to process them.

This is a very simple simple, I tried my best to explain each part of it so for those starting with python and playing with scapy can follow it and learn. You can download the whole script at cdp_parser.py

-Carlos

If you have never used this tool, you should. Whether you are testing your own network or doing penetration testing, constantly identifying weak passwords is a must. There are so many breaches, and so many are successful because someone had a weak password. Weak passwords hide, and so many technologies and services have crept into our environments, it’s tough to keep up. Nice patches can be added that will generate passwords and support for all kinds of auth methods, TLS support for more protocols, SASL, and more! We also thought it would be fun to go through our archives and share some of the cool things we have done with Hydra in the past. Waaay Back in Episode 20 Using Hydra was one of our first technical segments. For the record, the text is special "hidden" text. You need to highlight it to see it…. Yeah, that was intentional. Then, Paul and I were working on a penetration test and we wanted to share how to use Hydra in such a way that you would not lock out accounts. This pen test was awesome. We were dealing with an environment that was using LDAP for Linux authentication and we wanted to take a list of passwords that we had cracked from a Windows 2K3 server and try them each individually against a number of user accounts. The goal was to try one password with multiple accounts, and restrict specific passwords to default accounts like root. Worked like a champ. Just a couple of quick tips on using Hydra: 1. Don't use the GUI. It has issues from time to time. 2. Slow down. This is not password cracking. You need to take your time. Throttle back the number of threads and make sweet, slow password love to a service. 3. Practice on test systems first. Create a series of accounts that should be guessable with Hydra. Then run it. If it is working "yeah!" If not, find out why. I was also thinking that this is a great opportunity to say to the guys at THC "Thanks." I don't think we do that enough in this industry. Take a few moments and write an email thanking an author or authors of a free/Open Source tool that makes your life easier. So, here is to the fine developers of Hydra: Who's Awesome? Your Awesome! PaulDotCom and John Strand Originally discussed during episode 238 John Strand will be teaching SANS 660 Advanced Network Penetration Testing and Metasploit for Penetration testers This April in Reston, VA April 15 - 23.

Here is our fabulous 238th episode.

Chris Palmer, the Technical Directory for the EFF, tells us its time to fix SSL:

Ryan Barnett drops us into a XSS street fight:

And of course drunken security news for the week with Paul, Larry, and John. Our best advice in stories is to bury it deep:

Episode 238 Show Notes

Episode 238 Direct Audio Download

All the Pauldotcom Security Weekly episodes on our Bliptv archives.

Hosts: Paul "PaulDotCom" Asadoorian,John Strand,Larry Pesce

Audio Feeds:

Yes, this article suggests not using a firewall. Its a bit scary, I know. The article states: "In many cases a large number of unnecessary and insecure services are running on the network, but are only hidden by a firewall." Aha, so true, something we've discussed a lot in the past. Someone tested this theory, and guess what, they are doing okay (at least as far as they know). Guess what? They used systems hardening? Guess what? They used simple and easy to manage protocols and stayed away from proprietary stuff. Configuration management is important. If you spent more time on configuration management, and borrowed time from firewall management, you'd have a more secure network. If you had a baseline system, and re-imaged systems that did not meet the baseline, you'd have a more secure network.

We have discussed this from a mental-exercise perspective on the show a number of times in the past. While we look at this as an effective mechanism for thinking about attacks and defenses, it is not something we at PaulDotCom recommend. Rather, we have another approach. Anytime someone says, "A firewall/AV/IPS will protect us," they get one free punch in the face. I know what your thinking, "We cant give punches in the face away for free!!" And, I understand. However, I think in the long run it will start to reshape the day you think about securing your applications and systems. And maybe, just maybe people will stop saying security technologies will save them.

At the very least the violence will be satisfying Like sweet, delicious milk..

So, here's your homework: Take a group of systems that exist on your network, figure out what they do, configure them as such, then monitor for changes. Organizations that can do this well will be "resilient to 0day attacks" and "catch the latest malware", with very little help from vendor products. Marcus Ranum tells a great story about the CSO of a major retailer. They use imaging software on all their cash registers. They know exactly what files are created and what behavior is normal. If one falls out of that, makes a random connection or creates new files or processes, its re-imaged immediately.

At the very least, you will be alerted to the change quickly... And that counts for something.. Right?

PaulDotCom and John Strand

Originally discussed during episode 238

John Strand will be teaching SANS 660 Advanced Network Penetration Testing and Metasploit for Penetration testers This April in Reston, VA April 15 - 23.

Chris Palmer from the Electronic Frontier Foundation comes on the show to give us his method of fixing the current Certificate Authority/Comodogate debacle using, of all things, tofu, while Ryan Barnett from Trustwave SpiderLabs challenges you to a XSS Street Fight! We therefore ask you, what do you get when you combine these two topics in one fun filled evening? You get:

As always, you can catch the full glory of Episode 238 by watching live:

For interactive live video, audio, and chat during each episode you can visit PaulDotCom Live!, just hang out in our IRC channel, tune into PaulDotCom Radio for an audio only version of the show, or if you prefer, visit the Episode 238 show notes page.

- Paul Asadoorian, Larry Pesce, Carlos Perez, Darren Wigley, John Strand and Mike Perez.

Deral Heiland joins us for a tech segment on how to use multi-function printers on a pentest.

Then we talk about some security news from the week.

Episode 237 Show Notes

Episode 237 part 2 Direct Audio Download

All the Pauldotcom Security Weekly episodes on our Bliptv archives.

Hosts: Paul "PaulDotCom" Asadoorian,John Strand,Larry Pesce

Audio Feeds:

I almost feel like we need to just keep a running list of sites and companies that have been hacked on a weekly basis. In the past week we have had two fairly sizable compromises come to light.

Or, you can visit and donate to DatalossDB.

First up, mysql.com has been compromised. You'd think they would know better, right? I think it really shows that security is not about knowledge, but about practice. And I'm not talking about going out into the woods and kicking a tree, I mean you have a training schedule that is 6 days a week, and incorporates diet, cardio, internal, and external styles. But that is doing what we know is good for us. Diet and exercise do not sell well because they are free.

Second, Epsilon was compromised. Why do you care? Do you have an account with Best Buy, TiVo, Walgreens, Dell, JPMorgan or Chase? There is a good chance that your email address was compromised if you do.

I just want to do a quick run through of some of the data breaches over the past few months:

Google, Adobe, Dow Chemical, GE, HBGary, Gawker, mysql.com, RSA, Epsilon....

Folks, we need to stop looking at these as stories where we can simply say they should have known better. These are large organizations with security budgets and regular audits falling flat on their faces when confronted with a targeted attack.

Or.. Running away
That would be an equally bad option

These are not simple point events that we can use as cautionary tales whose punch line is consistently, "don't make that mistake." No, this is a trend. We have been talking about this on the show for the past few weeks now. These are not a simple series of compromises. This is proving to us all that:

1. We are preparing our networks for the type of automated malware we saw five years ago. Why? Because the managers making the purchasing decisions today were cutting their teeth in the trenches five years ago.
2. Traditional security technologies (i.e. AV, IDS, Firewalls) have failure points.
3. Our staffs are most likely not trained to deal or even recognize the kind of threats we are facing.t
4. Most penetration testing does not model the attacks we are seeing in the wild.
5. We have job security for a little while longer....
6. Heavy drinking can help!

It is time to focus on trying to know your network and core applications. It is time to play a game. The steps are easy. Step one, put up a network map on your wall at work. Step two, get drunk. Not just slightly drunk, but Charlie Sheen "rush-me-to-the-hospital" drunk. This is an important step. Anything less than this and your tests may be biased. It all has to be very scientific. Step three, stop hitting on the intern. Step four, throw darts at your network map for about an hour or two. Step five, try to go to sleep for a while. At this point it is probably okay to resume hitting on the intern. The job of throwing darts at a network map is over and accuracy is not as critical. When you wake up, most likely dejected and alone, go back to the map. For every dart hole that landed on a server or network device in your network ask yourself what you would do if it was compromised. Would your entire security support structure collapse? What is the normal path users and applications use to access or pass through the device or application? Do we baseline that traffic? Do we have any idea beyond a simple Nessus scan what is on that server or device?

Or, why do I have I-HACKED on my forhead?

It is time to get to know our networks. It is time to stop looking for a series of security products that are bulletproof.

PaulDotCom and John Strand

Originally discussed during episode 237

John Strand will be teaching SANS 660 Advanced Network Penetration Testing and Metasploit for Penetration testers This April in Reston, VA April 15 - 23.

Yes, let’s take these words back damnit! They are so often used incorrectly. Okay, I'm the first to admit, I'm not an expert when it comes to the English language. However, here's my take: First, "cyber" is NOT a noun. I think this is the first golden rule of "cyber" (ha! see, cyber noun is BAD). I've heard people saying things like, "This doesn't apply to "cyber." Cyber should be, first and foremost, a verb, like "cybersex" or "Hey baby, want to cyber?"

"Sure I'm 18, female and interested in your level 45 Paladain."

The grey area for me is using it as an adjective, like "cyberwar," "cyberwarrior," or "cyber attacks." I can see the point, it distinguishes war, warriors, and attacks from guns and ninja swords, to exploits and packets. However, it’s way over used, so please, please limit the usage of it as an adjective. As for the word “hacker,” the rule is simple, you can use it as a noun, "A hacker figured out how to transmit Zigbee packets." You can use it as a verb, "I want to hack my badge." We need to be careful not to use it to describe evil without another adjective. So, "Hackers gain unauthorized access to the bank." I'd prefer "evil hackers," but even then I have trained myself to use the word "attackers" instead.

The reason for my desire for clarity is that the definition of a hacker was someone who simply wanted to know how something worked years ago. Many times this involved breaking things to see how they worked. Also, in the early days of computers getting anything to work together usually involved taking apart other parts and cobbling them together. I remember my father working on old Triad systems and literally using a hack-saw to get what he needed out of them. He was (and still is) nuts and brilliant, and the man loved his hack-saws. The point is that when people call someone else a "hacker," I think of my father cussing and cutting out boards with a cigarette dangling from his mouth, then magically getting the damn thing to work. It was nuts and a bit scary. To this day it is the most impressive computer "hacking" I have ever seen. When someone equates that with a jackass who breaks into a system using a default password I get a bit pissed. The reason we need to fight to get this word back is because we need to show some respect for the people who were getting this "computer" stuff to work before it was cool, before there were Conferences and 20 podcasts on the topic.

Respect for the 3 or 4 of you who know what this is.

And for the record, we do not need to call cyber-criminals (sorry Paul) hackers or even cyber-criminals for that matter. They are quite simply criminals. Do not make them any cooler or diversified than they actually are.

PaulDotCom and John Strand

Originally discussed during episode 237

John Strand will be teaching SANS 660 Advanced Network Penetration Testing and Metasploit for Penetration testers This April in Reston, VA April 15 - 23.

Larry called shenanigans on the Caribou project so we bring them on to talk about it, then Larry decides to flee to Canada to look for real Caribou.

Episode 237 Show Notes

Episode 237 part 1 Direct Audio Download

All the Pauldotcom Security Weekly episodes on our Bliptv archives.

Hosts: Paul "PaulDotCom" Asadoorian,John Strand,Larry Pesce

Audio Feeds:

Join us at 9 PM tonight as Carlos Perez interviews Julio Canto of the Virus Total website. Virus Total is a free file analysis service that allows users to submit possible malware samples and potentially malicious URLs to multiple antivirus engines for investigation.

Join Carlos and Julio as they discuss the history and possible future directions for Virus Total, go over current events, and marvel at the PaulDotCom crew's fascination with Thermite.

For live video, audio, and chat during each episode you can visit PaulDotCom Live!, just hang out in our IRC channel, or tune into PaulDotCom Radio for an audio only version of the show.

- Paul Asadoorian, Larry Pesce, Carlos Perez, Darren Wigley, John Strand and Mike Perez.