Archive for the ‘HOWTO’ Category

Compiling Capture-HPC on VMWare Server 1.0.6

Monday, July 28th, 2008

We often use Capture-HPC as a high interaction client honeypot for analyzing suspect URLs, but getting it up and running on a new platform can sometimes be a somewhat frustrating and time consuming process. I’ve recently had to repeat the build process on the latest version of VMWare Server (release 1.0.6 build-91891) running on Ubuntu Gutsy, so in case this saves anyone else some pain, this is what I had to do to make it work:

1) Download the latest sources (at the time of writing this was capture-server-2.1.0-300-src.zip)

2) Extract the latest sources

unzip capture-server-2.1.0-300-src.zip
cd capture-server-2.1.0-300-src

3) Ensure the necessary build dependencies were installed

sudo aptitude update ; sudo aptitude install ant ant-optional sun-java6-jdk sun-java6-bin sun-java6-jre
sudo install VMWare-Server-1.0.6-build-91891

4) Set the correct environment variables

  JAVA_HOME=/usr/lib/jvm/java-6-sun-1.6.0.03/ ; export JAVA_HOME
  VIX_HOME=/usr/lib/vmware-vix/ ; export VIX_HOME
  VIX_INCLUDE=/usr/include/vmware-vix/ ; export VIX_INCLUDE
  VIX_LIB=/usr/lib/vmware-vix/ ; export VIX_LIB
  ANT_HOME=/usr/share/ant/ ; export ANT_HOME

5) Hack the revert compilation shell script:

chmod +x compile_revert_linux.sh
cat compile_revert_linux.sh
#!/bin/sh
echo $VIX_INCLUDE
#gcc -I $VIX_INCLUDE -o revert revert.c $VIX_LIB/libvmware-vix.so
gcc -I $VIX_INCLUDE -o revert revert.c /usr/lib/libvmware-vix.so

6) Remove any of the logic from build.xml that refers to the Windows OS branch:

vi build.xml
<?xml version="1.0"?>
<project name="CaptureServer" default="release" basedir=".">
        <!-- all stuff to get the jni wrapper compiled -->
        <taskdef resource="net/sf/antcontrib/antcontrib.properties"/>

        <condition property="os" value="unix">
        <os family="unix"/>
    </condition>

         <property environment="env"/>
     <property name="src" value="."/>
     <property name="build" value="build"/>
     <property name="release" value="release"/>

     <target name="init">
          <mkdir dir="${build}"/>
                  <mkdir dir="${release}"/>
         </target>

     <target name="compile" depends="init">
          <!-- Compile the java code -->
          <javac srcdir="${src}" destdir="${build}" debug="true" debuglevel="lines,vars,source"/>

                  <!-- Compile the revert code -->
                   <exec command="sh" executable="./compile_revert_linux.sh"/>

     </target>

         <target name="jar" depends="compile">
        <mkdir dir="${build}/jar"/>
        <jar destfile="${build}/jar/CaptureServer.jar" basedir="${build}">
            <manifest>
                <attribute name="Main-Class" value="capture.Server"/>
            </manifest>
        </jar>
    </target>

        <target name="release" depends="clean,compile,jar">
                <copy file="${build}/jar/CaptureServer.jar" todir="${release}"/>
                <copy file="./COPYING" todir="${release}"/>
                <copy file="./Readme.txt" todir="${release}"/>
                <copy file="./input_urls_example.txt" todir="${release}"/>
                <copy file="./config.xsd" todir="${release}"/>
                <copy file="./config.xml" todir="${release}"/>

                    <exec executable="cp">
                      <arg value="./revert"/>
                      <arg value="${release}"/>
                    </exec>

                <zip destfile="./CaptureServer-Release.zip" basedir="release"/>
        </target>

        <target name="clean">
        <delete dir="${build}"/>
                <delete dir="${release}"/>
                <delete>
                        <fileset dir="." includes="revert.exe"/>
                        <fileset dir="." includes="revert"/>
                        <fileset dir="." includes="CaptureServer-Release.zip"/>
                </delete>
    </target>
</project>

