OpenBSD 5.4 Released. OAMP/ONMP walk-throughs updated

OpenBSD 5.4 was released on November 1st. Some new features include:

• Support for BeagleBone and BB Black
• Some much-needed improvements to dhclient
• OpenSSH 6.3 with some new features

Of course, the nginx and Apache MySQL/PHP walk-throughs have been updated and tested. Enjoy:

OpenBSD/Apache/MySQL/PHP guide
OpenBSD/nginx/MySQL/PHP guide

Breaking in (to the information security field)

Much has been written about how to get started in InfoSec. Last week, I happened across this excellent post with guidance for college students interested in security. The fact is, most of his points are relevant for anyone, student or not, that feels like security is their calling. Of particular note that you really need to love this field to make a career of it without getting burned out in the first few months.

Landing an internship is a good start. I've worked with some brilliant interns from high school and college, but internships are usually only available to students. Most security industry internships are not only paid, but paid quite well compared to many entry-level part-time jobs. Like most internships, you stand a pretty good chance of finding a job in the field if you excel at your work.

Brian Krebs has also sought advice from various high-profile folks in the industry. Most of their sentiments line up: Be curious. Learn. Tinker. Show it off. Crafting excellent write-ups shows potential employers that you're an effective communicator, and that you have the skill to really dig into and understand a topic. These traits matter through your entire career. Even now, with nearly half my life spent in the information security field, I still can't resist the urge to get my hands dirty in the lab. As for how to show off your findings and get involved with the community,  try setting up a blog, hanging out in /r/netsec and visiting local gatherings such as CitySec, ISACA, OWASP, yes, even 2600. If you get a chance, big security conferences can be a lot of fun, but I'd argue they're less useful for getting your foot in the door, and more useful for getting to know others in the field from all over the world.

It's worth reiterating how unfathomably broad the field of information security is. If you're looking to get started, it's best to pick one or two subjects to really focus on. Many of the "fun" topics make use of both offensive and defensive skills. You might need to Google some of the sub-topics, but to name a few I can arbitrarily think of off the top of my head:

• Network Security (Firewalls, IDS/IPS, WAF and penetration testing)
• Software Security (Fuzzing, OWASP Top 10, code review, malware analysis, vulnerability exploitation)
• Endpoint security (Desktop security, FDE, Group policies,  NAC, anti-virus)
• Cryptography (Implementation, design, analysis and cracking)
• Disaster Recovery (data backup/restoration/replication, RAID, UPS, hot-sites)
• Authentication, Authorization and Accounting (Passwords, tokens, logging)
• Security architecture and policy design
• Governance, Risk Management, Compliance, Legal and Regulatory matters (GRC)
• Physical and Operational security (surveillance, risk assessment, lock picking, social engineering)

Lots of security content: July 2013 BSD Magazine

Yes, you have to give them your e-mail address. And yes, like many publications, there are a bunch of advertisements. Every once in a while, BSDMag covers a lot of security-related topics, and this is one of those. Click below to get the latest issue.

 

A UNIX System! I know this!

I warned you all. I was going to do it.

When I was a kid that actually knew and used UNIX (AT&T and AIX at the time), I knew in my heart of hearts that there was no video-game-like flying graphical file manager for UNIX. A lot of us made fun of the computer scenes in Jurassic Park. Well, I was wrong. All of us were. Here's the 20+ year-old Fusion (fsn) file manager running on a 20-year old computer.

Olde-school DES Cracking

I like old computers. I like playing with different operating systems, including old ones. A year and a half ago, give or take, I received an SGI Indy from someone who was cleaning out the shed. This was a low-end machine from SGI, but a relatively high-end workstation by most standards of the era, meant for people doing 3D design and CAD work. This one was made in 1996, about a year before the product line was discontinued.

I've never used IRIX (Silicon Graphics' implementation of UNIX) before, but when the machine booted, I was presented with a graphical account chooser, not too different from what you might see on a modern computer (except lacking 20 years of graphical finesse). Of course, the first account I try to get into is root, because I would like to actually get this machine on the network. I cannot.  I try a few other accounts until I come across one without a password. Then, I checked out /etc/passwd and found that the hashes weren't even shadowed. You can see several accounts don't have passwords at all.

When you encounter password hashes like this, they're traditional salted DES passwords. I haven't actually cracked DES passwords since 1996 or so. By the time I got my first job in information security (early 2000), password shadowing was common practice, and better hashing algorithms were in place.

I had a Kali Linux VM running on my laptop already, so I scribbled the password hash on a piece of paper, then re-constructed a fake password file from this one line and set John The Ripper loose on it.

In the mean time,  I tried some tricks from the console to get the machine to boot up in single user mode, but I was faced with quite a bit of adversity. Official single user mode required the root password, and attempts to bypass the root password (like calling a shell for init) didn't work.

Trying to load a shell as a kernel, obviously, wouldn't work, but it didn't stop me from trying, thus causing a panic and crash.

A short while later, I heard a noise on my laptop, and saw this:

That password worked just fine, and I was on my merry way.

Humorously, a few folks also tried cracking the same password on their equipment. One ended up finding it in under 2 minutes with 4 threads on an i5-2400 desktop, Fritz smashed it in a mere 13 seconds on a 32-core VM. I should probably see how fast JTR would get it on the laptop natively, with 4 threads outside a VM, but I'm not going to bother with that.

Now I just need to get Fusion installed on this IRIX box so I can reproduce the cheesy scene from Jurassic Park.

Decoding VBScript Malware-infected HTML files

I have been running across malware like this lately.  It appears to be a local infection that appends some VBScript to HTML files on the webmaster's computer, spreading to the Internet when it's uploaded. Alternatively, it could be an infection on a Windows IIS server.

At any rate, WriteData is a hex string that goes on and on for a good couple of screen lengths, followed by some more VBScript to open a file handle, write binary data to it, then execute the dropped binary.

Since it appears this HTML file has been infected multiple times, I use uniq to get only one copy of the WriteData line. I split it with cut based on the double quotes to get only the hexadecimal part. I decided I'd try to use xxd to decode it. xxd can create or read hex dumps. I save xxd's output to svchost.exe (which is what the VBScript would have called it).

Finally, I use file to determine what kind of file svchost.exe is, presuming it'll be a Windows executable file.

No surprises there. I uploaded it to VirusTotal, and it looks like we have a ZBot (ZeuS) on our hands.

OpenBSD 5.3 Released

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

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

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

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

Edit (April 24, 2016): A Few years ago, OpenBSD developers started issuing an "installXX.fs" image which was designed to be written to a USB drive with dd(1). This makes the article below mostly obsolete.

From pretty much any unix-like operating system, you should be able to use dd to write the .fs image to the USB stick directly, like this:

sudo dd if=install59.fs of=/dev/rsd2c  

(Just make sure you have the right target device specified. You don't want to overwrite the wrong drive!)

--- 

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:

1. Boot a desktop from the boot CD
2. Insert the USB stick you wish to use
3. Choose "Install" from the CD's menu.
4. 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.
5. After install, re-mount the cd and copy the install files to the root partition.
6. Create an etc/boot.conf file on the USB stick (mounted to /mnt) with "bsd.rd" as the first and only line.
7. 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!