Tuesday, December 25, 2012

Hacking the Wiegand Serial Protocol

By Brad Antoniewicz.

"Wiegand" is used to describe a number of different things used within access control systems such as the format in which data is stored on a card, the protocol which is used to transmit the data, and different types of access cards that leverage it. In this blog post we'll focus on targeting the serial protocol while touching on some of the other uses. You'll find Wiegand used in magnetic strip, RFID (proximity card), and various other access card systems

I originally came across Wiegand as part of my Attacking Proximity Card Access Systems talk where I demonstrated attacks against each of the components involved in access control systems. Later on someone told me about Zac Franken, who created Gecko, a sort of Wiegand man in the middle tool. This blog post will implement and expand on Franken's tool using an Arudino.

On the Wire

Wiegand is used to transmit data from the access card reader to the backend controller for processing. It's a super simple protocol consisting of two wires: DATA0 and DATA1. When the reader wants to send a zero, it lowers DATA0 and whenever it wants to send a one it lowers DATA1. Here's what it looks like within an logic analyzer. I've written the one's and zero's in green and translated them to the card values printed on the back of a proximity card.


In a non-lab environment the wires are physically accessible anywhere between the reader and the controller. For a completely unauthenticated user, the easiest way is to pop off the cover of the reader which will expose the two screws. Remove the screws, pull the reader away from the wall, and you'll be able to access the wires. They're usually colored green for DATA0 and white for DATA1. You can also use the power wires (red and black) to power your Arduino.

Capturing Card Values (Skimming)

The first attack that's possible is to capture valid card values as they're being transmitted. The values can then be stored on a memory card off the Arudino or even transmitted wirelessly. The Gecko tool skimmed card values, then when a special replay card was provided, it would repeat a stored card value to the controller.

The Arduino code to implement this is pretty simple. Mike Cook created some basic code that places an interrupt on the wires, so when there is a change, the interrupt function will be called. I leveraged this technique in my Arduino code too. The skimmed card values are sent via the Arduino's serial interface.

The Skimmer is implemented in the emulator code in the next section.

Emulating Card Values

Something that's obvious but for some reason overlooked is that with direct access to the Wiegand interface, you can bypass all reader-level security. For instance, there are certain proximity cards that implement RFID authentication, encryption, and replay protection. In most cases this security is in place to protect the card value stored on the card. If you can somehow obtain a card value, it can be replayed via wiegand without ever considering the reader to human interface. This even extends to biometrics.

Furthermore, if you add a wireless component to your Arudino setup, you can wirelessly provide those card values. Here's the code:

Brute Forcing Values

Another interesting idea is brute forcing values. There may be times that you have a valid (or once valid) card value and you need a card value with higher privileges (e.g. access to restricted areas). Due to the way certain card formats (e.g. 26-bit format) distribute card values, with knowledge of one card, you could determine other card values with a simple incremental brute force. This technique can be also be applied to the reader interface, but because of the delay between reads, you can only get about one read a second. Using the Weigand interface, you can get 5!

Here's the code:


Don't forget that both the controller and the backend system process the values received via Wiegand. This gives us two potential targets to fuzz. Although the test cases are pretty limited: length, raising DATA0 and DATA1 at the same time, raising the two for a long time, etc... It's still worthwhile to fuzz - if you get a crash, you can potentially implement the trigger in a RFID or magstripe card, and crash the system from reader's interface!!

I implemented a basic fuzzer using the Arudino:


As mentioned, you can expand upon all of this by adding wireless capabilities. Another cool thought is that because all of this is on an Arduino, you can easily communicate with it via a cell phone, making things really inconspicuous :)

Got any more ideas on expanding this? Let us know in the comments down below!!

Tuesday, December 11, 2012

Testing Your Defenses - Beaconing

By Tony Lee.

You have invested time, effort, and money in defenses. But, how do you know they are working? Unless you are willing to intentionally get owned or you want to introduce a piece of malware into your environment, you need safe and effective ways to test your visibility. This article will discuss beaconing — what it is, how it works, and how you might be able to detect it. As a bonus, at the end of the article, we will provide some benign sample source code and programs that you can use to test your beacon detection capabilities.

What is a beacon?

A beacon is traffic leaving the inside of a network at regular intervals—it is also called a heartbeat. Beacons can be used for a variety of purposes such as obtaining new orders from a command and control (C&C) server as well as to download updates or other tools. Functionality depends on the goal of the attacker and the stage in the attack. In the example traffic image below, the beacons are in red and normal traffic is in blue. Notice that the beacons occur every two hours all day and are harder to find when traffic volume is higher (between the hours of 5AM and 8PM).

How does a beacon work?

A beacon can use any protocol; however, the most prevalent would probably be HTTP or HTTPS. This is most common because egress rules typically allow these protocols out of the network. After all, every employee needs to be able to access their Facebook page and YouTube from their work PC. :) Increasingly, we are seeing attackers using encryption for their C&C and data transfers—thus the use of HTTPS is on the rise.

Beacons can attempt to communicate with a single URL or multiple URLs. For more complex stagers, multiple URLs are used which makes it more difficult to detect this behavior. Parameters can be used to trigger different downloads or send different command and control signals. We have even seen a bot beacon out to a C&C server using emoticons to communicate its status.

How might we detect a beacon?

There is a good saying, that “In order to detect abnormal, you must first know what normal looks like.” This is very true in the case of beaconing. If you know that your business hours are from 5am-8pm and you have something calling out of the network during off-hours (as seen in image above)—this could indicate an issue worth investigating. To obtain this baseline of normal though you will probably utilize a security product of some sort… but what are your options?

There are multiple products that may help detect a beacon. While it can be detected at the host level, you probably have a better chance detecting it at the network level. Attackers can easily hide maliciousness on the host via rootkits, but it is much harder to hide from all of the network-based security devices. Additionally, if you have a couple of choke points in your network—it provides a prime opportunity to gain some insight into your network traffic.

These devices include, but are not limited to:
  • Firewalls
  • Web Proxies
  • IDS
  • Malware/anomalous traffic detection appliances
  • Security Information and Event Management (SIEM) solutions


Firewalls can contain vital information in the logs such as the presence of network traffic and the action taken upon that traffic. If the beacon is trying to callout using a port/protocol that is disallowed, it may be easy to detect this constant callout by looking for repeat blocked traffic. Keep in mind that all blocked traffic is not necessarily a beacon and it most often needs to be investigated in order to determine legitimacy. Unfortunately, the larger the network, the more difficult it can be to track down a host and determine the functionality of the host. Knowing the functionality can be instrumental in determining if the traffic is normal or suspicious.

Web Proxies

Web proxies are useful if the beacon is occurring over a supported web protocol. If the beacon is using HTTPS and the traffic is properly intercepted and decrypted by the web proxy, it can provide even more insight as to what is happening. Additionally, the web proxy may be able to provide the user’s name/token that the beacon is utilizing in order to get out of the network. This information can be used to aid in the investigation by providing an opportunity to interview the potential victim.

Intrusion Detection Systems

An intrusion detection system (IDS) can potentially detect this activity if a rule is triggered. This is useful as a layered defense, but the traffic will usually have to be something that is previously known and understood in order for a rule to hit. If the IDS has additional intelligence such as traffic thresholds or trending, then there is a chance it could be detected from this capability.