6) Compile the Capture Server

ant
Buildfile: build.xml
  [taskdef] Could not load definitions from resource net/sf/antcontrib/antcontrib.properties. It could not be found.

clean:
   [delete] Deleting directory /home/david/client_honeypots/capture-server-2.1.0-300-src/build
   [delete] Deleting directory /home/david/client_honeypots/capture-server-2.1.0-300-src/release

init:
    [mkdir] Created dir: /home/david/client_honeypots/capture-server-2.1.0-300-src/build
    [mkdir] Created dir: /home/david/client_honeypots/capture-server-2.1.0-300-src/release

compile:
    [javac] Compiling 32 source files to /home/david/client_honeypots/capture-server-2.1.0-300-src/build
    [javac] /home/david/client_honeypots/capture-server-2.1.0-300-src/capture/ClientFileReceiver.java:9: warning: sun.misc.BASE64Decoder is Sun proprietary API and may be removed in a future release
    [javac] import sun.misc.BASE64Decoder;
    [javac]                ^
    [javac] /home/david/client_honeypots/capture-server-2.1.0-300-src/capture/ClientFileReceiver.java:42: warning: sun.misc.BASE64Decoder is Sun proprietary API and may be removed in a future release
    [javac]                             BASE64Decoder base64 = new BASE64Decoder();
    [javac]                             ^
    [javac] /home/david/client_honeypots/capture-server-2.1.0-300-src/capture/ClientFileReceiver.java:42: warning: sun.misc.BASE64Decoder is Sun proprietary API and may be removed in a future release
    [javac]                             BASE64Decoder base64 = new BASE64Decoder();
    [javac]                                                        ^
    [javac] Note: /home/david/client_honeypots/capture-server-2.1.0-300-src/capture/MockClient.java uses unchecked or unsafe operations.
    [javac] Note: Recompile with -Xlint:unchecked for details.
    [javac] 3 warnings
     [exec] The command attribute is deprecated.
     [exec] Please use the executable attribute and nested arg elements.
     [exec] /usr/include/vmware-vix/
     [exec] revert.c:232:2: warning: no newline at end of file

jar:
    [mkdir] Created dir: /home/david/client_honeypots/capture-server-2.1.0-300-src/build/jar
      [jar] Building jar: /home/david/client_honeypots/capture-server-2.1.0-300-src/build/jar/CaptureServer.jar

release:
     [copy] Copying 1 file to /home/david/client_honeypots/capture-server-2.1.0-300-src/release
     [copy] Copying 1 file to /home/david/client_honeypots/capture-server-2.1.0-300-src/release
     [copy] Copying 1 file to /home/david/client_honeypots/capture-server-2.1.0-300-src/release
     [copy] Copying 1 file to /home/david/client_honeypots/capture-server-2.1.0-300-src/release
     [copy] Copying 1 file to /home/david/client_honeypots/capture-server-2.1.0-300-src/release
     [copy] Copying 1 file to /home/david/client_honeypots/capture-server-2.1.0-300-src/release
      [zip] Building zip: /home/david/client_honeypots/capture-server-2.1.0-300-src/CaptureServer-Release.zip

BUILD SUCCESSFUL
Total time: 2 seconds

7) Extract the newly made CaptureServer-Release.zip file into a suitable location (such as a newly made capture-server-2.1.0-300 directory).

8) Configure config.xml and run as normal, such as via:

cd capture-server-2.1.0-300
vi config.xml
/usr/lib/jvm/java-6-sun/bin/java -Djava.net.preferIPv4Stack=true -jar CaptureServer.jar -s your_ip:7070 -f input_urls_example.txt

Hopefully Capture-HPC should work cleanly after that.

NOTE: If you experience problems running Capture and find you receive this error when attempting to run the server:

VIX Error on connect in connect: One of the parameters was invalid

check that your VMWare Server installation was clean by removing VMWare Server (vmware-uninstall.pl), finding any vmware related files in /usr, deleting them and then reinstalling VMWare. I found that one of my VMWare Server upgrades had left a number of vmware-vix shared libraries on disk and these seem to cause the newly compiled Capture Server to fail to connect on revert.

