HiR Information Report

OpenBSD 5.3 Released

noreply@blogger.com (Ax0n) — Tue, 07 May 2013 16:36:00 +0000

OpenBSD 5.3 was released on May 1. (I told you I'm running behind!)

There are many enhancements and changes, including some much-needed tweaking to dhclient, making it a little less frustrating to use. While updating the nginx/MySQL/PHP-FPM how-to, I noticed that nginx is now defined in rc.conf like Apache has been for quite a while, so the setup procedure changed ever so slightly. The Apache/MySQL/PHP how-to remains basically unchanged, and it'll continue to be maintained so long as Apache is available in either the base distribution or from ports/packages.

xkcd on local administrator rights

noreply@blogger.com (Ax0n) — Tue, 07 May 2013 16:25:00 +0000

Yes, I know, I'm running way behind, aren't I?

The thing is, authorization to your web-based accounts isn't why we recommend using an unprivileged account for your daily computing use. On Windows, OS X and most popular desktop distributions of Linux, the first account that's created has administrator-level access. Increasingly, privilege escalation tools such as sudo, UAC and keychain access have made it to where you have to authenticate in order to make dramatic changes to the system (such as install drivers) but this protection can often be disabled or wholly bypassed.

In any case, an administrator-level account on a computer can not only install drivers and software, but may unwittingly allow malware to set its hooks deep into the operating system. It's for this reason that people recommend setting up another user-level account without privileges to install software.

As for protecting your sensitive data inside that user-level account, full-disk encryption is the way to go. This feature ships standard (although it is disabled by default) with OS X, many popular Linux distribution, and even the premium and enterprise versions of Windows. FDE has its flaws, but it's better than nothing.

Decoding obfuscated JavaScript: Shell Script Edition

noreply@blogger.com (Ax0n) — Sun, 24 Mar 2013 18:33:00 +0000

I've been playing with a bunch of malware lately. Most security researchers have run across obfuscated JavaScript, and we all have our favorite ways of defeating it. I'd written about one way to decode this sort of thing back in 2011.

Why bother decoding this stuff? Because encoded within this mess is another URL. Depending on the source of the obfuscated code it may be a link to a page full of exploit payloads or something similarly sinister. Unwrapping the layers of malware allows researchers to find out where the bad guys are actually hosting their stuff, and helps us identify providers who are willing to help with or at least turn a blind eye to cybercrime operations.

Lately, I've become more determined to handle javascript de-obfuscation outside the browser. Over the last year or so, I've been experimenting with a bunch of techniques to make sense of blocks of code that look like this:

I think it goes without saying that this looks like a monumental pain in the ass. The truth is, it's not as bad as it appears, but I didn't say it was going to be easy.

First, the basics. In JavaScript, FromCharCode() turns a decimal number between 0 and 255 into its ASCII character counterpart. You've all seen the ASCII table, right? Same thing.

I found a way to use printf in most shells to create a similar behavior, and I called this function "chr". So let's start really simple. Here's a file containing a message encoded with CharCodes, and a quick way to decode it. It simply reads each number in (by replacing , with a space and using a for loop, then prints each character one at a time.

This is the basis for the rest of what we're about to do. Let's break down that obfuscated javascript:

The yellow highlighted area is a bunch of numbers separated by the letter w. This is stored in an array labeled "f". If you look after the yellow, you can see that the code uses the letter w to split it.

The blue highlighted area is the loop that handles decoding the numbers into characters. This is obfuscated code, so by definition they've made it a bit confusing, but the end result is that they keep appending each character to the end of the "s" variable.

The bulk of the conversion of number to charcode (ascii decimal number of the character to be rendered) is here: (w[j]*1+41)

This gets us to the essence of the article: You'll need to use some brain power. The first thing I do is turn the data block into a string of comma-separated numbers so they're easier to work with, and I put these in their own file, like so. You can do this inside a text editor with search/replace, or on the CLI if you like.

Then you need to figure out the math. In our example code, what is w? what is j? You'll probably run into a bunch of bizarre variable reassignment when trying to make sense of obfuscated code like this. Looking above, you can see between the yellow and blue blocks, w=f. So w is now a copy of that array full of numbers. Inside the blue block of code, you can see that j=i. So, w[j] points to the current number in the array. But this number isn't the CharCode. There's still the "*1+41" part to deal with. Manually, we can see what's going on here. This is a very simple algorithm. The first 3 numbers are -32,-32,64.

-32*1+41 = -32+41= 9 - CharCode 9 is a tab.
64*1+41 = 64+41 = 105 - CharCode 105 is a lowercase "i"

Doing this manually would suck. The algorithm here is obvious. The CharCode is the number, plus 41. That's it. Let's decode it with my script:

So what happened here? This is the source of my relatively simple script.


#!/bin/sh
# Obfuscated JS Decoder
# Ax0n - 2013-03-22
# ax0n@h-i-r.net
#
if [ -z "$1" ]
then
  echo "$0 codefile algorithm"
  echo "c = placeholder for each number"
  echo "i = iterator"
  exit 1
fi

chr() {
  # http://mywiki.wooledge.org/BashFAQ/071
  # Turns a charcode into the ASCII byte
  printf \\$(printf '%03o' $1)
}
count=0
file=$1
shift
algo="$*"
for code in `cat $file | tr "," " " `;
do
  chr `echo "$algo" | \
    sed -e s/"i"/"$count"/g -e s/"c"/"$code"/g | \
    bc | cut -f1 -d\.` | tr -d "\r"
  count=`expr $count + 1`
done
echo
echo "----- done ----"

At the heart of the above script is a nifty function I found in the Bash FAQ. And then, I used a pair of sed expressions to replace the "i" and "c" placeholders within the loop that handles the output. We call on the "bc" command-line calculator to work all the math magic. tr -d "\r" fixes some broken newlines found in some of the samples I decoded. Let's see it in action:

Now, let's look at the one in the video. It has a much more complicated algorithm than simply adding 41 to each digit before converting it to the ASCII byte! It's hard to read in the video, so here it is:

Fortunately, this one already separates the codes with commas, so we can pretty much just copy and paste the numbers into a text file for decoding. As you can see on the 3rd-to-last line, the algorithm it uses for each character is this:
((w[j]*1+e(x+3)+11))

Let's tear into it, shall we?
w[j] starts out just like the last example. We can see they set j=i and w is a copy of the array, so for each iteration, this is the digit. We can replace this with "c" in our algorithm expression.

That leaves us to figure out what e and x are. Also like the last example, e is set to "eval" at the end of the second line. We'll ignore it. Let's look for x= in the code.

There it is! j% - and remember, j = i, so it's the iterator. % is a mathematical modulus operator. -- that is, it divides two numbers and the output is the remainder. Example: 17 divided by 4 is 4 with a remainder of 1.
$ echo "17 % 4" | bc
1

(x+3) becomes essentially, (i % +3) and +3 just means "positive 3" in this context. We don't even need the +.

((w[j]*1+e(x+3)+11)) becomes ((c * 1 + ( i % 3 ) + 11)) or simply "c + ( i % 3 ) + 11"

You can see these two examples plus two more here (the password is "infected"):
http://stuff.h-i-r.net/bhlog.zip

ISO-8601

noreply@blogger.com (Ax0n) — Wed, 27 Feb 2013 23:46:00 +0000

This. So much this.

In C:
#include <stdio.h>
#include <time.h>
#define SIZE 0x100
int main ()
{
    time_t t;
    char buffer[SIZE];
    struct tm ltime;
    t = time (0);
    localtime_r (& t, & ltime);
    strftime (buffer, SIZE, "%Y-%m-%d", & ltime);
    printf ("%s\n", buffer);
    return 0;
}

In Bourne-derived shell:
#!/bin/sh
iso8601=`date +%Y-%m-%d`
echo $iso8601


In Perl:
#!/usr/bin/perl
use POSIX qw/strftime/;
my $date = strftime "%Y-%m-%d", localtime;
print "$date\n";


In Ruby:
#!/usr/bin/ruby
iso8601 = Time.now.strftime("%Y-%m-%d")
p iso8601


In PHP:
<?php
$iso8601=date('Y-m-d'); 
print $iso8601."\n";


In Python:
#!/usr/bin/python
from datetime import date
iso8601=date.today().isoformat()
print iso8601

Got it? Good.

Making a bootable USB installer for OpenBSD

noreply@blogger.com (Ax0n) — Wed, 13 Feb 2013 01:11:00 +0000

When I first installed OpenBSD to my netbook, I had tried several ways to get the ISO written to a USB stick including unetbootin, using dd to directly write the image to USB, and a few other tricks. The Googles showed me a workable yet rather complicated way to do it, but that sounded like a pain in the butt. I didn't have an external USB optical drive, but I had the hardware to hack one up. This is really how I did that first OpenBSD install:

Earlier, I had actually installed OpenBSD to a USB stick, and run the whole system directly from USB, including a swap partition, logs going to /var and the whole nine yards. OpenBSD's gratuitous logging and swap utilization killed that USB stick in a matter of months after daily use, but the thought hit me to use that same method here. By default, the bsd.rd package is installed to the root filesystem to use in a recovery situation. This is an initial ramdisk, a bare-bones userland with just enough tools to install or rescue a system. So that's what we're going to do. The TL;DR goes something like this:

Boot a desktop from the boot CD
Insert the USB stick you wish to use
Choose "Install" from the CD's menu.
Format the USB stick, and install OpenBSD to it. If it's a 4GB stick or larger, the default partitioning scheme will work great. Otherwise, make one root partition without swap. Install only the base, bsd, bsd.rd and etc packages.
After install, re-mount the cd and copy the install files to the root partition.
Create an etc/boot.conf file on the USB stick (mounted to /mnt) with "bsd.rd" as the first and only line.
Shut down the system. The USB stick will now boot on most servers and netbooks lacking optical drives, and will go directly to the installer. All the OpenBSD install packages will be right there on the USB stick.

Here's the walk-through.

I booted up the system, and after the installer menu popped up, I plugged in my USB stick. I did this to make it obvious what its device id is. You can tell it's sd0 in this image. Adjust accordingly. At the menu, I chose "I".

You can see I'm choosing sd0 here. Again, use the right device, or you may damage important filesystems.

I just rolled with the default partition sizes here. The install files are a little over 100 megs, so they'll fit in the root partition. If you're an avid OpenBSD user, feel free to mess with the disk options here, but the defaults work well on a 4GB stick (the smallest I had laying around).

When the time comes to install sets, the only ones you really need to get an installation environment up are bsd, bsd.rd, baseXX.tgz and etcXX.tgz (where XX is the release number) - I had an official OpenBSD 5.1 install set at my desk, so I used it for this example. The numbers will change for each release, but the process works the same.

When the installer exits, it will un-mount the CD. You'll want to re-mount it to copy the install sets to USB. Also note that I set mnt/etc/boot.conf to "bsd.rd" - This forces the USB stick to boot directly to the installer ramdisk, so you'll be ready to go!

To test, I put the USB stick into my netbook and fired it up.

Voila!

Introducing: nginx/MySQL/PHP stack on OpenBSD

noreply@blogger.com (Ax0n) — Sat, 03 Nov 2012 06:35:00 +0000

While our walk-through for Apache/MySQL/PHP on OpenBSD is quite popular, the upgrade documentation for OpenBSD 5.2 is quoted thus:

nginx (see also nginx(8)) has been added to OpenBSD, ultimately to replace the Apache 1.3 derived httpd(8). For new installations, you are encouraged to utilize nginx rather than httpd, existing installations are encouraged to start planning replacing the stock httpd with nginx.

With Apache 1.3 being awfully long in the tooth, most of us saw something like this coming. With that, there's a new walk-through that covers the basic configuration of nginx, MySQL and php-fpm to create a working, secure and chroot-enabled web application environment in OpenBSD 5.2.

Introducing: The OpenBSD nginx/MySQL/PHP stack

OpenBSD 5.2 Released

noreply@blogger.com (Ax0n) — Fri, 02 Nov 2012 11:52:00 +0000

OpenBSD 5.2 was released yesterday; That means it's time to update the OpenBSD Apache/MySQL/PHP page!

Some changes I noticed right away while updating the walk-through:

pkg_add defaults to interactive mode. For example, when trying to resolve ambiguous packages (multiple versions available in the repository), it prompts you for which package you want to install. It will also do this for dependencies, and may ask other questions during installation.
The MySQL Server package comes with an optional-use script to help lock down MySQL and remove all test data.

You can see the detailed changelog for more details. I noticed that nginx ships by default now, and that there have been other improvements all around. This post is even coming from within Chrome on OpenBSD 5.2.

MySQL logging for OSSec

noreply@blogger.com (Ax0n) — Sun, 28 Oct 2012 23:26:00 +0000

From their website: "OSSEC is an Open Source Host-based Intrusion Detection System that performs log analysis, file integrity checking, policy monitoring, rootkit detection, real-time alerting and active response."

I use OSSec in several places. In my home lab and on my web servers (hosted elsewhere) for starters. While OSSec alone can't take the place of an enterprise-grade SIEM, the HIDS component can work well with them. If you're running a relatively small shop on a limited budget, it might be good enough, especially if you're willing to invest some time into tinkering.

I thought it'd be easier to report on OSSec's alerts if it were somehow able to store them in a database. As it turns out, OSSec can be made to log much of its information to either MySQL or PostgreSQL, but the documentation is a bit spread out and hard to follow.

First things first, you'll have to (re)compile OSSec, and and you'll need the MySQL bits and pieces for both OSSec MySQL connector as well as a working MySQL server, assuming you want MySQL to work locally with the OSSec server. So make sure you have all the packages you'll need:

sudo apt-get install build-essential libmysqlclient-dev mysql-server

Fetch the OSSec source code and extract it. http://www.ossec.net/

On Ubuntu 12.04 LTS and with OSSec 2.6.0, I had to apply this patch: http://pastebin.com/Pg3pDtr0 - It changes one line in a single Makefile, but it wouldn't compile properly otherwise.

In the "src" directory of the OSSec source code, run "make setdb" and if the proper libraries are installed, you should see something like this:

Error: PostgreSQL client libraries not installed.
Info: Compiled with MySQL support.

Before you install OSSec, you need to create the database, add a MySQL user for OSSec to use, and import the schema. You can change the username and password below to suit, obviously.

mysql -uroot -p[password]
mysql> create database ossec;
mysql> grant INSERT,SELECT,UPDATE,CREATE,DELETE,EXECUTE on ossec.* to ossec@localhost;
mysql> set password for ossec@localhost=PASSWORD('53Cr37p4ss');
mysql> flush privileges;

cd src/os_dbd (in the OSSec source code directory)
mysql ossec -uossec -p53Cr37p4ss < mysql.schema

Go back to the OSSec source code base directory, and run install.sh (as root or with sudo) - Your options will vary, but the defaults are usually sane.

Once OSSec is installed, you need to add the following snippet to the end of ossec.conf (usually in /var/ossec/etc) - Remember to make sure you edit this to reflect your actual database information.

<ossec_config>
    <database_output>
        <hostname>localhost</hostname>
        <username>ossec</username>
        <password>53Cr37p4ss</password>
        <database>ossec</database>
        <type>mysql</type>
    </database_output>
</ossec_config>

To enable the ossec-dbd database logging, you must run /var/ossec/bin/ossec-control enable database

Restart ossec (/etc/init.d/ossec restart) and you should be good to go. On my installation, OSSec immediately begun populating the "signatures" table, and after a short while, alerts were logging to the "alert" and "data" tables.

My next step is to generate some scheduled email summary reports, but all in all, having logs in a database will certainly make poring through them a much easier task.

Emergency power show-down

noreply@blogger.com (Ax0n) — Wed, 01 Aug 2012 04:31:00 +0000

Being an amateur radio operator and a nerd in general, I make sure I have emergency power available. This is in the form of gel cells, several UPS units and of course the obligatory inverter for road trips. I have a solar panel that can put a reasonable charge back into my gel cells with one bright day's worth of sunshine. I don't feel like I need a generator. If the power goes out for a week or two over a wide area, most of my gadgets will be marginally useless, and I'm pretty comfortable living without electricity, as I go backpacking and camping frequently.

I do use my netbook for certain digital modes with amateur radio, and I could see it coming in handy for emergency operations. Considering the electronics I might choose to use sparingly in a power outage, I did some experimentation over the weekend.

My netbook requires 19VDC, and It seemed silly to me to turn DC into AC, and step it all the way up to 120 volts, just to step it back down, rectify and filter it for devices that fundamentally operate on DC to begin with. The same goes for desktop PCs that take 120VAC and turn it into +-12VDC, 5VDC and 3.3VDC. The rest of my "ham shack" runs fine on car batteries. Why not my computers?

In all of the following photos, you'll see amperes on the display, but I'll reference watts. The battery pack was sitting at 13.2 volts for all of these tests.

To baseline this thing, I went with the obvious choice of plugging into one of my UPSes. I have a feeling this is how most folks would choose to operate their computer in a power outage if it were an option.

The UPS consumes a paltry 5 watts without a load. This is looking pretty good.

Plugging the power brick in bumps consumption up less than a watt for a total of about 5.7 Watts.

With the laptop booted up and running on the UPS, battery consumption tops out at around 20 watts. I noticed numbers higher than 1.5 amperes momentarily. One of our cats also has some obsession with laying on warm electronics such as power bricks.

Next, I tried my 450 Watt inverter. Without a load, it uses about 6.6 watts. Not terribly surprising. It has two noisy fans and a display to power as well.

Plugging the power brick in without any load bumped consumption up to 7.1 watts. This is similar to what happened with the UPS, but still less efficient.

Attaching the netbook spiked the load to about 43 watts total. Ouch!

Finally, I tried operating my laptop on a DC-to-DC power supply. This was vastly more efficient than relying on an inverter, and considerably better than my UPS as well. The DC-DC converter consumed 11 watts from my battery pack.

The clear winner is obviously the DC-to-DC converter. If the laptop were the only thing in use, I could expect about four times the run time from the DC converter compared to using my inverter.

The DC converter I used was originally for a Macintosh G3 PowerBook, and was set for 24 VDC. My netbook requires 19VDC, and I was fortunate enough to find a set of potentiometers on my old DC-DC supply to allow me to adjust the voltage, and then I hacked a plug onto it that works for my netbook.

Most laptops require somewhere between 15-24 VDC, and are sensitive to dirty power. Good DC-DC converters are capable of dealing with 10-30+ volts of input and provide stable, clean power on the output suitable for sensitive electronics. They're easy to find, if a little pricey compared to traditional transformer bricks. They are often sold as "Laptop Car Chargers"

Similarly, a company called PicoPSU makes a tiny solid-state DC-to-DC power supply that plugs directly into a computer motherboard's ATX connector and provides power cables for a few hard drives or other peripherals as needed. They're not designed to run powerful desktops or servers, but work fine for lower-power workstations or "book PCs." You'll have to find a way to power a monitor, though. Hint: many LCD displays can be powered by a DC-DC converter, too.

Westlake Hardware: My hackerspace?

noreply@blogger.com (Ax0n) — Wed, 25 Jul 2012 01:59:00 +0000

It started as a simple trip to the hardware store. My mission was to find some 3/8" threadrod at 24 threads per inch. I was going to chop it with my dremel to a length of 6 and 9/32 inches long and use it as a 1/4 wavelength antenna in a mount similar to the one shown above. What I found were many kinds of threadrod, but nothing that would screw into either of my antenna bases.

I opted for a piece of 3/8" smooth rod without threads, figuring I could just wander over to the hardware store's selection of threading dies and pick up the one I needed to cut a dozen or so threads into the rod. There, I found many dies, but not the 3/8" x 24 I needed for the project. There was a spot for the die I needed, but it was empty.

I finally cornered a sales associate, who looked up the part number, said they had one in stock, and even scoured the shelves looking to see if someone had placed it in the wrong spot. What happened next took me by surprise. The associate went around to the back shop, pulled a full set of dies out of the tool chest, found the one I needed, and brought me around to the vise and tossed me some cutting oil and gloves so I could tap threads onto the rod myself. While I was working away, curiosity got the best of him. "What are you building?" he asked. I explained that I was building a very cheap antenna, and explained that I was going to take it home and cut it to length so that it resonated at about 448 MHz. That's about the time he took me over to the chop saw with a cutoff wheel and a bench grinder. He found a couple pair of goggles and we got to work.

So there you have it. I walked in, spent a few bucks on a steel rod, got about 20 minutes of free shop time and left with a finished product. Westlake, you're like having a hackerspace a mile from home!

Windows SysAdmin trick: All your MMC snap-ins in one spot

noreply@blogger.com (Ax0n) — Fri, 20 Jul 2012 00:10:00 +0000

At work, I frequently deal with both UNIX and Windows servers. My UNIX background has taught me to avoid logging in to systems -- even workstations -- with an administrative account unless you really need to use the power, even if you're a sysadmin. This works really well until it's time to start managing enterprise-wide settings like AD, DNS and DHCP. There are a variety of ways to solve the problem. Most places provide sysadmins with a user-level account and then an administrative-level account. You can log off from your workstation and log in with a domain administrator account to manage things. That's a genuine pain. You can remote desktop to a domain controller and log in with your admin account. You can even set up a terminal server with RSAT and other useful tools, and have your admins log in to that for routine enterprise maintenance.

Alternatively, you can install Remote Server Administration Tools onto Windows 7 Enterprise, and using a few quick tricks, you can have all of the MMC Snap-Ins you like at your fingertips, while still using an unprivileged domain account on your workstation.

Once you get RSAT installed, you may need to also use "Programs and Features" to enable the Remote Server Administration Tools roles or its sub-roles as desired.

After installing RSAT, you'll notice an "Administrative Tools" item in your start menu, but the tools won't work unless you have domain admin privileges.

There's a trick to launching an authentication prompt before running any program on Windows. Hold shift, then right-click the program, and select "Run as different user." While you can do this to any of the Administrative Tools items in the start menu, We're going to use this trick to launch the Microsoft Management console so that we can make life even easier. Hit Start, then use the search to find mmc.exe. Hold shift. Right click it. Run as different user.

Here, provide a domain administrator account. If you have UAC enabled (as you well should!) you'll be asked if you wish to allow mmc to make changes to your computer. Obviously, you do.

Once MMC is running, select "Add/Remove Snap-Ins" from the File menu. Here, you'll be able to load up a bunch of the individual modules from Start->Administrative Tools all into one MMC window.

Once you have selected the tools you use frequently, you'll have a tree view of your favorite utilities, kind of like this:

Be sure to connect the individual snap-ins to the servers you need, if they require it (Hyper V, DNS and DHCP in the above example need to connect to other servers) and once you have everything configured the way you plan to use it, use the File-> Save menu to stash the configuration file somewhere handy, such as on your network profile or hard drive.

I opted to create a shortcut on my desktop that launches mmc.exe C:\console.msc and I titled it "AD Console." When I run it, I have to remember to launch it with my domain admin account using the trick above. Now, taking care of the day to day tasks on the enterprise is simple.

OpenBSD and Windows 7: Multi-boot

noreply@blogger.com (Ax0n) — Mon, 16 Jul 2012 14:47:00 +0000

A little more than a year ago, I switched my netbook over to OpenBSD 4.9. From the start, the netbook had been set up to dual-boot with Ubuntu or XUbuntu, so those 6 months running only OpenBSD really exposed how much I've come to rely on Windows, even if it's only occasionally. That's fine. I'm not an anti-Windows zealot and I use it every single day at work.

I decided to start from scratch one more time when OpenBSD 5.0 came out, and to attempt to dual-boot Windows 7 and OpenBSD. As it turns out, setting up Windows 7 and OpenBSD to coexist was covered in surprisingly fine detail in the OpenBSD FAQ. I've been running Windows 7 and OpenBSD side by side now for more than half a year. This setup has proven to be more stable than Ubuntu and Windows 7 dual booting, and I'm very pleased with this setup. I urge anyone interested in this to read the FAQ, but this post should give you a taste of what you're in for.

Before I nuked the whole system, I rsynced all of my data to a file server at home, then re-installed Windows from the recovery media. From Windows, I set aside a FAT32 partition for sharing files between the two operating systems, since OpenBSD can only read NTFS, and I left 10GB blank for OpenBSD. From there, the rest of the instructions worked great. Once you have Windows installed and your partitions set up, the short version goes something like this:

Install OpenBSD. DO NOT tell it to use the whole disk. I opted to use only one root partition and a swap partition. For a netbook, this makes quite a bit of sense. You'd rarely want to set up a server that way.

After the installer finishes and before you reboot, copy the partition boot record (first block of the openbsd partition) to a file called openbsd.pbr using dd as in the example below. Be certain to use the raw device and get the partition right. The example command below was taken from the FAQ and is probably going to differ for you.

# dd if=/dev/rsd0a of=openbsd.pbr bs=512 count=1

Copy openbsd.pbr to somewhere useful. I copied it to the Fat32 partition I created earlier on. You could copy it to a usb stick or upload it to another location. You'll need this on the Windows machine. When you reboot into Windows, move this file to the root of c:

Start a cmd.exe window as administrator (Start -> use text box to search for cmd.exe -> right-click it -> Run as Administrator), then set up the boot loader. Ripped directly from the OpenBSD FAQ again:

    C:\Windows\system32> bcdedit /create /d "OpenBSD/i386" /application bootsector
    The entry {0154a872-3d41-11de-bd67-a7060316bbb1} was successfully created.

    C:\Windows\system32>

As admonished before, the {0154a872-3d41-11de-bd67-a7060316bbb1} 
GUID is system-dependent. Note the value you receive when executing, 
and copy it into the following commands:

    C:\Windows\system32> bcdedit /set {0154a872-3d41-11de-bd67-a7060316bbb1} device boot
    The operation completed successfully.

    C:\Windows\system32> bcdedit /set {0154a872-3d41-11de-bd67-a7060316bbb1} path \openbsd.pbr
    The operation completed successfully.

    C:\Windows\system32> bcdedit /set {0154a872-3d41-11de-bd67-a7060316bbb1} device partition=c:
    The operation completed successfully.

    C:\Windows\system32> bcdedit /displayorder {0154a872-3d41-11de-bd67-7060316bbb1} /addlast
    The operation completed successfully.

    C:\Windows\system32>

Additionally, since OpenBSD is going to be my primary OS, I used the bcdedit command line options to further modify the Windows Boot Loader so that OpenBSD is displayed first and loaded by default after a brief prompt.

Upgrading OpenBSD is usually pretty easy. There's only one pitfall when you're upgrading OpenBSD in a multi-boot environment: Make sure you copy the PBR to C:\openbsd.pbr as you did in the initial multi-boot setup before you reboot after the upgrade installer exits. Failure to do this might render your openbsd install difficult to boot. You should still be able to boot your system from the install media if all else fails.

If you've installed packages, you'll need to upgrade them separately. Set the pkg_path variable to a repository for the version of OpenBSD you're installing (5.1 as of this writing) or if you're using my preferred method of using /etc/pkg.conf, edit that file since it'll still be pointing to the older package repository from before the upgrade. Then simply run "pkg_add -ui" through sudo or as root. This will find the new packages and upgrade all that are available. the "i" in the above command tells pkg_add to prompt the user for any questions (resolving dependencies, etc).

Edited to embed a highly relevant xkcd:

Guts of the password hash checker

noreply@blogger.com (Ax0n) — Thu, 07 Jun 2012 23:21:00 +0000

A few folks asked how I put together the password hash checker yesterday. Understand that I was sick and in bed most of the day, and did most of this from my Motorola Droid 4. It was really ugly. A local KC2600'er found a link to the hash dump on a shady Russian website. If you really want the dump of hashes and haven't found it yet, look for combo_not.zip and/or combo_not.txt. I downloaded the file via wget on one of my OpenBSD web servers. The text file was likely made from a Windows environment because it has telltale CR/LF line breaks. The first thing I did was fix the line breaks with sed. This cute little one-liner replaces all CR/LF line breaks with traditional UNIX line breaks so that command-line wizardry will work on it.

sed -i "" 's/.$//' combo_not.txt

Then, I figured I should cram it all into MySQL to make queries against the data less of a pain in the ass. I created a database and user named lihash, then created the DB with only an auto-incrementing ID and a hash column:

create table lihash (id int primary key auto_increment, hash varchar(40));

And then I used some more sed stuff to turn each hash into an "insert" line for MySQL. Here's what the output looks like (limited to the first 10 lines with head):

$ sed 's/^/insert into lihash values (NULL,"/;s/$/");/' combo_not.txt | head
insert into lihash values (NULL,"000000a94d47b9ca82c58a3b092a50263b40f66e");
insert into lihash values (NULL,"000000a9876203148923f97c6f1a0635472e1e38");
insert into lihash values (NULL,"000000a9bf60e7f17fcac444a54791af780743a3");
insert into lihash values (NULL,"000000a97e734e7ed9766d1ce08ebc68d3e93ab2");
insert into lihash values (NULL,"000000a9b4b1b3497aac51e212ac9efdb00e7f4e");
insert into lihash values (NULL,"000000a9affc26ed1b0ef2956825e85f9a2567ff");
insert into lihash values (NULL,"000000a93c829bab8c40f805bd3adec3302edf06");
insert into lihash values (NULL,"000000a9e3686034e4f7a1f5b8d6de92679dba5c");
insert into lihash values (NULL,"000000a966dd229cbdd0c4ccc524f0aff6c0fc31");
insert into lihash values (NULL,"000000a9317a995cb16dec71edf0d3aa4b918de6");

With that looking all fine and proper, I piped all that straight into MySQL.

$ sed 's/^/insert into lihash values (NULL,"/;s/$/");/' combo_not.txt | mysql lihash

It took several minutes to munch through the data and created many megabytes of MySQL binary logs. While that was processing, I scoured the web looking for a decent javascript SHA-1 hashing method so that I didn't have to worry about handling peoples' passwords via my site. You can simply view the source of this page to see how that works. It was mostly copypasta. Finally, there's the PHP that drives it on the back-end. You can see the PHP Source HERE. When I was testing, I had it displaying the hash that was passed. I got rid of that part to keep XSS shenanigans at bay. I'm probably doing all sorts of things wrong with the SQL queries, but I copied some of that database code from another project on that server (I was using a phone for this, remember?)

LinkedIn: Was your password leaked?

noreply@blogger.com (Ax0n) — Wed, 06 Jun 2012 18:32:00 +0000

By now, you may have heard that a list of 6.5 million hashes have been posted to the Internet, and that they appear to be password hashes from LinkedIn. CNet has some of the deets, but there's a great thread on YCombinator Hacker News where some observations are made. Namely, SHA1 hashes for easily-guessed passwords (such as "linkedin" or "password") do not show up in the list, but if you replace the first five characters of the hash with "00000", then hashes do match for simple passwords. This leads to speculation that the attackers have already cracked some of the easy ones and truncated them in the list.

I've made a really quick and dirty web page that will help you check if your password is on the list. It features a nifty javascript SHA-1 digest hash generator so that the password you check never gets sent over cleartext. It will check hash and truncated hash against the dump. If it detects the entire hash, then your LinkedIn password hash is now in the wild, and it's likely only a matter of time until it's cracked. If the truncated version is in the password dump, it's almost certain your password is compromised.

OpenBSD 5.1 Released: OAMP Updated

noreply@blogger.com (Ax0n) — Tue, 08 May 2012 04:02:00 +0000

OpenBSD 5.1 was released last week, so the update is a bit overdue. HiR's Secure OpenBSD + AMP guide has been updated. OpenBSD 4.x is officially unsupported now, so we've dropped the 4.x parts from the guide and refined the rest. Since we've started covering the setup of an AMP stack on OpenBSD, the process has gotten considerably easier. OpenBSD is a completely viable and stable environment for running almost any PHP/MySQL web app, with a little extra consideration given to the chroot environment and Suhosin hardening patches while you're setting up your applications or programming new ones.

Links: Root, Patch and Tether a Droid 2 Global

noreply@blogger.com (Ax0n) — Sun, 04 Mar 2012 04:53:00 +0000

My wife and I have identical phones. She actually got hers before I got mine. Occasionally, I have to tether for troubleshooting, and I set hers up tonight to do the same.

I encountered a number of stumbling blocks the first time around. Fortunately, other people did all the hard work. Here are links I found helpful.

Download the latest SuperOneClick package. You'll have to root your phone. There's no easier way than this: SuperOneClick - Shortfuse

Get the Android WiFi Tether APK from Google Code.

At this point, if you try to tether, you'll run into a similar issue as I've described in previous tethering posts: the authentication string will cause tethered traffic to bounce up against Verizon's wrath warning page.

You'll need to download RadioComm, and the best way to find that is Google. You'll probably find fresh links to recent versions on XDA Devs or MotorolaFans. Caveat Emptor and all that. Shady download links galore, so be on your guard with good backups and malware protection. Here are the instructions to patch your phone's baseband configuration for tethery goodness.

After that, all should work well.

Alinco DJ-C1 Hack: Internal Speaker

noreply@blogger.com (Ax0n) — Wed, 08 Feb 2012 02:38:00 +0000

The Alinco DJ-C1 was made in the 1990s and was a groundbreaking ham radio micro-transceiver about the thickness of an iPhone 4 and with a smaller footprint nearly identical to that of a credit card. It was designed to work on the 2m FM Voice band at 300mW. It featured an integrated microphone, but had no internal speaker from the factory; One had to rely on an earphone or an external speaker/microphone unit such as the one shown above.

Over time, these micro radios evolved. The DJ-C4 came out at the same time as the C1, and was made for 440 MHz (70cm FM Voice). The DJ-C5 was a bit thicker and was the first to have an integrated speaker and work on both of the above bands. The latest one, the DJ-C7, lacks resemblance to these tiny relics of the late 90s aside from being smallish.

You can still find these micro-handheld transcievers at hamfests, swap meets and online auctions. I got mine from a friend that's happened upon two C1s and a C4 in the past year. I was immediately somewhat frustrated by the lack of a built-in speaker. I opened it up and found plenty of room in the back for a piezoelectric element, similar to what you find as the alarm speaker in digital wrist watches.

I couldn't find anything to salvage a piezo speaker out of, so I coughed up a couple of bucks at Radio Shack for one. I used a tiny screwdriver to pry the back cover off and to pry the element out of the case.

Disassembly of the DJ-C1 initially looks pretty straight-forward. There are three small philips screws on the back which give you access to the battery and the back of the circuit board. You'll have to open the back up and you'll want to disconnect the battery before proceeding. Unfortunately, most of the stuff we need access to is on the other side of the circuit board. You can't get the board out from the back, so leave the screws through the circuitboard attached. To remove the front plate, carefully peel the sticker and membrane buttons off, then remove the three screws found underneath.

There aren't many places to pass wires from the back of the radio where the speaker will be to the front of the radio where they can attach to the solder pads for the audio jack, so I ran them between the legs of the transmit LED. With the front and back removed, you can slide the circuit board out of the rectangular plastic frame enough to get access to the solder pads with almost any kind of soldering iron. You can see the red and black wires here:

I taped the piezo element to the back case toward the bottom. The copper shield in the middle of the circuit board seen below will sit flush against the back case, so keep the speaker and wires clear of it. The piezo speaker is actually louder when it's taped to the back case than it is when it's hooked up to the audio jack by itself.

Gently re-assemble everything, making sure everything fits neatly inside. Re-position the speaker and wires as needed. I ended up placing a bit of tape inside to keep the speaker wires from getting in the way. Re-connect the battery, screw the front plate back on, re-attach the membrane buttons to the front, and test it before you button the thing back up.

The resulting speaker works, but isn't terribly loud. It's loud enough to get your attention from the office desk, and if you hold it up next to your ear, you can make out what's being said. This is all I expected from this hack. You'll want to hold on to that earphone or external speaker, though.

Here's some crappy cell phone video of it in action.

February 2012 KC2600 Meeting

noreply@blogger.com (Ax0n) — Fri, 03 Feb 2012 21:19:00 +0000

It's that time again! Bring your questions, projects, interesting topics of discussion, war stories and conspiracy theories. As a reminder, the official 2600 meeting start time is 5:00 PM local time, but the Greater Kansas City folks tend to start trickling in at 5:30 or so.

If people are interested, I'll go over some of the common complaints of this lock and how so many people manage to lock themselves out of it forever. I might live stream it on uStream. I might actually lock myself out of this lock forever, too, but hopefully not.

(Crossposted from KC2600)

Lock Fail 2.0

noreply@blogger.com (Ax0n) — Sat, 14 Jan 2012 20:08:00 +0000

I wonder what the combination is.

Previously.

PHP Programming: Clean URLs

noreply@blogger.com (Ax0n) — Sun, 08 Jan 2012 15:28:00 +0000

I've spent the past two weekends re-writing old, horrible, ugly code that I wrote as a kid. I still have a lot of work ahead of me, and there's still no guarantee that the code I'm writing now will be great, but it'll be better than the stuff I wrote before. I'm not a web developer by any means, but it won't keep me from having some nerdy fun on the weekend. I've learned some tricks, and figured I'd share them here in a few short entries. Today, it's so-called "Clean" URLs.

In most dynamic web scripting languages such as PHP, dynamic pages can be accessed by passing parameters through a query string. As an example: http://foo.somesite.com/article.php?p=42

You've undoubtedly seen dynamic websites that don't pass query strings, but instead generate nice, friendly URLs that look more like this: http://foo.somesite.com/article/Hello_World

Clean URLs are easier to link to, they're better for search engine optimization, and with proper implementation provide a few security features as well. The project I'm working on is a custom CMS that was my very first Apache/PHP/MySQL project. It ended up getting kind of popular among a niche crowd, so I left it online in all its ugly glory. I have an article list script that can filter articles by category, and another script to display the articles. I'll just call them list.php and article.php here for the sake of discussion.

Removing .php from the URL

The first part of the problem is the fact that I'd rather not have ".php" show up in the URL, so that "article" and "list" would appear to be sub-directories of my site.

After playing around with a bunch of promising hacks that tended to work fine, including mod_rewrite, I decided that the most elegant way to tackle this was to rely on Apache's "FilesMatch" directive. I created symbolic links from list.php and article.php to strip the .php extension. You could just as easily rename them, though. Then I added the FilesMatch directive to .htaccess for "article" and "list" as shown below. Make sure "AllowOverride All" is set in your Apache configuration, too.

At this point, pulling up http://foo.somesite.com/list will try to run "list" as a PHP script. In my case, it shows a list of articles.

Parsing URI parameters with PHP

The next part is mostly easy. As far as I know, any PHP script will let you add a bunch of parameters to it with slashes like this: http://foo.somesite.com/index.php/testing/1/2/3/4/5. It may not render well, but it doesn't keep it from executing. Above, we got list to show a list of articles, so now it's time to set up filtering. As you can see below, the last element of the URL (split by /) is considered to be the category. The following URL would show a category of "Widgets": http://foo.somesite.com/list/Widgets

To avoid the problem of getting a category of "list" or "list.php" (remember, I chose to symlink my .php files), I included logic to check to see if the category matches the script name. If so, it assumes that it should instead display the Table Of Contents. You'll also see I am setting the title based on what happens here. As the category types are stored in the database and displayed with spaces, I am using str_replace to replace underscores in the URI with spaces. This means that I have to ensure spaces are turned into underscores elsewhere in the code and in all links to my site. That's beyond the scope of this article, though. What matters is that a URL of http://foo.somesite.com/list/Arts_and_Crafts would pull up a category of "Arts and Crafts".

$category=(end(explode('/', urldecode($_SERVER['REQUEST_URI'])))); if(($category) && ($category != 'list.php' && $type != 'list')) { $rawcat=str_replace('_', ' ', $category); $list=getlist($rawcat); $title=$rawcat." Articles"; } else { $toc=TRUE; $list=getlist(); $title="Table of Contents"; }

From here, the rest of my PHP code can query the database for articles. getlist() is a function that I wrote. If its parameter is null, it gets all of them, otherwise it (safely!) queries the database for a category.

I used similar code in the article php script, which queries the database for the title of an article, so I get nice-looking URLs for individual articles as well, such as:

http://foo.somesite.com/article/How_to_narfle_the_Garthok

Why Ham?

noreply@blogger.com (Ax0n) — Tue, 03 Jan 2012 16:26:00 +0000

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

noreply@blogger.com (Ax0n) — Sat, 17 Dec 2011 00:54:00 +0000

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

noreply@blogger.com (Ax0n) — Mon, 05 Dec 2011 03:48:00 +0000

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

noreply@blogger.com (Ax0n) — Fri, 18 Nov 2011 17:47:00 +0000

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

noreply@blogger.com (Ax0n) — Sat, 12 Nov 2011 07:52:00 +0000

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.