Malware/Anomalous Traffic Detection

Malware detection appliances go a step beyond traditional IDS by integrating multiple detection mechanisms into one device. McAfee’s Network Threat Response (NTR), for example, uses the following detection mechanisms:
  1. Antivirus definitions
  2. Network signatures
  3. File Reputation (McAfee’s Artemis)
  4. IP reputation (McAfee’s Trusted Source)
  5. Static file analysis
Disclaimer: I work for Foundstone, who is owned by McAfee which sells NTR. However, I am using NTR as an example because I have more experience and familiarity with NTR than I do other tools.


Security Information and Event Management solutions can also help detect the presence of a beacon, but it is usually using logs from one or more of the devices mentioned above. The advantage here is greater visibility by using multiple different types of logs—from hosts to network gear. Additionally, some advanced SIEMs can do trending to detect and understand what is normal and then set thresholds to alert on unusual traffic.

Sample Beacon Code

We have scratched out some sample code for you below. Our example code could use a variety of sites and behavior in order to simulate an attacker; however, we will keep things relatively simple and flexible to allow the tester to define two properties:
  1. URL
  2. Frequency
A more comprehensive test would potentially involve changing the URL and/or the parameters—but we will leave that as an exercise for the reader. Feel free to use the examples below as a code base though.

We have the code up on the Open Security Research GitHub (its also provided below for completeness) and can be cloned by:

 root@bt:~# git clone https://github.com/OpenSecurityResearch/beacon_simulator.git

Our example code below uses the registration site for ccTLD Tokelau dot.tk domains (this site does not host malware). Tokelau is a territory of New Zealand that is 5 sq. miles of atolls in the South Pacific with a population of roughly 1,400 people, but they are the fastest growing ccTLD because domain registration is free and does not require a credit card. Even with their anti-abuse efforts, it is still a popular landing or redirector for malware.

Because of that, the domain also happens to trigger in the emerging threats snort rule:

 alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"ET CURRENT_EVENTS HTTP Request to a *.tk domain"; flow:to_server,established; content:"|0d 0a|Host|3a| "; content:".tk|0D 0A|"; within:50; content:!".tcl.tk|0d 0a|"; classtype:bad-unknown; sid:2012810; rev:6;)

We are explaining this because if you are running the emerging threats rule, you may see an alert—but feel free to use any site for your beacons.

One-Liner Beacon

So, any *nix hacker out there is saying, we can do this with one line. Yes you can. The line below begins an infinite loop with while true. It then uses wget to call out and grab content from a site (redirecting the output to /dev/null). We then sleep for 10 seconds and do it again. This will continue to repeat until the user kills the infinite loop with CTRL+C.

 root@bt:~/beacon_simulator# while true; do wget -O /dev/null http://www.dot.tk/en/index.html?lang=en; sleep 10; done;

--2012-11-09 11:32:44--  http://www.dot.tk/en/index.html?lang=en
Resolving www.dot.tk...
Connecting to www.dot.tk||:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 11393 (11K) [text/html]
Saving to: `/dev/null'

100%[=============================================================================================================================>] 11,393      --.-K/s   in 0.02s   

2012-11-09 11:32:45 (573 KB/s) - `/dev/null' saved [11393/11393]

--2012-11-09 11:32:55--  http://www.dot.tk/en/index.html?lang=en
Resolving www.dot.tk...
Connecting to www.dot.tk||:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 11393 (11K) [text/html]
Saving to: `/dev/null'

100%[=============================================================================================================================>] 11,393      --.-K/s   in 0.008s  

2012-11-09 11:32:56 (1.36 MB/s) - `/dev/null' saved [11393/11393]

[ CTRL + C ]

This is handy because it does not require us to download a beaconing app and it can be remotely pushed to several boxes to generate even more traffic. How about something more re-usable that we can pull off the shelf when needed?

Bash script beacon

If you are seeking reusability and want to extend functionality and complexity you can use the bash script provided below. It does some error checking and provides the same functionality as the one-liner above. It can also be extended to provide additional features such as altering the URL and parameters.


The script takes the URL and the frequency (how often to fetch the URL) in seconds, you can see some example usage by running it without any parameters:
 root@bt:~/beacon_simulator# ./beacon.sh 
This program will beacon out to a website on a user-defined schedule to simulate malware.  (Use ctrl+c to stop the beaconing)
Email Tony.Lee-at-Foundstone.com for questions.

Usage: ./beacon.sh <URL> <Frequency in seconds>
Example: ./beacon.sh http://www.dot.tk/en/index.html?lang=en 60


Simply launch the script and define the URL and the frequency:
 root@bt:~/beacon_simulator# ./beacon.sh http://www.dot.tk/en/index.html?lang=en 10
Getting the site http://www.dot.tk/en/index.html?lang=en

--2012-11-09 12:34:50--  http://www.dot.tk/en/index.html?lang=en
Resolving www.dot.tk...
Connecting to www.dot.tk||:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 11393 (11K) [text/html]
Saving to: `/dev/null'

100%[=============================================================================================================================>] 11,393      --.-K/s   in 0s      

2012-11-09 12:34:57 (324 MB/s) - `/dev/null' saved [11393/11393]

Sleeping for 10 seconds

Bash Beacon Source

# Beacon simulator
# Tony.Lee-at-Foundstone.com
# Input: URL and frequency to beacon (in seconds)
# Output: Beaconing web requests to a URL at a user-defined interval
# Requirements - curl or wget

##### Function Usage #####
# Prints usage statement
echo "This program will beacon out to a website on a user-defined schedule to simulate malware.  (Use ctrl+c to stop the beaconing)
Email Tony.Lee-at-Foundstone.com for questions.

Usage: $0 <URL> <Frequency in seconds>
Example: $0 http://www.dot.tk/en/index.html?lang=en 60"

###### Core Program ######
# Parameter Detection
# Beaconing