For more trouble shooting details, see this thread on the public Capture-HPC mailing list:

http://public.honeynet.org/pipermail/capture-hpc/2008-August/000431.html

submit-http for nepenthes

Tuesday, June 3rd, 2008

A hideously simplistic PHP handler for the nepenthes submit-http module. It Works For Me ™.

<?php

$ts=date('U');
$log= "timestamp=$ts";
$log.=",remotehost=".$_SERVER['REMOTE_ADDR'];

foreach ($_POST as $key => $value)
{
        switch ($key)
        {

        case "url":
        case "trigger":
        case "md5":
        case "sha512":
        case "filetype":
        case "source_host":
        case "target_host":
        case "filename":
          $$key = $value;

          $log .= ",$key=$value" ;
          break;
        }
}
$log=$log."\n";
$myFile = "/tmp/submit-log";
$fh = fopen($myFile, 'a');
fwrite($fh, $log);
fclose($fh);

?>

You’ll want your config file /etc/nepenthes/submit-http.conf to give this script as the URL, e.g. “http://myserver.example.com/submit.php” and enable the submit-http module in /etc/nepenthes/nepenthes.conf. After that, you probably want to figure out how to collect the binaries that nepenthes has just captured.

p0f 2.0.8 on openWRT

Tuesday, June 3rd, 2008

First, read the posting by David about nepenthes on openWRT. Then get p0f from here http://lcamtuf.coredump.cx/p0f.tgz.

cd kamikaze_9.04/dl
tar zxf ~/p0f.tgz
cd p0f
vi mk/Linux

#change these lines to the full path to your compiler, include and library dirs
# probably a nicer way to do it, but i'm in a hurry :) 
CC      = /home/jamie/slug/kamikaze_7.09/staging_dir_armeb/bin/armeb-linux-uclibc-gcc
LIBS    = -lpcap -I/usr/include/pcap -I/usr/local/include/pcap -I/home/jamie/slug/kamikaze_7.09/build_armeb/libpcap-0.9.4/ -L/home/jamie/slug/kamikaze_7.09/build_armeb/libpcap-0.9.4/

cd ..
mv p0f p0f-2.0.8
tar zcvf p0f-2.0.8.tgz p0f-2.0.8

cd ..

Now, create the Makefile below in packages/p0f/Makefile – remember to make sure it has tabs, not spaces! Then compile:

make package/p0f-compile V=99

Copy the ipkg file onto your openWRT box and install, the just type p0f to run:

== output ==

root@OpenWrt:~# p0f -l
p0f - passive os fingerprinting utility, version 2.0.8
(C) M. Zalewski <lcamtuf@dione.cc>, W. Stearns <wstearns@pobox.com>
p0f: listening (SYN) on 'eth0', 262 sigs (14 generic, cksum 0F1F5CA2), rule: 'all'.
77.a.b.c:59460 - Linux 2.6 (newer, 2) (NAT!) (up: 200 hrs) -> 88.x.y.z:22 (distance 14, link: BT DSL (?))

== Makefile for p0f ==
#
# Copyright (C) 2006 OpenWrt.org
#
# This is free software, licensed under the GNU General Public License v2.
# See /LICENSE for more information.
#
# $Id: Makefile 9695 2007-12-09 18:59:01Z nbd $

include $(TOPDIR)/rules.mk

PKG_NAME:=p0f
PKG_VERSION:=2.0.8
PKG_RELEASE:=1

PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tgz
PKG_SOURCE_URL:=http://www.stearns.org/p0f
PKG_MD5SUM:=unknown

include $(INCLUDE_DIR)/package.mk

define Package/p0f
SECTION:=net
CATEGORY:=Network
DEPENDS:=+libpcap
TITLE:=P0f
URL:=http://http://www.stearns.org/p0f/
endef

define Package/p0f/description
P0f
endef

CONFIGURE_VARS += \
CPPFLAGS="$$$$CPPFLAGS -g " \
LIBS="-nodefaultlibs" \

define Build/Configure
$(call Build/Configure/Default,)
endef

