Why Ham?

Amateur radio is called "ham radio" by many. Ham isn't an acronym, but the origin of the sobriquet is a topic of debate. The most plausible explanation I heard is that professional telegraph operators considered amateur radio operators to be inferior, ham-fisted tinkerers. In this case, "ham" is actually a derogatory remark. Despite the fact, it's been adopted by the community now and is synonymous with "amateur radio." Amateur doesn't mean neophyte, however. It is the antonym of "professional radio," in that amateur stations are not commercial, and hams cannot recieve compensation for operating their equipment.


(The ham shack at MST's Amateur Radio Club, W0EEE)

Several co-workers and friends flaunted their amateur radio gear and goaded me into joining their ranks last year. Many hackers carry a ham license, or are getting interested in the hobby. Still, some people occasionally ask me "what's the point? We have smartphones and the Internet now." It's true. The telephone as we know it has indeed enjoyed evolution at a breakneck pace. My co-worker's Nexus LTE sucked 20 megabits per second out of thin air the day he got it. I don't even get that kind of pipe to my home. Still, to me, there's always been something about amateur radio that can't quite be compared with the Internet or mobile phones. I'll explain just a few of those things, from my own novice perspective.

In 1987, I saw an amateur radio demonstration that was given to my scout troop in the middle of Nebraska. With a brick-like walkie-talkie weighing more than a pound and about the size of two Wiimotes side by side (not counting the big rubber antenna on top of it), the presenter was able to communicate with others several counties away, and even place telephone calls. He said that with a bigger antenna and more powerful radio at home, he could talk to people all over the world, all without relying on telephones or even the power grid, because much his radio equipment could be powered by car batteries.

This blew my 8-year-old mind. It was nothing like my little walkie talkies at home. I wanted to be a ham, and even put in some work toward it, but I simply wasn't ready. The urge hit me in waves on occasion. In high school, I experimented with CB. In college, I took some interest in those FRS walkie-talkies that are now ubiquitous in every department store. A few classmates were amateur radio operators, and I got the itch again, but never really got the motivation to get licensed. It would go on like this for many years. For me, it took a friend in California selling me some of his used radios for cheap. At that point, I had the equipment in my hot little hands, but I didn't have a license to use them for anything other than listening. That lit a fire under me.

Aside from their size (owing to advances in surface-mount electronics and battery performance), the most basic hand-held ham radios haven't changed a whole lot in the last 20 years. For reference, my smallest radio is about the size of a closed Motorola StarTAC, but packs nearly as powerful a transmitter as the giant brick radio that had me awestruck more than 20 years ago. Most hand-helds work on the FM Voice part of the VHF band (~144 MHz) or the UHF band (~440 MHz), or both. Some operate on other bands as well. Transmit power from 300mW to 5W is common. Although these smaller radios are most often used to contact a high-power repeater, they can also be used directly between licensed amateurs over shorter distances with some rules and restrictions noted. They have more power and better antennae than FRS radios, and can be connected to an externally-mounted antenna if desired. They're great for highway convoys and outdoor activities. Many hand-held transceivers are capable of tuning in a very wide range of frequencies, so they can be used somewhat like analog non-trunking scanners and frequency counters for finding and listening to public safety, railroad, airport or rent-a-cop chatter. More on that in a separate article.

Repeaters are usually mounted on radio towers, tall buildings or up in mountains. They recieve on one frequency (an input frequency), then transmit what's received in real-time on the output frequency, allowing one-to-many conversations over a relatively large region within a 20-50 mile radius. Radios designed to be used with repeaters are able to automatically switch to a repeater's input frequency when transmitting. Repeaters are often linked together via high-power point-to-point radio links, telephone lines or digitally over the Internet. Some repeaters are actually built into satellites in space, covering extremely wide areas, but those can be a challenge to use as they traverse the sky. Many repeaters have redundant power, via battery and generator backup. And yes, a lot of this stuff is very similar to what existed 30 or more years ago, save for the Internet-connected repeaters.

Hams are often called upon to help where efficient communications are desired. You're likely to find amateur radio operators volunteering behind the scenes helping marathon or charity bicycle ride officials locate event participants in need of assistance, providing the National Weather Service with critical storm data from the ground, or establishing point-to-point radio links with nearby hospitals and participating in relief efforts in communities whose infrastructure has been crippled by floods, tornadoes, hurricanes or earthquakes. All of this is made possible because hams know how to communicate efficiently in groups, and their equipment isn't completely disabled by disruptions of complex infrastructure (although, as noted, infrastructure such as the power grid and telecom is often used when available.)

Many people think of morse code when they think of ham radio. Morse code is still in use, but you no longer need to know it to get licensed by the FCC. Morse code is essentially a human-comprehensible binary mode of communication. There are several other digital modes available, allowing you to blend technologies, and some common modes rely on AX.25 packet data. You can run a packet radio BBS over the air if you like, or transmit your GPS coordinates while hiking through the woods or helping disaster relief efforts. Some of these digital modes are extremely efficient, use very little bandwidth, and can be easily received from long distances, even if they aren't transmitted with much power. Conversely, hams can also enjoy many parts of the amateur bands, including parts of the 2.4 GHz spectrum (with some overlap on WiFi channels) with up to 1500 watts.

Although some hams might seem like retro-grouches with their morse code conversations, technology doesn't stand still with amateur radio! There's a very hearty "do it yourself" spirit here. Many participants might very well be considered radio hackers. They build their own transmitters, recievers and repeaters, and most of them are -- by nature -- gifted problem solvers.

Check out this video from ARRL for some more info.



What's it take to get licensed? There are three classes of amateur radio licenses in the US. In order from lowest to highest, they are Technician, General and Extra class. The exams are multiple-choice quizzes, each coming from a pool of several hundred possible questions. The Technician and General exams have 35 questions each, while the Extra exam is 50 more challenging questions covering material that's ostensibly arcane. The test to get each license requires progressively more depth of knowledge in safety (RF exposure, antenna towers, grounding), electronics, FCC rules, transciever and antenna designs and other information that proves the licensee understands the craft well enough to safely operate their own station. Each higher license class grants access to transmit on more frequencies, usually in the lower frequency bands that are more useful for reliable long-distance communication.

Since the question pools and study materials for licensing are publicly available, I studied the Technician material on my own for a few weeks before acing the technician exam. Most major metro areas have groups that give frequent classes, and all metro areas have volunteer examiners who will administer the test to those who have studied on their own.

I may upgrade to the General class license this year, but I'm honestly a lot more interested in the merge of digital technology with amateur radio. The Technician class license allows me to operate digital and "sideband" voice on the 10 meter band, but there's a lot of digital stuff in the higher frequencies that Technicians are allowed to use.

If you are interested in learning more about amateur radio but can't seem to find anything in your area, post away in the comments and I'll see if I can help you out.

Intro to javascript malware analysis

I am by no means an expert on this stuff. A few weeks ago, I ran across some suspicious links in spam and decided to see where they led. Some of them claimed to be from financial institutions that I have absolutely no connection to, and claimed that some transaction had failed to occur. Others were variants of shipping confirmation scams, pharmacy junk, etc. I wish I could say that I have no idea how people fall for these, but the fact is that some people will literally click on anything that shows up in their inbox, open any attachment and follow any link, no matter how blatantly fake we professionals think these scams are.

What lay at the tail end of all the script="http://some-site/whatever.js" includes and document.location redirects? A webpage that'd been owned, filled with a huge pile of nonsensical jibberish that could barely pass as javascript, which happened to be part of the Blackhole Exploit Kit.

I've done my share of picking apart obfuscated javascript before, but it had been a while. I gave a presentation of this same thing at KC2600 a few weeks ago. Then, this week, a colleague of mine who missed the meeting ran into the same thing in the wild. I passed on what I'd learned, and decided it might be time to write it up with a little more detail than I did a few weeks back. He made this quick video that covers how he was able to de-obfuscate this particular sample:



By now, I've seen several different obfuscation schemes for BlackHole, but once it's decoded, it all looks about the same.

The introductory basics are simple. Minimize the potential of infection by using a non-privileged account (and perhaps an OS other than Windows) and/or minimize the impact of a successful infection by running a virtual machine that you can blow away or revert to a snapshot of a known clean state. For the malware I'm using in this example, either (or both) of the above criteria will be ample to keep things from getting out of control. Other malware may be more insidious or may target non-Windows platforms. I have a few friends that have unwittingly infected their own workstations while trying to analyze things. Play safe.

Once you have a safe lab environment, your goal is to examine a suspicious link and dissect it.

In my case, I was able to find a few links to malware in my personal mail's spam folder. For the demo at KC2600, I used Malware Domain List to find some Blackhole samples.

In the wild, there may be any number of redirects ahead of the malware. You may see a shortened URL (through goo.gl, tinyurl, etc) which goes to a sparse HTML page with several calls to javascripts hosted on various sites, and those javascripts may simply be a document.location pointing to the malware. I usually stick with curl or wget to pull down suspicious links, and then I keep looking at the content and following the redirects until I strike gold.



The javascript itself is ugly once you get to it. Sometimes, the byte array is only a few (really long) lines. Other times, like this sample, each byte of the obfuscated data is on a new line, like this:


You'll see a few interesting things. There's an "e=eval;" line near the bottom, and then "e(c);" after that. It doesn't take a coding genius to realize that this is a way to call eval(c) without triggering some IDS signatures that look for "eval(". Many samples I saw weren't quite this obvious. In fact, the script in the video has the eval alias in a different part of the script and varies in several other ways if you look closely.

To turn this cryptic payload into something that resembles actual javascript, there's a post on SANS ISC from several years ago covering a few methods. I went with the so-called Tom Liston Method, essentially trying to wrangle the decoded stuff that was destined for the eval function into a document.write within a textarea box instead. Note: I ran into one sample of BlackHole that has a /textarea tag near the beginning, which would keep someone from using this trick to easily view the code with this trick, but I don't think it will eval the stuff behind it since it's been changed to a document.write.

In the above example (and in the video), the content that is destined for eval is stored in variable "c", so you simply replace "e(c);" with:

document.write("<textarea cols="150" rows="100">" + c + "</textarea>");

But obviously, you need to use some brain power here to figure out what trickery they're using to call eval, and what the variable is that needs to be wrapped up in the above document.write command. You may also wish to mess with the rows and columns on the textarea. I know on my netbook, that textarea size is far too unweildy. On my desktop, it's almost perfect.

Make sure the file is renamed as a .html, then load it up in your safe lab environment's browser, just in case something goes wrong.



Voila. If you scroll through recent versions of BlackHole Exploit Kit, you'll see that it tries to load an embedded java applet and a PDF, both of which are designed to exploit recent vulnerabilities in JRE and Adobe Reader. Since I don't have Windows running in a VM environment (and I'm not keen on actually infecting any of my Windows boxes) I'm not entirely sure what gets loaded from there. I'm guessing the carberp trojan, given most of what I've read lately. If that's the case, a successful infection would likely block access to anti-malware sites, try to sabotage existing security software, and start gathering sensitive data such as card numbers and online banking credentials.

UPS Battery Hackery: Not highly recommended

Step 1: Disassemble UPS (not shown). That includes unplugging it and removing the battery, and taking the outer shell off. This was a dumpster rescue that was missing the battery entirely. Be careful. Lots of capacitors and transformers inside. See the disclaimer in the title. Not highly recommended.

Step 2: Drill a hole in the case, near where the battery wiring harness enters the battery chamber. I used a 1/2" drill bit for this.

Step 3: Make a grommet. I used some silicone air hose for my aquarium, cut a length of it, then split it. I used a few separate pieces.

Step 4: Re-assemble, Hook up a much bigger battery than what's supposed to be inside.


I accept no blame for any of the many things that could possibly go wrong with this.

Shell Script: Parse Juniper firewall logs

Juniper firewalls (at least the ScreenOS-based one I have in the lab) have an interesting format for their syslog entries. It's a whole line full of variable=parameter type stuff. Usually, these are in a pretty predictable order, but you can't rely on the nth parameter to be the same in every log entry just due to the fact that different types of traffic have different parameters. You don't see a source or destination port on ICMP traffic, for example.  This script reads a log file (I'm using Syslog-NG in the lab), splits the entry up into one parameter per line, grabs only parameters matching the list you provide on the command line, then stitches it back together into one line. I saw no benefit in trying to make the output order match the order provided on the command-line, since some columns are prone to be blank in certain situations anyway. This is quick and dirty, but it does the job for what I need, and I thought I'd share.

axon@moo:~$ ./juniper-parse.sh

Parse columns from Juniper firewall logs
  Syntax:
  ./juniper-parse.sh logfile column [column ...]

Common columns:
  action, device_id, dst, dst_port, duration, ip,
  policy_id, port, proto, rcvd, reason, sent, service,
  session_id, src, src_port, start_time, zone


Here, you can see some of my lab machines trying to fetch updates from an Ubuntu mirror, getting denied because I only allow requests through my proxy server:

axon@moo:~$ sudo ./juniper-parse.sh /var/log/firewall.log action policy_id proto src dst dst_port

2011-11-13T08:35:09-06:00 policy_id=12 proto=6 action=Deny src=192.168.42.75 dst=91.189.92.169 dst_port=80
2011-11-13T08:35:09-06:00 policy_id=12 proto=6 action=Deny src=192.168.42.112 dst=91.189.92.169 dst_port=80
2011-11-13T08:35:10-06:00 policy_id=12 proto=6 action=Deny src=192.168.42.171 dst=91.189.92.169 dst_port=80
2011-11-13T08:35:13-06:00 policy_id=12 proto=6 action=Deny src=192.168.42.171 dst=91.189.92.169 dst_port=80
2011-11-13T08:35:15-06:00 policy_id=12 proto=6 action=Deny src=192.168.42.77 dst=91.189.92.169 dst_port=80
2011-11-13T08:35:18-06:00 policy_id=12 proto=6 action=Deny src=192.168.42.75 dst=91.189.92.169 dst_port=80
2011-11-13T08:35:18-06:00 policy_id=12 proto=6 action=Deny src=192.168.42.77 dst=91.189.92.169 dst_port=80
...

Script below:

#!/bin/sh
#juniper-parse.sh
if [ $# -lt "2" ]
then
echo "
Parse columns from Juniper firewall logs
  Syntax:
  $0 logfile column [column ...]

Common columns:
  action, device_id, dst, dst_port, duration, ip,
  policy_id, port, proto, rcvd, reason, sent, service,
  session_id, src, src_port, start_time, zone

"
exit 1
fi

filename=$1; shift
until [ $# = "0" ]
do
  pattern="$pattern -e ^$1="
  shift
done
while read line
do
  timestamp=`echo $line | cut -f1 -d" "`
  echo "$timestamp `echo $line | tr ' ' '\n' | grep $pattern | tr '\n' ' '`"
done < $filename

OpenBSD 5.0: Apache, PHP and MySQL

The basic steps for taking a bare-bones install of OpenBSD and adding an AMP stack for web applications hadn't changed much in the past 2 years. Although 5.0 is not seen as a "major update", but simply a continuation of the normal development cycle, the OpenBSD team did a few things that make the installation a bit different this go around. I'll cover some of the recent changes to OpenBSD and its packages in this post, then you can dive right into the updated OpenBSD Chroot Apache, PHP, MySQL setup guide.

Initialization scripts: Starting with OpenBSD 4.9, the RC scripts became modular. This is similar to how NetBSD and FreeBSD have worked for many years. Individual daemons have startup scripts in /etc/rc.d, but rc.conf, rc.local and rc.conf.local still work the same, so it wouldn't surprise me if many OpenBSD users didn't even notice the change. It seems like OpenBSD 5.0 packages for most of the popular services (samba, cups, postgres, etc) are actually creating these startup scripts now. If a third-party application from packages installs a startup script in /etc/rc.d, you can add it to the pkg_scripts variable in /etc/rc.conf.local like so, and it'll magically start.

pkg_scripts="mysqld cups samba"

See the OpenBSD man page for rc.d for more details.

MySQL and chroot: I'm not sure why it didn't dawn on me before, but one really simple way around hard-linking MySQL's socket file into the chroot environment is to simply have your web applications connect to MySQL's TCP port on 127.0.0.1 (not localhost, because that means "use the socket file" in MySQL-ese) I think I'll be doing it this way in the future.

PHP: PHP 5.3 added a lot of features, such that PHP 5.2.x and PHP 5.3 might as well be different major version numbers when complex web applications are considered. OpenBSD 5.0 adds packages for PHP 5.3 for the first time, but PHP 5.2 is still available in the repository. For this reason, the PHP core and module packages are no longer prefixed by php5-, they're just php, php-mysql, etc. Since PHP 5.2 is still supported, the version numbers are used to distinguish them, like this:

$ sudo pkg_add php-mysql
Ambiguous: php-mysql could be php-mysql-5.2.17p3 php-mysql-5.3.6

Further, some configuration file locations have been changed. If you pay attention to the text after installing packages, this shouldn't make much difference. Hint: you can always re-read the post-install notes afterward by using pkg_info -M.

All in all, the recent changes to OpenBSD are welcome. Some of the things I outlined here are areas where OpenBSD had some catching up to do. They've managed to do a lot of proactive stuff in the realm of hardware support and (of course) security and encryption. This is still one of my favorite platforms to tinker with.

BSidesKC Videos

I actually didn't get to present anything this year. Not for any particular reason. All the talks were awesome and they tied together pretty well. It took me a while to get UStream working on my phone, via 3G. Also, not all the videos worked or uploaded properly, so my apologies in advance for not getting all the talks, and for the crappy video quality, especially on the slides. Slides should be online soon, though.

Here are my archived UStream videos, though. There are only 4 from BSidesKC, and then some older stuff from Maker Faire.

As for my talk on remote pentest appliances: It's probably best I didn't get a spot this year. Turns out that those 1 million writes (or whatever) that USB flash drives are good for go by pretty fast when you're running a full operating system (with databases, etc) direct from the drive for a few months straight. My demo platform died a week ago. I had backups, but I have some re-thinking to do. I'd probably best stick with external 2.5" drive enclosures for this project. I'll be documenting it properly.

Bulk date conversion with GNU Date

GNU's version of the date command (which ships with almost all Linux flavors) can accept an arbitrary date and/or timestamp as input to display. Combined with the output formatting feature found in all posix flavors of the date command, you can use it to convert almost any format of date or time to a standard format.

axon ~$ date --date "yesterday"
Tue Oct 11 07:47:33 CDT 2011

axon ~$ date --date "Saturday, August 19, 1989"
Sat Aug 19 00:00:00 CDT 1989

axon ~$ date --date "21-APR-2001" +%Y-%m-%d
2001-04-21

So if you have a bunch of dates or timestamps, one per line, that you wish to convert:

axon ~$ cat file
1/21/2011
2/5/2011
2/10/2011
2/20/2011
3/7/2011
3/22/2011
4/16/2011
4/21/2011
4/26/2011
5/21/2011
1/24/2011
2/1/2011
3/6/2011
3/9/2011
May 25, 2011
6/23/2011
7/23/2011
8/10/2011
9-SEP-2011
Sat Sep 10 00:00:00 CDT 2011

... say to ISO 8601 Year-month-date format , you can knock it out easily like this:

axon ~$ cat file | while read line; do date --date "$line" +%Y-%m-%d; done
2011-01-21
2011-02-05
2011-02-10
2011-02-20
2011-03-07
2011-03-22
2011-04-16
2011-04-21
2011-04-26
2011-05-21
2011-01-24
2011-02-01
2011-03-06
2011-03-09
2011-05-25
2011-06-23
2011-07-23
2011-08-10
2011-09-09
2011-09-10