# Detect the absence of command line parameters. If the user did not specify two, print usage statement
[[ $# -ne 2 ]] && { Usage; exit 0; }

while true
        echo -e "Getting the site $1\n";                # user notification output
        wget -O /dev/null $1;                           # wget the URL (to avoid files from building up output to /dev/null)
echo -e "\n\nSleeping for $2 seconds\n\n";      # user notification output
        sleep $2;                                       # Sleep

The previous two examples are useful for generating the beacon from within your network, however what if you want to track the attack back to the point of download? For example, maybe an unsuspecting user downloaded a malicious binary that is beaconing out for instructions.

C++ Beacon

The following program was written in C++ on Linux and compiled with g++. It does some simple error checking and then uses a string to generate the wget command and converts it to a char* to pass into system(). We realize that the program passes a command line parameter into wget. Since this is designed to be run on the command line there is no additional risk due to a shell escape as long as the application is not run as root and does not have the SUID bit set.

 // Simple Beacon Simulator
// Input: URL and frequency to beacon (in seconds)
// Output: Beaconing web requests to a URL at a user-defined interval
// Requirements - curl or wget
// For questions ask Tony.Lee-at-Foundstone.com

#include <stdio.h>
#include <unistd.h>
#include <string>
#include <iostream>
#include <stdlib.h>

using namespace std;

int main(int argc, char *argv[])
        printf("This program will beacon out to a website on a user-defined schedule to simulate malware.  (Use ctrl+c to stop the beaconing)\n");
        printf("Email Tony.Lee-at-Foundstone.com for questions.\n\n");

        if ( argc != 3 )        // Detect command line arguments - 2 are needed for correct execution
                printf( "Usage: %s <URL> <Frequency in seconds>\n", argv[0] );
                printf( "Example: %s http://www.dot.tk/en/index.html?lang=en 60\n", argv[0] );
                return 1;

        unsigned int seconds = strtoul(argv[2],NULL,0); // sleep takes an unsigned int, must convert string input to unsigned long

        std::string command;                    // initialize command
        command = "wget -O /dev/null ";         // build the first part of the string
        command += argv[1];                     // add the URL

        const char * charcommand = command.c_str();     // convert string to char*

                printf("\nGetting the site %s\n", argv[1]);             // user notification output
                system( charcommand );                                  // execute wget 
                printf("\n\nSleeping for %u seconds\n\n", seconds);     // user notification output
                sleep(seconds);                                         // sleep

        return 0;


You can compile the binary statically or dynamically, depending on your needs. Here are the g++ commands for both.

Dynamically Compiled:
 root@bt:~/beacon_simulator# g++ -o beacon beacon.cpp
  root@bt:~/beacon_simulator# file beacon
beacon: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.9, dynamically linked (uses shared libs), not stripped

Statically Compiled:
 root@bt:~/beacon_simulator# g++ -static -o beacon beacon.cpp 
  root@bt:~/beacon_simulator# file beacon
beacon: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.9, statically linked, not stripped


In order to know that your defenses are effective you need to test them. If you don’t want to introduce evil to the network, it can be helpful to have a few benign files at your disposal. We have hopefully provided a few useful example programs that can help you investigate the visibility that you have in detecting a beaconing application.

Do you have any tests that you use to ensure your defenses are effective? Let me know in the comments below!

Tuesday, December 4, 2012

WAPT Workaround: Following Redirects without Downloading Content

By Tony Lee and Amit Bagree.

We get some very unique requests from time to time—such as: “Please walk the site with sequential file IDs in order to gather file type statistics. Oh yeah, do this from outside the network and consume minimal bandwidth.”

Yes, we realize that this is not an ideal scenario because you could just go to web server locally, but how many ideal scenarios do you really come across? Plus we love a challenge. :)

Mission if you choose to accept it

A redirect page in a client site takes an object parameter called ID. These are potentially sensitive files and you want to traverse all of the redirect URLs and resolve the redirect names to their full path to check for sensitive names and gather statistics. Unfortunately, your client is bandwidth sensitive and does not want you downloading their entire website (some files are +10MB in size) – you don’t want that either... However, you still need to obtain a site map, parse the file names for potentially sensitive titles and gather statistics.

One Possible Solution

A few of us kicked the problem around for the optimal answer. We finally settled on the spider option contained within wget. From the wget man page:

--spider When invoked with this option, wget will behave as a Web spider, which means that it will not download the pages, just check that they are there.

Now that we have a way to resolve the redirects, yet ignore the content, we will need some Linux scripting foo to help with traversing the IDs and parsing the output.

Solution: Steps (High Level)

  1. Run “script” to capture the output for grepping
  2. Create a bash shell script that counts from the lower range to the upper range…
  3. Kill “script” with CTRL + D
  4. Grep like there is no tomorrow

Step 1: Run Script

 root@bt:~# script

Step 2: for Loop

 root@bt:~# for i in {110000..110002}; do wget --spider --force-html https://site.com/crazy/long/directories/Redirect.aspx?ID=$i; done

Step 3: CTRL+D


Typical Output

After letting that run for a while, we finally have some output. It appears that wget resolved the location and followed it to check to see if the file exists. Just as we planned! On top of that, we did not download the file. Now we need to make the output actionable—grep to the rescue.


Spider mode enabled. Check if remote file exists.
--2012-01-09 13:29:11--  https://site.com/crazy/long/directories/Redirect.aspx?ID=120305
Resolving www.site.com...
Connecting to www.site.com||:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: /crazy/long/directories/someexcelfile.xls [following]
Spider mode enabled. Check if remote file exists.
--2012-01-09 13:29:11--  https://site.com/crazy/long/directories/someexcelfile.xls
Connecting to www.site.com||:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 50688 (50K) [application/vnd.ms-excel]
Remote file exists.


Step 4: grep grep grep

You could grep on just about anything in the output above. You could grep on “Location” or the second date tag if you wanted. Below is just one example. We are using two greps piped together. The first one grabs the lines with the double dash and the second looks for file extensions. We pipe that into word count with a ‘–l’ to count the number of lines that match that as shown below.

 root@bt:~# grep "\-\-" <script file name> | grep “.pdf” | wc -l

You could now change the grep to xls, doc, docx, etc. “wc –l” will continue to give you the number of instances or leave it off in order to grab the full paths to the files.

What do you think?

This is just one possible method in obtaining full path names by sequentially walking a website. This also avoids downloading the large files to save on bandwidth. We would be very interested in other (possibly more efficient) ideas on how to tackle this using free software. :)

Tuesday, November 27, 2012

Solder Time! FaceDancer11 and GoodFET41 Assembly

By Brad Antoniewicz and Tushar Dalvi.

At Recon 2012 Travis Goodspeed and Sergey Bratus released the Facedancer, an extremely flexible piece of hardware for emulating and tinkering with USB devices. Although the Facedancer is very much it's own device, it evolved from another one of Travis Goodspeed's projects, the GoodFET, which is his own customized Flash Emulation Tool debugger for the MSP430 microcontroller.

The PCBs for each device can be ordered online however, the devices are not currently available pre-assembled. So if you want to play with them, you'll need to learn how to solder! Although some may see this as a pain, I personally love it and hope assembled boards are never released - it forces people to learn the fundamentals of what they're doing.

I've done almost no surface mount soldering before and have always wanted to play with USB so the Facedancer was a perfect project for me. Although I don't have much use for the GoodFET, two were generously included within my shipment, so I ordered the spare components and built them too.


Both the Facedancer and GoodFET include a parts list on their description pages but when you go to order them from any supplier, you'll quickly realize there are a seemingly endless combination of options to choose from. After spending some time putting together an actual order, I jumped on #goodfet and asked for a little help. Luckily the channel is populated with hardware rock stars like Michael Ossmann and dragorn who were kind enough to help redefine my order, pointing out corrections to the online parts list that weren't published yet and alternate crystal options. Throughout the entire assembly process, these two defied standard irc help channel etiquette by offering extremely useful tips and troubleshooting suggestions - These guys ROCK!

In the end, here's the detailed part list I used. Everything was ordered from DigiKey, since that's were I bought my first 6.5535MHz crystal. I made a reddit post, just in case you want to add any updates.