define Build/Compile
$(MAKE) -C $(PKG_BUILD_DIR) DESTDIR="$(PKG_INSTALL_DIR)"
endef


define Package/p0f/install
install -d -m0755 $(1)/usr
install -d -m0755 $(1)/usr/bin
install -d -m0755 $(1)/etc
install -d -m0755 $(1)/etc/p0f
install -m0755 $(PKG_BUILD_DIR)/p0f $(1)/usr/bin
cp -R $(PKG_BUILD_DIR)/p0f.fp $(1)/etc/p0f
endef
#
$(eval $(call BuildPackage,p0f))

OpenWrt Nepenthes on VMWare x86 and Routerboard 532a

Tuesday, May 20th, 2008

Experimentation with running Nepenthes malware collectors on the OpenWrt emebedded platform continues, so I’ve updated the Nepenthes on OpenWrt HOWTO with information on building x86 ports to run under VMWare and also added build instructions for the Mikrotic Routerboard 532a embedded device.

Embedded Nepenthes – malware collection using OpenWRT

Wednesday, May 7th, 2008

For Phase Two of our Global Distributed Honeynet Project (GDH) I’ve been continuing to explore how to extend our sensor deployment footprint at minimum cost. Mixed High and low interaction nodes will always require real server / PC hardware, but for a number of years I’ve been interested in using “plug and play” low interaction-only honeypots such as Nepenthes malware collectors via bootable or embedded devices. These devices are much easier to mass produce and distribute to project members, and with consumer device price levels continuing to fall it has become practical to distribute such sensors on a larger scale internationally (ie hundreds rather than tens of live sensor nodes).

Deployment options are generally based around two models:

  1. Local sensor, with honeypot software running locally on the sensor.
  2. Gateway sensor, with no honeypot software running locally and instead some form of tunnelling solution (GRE, IPSEC, OpenVPN, Honeymole, etc) being used to transparently bridge IP traffic to a central honeyfarm.

I won’t go into too much detail here at this stage, but as we plan to roll out an expanded data collection system along these lines during 2008 you can expect to see more information here in the future.

As part of the background research into building reliable low cost low interaction honeypots, I’ve recently needed to port a number of tools such as Nepenthes to various embedded devices for testing. As this turned out to be a little more time consuming than originally expected, I’ve posted a HOWTO guide for building Nepenthes on the OpenWRT embedded platform. Hopefully this information might help anyone else interested in similar research save a few hours of confusion.

Visualising IRC data

Thursday, August 30th, 2007

I’ve wanted to post this graph for a while but only just got round to anonymising the data.

Looking at piles of IRC logs can be very unilluminating, but it’s not obvious what to do with all the data. One nice way of getting a handle on links between channels is to plot channels with links between them weighted by the number of users in common.


The example above is from a honeynet we ran in 2004/5. The graph shows up a couple of things nicely:

1) There are two distinct groups of channels, and a look at the data shows that there two groups correspond to channels in different languages and,
2) The strong links between a couple of channels in the main group show up that these channels are related and looking at the data shows them to be used for discussing hacking, while the other channels are innocuous.

The original channel names have been replaced by ‘cN’ to protect the guilty.

Spotting malicious javascript

Monday, August 6th, 2007

There’s been much discussion about how to spot malicious javascript. One simple approach that spots a reasonable amount of malware is a simple ratio of the number of Javascript keywords in the code to the total length of the code. This nicely spots things like uuencoded code, although it will miss some other types of obscufation.

Expressed as a formula (*):

m’ = Sum over k of count(T, k)/len(T)

m = 1/m’ if m’ != 0

where T is the text, count(T, k) is the number of occurences of k in T and k is a set of all javascript keywords + a few common browser extensions. Higher numbers = more badness.

It’s not infallible in that it’s easy to create bad javascript that this doesn’t spot, but anything that does score highly is likely to be bad.

Sample python code (right-click and use ‘save as’): js_measure.tgz

(*) Oh for latex!

Honeystick HOWTO published

Tuesday, November 1st, 2005

A new HOWTO has been published: make your own Honeystick!