Package Pg. Description DigiKey Part DigiKey Description
0603 1.0µF Capacitors 587-1242-1-ND CAP CER 1UF 10V 10% X7R 0603
0603 0.1µF Decoupling Capacitors 490-1532-1-ND CAP CER 0.1UF 16V 10% X7R 0603
0603 18pF Capacitors 445-1272-1-ND CAP CER 18PF 50V 5% NP0 0603 (see note)
0603 27pF Capacitors 490-1413-1-ND CAP CER 27PF 50V 5% NP0 0603
HC49/UP** 12MHz SMD Crystal, 18pF 535-10218-1-ND CRYSTAL 12.000 MHZ 18PF SMD
0603 0603 LED 754-1121-1-ND LED 1.6X0.8MM 568NM GRN CLR SMD
0603 330R LED Series Resistors RMCF0603JT330RCT-ND RES 330 OHM 1/10W 5% 0603 SMD
0603 33R USB Series Resistors RMCF0603JT33R0CT-ND RES 33 OHM 1/10W 5% 0603 SMD
Note: Although the 18pF capacitor might be a good capacitor, it is not ideal for the chosen crystal so the 27pF cap was chosen


Here's a list of tools I used to put it all together. Hopefully you have most of these already:

Soldering Iron. One of the biggest things is to get a good soldering iron - leave the crappy radio shack one on the shelf and get one with temperature control and a fine tip. I went for the Weller WES51.
Flux! You won't understand how amazing this is until you use it. Then you'll question what the heck you were doing without out. I used the RadioShack stuff. Its messy, dragorn recommended ChipQuik No Clean Flux.
Head mounted magnifier - There's probably a more official name for this :) It was extremely useful to have a head mounted magnifier over those stupid helping hands. I bought this one.
Tweezers - Impossible to place surface mount capacitors without these guys. I used the Wiha 7a SA-ESD, which I think these are close to.
Tip Cleaner. This helps keep the tip clean and help with spreading the solder when its dirty and needs to be tinned. This is the Hakko 599B.
Multimeter - Extremely important for any electronics project. This is the Extech 430
Desoldering Braid - Helps when you mess up. So much easier to when you use a little flux with it. I used the RadioShack stuff.
Solder - I used the RadioShack's 0.022" solder, that they don't have on their site.
Hot Plate - When I started this project out, I was really excited to do some hot plate reflow. Before you buy anything, read the rest of this article :) This is the Brentwood TS-337
Soldering Paste - For hotplate reflow. I used the No Clean Zeph Paste. They didn't ship me the fine tips I ordered and haven't responded to any of my emails. :/
Infrared Thermometer - Needed for the hot plate reflow, this is the Kintrex IRT0421

Hot Plate Reflow

I wanted to try out the hot plate reflow technique because it looked really easy and seemed like a fun way to get everything done quickly. I also came across another great blog post showing how someone else used it for an earlier GoodFET, which helped me make my decision.

Here's a quick video I put together showing the process:

Overall, I feel like hotplate reflow is cool but I don't know that it was really needed. I sort of cheated by running a super thin line of paste down across all of the pads on the PCB rather then being more precise with a toothpick. Since the paste didn't flow smoothly out of the syringe, I ended up getting uneven globs which eventually turned into bridges once the reflow completed. To fix the bridges, I ended up drag soldering (which is one of the most popular ways to hand solder surface mount components) so I could have probably just skipped the hotplate entirely. Also, the hotplate temperature is pretty hard to control, after completing the first board it took a long time for the plate to decrease in temperature, I got impatient and threw on the next board which put me pretty close to frying everything.

Drag Soldering

For future projects, I'll be drag soldering my surface mount components. It's just plain easy. Turn your soldering iron to about 725F, place the component, apply a generous amount of flux, tack down one pin to hold everything in place then semi-slowly drag the iron over multiple pins. The solder will hop from pin to pin leaving just enough to hold the part in place. This is an awesome video by Curious Inventor demonstrating the method:


Once I had everything assembled, I connected it to my system and discovered the FT232R chip was not being recognized. I used the audible continuity tester on my multimeter to debug the issue. Starting from the host side USB connector, I tested the paths between the connector and the FTDI input pins which quickly revealed I had a small solder bridge. I used a some flux with the desoldering braid to clean it up and then drag soldered it a little more to make sure I had a good joint.

After that I gave everything a close inspection under magnification again and noticed a couple more tiny bridges. As I removed them, I accidentally broke one of the pins off of the MSP430. Normally this would be an issue, but since the pin wasn't used, it was ok to leave it alone. I reconnected the Facedancer to my computer and it worked!


Once everything is assembled on the Facedancer, connect the host side to your system. dmesg should show a similar set of logs:

 root@bt:~# dmesg
[7097779.953802] ftdi_sio 5-1:1.0: FTDI USB Serial Device converter detected
[7097779.953882] usb 5-1: Detected FT232RL
[7097779.953889] usb 5-1: Number of endpoints 2
[7097779.953896] usb 5-1: Endpoint 1 MaxPacketSize 64
[7097779.953903] usb 5-1: Endpoint 2 MaxPacketSize 64
[7097779.953909] usb 5-1: Setting MaxPacketSize 64
[7097779.955746] usb 5-1: FTDI USB Serial Device converter now attached to ttyUSB0

And you'll also see a FTDI entry using lsusb
 root@bt:~# lsusb
Bus 005 Device 045: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC

Next you'll need to install the prerequisites, download all of the supporting code from the SVN server, and build the client

 root@bt:~# apt-get install python-sqlite python-serial
 root@bt:~# svn co https://goodfet.svn.sourceforge.net/svnroot/goodfet
 root@bt:~# cd goodfet/trunk/client
 root@bt:goodfet/trunk/client# make link

You can define the board you're using via the board environment variable. I tend to use different boards so I'll specify it on the command line. It's recommended that you first backup the info flash (be sure to store it in info.txt) from the board before installing the firmware, to do so:

 root@bt:goodfet/trunk/client# board=facedancer11 goodfet.bsl --dumpinfo > info.txt

Now we can install the firmware:

 root@bt:goodfet/trunk/client# board=facedancer11 goodfet.bsl --fromweb

This may or may not work for you. As of 11/26, you'll get this error:

 The --fromweb feature is temporarily disabled, pending a rewrite.
 Please grab a copy of the appropriate .hex from
 http://goodfet.sf.net/dist/ and flash it like so:

 goodfet.bsl -e -p foo.hex

So let's manually download and install:

 root@bt:goodfet/trunk/client# wget http://goodfet.sourceforge.net/dist/facedancer11.hex
 root@bt:goodfet/trunk/client# board=facedancer11 goodfet.bsl -e -p facedancer11.hex
 MSP430 Bootstrap Loader Version: 1.39-goodfet-8
 Mass Erase...
 Transmit default password ...
 Invoking BSL...
 Transmit default password ...
 Current bootstrap loader version: 2.13 (Device ID: f26f)
 Program ...
 4932 bytes programmed.

Once everything has completed, just run a quick test to make sure nothing is broken!

 root@bt:goodfet/trunk/client# bboard=facedancer11 goodfet.monitor test
 Performing monitor self-test.
 Self-test complete.

Looks like everything is working. Now you'll need to dig throw a lot of python, the USB specifications and blog posts to do some awesome USB hacks. This is a great place to start:


Tuesday, November 20, 2012

Dumping iClass Keys

By Brad Antoniewicz.

iClass, arguably the second most widely deployed technology in proximity card access systems (the first being the ProxCard II), is a proprietary RFID communications standard and card type. It provides an enhanced level of security over the ProxCard as it encrypts the data stored on the card and leverages a challenge/response form of authentication between the card and the reader. At the 27th Chaos Communication Congress (27C3) Henryk Plötz and Milosch Meriac took a look at iClass systems. They ingeniously dissected the RW400 iClass reader and released a method to dumping it's firmware via the exposed In Circuit Serial Programming (ICSP) interface of reader's PIC18F452 microcontroller. Within the firmware were the keys used as part of the iClass card to reader authentication making it possible for anyone with the appropriate skill to read and clone these cards. It was an awesome moment for RFID and hardware hacking geeks everywhere!

The Downside

But... there was a slight downside - the method of dumping the firmware was a arguably brutish. You have to actually overwrite a portion of the reader's firmware with "dumper code" that reads and then dumps the remaining portions of it's own firmware. To obtain a complete firmware image, you have to have access to two readers. This isn't that big of a deal when targeting "Standard Security" iClass implementations because you can just buy two RW400s, get their keys, and be forever happy since the keys are static across all cards/readers. But when it comes to "High Security" implementations, you have to physically remove a reader from the wall within your target's facilities, dump a portion of the firmware, then using another reader, dump the portion of the firmware you overwrote with the dumper code on the first reader. I should say that in theory you could just write the dumper code, dump the area of the firmware that contains the keys, and then just leave the reader in a inoperable state - but a good hacker wouldn't be a jerk and just leave a broken reader laying around so lets just forget about that option.

Another Method

Those interested in RFID hacking have probably stumbled upon http://www.proxclone.com/ at least once. It's a humble site in which the author takes on various RFID related hacking projects. One of the projects was to emulate the iClass work presented at 27C3. The author successfully re-enacted the method on a RW300 reader using the same general idea, but with the author's own code and different tools. Well done. Even more interesting though was that during the re-enactment, the author discovered a new method to gain access to the reader's keys - one that only required access to a single reader, didn't involve overwriting the firmware, and even yielded the last read card value stored by the reader!

Another Downside

There is also slight downside with this as well - the author described how to perform the attack, but implemented in a hardware prototype without releasing any code or schematics. This made it a little challenging for someone like me, who wanted to reproduce his work. Here's the hardware device he created, this image is straight from the whitepaper:

Using the Old with the New

Henryk Plötz and Milosch Meriac leveraged the FTDI TTL-232R-5V-WE to interact with the reader's microcontroller. It's a simple and elegant solution and I really wanted to use it to implement the proxclone method.


The TTL-232R-5V-WE's true power is shown through its "bit bang" mode that allows its pins to be individually controlled. This makes it possible to emulate the PIC programming hardware without the restrictions imposed by more traditional PIC programmers. It costs around $20USD. The only additional hardware requirement is a power source to bring the PIC into High Voltage programming mode. I used a 9V battery power supply enclosure that included a switch so I can enable/disable it as needed. So all in all, we're looking at about a $25USD investment!

The exposed 6 pin ICSP interface on RW300s/RW400s is usually under a piece of electrical tape on the back of the reader. It differs slightly from the standard ICSP interface but not by much. Connect the ground on your 9V power to the FTDI ground (Black) and the VCC to PIN 3 on the reader. The pinouts are as follows:

Black (GND)Black1VSS

The green FTDI wire looks very much Blue in this picture, my guess its just iPhone camera funky-ness:


On the software side, I used much of the code from the PIC18F ICSP programmer to implement the read instructions used in the proxclone paper. The instructions seemed simple enough:

The code can be found on our github repo here:

We'll also need to install the D2XX drivers from FTDI. You can get away with using the standard libFTDI that's included with most Linux distributions (you'll just need to change some function names and add some #define's) but I choose the D2XX drivers. To install:
 root@bt:~# wget http://www.ftdichip.com/Drivers/D2XX/Linux/libftd2xx1.1.12.tar.gz
 root@bt:~# tar -zxvf libftd2xx1.1.12.tar.gz
 root@bt:~# cd release/build/i386
 root@bt:~/release/build/i386# sudo cp lib* /usr/local/lib
 root@bt:~/release/build/i386# sudo chmod 0755 /usr/local/lib/libftd2xx.so.1.1.12
 root@bt:~/release/build/i386# sudo ln -sf /usr/local/lib/libftd2xx.so.1.1.12 /usr/local/lib/libftd2xx.so

I choose this method because its easy and I'm working on non-persistent BT5R3, alternate installation methods are detailed in the ReadMe.txt included within the archive.

Dumping Keys

Once the hardware is all set up, connect the FTDI adapter to your Linux box. You may have to rmmod the ftdi_sio and usbserial modules so that the D2XX drivers can work.

 root@bt:~# rmmod ftdi_sio usbserial

Next clone the github repo and compile:

 root@bt:~# git clone https://github.com/OpenSecurityResearch/iclass_dump.git
 root@bt:~# cd iclass_dump/
 root@bt:~/iclass_dump# gcc -lftd2xx -o iclass_eeprom_dump-d2xx iclass_eeprom_dump-d2xx.c

Apply power to the reader (I just used a spliced Enercel 12V adapter I picked up at a nearby RadioShack), read a card, then run:

 root@bt:~/iclass_dump# ./iclass_eeprom_dump-d2xx -v 

iclass_eeprom_dump-d2xx will give you 20 seconds to connect the FTDI cable and apply the VPP programming voltage.

The program will continue and start dumping. About 10 seconds later, you'll have the full memory dump. Note that I'm not disclosing the offsets for any keys, so you'll have to figure them out yourself. iclass_eeprom_dump-d2xx automatically provides the key permutations so you don't have to worry about running them through permute.php.
 root@bt:~#  ./iclass_eeprom_dump-d2xx -v
iClass EEPROM Dumper
Connecting to FTDI TTL-232R-5V-WE...Connected!!
Checking bitmode...Success! - 0xf0

Make sure at least one card has been read by the reader, then
connect your FTDI TTL-232R-5V-WE to the reader's ICSP port
and introduce the VPP power

Sleeping for 1 Seconds while you do so....

Starting EEPROM Dump
        MOVLW       - Writing PGM_CORE_INST 0x0E00
        MOVWF FSR0H       - Writing PGM_CORE_INST 0x6EEA
        MOVLW       - Writing PGM_CORE_INST 0x0E00
        MOVWF FSR0L       - Writing PGM_CORE_INST 0x6EE9

Dumping (takes ~10 seconds)..
Dump Complete!

Full EEPROM Dump:

                [ REMOVED ]


Parsed Keys:
        HID Master:
                [ REMOVED ] (parsed)
                [ REMOVED ] (rev. permutated)
                [ REMOVED ] (shaved)
        TDES K1:
                [ REMOVED ] (parsed)
                [ REMOVED ] (rev. permutated)
                [ REMOVED ] (shaved)
        TDES K2:
                [ REMOVED ] (parsed)
                [ REMOVED ] (rev. permutated)
                [ REMOVED ] (shaved)
Parsed Last Read Card:
        Wiegand:        [ REMOVED ]
        First 4 of CSN: [ REMOVED ]
        Full CSN:       [ REMOVED ] (not always right)

All Done!  - Closing the adapter
Dont forget to disconnect the FTDI from the reader's ICSP


Tuesday, November 13, 2012

Hacking Through Language Barriers

By Tony Lee and Chris Lee.

When assessing a global corporation's external network, a security consultant may not immediately realize geographically where in the world they may end up. We are often given large IP blocks that contain hosts around the world. As you interact with these systems, you may discover that the tools/applications you regularly use do not support the language of your target! This article will help provide a few ideas on determining where in the world you end up and how to continue the hack—even if you cannot natively read what you are doing.

I’m in! Now what?

Inevitably you'll discover a misconfiguration or some other vulnerability that will yield you access to something on the target's external network. Sometimes you might not even be sure what the system is (e.g. access obtained via a weak password). We've seen tons of stuff fall into this category - from VOIP gateways and VPN appliances to SCADA sensors and controllers (ironically, we find the most unique equipment is usually available over dial-up --yeah War Games!).

Nonetheless, here we are again, we have access to some unidentified host - but now what? Since we don’t manage the device and may not immediately know what it is, we look for some sign of a manufacturer or version in the banner. If it lacks a banner, we try to activate the help menu. This is all well and good, however what if the help menu or the banner show up as non-printable characters?

What the hex?

On a recent engagement, we ran into just this problem. The password prompt and a very lengthy copyright banner were legible, however all of the help functionality displayed as non-printable characters as shown in the example below:

Since it is impossible to know every device out there the help menu can be crucial to navigating the device and turning low hanging fruit into further access or substantial impact. So, how do we interpret the menu when it looks like that?

The first thing we have to assume is that the device and our client application do not speak the same language. This could be protocol or natural language. In the screenshot above, we see that the protocol is most likely not the culprit because we can read some of the menu—thus we have to assume this is a natural language issue. But what language is this?

Location clues

In order to pick the right language, it may help to figure out the geographic location of the device. Again, even though this may be a company that is headquartered in the US or elsewhere, it does not mean that the device is located in that country or even configured to be in that language since it is often local employees that have to manage the device.

To help discover the location, we will use the following clues:
  • Manufacturer
  • Login banners
  • Hostname or DNS name
  • GeoIP Data


The manufacturer can sometimes be an indicator of the language, but this is not always the case due to global manufacturing and distribution of equipment, however there are countries that tend to purchase and support their own local products more often than they purchase foreign equipment. With that said, this is probably the least accurate clue, but worth noting. In the case above, Yamaha (a Japanese company) makes the device to which we have gained access. Additionally, it looks like the Tokyo Institute of Technology and the Japan Advanced Institute of Science and Technology also have copyrights on this device. Let’s see if this holds any weight as we move along.

Login banners

Warning and consent to monitoring banners will often have the company name and possibly location of the device. If listed, this information is usually more accurate than extrapolating the device location from the manufacturer’s origin.

Fictitious example:

It is the policy of the law firm of the Smith group to monitor the Internet 
access of its employees to ensure compliance with law firm policies.  
Accordingly, your use of the Internet may be monitored.  The firm reserves 
the right to disclose the fruits of any monitoring to law enforcement if it 
deems such disclosure to be appropriate.

Smith1 – Memphis


Many security industry experts advise against this disclosure as it makes it very easy for the attackers to find and validate their targets—however it is still prevalent. The client’s argument is that it is very useful for administrators to also know the location and ownership of the device. In this situation, there was no consent to monitoring or other warning banner to clue us into the location.

Hostname or DNS name

Another tip-off can be the hostname or DNS Fully Qualified Domain Name (FQDN). Companies will often put geographical location info either in the hostname or as part of the FQDN.

Examples of this would be:
  • VAWin2k8Server
  • UKc2600
  • Sharepoint.company.co.jp

Looking at the examples above, one could probably infer that the first example is in VA, in the US, the second example is located in the UK, and the last example is in Japan.

A real-world example can be seen when doing a traceroute to a device that is relatively far away:

 traceroute to nyu.edu (, 30 hops max, 60 byte packets
 1  56-92-10-6.static.twtelecom.net (  1.058 ms  1.307 ms  1.662 ms
 2  20-34-18-25.static.twtelecom.net (  4.991 ms  5.194 ms  5.196 ms
 3  lax2-pr2-xe-0-3-0-0.us.twtelecom.net (  6.109 ms  6.106 ms  6.239 ms
 4  xe-7-1-0.edge2.LosAngeles9.Level3.net (  6.438 ms  6.412 ms  6.423 ms
 5  vlan70.csw2.LosAngeles1.Level3.net (  7.172 ms vlan90.csw4.LosAngeles1.Level3.net (  13.436 ms vlan70.csw2.LosAngeles1.Level3.net (  7.302 ms
 6  ae-93-93.ebr3.LosAngeles1.Level3.net (  7.863 ms  8.785 ms ae-73-73.ebr3.LosAngeles1.Level3.net (  8.067 ms
 7  ae-3-3.ebr1.SanJose1.Level3.net (  15.933 ms  15.797 ms  17.652 ms
 8  ae-2-2.ebr2.NewYork1.Level3.net (  83.898 ms  84.117 ms  83.987 ms
 9  ae-82-82.csw3.NewYork1.Level3.net (  84.614 ms ae-72-72.csw2.NewYork1.Level3.net (  84.346 ms ae-92-92.csw4.NewYork1.Level3.net (  85.171 ms
10  ae-1-60.edge4.NewYork1.Level3.net (  84.339 ms ae-3-80.edge4.NewYork1.Level3.net (  84.582 ms  84.581 ms
11  NEW-YORK-UN.edge4.NewYork1.Level3.net (  85.143 ms  85.140 ms  85.119 ms

It is interesting to see the physical path that packets take over long distance journeys.

Unfortunately, in our case, this did not help us as we were working off of IP address only and the hostname was not displayed in the banner or resolvable via a reverse DNS lookup.

GeoIP Data

The last tactic you can use is a GeoIP location search engine and database. This is a mapping of real world physical locations to Internet Protocol addresses. I recommend using a couple of them to validate each other’s results. Sometimes you may get one that is pretty far off in accuracy.

Some potential sites to use are:

In our case, we included the result from geobytes below. This confirmed our suspicion from earlier that it may be Japanese.

Overall, these tools are fairly accurate, sometimes even down to the city, and will almost always get you in the right country.

Encoding/language support

Now that we know the language we want to try, the first attempt at making it readable was to try another program. Unfortunately, Putty was no help in this instance. None of the language settings under Putty Configuration then Translation seemed to match a Japanese character encoding.

It turns out that you need to download a separate version of Putty called Puttyjp. Since we did not want to install a special version of Putty for this, we looked through the character encoding in gnome-terminal . There are a few Japanese encodings, so we tried Japanese ISO-2022-JP as shown in the screenshot below:

No dice!

Let’s try another character encoding set, Japanese (SHIFTJIS)… Voila! We have something that is legible! Sorta… If you read Japanese you are in good shape. For the rest of us, we can either make a friend who reads the language or there is Google Translator.

Google translator to the rescue

The detect language feature in Google Translate guessed incorrectly, but it can be overridden. When in a pinch, this is not a bad option. The Ping help menu even makes sense when you read the English version—or at least enough to understand the command and how to use it. This was the same for the rest of the help menus which provided enough information to properly leverage the device.


Even though you may be assessing devices and networks around the world, it is not impossible to hit a home run on a device that you cannot even natively read. With enough patience and careful fiddling, a foreign device can be utilized as if it were a native device.

For those of you that were wondering what the mystery device was… It was a VPN concentrator designed for small/medium size businesses. One clue, intentionally not disclosed earlier, was the very subtle model number in the banner: RT107e.

Have you ever run into a language issue before? If so, what clues did you use to figure out the language of the device? What tools did you have to use to correctly render the text? What did you use to translate it once it was properly rendered?

Tuesday, October 30, 2012

for loops! Bash One-liners to Validate Vulnerabilities on Multiple Hosts

By Amit Bagree.

This is a quick blog post on one-liners. Recently I was working on manually validating vulnerabilities for a customer with a very large Internet presence. There were a lot of findings - each with hundreds of affected systems and I needed a quick way to confirm the vulnerability on each system and weed out false positives. I achieved this by using common *nix commands and tools. This might not get you a standing ovation or pick up a partner but they'll help you wrap up the automated scanning to give you time to spend on the real hax!


McAfee Vulnerability Manager: Web Server Supports Outdated SSLv2 Protocol
Nessus: SSL Version 2 (v2) Protocol Detection

 root@bt:~# for i in `cat Affected-SSLv2-IPs.txt`; do echo -e "\n----START "$i"----" ; echo -e "HEAD / HTTP/1.0\n\n" | openssl s_client -connect "$i" -ssl2; echo -e "\n----END "$i"----"; done > SSLv2-Output.txt


McAfee Vulnerability Manager: TLS / SSL Man-In-The-Middle Renegotiation Vulnerability
Nessus: SSL / TLS Renegotiation DoS & SSL / TLS Renegotiation Handshakes MiTM Plaintext Data Injection
  root@bt:~# paste SSL-Renego-IPs.txt | while read IP port; do echo "----START "$IP":"$port"----"; echo -e "HEAD / HTTP/1.0\nR\n\n" | ncat --ssl "$IP" "$port"; echo -e "\n----END "$IP":"$port"----\n"; done

Where SSL-Renego-IPs.txt has an IP address and port number on each line separated by a space. You can use OpenSSL instead of Ncat as well. An online test tool is available here.


McAfee Vulnerability Manager: ISC BIND DNS Out-Of-Bailiwick Cache Poisoning
Nessus: Multiple Vendor DNS Query ID Field Prediction Cache Poisoning

  root@bt:~# for i in `DNS-CachePoison-IPs.txt`; do dig @"$i" +short porttest.dns-oarc.net TXT; done; > DNS-CachePoison-Output.txt


Nessus: DNS Server Spoofed Request Amplification DDoS

  root@bt:~# for i in `cat DNSRootAmpDoS-IPs.txt`; do dig @"$i" . NS; done > DNSRootAmpDoS-Output.txt


McAfee Vulnerability Manager: Internet Key Exchange (IKE) Aggressive Mode with Pre-Shared Key
Nessus: IKE Server Allows Aggressive Mode for Shared Secret Authentication
  root@bt:~# for i in `cat IKE-AggresiveMode-IPs.txt`; do sudo ike-scan -M -A "$i"; done > IKE-AggresiveMode-Output.txt

CVE-2003-1567, CVE-2004-2320, CVE-2010-0386

McAfee Vulnerability Manager: Web Server HTTP TRACE or TRACK Methods Enabled
Nessus: HTTP TRACE / TRACK Methods Allowed

  root@bt:~# paste Trace-IPs-SSL.txt | while read IP port; do echo "----START "$IP":"$port"----"; echo -e "TRACE / HTTP/1.0\n\n" | ncat --ssl "$IP" "$port"; echo -e "\n----END "$IP":"$port"----\n"; done > Trace-SSL-IPs-Output.txt

CVE-2006-3918, CVE-2007-5944

McAfee Vulnerability Manager: F-Secure Policy Manager Expect Header Cross-Site Scripting
Nessus: Web Server Expect Header XSS

  root@bt:~# for i in `cat ExpectHeaderXss-IPs.txt`; do echo -e "\n----START "$i"----" ; echo -e "GET / HTTP/1.0\nExpect: <script>alert(1)</script>\n\n" | openssl s_client -quiet -connect "$i":443; echo -e "\n----END "$i"----"; done > M-ExpectHeaderXss-Output.txt


Nessus: Apache HTTP Method Request Entity XSS

  root@bt:~# for i in `cat ApacheMethodRequestXSS-IPs.txt`; do echo -e "\n----START "$i"----" ; echo -e "<script>alert(1)</script> / HTTP/1.1\nHost: foundstone.com\nConnection: close\nContent-length: -1\n\n" | nc "$i" 80; echo -e "\n----END "$i"----"; done > ApacheMethodRequestXSS-Output.txt

SSL Ciphers and Certs

Couple of quick tips/tools for checking weak SSL ciphers, expired SSL certificates, certificates with weak signature algorithms, etc...


Download here. Simply import your IPs with port info like from a text file and click ‘Start Test’. The advantage with SSLSmart is that if you perform a ‘Content’ test you can catch that pesky system which would allow a weak cipher connection but then display a page saying you are not good enough to connect to it. The two methods below won’t catch this false positive.


Another nice tool is this Perl script SSLAudit.pl. The nice feature about this is that the results are graded as per the SSLLabs SSL Server Rating Guide. If you are providing a list of IPs, you will notice quickly that the tool errors out without performing the checks if there is a hostname mismatch (Errors - Hostname verification failed, Hostname mismatch). Worry not! just disable the mismatch check. To apply the patch:

root@bt:~# wget https://sslaudit.googlecode.com/files/SSLAudit%20r6%20%2820100119%29.zip
root@bt:~# unzip SSLAudit\ r6\ \(20100119\).zip 
root@bt:~# wget https://github.com/OpenSecurityResearch/pentest-scripts/blob/master/SSLAudit-r6-20100119-RemoveHostnameCheck.patch
root@bt:~# patch -p1 < SSLAudit-r6-20100119-RemoveHostnameCheck.patch

Then you're all ready to:
  root@bt:~# cat All_SSL_IPs.txt | while read IP port; do echo -e "\n----START "$IP":"$port"----”; perl SSLAudit.pl "$IP" "$port"; echo -e "\n----END "$IP":"$port"----\n"; done > All_SSLAudit_Output.txt

Oh by the way you would need the following modules for SSLAudit to work:
  • inifiles
  • libio-socket-ssl-perl
  • libtime-modules-perl


  root@bt:~# nmap --script ssl-enum-ciphers -p port/s IP-Address/es

Non-Recursive DNS Queries

  root@bt:~# for i in `cat DNS-NonRecursive-IPs.txt`; do dig @"$i" www.google.com A +norecurse; done > DNS-NonRecurive-Output.txt

Assuming www.google.com would be cached. You can make it cache first if you wish.

Checking Remote NTP version

  root@bt:~# for i in `cat NTPVersion-IPs.txt`; do echo -e "\n----START "$i"----" ; ntpq -c readvar "$i"; echo -e "\n----END "$i"----"; done > NTPVersion-Output.txt

Check XSS in URL/URL parameter using Curl

  root@bt:~# curl '<script>alert(1)</script>' | grep 'alert(1)'

Download a specific file from multiple IPs

  root@bt:~# for i in `cat IPs.txt`; do curl -o "$i"_crossdomain.xml “http://"$i"/crossdomain.xml”; done
for i in `cat IPs-SSL.txt`; do curl -k -o "$i"_robots.txt “https://"$i"/robots.txt”; done

Ok, you get the point :)

One final tip - use grep & wc or vim (:%s/pattern//gn) to check for number of occurrences of a pattern in your output.

Hope you find these helpful and please share if you have some favorites as well.

Friday, October 26, 2012

Comcast and DOCSIS 3.0 - Worth the upgrade?

By Tony Lee.

There doesn't seem to be a whole lot of useful information about Comcast's DOCSIS v3.0 upgrade available on the web, so I figured I would post my findings. About a month back I received a letter from Comcast saying that they have upgraded their “Blast Internet service” in my area and that their records showed that I was still on a DOCSIS 2.0 modem. They were advising me to purchase a DOCSIS 3.0 modem and I wondered if it would even be worth the upgrade. This article will explain the results.

Suggested Upgrade

Armed with this letter’s vague claim to upgrade, I went to the Internet to look for others who received the same letter, but I found nothing. I even went to Comcast’s website to find empirical evidence - that was met with more unsubstantiated claims of increased speeds and the benefits of DOCSIS 3.0. You will find wording such as:

Upgrade your speed
DOCSIS 3.0 is the next generation of DOCSIS (Data Over Cable Services Interface Specification), an international telecommunications standard that lets cable television operators add high-speed and telephony data to their current cable TV systems.

With DOCSIS 3.0, you’ll experience significantly faster speeds, so you can make the most of your online experience. DOCSIS 3.0 also opens the door to new Internet technologies.

Upgrade your equipment
To take advantage of DOCSIS 3.0, you need a DOCSIS 3.0 modem. DOCSIS 2.0 modems will still work with our speed tiers (except for Blast and Extreme 50), but you won’t experience the blistering fast speeds now available. We also recommend upgrading to an 802.11n wireless router; 802.11g routers only support up to 20 Mbps. If you lease your modem, router, or gateway device from us, we’ll upgrade it at no extra charge.

If you already have a DOCSIS 3.0 modem, you may need to power cycle it to take advantage of our new, faster speeds.

-- Source: http://customer.comcast.com/help-and-support/internet/docsis3/

So what is an inquisitive nerd to do? -- Why, contact the expert technicians course! I asked multiple employees questions such as the following:

  • What sort of speed difference will I see?
  • Why does a DOCSIS 3.0 modem increase my speed?
  • Are you channel bonding? (explained later)
  • Do you support the SB6180 modem? (explained later)

However, to my frustration, no one could answer these questions. To understand the answer, you should understand a little bit about the difference in technology.

DOCSIS 1.0/2.0 vs. 3.0

The major difference between DOCSIS 1.X/2.0 vs. 3.0 that concerns the average person is the fact that DOCSIS 3.0 supports channel bonding. Channel bonding means combining multiple downstream and upstream channels to support greater speeds. The maximum usable downstream throughput on a single channel is 38 Mbit/s (EuroDOCSIS is 50Mbit/s). Since a DOCSIS 2.0 modem only supports a single channel up and down, 38 Mbit/s is the theoretical downstream max. Thus, if the cable provider rolls out a 50 Mbit/s service (such as Comcast’s Blast 50), you will most likely not see the entire speed increase.

So the big question is… Is Comcast channel bonding? Unfortunately, no one on the help chat or first level phone support could answer the question. It was not until I called upon an inside person did I get the answer I was seeking. The answer is YES! (In my area) Now, off to buy a modem… but which one?

Modem Choices

Personally, I am a huge fan of Motorola Cable modems because they just seem to work. I go all the way back to the DOCSIS 1.0 Motorola SB4100 (remember the hideous grey thing that came in a box with the gnarly surfer on it?) It just worked.

Then to my current DOCSIS 2.0 Motorola SB5120. So familiar to many of us—you probably own one or owned one at some point. It just worked too.

So, what model do we buy now? After doing a ton of research, I narrowed it down to two models:

  • Motorola SB6121
  • Motorola SB6180

Motorola SB6121

Amazon's description sounds great:

“It harnesses the power of DOCSIS 3.0 technology to bond up to four downstream channels and four upstream channels--providing you advanced multimedia services with data rates of more than 100 Mbps in each direction. That makes gaming, shopping, downloading, working, high-quality voice and video conferencing, and peer-to-peer networking applications far more realistic, faster, and efficient than ever before.”

Motorola SB6180

This one sounds even better!

“The SB6180 is the ideal competitive solution for the high-end residential user, the small home office owner, as well as for the medium-to-large business enterprise. Utilizing the power of DOCSIS® 3.0, the SB6180 enables channel bonding of up to 8 downstream channels and 4 upstream channels, which allows an operator to offer their customers advanced multimedia services with data rates of well over 300 Mbps in DOCSIS mode and 400 Mbps in EuroDOCSIS mode for downstream and 120 Mbps upstream.”

So, if you didn’t see the bolded difference, the SB6180 is a “future proofing” device that was originally marketed for small home office and business use. Ironically, you can also find it cheaper than the SB6121 on Amazon.

Here is a helpful chart from Wikipedia to understand the real numbers difference between 8 and 4 channel bonding:

So which one did I buy? - The SLOWER one of course :)

But why? - Comcast has a “Device Compatibility and Capability” page that lists the modems that work with their network. Unfortunately, the SB6180 is not listed anywhere on their site. Additionally, after asking no less than three Comcast techs, all of them said that the SB6180 would NOT work on their network—thus I did not take the chance. Although, the inner nerd in me is mad that I didn’t try it.

Modem Indicators

If you are not one for reading the documentation that accompanies purchases, shame on you—I don’t always read them either. However, the documentation with the SB6121 was very clear and useful. So useful, I scanned it into the computer for you. What you should notice is that if the downstream or upstream light turns blue, your cable provider is channel bonding. If either light is green, that channel is a single channel.

Having read this, I mumbled to myself… Those lights better be blue!

And they were! Whew! (Sorry to those who are blue/green color blind, you will have to take my word for it that upstream and downstream are blue)

Let’s see what those blue lights buy us…

Before upgrade tests

I made sure to test the bandwidth before and after the cable modem swap. To test the bandwidth, I used the ever-popular site: speedtest.net. I had a respectable 28.60 Mbps down and 7.37 Mbps up prior to the modem upgrade.

After upgrade tests

Now for the moment I had anxiously been waiting for… the new modem test! At first I was getting the same speeds... Uhh What?? Then I reset the modem a couple of times and then finally--MOAR POWA!

That is a 24.38 Mbps increase in download speed and a 3.54 Mbps increase in upload speed. Not too bad for a modem upgrade that was less than $100.

Final thoughts

Overall, I am happy with the modem upgrade as it does provide a significant speed increase. I am also happy with Comcast for the free speed increase and letting me know that my cable modem should be upgraded. However, I am disappointed in the lack of support or at the very least the technical knowledge pertaining to the SB6180 (supporting the 8 channel bonded downstream instead of 4). Additionally, I feel that companies could provide graphics or case studies such as the one provided here illustrating why people should upgrade their modems and the potential difference they could see.

Hopefully this article has helped someone else make the decision to upgrade their modem. If anyone has the SB6180 working on Comcast’s network, I would be interested to know. Maybe if enough people have this modem working on their network, they will update their compatibility page.