Categories

Massive Advertising Server Compromise/Socially Engineered By The RBN

We have identified several major websites (buy.com, cnbc.com, digg.com, evite.com and msn.com just to name a few) using the advertising services of malicious servers that are using Acrobat PDF and Java exploits to force the download and installation of fake antivirus software. Analysis from SysAdMini @ www.malwaredomainlist.com has informed us the sites are all using the NeoSploit drive-by kit. After further reseach, we found that Jiri Sejtko from Avast! has actually documented this and written up a great blog entry about this back on Feb 18th, 2010. It is unbelievable that online advertisers the likes of yieldmanager.com, fimserve.com, advertangel.com, bannerimg.com, jambovideonetwork.com, myspace.com, zedo.com, vestraff.com and others allowed this to occur and even thrive for the better part of a month. The host names hosting the drive-by and fake antivirus software that we have discovered so far are:

google.analytics.com.bazqrhafrrh.info
google.analytics.com.bidxctvqvwrw.info
google.analytics.com.byuigracdnjj.info
google.analytics.com.ckzqfrxaxihi.info
google.analytics.com.cvybexpnqhlx.info
google.analytics.com.dbvvwrkgycfa.info
google.analytics.com.dcghkoixsagu.info
google.analytics.com.dfxlhdyffzho.info
google.analytics.com.dwldxeqavts.info
google.analytics.com.dygpcewrjnw.info
google.analytics.com.eliyisgtkaj.info
google.analytics.com.eututrywxvhd.info
google.analytics.com.ezqaxnmsbs.info
google.analytics.com.friavuzpsvxc.info
google.analytics.com.fywthroeasx.info
google.analytics.com.gopbaqvgprvh.info
google.analytics.com.hjvcnunmtzc.info
google.analytics.com.hnstetlseuop.info
google.analytics.com.hzlyaejcvmat.info
google.analytics.com.inxvwrxogrc.info
google.analytics.com.jestywtvadgj.info
google.analytics.com.jgvsjnhmvngn.info
google.analytics.com.jjotqkhqymp.info
google.analytics.com.jklnznqvztu.info
google.analytics.com.jtmqypcgt.info
google.analytics.com.jttyhhvcxmbz.info
google.analytics.com.jvoamkvyxv.info
google.analytics.com.kijksoeohxze.info
google.analytics.com.kmpbfdtknwsh.info
google.analytics.com.kzpkpehthbgn.info
google.analytics.com.lsvoenxxyya.info
google.analytics.com.mnuzqxerjufm.info
google.analytics.com.muhrlwuzyaly.info
google.analytics.com.nbtislvidmq.info
google.analytics.com.nlfgjehbotwi.info
google.analytics.com.noltvoqmhoce.info
google.analytics.com.oaofmsckue.info
google.analytics.com.ocryspyjvkh.info
google.analytics.com.omvdbdcknpct.info
google.analytics.com.pmxjpigimsdv.info
google.analytics.com.prtrkmxkpctw.info
google.analytics.com.pzignbfxspou.info
google.analytics.com.qlgkmytdvyjx.info
google.analytics.com.rimofoixaf.info
google.analytics.com.rmkbyklbhawd.info
google.analytics.com.rtkffbmmgkpw.info
google.analytics.com.rxflhciirups.info
google.analytics.com.sphamifoaqpx.info
google.analytics.com.tbxierkoqze.info
google.analytics.com.tdrfhdzxyb.info
google.analytics.com.tidawgeihqch.info
google.analytics.com.tklaxlxvedkt.info
google.analytics.com.tluaweyermg.info
google.analytics.com.uentfkblzpxx.info
google.analytics.com.uoncvsqcuclx.info
google.analytics.com.uuyvsrbtpjhl.info
google.analytics.com.uwbhpcrydgta.info
google.analytics.com.vgmhlwrixzxz.info
google.analytics.com.vujpgvscrjbk.info
google.analytics.com.vwrvqmvrvjwi.info
google.analytics.com.wwkzrjfuhmjg.info
google.analytics.com.wxrzufdrzzn.info
google.analytics.com.xewffvnixdyk.info
google.analytics.com.xkduqnxfpnfg.info
google.analytics.com.xnboetuqunld.info
google.analytics.com.yfguydudorip.info
google.analytics.com.yggxvnwumcqv.info
google.analytics.com.yhaidebpfltr.info
google.analytics.com.yynspckhyebi.info
google.analytics.com.zejdcqsoglao.info
google.analytics.com.zelhnalbivd.info
google.analytics.com.zsrsjnihnb.info
google.analytics.com.zugponkeqtzz.info

All of these host names resolved to the following IP addresses at this time:

69.174.245.147
69.174.245.148
69.174.245.150
72.51.41.155
75.125.183.50
174.142.53.148

We have been observing this for a few days and have been checking our repository of traffic and this goes back even further than Feb 15th, 2010. The signature that will trip on the download of the malware more often than not is this one:

ET POLICY Binary Download Smaller than 1 MB Likely Hostile
http://doc.emergingthreats.net/2007671

Once a client is infected, the following signatures trip:

ET TROJAN Potential FakeAV HTTP GET Check-IN (/check)
http://doc.emergingthreats.net/2010597

ET TROJAN Potential FakeAV HTTP POST Check-IN (?r=)
http://doc.emergingthreats.net/2010594

ET USER_AGENTS Suspicious User Agent (Microsoft Internet Explorer)
http://doc.emergingthreats.net/2002400

The infected client will attempt to check-in to the follwing IP Address/hostname:

79.135.152.5 – avgroupwebsite.com
195.88.190.54 – av-command.com/av-crew.net

This campaign seems to have been very effective and we know of thousands of hosts that have been exploited by this campaign.

Integrating NetWitness and Sguil – Take Two

We have finished up our first round of testing against the modified version of the Sguil client (we have modified the 0.7.0 CVS version). Using the alert information displayed in the Sguil client we create a query and feed it into the NetWitness API through a vbscript which calls explorer.exe and passes it a NetWitness URL. When you install NetWitness Investigator, it registers the nw://<url> as a protocol within the OS. This URL is the API/method by which you can use alerting from other products to find specific sessions, ip’s or timeframes of traffic to review in any combination.

To do this, we first modified the Xscript section of sguil.tk and removed the transcript and wireshark options as we are now relying upon NetWitness for pcap capture instead of daemonlogger/sancp/tcpdump etc:

# Xscript Menu
set eventIDMenut [ menu .eventIDMenut -background $SELECTBACKGROUND -foreground $SELECTFOREGROUND \
  -activeforeground $SELECTBACKGROUND -activebackground $SELECTFOREGROUND -tearoff 0 ]
$eventIDMenut add command -label "Event History" -command "GetEventHistory"
$eventIDMenut add command -label "NetWitness Src -> Dst" -command "NetWitnessEvent from"
$eventIDMenut add command -label "NetWitness Dst -> Src" -command "NetWitnessEvent to"

You can see that we are calling the command NetWitnessEvent and passing it a value of from or to. The reason for this is that events that are triggered list the source and destination IP address for the particular packet that caused the alert. However, NetWitness is session aware, so you may need to query using the source address as the destination and vice versa. This is calling the NetWitnessEvent function that we have added to lib/extdata.tcl:

proc NetWitnessEvent { direction } {
    global ACTIVE_EVENT SERVERHOST XSCRIPT_SERVER_PORT DEBUG CUR_SEL_PANE XSCRIPTDATARCVD
    global socketWinName SESSION_STATE WIRESHARK_STORE_DIR WIRESHARK_PATH
    if {!$ACTIVE_EVENT} {return}
    set selectedIndex [$CUR_SEL_PANE(name) curselection]
    set sidcidList [split [$CUR_SEL_PANE(name) getcells $selectedIndex,alertID] .]
    set cnxID [lindex $sidcidList 1]
    set sensorID [lindex $sidcidList 0]
    set proto [$CUR_SEL_PANE(name) getcells $selectedIndex,ipproto]
    set srcIP [$CUR_SEL_PANE(name) getcells $selectedIndex,srcip]
    set srcPort [$CUR_SEL_PANE(name) getcells $selectedIndex,srcport]
    set dstIP [$CUR_SEL_PANE(name) getcells $selectedIndex,dstip]
    set dstPort [$CUR_SEL_PANE(name) getcells $selectedIndex,dstport]
    if { $CUR_SEL_PANE(format) == "SSN" } {
       set timestamp [$CUR_SEL_PANE(name) getcells $selectedIndex,starttime]
    } else {
       set timestamp [$CUR_SEL_PANE(name) getcells $selectedIndex,date]
    }   
    set future [clock scan "2 minute" -base [clock scan $timestamp -gmt 1]]
    set past   [clock scan "-2 minute" -base [clock scan $timestamp -gmt 1]]
    set future [clock format $future -format {%Y-%m-%d+%H:%M:%S} -gmt 1]
    set past [clock format $past -format {%Y-%m-%d+%H:%M:%S} -gmt 1]
    set future [regsub -all -expanded {[\:]} $future {%3A}]
    set past [regsub -all -expanded {[\:]} $past {%3A}]
    if { $proto == "6" } {
        if { $direction == "from" } {
            exec wscript c:/users/analyst/nw.vbs "nw://broker/?name=TCP+%7C%7C+$srcIP%3A$srcPort+-%3E+$dstIP%3A$dstPort&time=$past+to+$future&view=session&where=ip.src%3D$srcIP+%26%26+tcp.srcport%3D$srcPort+%26%26+ip.dst%3D$dstIP+%26%26+tcp.dstport%3D$dstPort"
        }
        if { $direction == "to" } {
            exec wscript c:/users/analyst/nw.vbs "nw://broker/?name=TCP+%7C%7C+$dstIP%3A$dstPort+-%3E+$srcIP%3A$srcPort&time=$past+to+$future&view=session&where=ip.src%3D$dstIP+%26%26+tcp.srcport%3D$dstPort+%26%26+ip.dst%3D$srcIP+%26%26+tcp.dstport%3D$srcPort"
        }
    }
    if { $proto == "17" } {
     if { $direction == "from" } {
         exec wscript c:/users/analyst/nw.vbs "nw://broker/?name=UDP+%7C%7C+$srcIP%3A$srcPort+-%3E+$dstIP+%3A+$dstPort&time=$past+to+$future&view=session&where=ip.src%3D$srcIP+%26%26+udp.srcport%3D$srcPort+%26%26+ip.dst%3D$dstIP+%26%26+udp.dstport%3D$dstPort"
     }
     if { $direction == "to" } {
         exec wscript c:/users/analyst/nw.vbs "nw://broker/?name=UDP+%7C%7C+$dstIP%3A$dstPort+-%3E+$srcIP+%3A+$srcPort&time=$past+to+$future&view=session&where=ip.src%3D$dstIP+%26%26+udp.srcport%3D$dstPort+%26%26+ip.dst%3D$srcIP+%26%26+udp.dstport%3D$srcPort"
     }
    }
    if { $proto == "1" } {
        if { $direction == "from" } {
            exec wscript c:/users/analyst/nw.vbs "nw://broker/?name=ICMP+%7C%7C+$srcIP+-%3E+$dstIP&time=$past+to+$future&view=session&where=ip.src%3D$srcIP+%26%26+ip.dst%3D$dstIP+%26%26+ip.proto%3D1"
        }
        if { $direction == "to" } {
            exec wscript c:/users/analyst/nw.vbs "nw://broker/?name=ICMP+%7C%7C+$dstIP+-%3E+$srcIP&time=$past+to+$future&view=session&where=ip.src%3D$dstIP+%26%26+ip.dst%3D$srcIP+%26%26+ip.proto%3D1"
        }
    }
}

This function will create different queries based upon protocol type (TCP/UDP/ICMP only currently) and use the source/destination address and source/destination port. It will look for sessions that match those specific values and then automatically open them in NetWitness Investigator:

sguilNetwitness1

To replicate the SANCP session type queries, we again modify sguil.tk but this time we modify the IPQuery Menu section:

# IPQuery Menu
set ipQueryMenu [ menu .ipQueryMenu -background $SELECTBACKGROUND -foreground $SELECTFOREGROUND \
  -activeforeground $SELECTBACKGROUND -activebackground $SELECTFOREGROUND -tearoff 0 ]
.ipQueryMenu add cascade -label "Quick Query" -menu $ipQueryMenu.quickMenu
.ipQueryMenu add cascade -label "Advanced Query" -menu $ipQueryMenu.advancedMenu
.ipQueryMenu add cascade -label "Dshield IP Lookup" -menu $ipQueryMenu.dshieldIPMenu
.ipQueryMenu add cascade -label "Nessus Report Lookup" -menu $ipQueryMenu.nessusMenu
.ipQueryMenu add cascade -label "NetWitness Query" -menu $ipQueryMenu.netwitnessMenu

menu $ipQueryMenu.quickMenu -tearoff 0 -background $SELECTBACKGROUND -foreground $SELECTFOREGROUND -activeforeground $SELECTBACKGROUND -activebackground $SELECTFOREGROUND
menu $ipQueryMenu.advancedMenu -tearoff 0 -background $SELECTBACKGROUND -foreground $SELECTFOREGROUND -activeforeground $SELECTBACKGROUND -activebackground $SELECTFOREGROUND
menu $ipQueryMenu.dshieldIPMenu -tearoff 0 -background $SELECTBACKGROUND -foreground $SELECTFOREGROUND -activeforeground $SELECTBACKGROUND -activebackground $SELECTFOREGROUND
menu $ipQueryMenu.nessusMenu -tearoff 0 -background $SELECTBACKGROUND -foreground $SELECTFOREGROUND -activeforeground $SELECTBACKGROUND -activebackground $SELECTFOREGROUND
menu $ipQueryMenu.netwitnessMenu -tearoff 0 -background $SELECTBACKGROUND -foreground $SELECTFOREGROUND -activeforeground $SELECTBACKGROUND -activebackground $SELECTFOREGROUND

$ipQueryMenu.netwitnessMenu add command -label "SrcIP/1 Hour"           -command "NetWitness Src 1"
$ipQueryMenu.netwitnessMenu add command -label "SrcIP(as Dst)/1 Hour"   -command "NetWitness SrcAsDst 1"
$ipQueryMenu.netwitnessMenu add command -label "SrcIP/24 Hours"         -command "NetWitness Src 24"
$ipQueryMenu.netwitnessMenu add command -label "SrcIP(as Dst)/24 Hours" -command "NetWitness SrcAsDst 24"
$ipQueryMenu.netwitnessMenu add command -label "DstIP/1 Hour"           -command "NetWitness Dst 1"
$ipQueryMenu.netwitnessMenu add command -label "DstIP(as Src)/1 Hour"   -command "NetWitness DstAsSrc 1"
$ipQueryMenu.netwitnessMenu add command -label "DstIP/24 Hours"         -command "NetWitness Dst 24"
$ipQueryMenu.netwitnessMenu add command -label "DstIP(as Src)/24 Hours" -command "NetWitness DstAsSrc 24"
$ipQueryMenu.netwitnessMenu add command -label "Src To Dst/1 Hour"      -command "NetWitness SrcToDst 1"
$ipQueryMenu.netwitnessMenu add command -label "Dst To Src/1 Hour"      -command "NetWitness DstToSrc 1"
$ipQueryMenu.netwitnessMenu add command -label "Src To Dst/24 Hours"    -command "NetWitness SrcToDst 24"
$ipQueryMenu.netwitnessMenu add command -label "Dst To Src/24 Hours"    -command "NetWitness DstToSrc 24"
$ipQueryMenu.netwitnessMenu add command -label "Src To Dst/5 Days"      -command "NetWitness SrcToDst 120"
$ipQueryMenu.netwitnessMenu add command -label "Dst To Src/5 Days"      -command "NetWitness DstToSrc 120"
foreach { currentMenu subcommand } { .ipQueryMenu.quickMenu "quick" .ipQueryMenu.advancedMenu "build" } {
....truncated for brevity, everything below is should be as it was when you checked it out of CVS...

You can see we are calling a proc/function called NetWitness and are passing it a variable for which address(es) we are interested in (and if they are source or destination addresses) along with some predefined time periods. You have much better flexibility and control if you actually create these queries within NetWitness directly, but just being able to right click makes for greater ease of use for analysts. This is calling the NetWitnessEvent function that we have added to lib/extdata.tcl:

proc NetWitness { direction hours } {
    global ACTIVE_EVENT SERVERHOST XSCRIPT_SERVER_PORT DEBUG CUR_SEL_PANE XSCRIPTDATARCVD
    global socketWinName SESSION_STATE WIRESHARK_STORE_DIR WIRESHARK_PATH
    if {!$ACTIVE_EVENT} {return}
    set selectedIndex [$CUR_SEL_PANE(name) curselection]
    set sidcidList [split [$CUR_SEL_PANE(name) getcells $selectedIndex,alertID] .]
    set cnxID [lindex $sidcidList 1]
    set sensorID [lindex $sidcidList 0]
    set proto [$CUR_SEL_PANE(name) getcells $selectedIndex,ipproto]
    set srcIP [$CUR_SEL_PANE(name) getcells $selectedIndex,srcip]
    set srcPort [$CUR_SEL_PANE(name) getcells $selectedIndex,srcport]
    set dstIP [$CUR_SEL_PANE(name) getcells $selectedIndex,dstip]
    set dstPort [$CUR_SEL_PANE(name) getcells $selectedIndex,dstport]
    if { $CUR_SEL_PANE(format) == "SSN" } {
       set timestamp [$CUR_SEL_PANE(name) getcells $selectedIndex,starttime]
    } else {
       set timestamp [$CUR_SEL_PANE(name) getcells $selectedIndex,date]
    } 
    if {$hours == 1} {
     set future [clock scan "30 minute" -base [clock scan $timestamp -gmt 1]]
     set past   [clock scan "-30 minute" -base [clock scan $timestamp -gmt 1]]
    } else {
     set hours [expr $hours / 2]
     set future [clock scan "$hours hour" -base [clock scan $timestamp -gmt 1]]
     set past   [clock scan "-$hours hour" -base [clock scan $timestamp -gmt 1]]
    }
    set future [clock format $future -format {%Y-%m-%d+%H:%M:%S} -gmt 1]
    set past [clock format $past -format {%Y-%m-%d+%H:%M:%S} -gmt 1]
    set future [regsub -all -expanded {[\:]} $future {%3A}]
    set past [regsub -all -expanded {[\:]} $past {%3A}]   
    if { $direction == "Src" } {
     exec wscript c:/users/analyst/nw.vbs "nw://broker/?name=ip.src%3D$srcIP&time=$past+to+$future&where=ip.src%3D$srcIP"
    }
    if { $direction == "SrcAsDst" } {
        exec wscript c:/users/analyst/nw.vbs "nw://broker/?name=ip.dst%3D$srcIP&time=$past+to+$future&where=ip.dst%3D$srcIP"
    }
    if { $direction == "Dst" } {
     exec wscript c:/users/analyst/nw.vbs "nw://broker/?name=ip.dst%3D$dstIP&time=$past+to+$future&where=ip.dst%3D$dstIP"
    }
    if { $direction == "DstAsSrc" } {
     exec wscript c:/users/analyst/nw.vbs "nw://broker/?name=ip.src%3D$dstIP&time=$past+to+$future&where=ip.src%3D$dstIP"
    }
    if { $direction == "SrcToDst" } {
     exec wscript c:/users/analyst/nw.vbs "nw://broker/?name=$srcIP+-%3E+$dstIP&time=$past+to+$future&where=ip.src%3D$srcIP+%26%26+ip.dst%3D$dstIP"
    }
    if { $direction == "DstToSrc" } {
         exec wscript c:/users/analyst/nw.vbs "nw://broker/?name=$dstIP+-%3E+$srcIP&time=$past+to+$future&where=ip.src%3D$dstIP+%26%26+ip.dst%3D$srcIP"
    }
}

Now we can right click on IP’s within Sguil and use the alert data to perform these SANCP queries into NetWitness as shown below:

sguilNetwitness2

You may have noticed that the nw://<url>’s are being passed to a visual basic script entitled nw.vbs within the analyst accounts home directory. We had some issues with executing long length commands from within TCL and ran into 8.3 filename limitations as well. The vbscript is very simple and uses the run method to execute explorer.exe while passing it the URL we have formed to perform the query in NetWitness Investigator. If NetWitness Investigator is not running, it will open up and prompt you for your authentication credentials. Additionally, if is already open it will just create a tab in the investigator and display you the sessions/reports. The contents of the nw.vbs file are as follows, it may look weird butyou have to escape quotes with quotes when you do vb scripting so it looks like you have gone quote crazy:

Set objShell = Wscript.CreateObject("Wscript.Shell")
Set ArgObj = WScript.Arguments

Cmd = """" & "c:\windows\system32\explorer.exe" & """" & " " & """" & WScript.Arguments.Item(0) & """"

objShell.Run Cmd

Fixing Barnyard2 Duplicate Database Entries With Sguil Output

Well the good folks over at SecurixLive.com have already fixed this and a few other little things and rolled it into their latest release of Barnyard2 v1.8-beta1. Go and get it!

We have identified an issue with Barnyard2 version 1.7 build 255 that causes duplicate entries to be created in the Sguil database. The issue was that the entries in the unified2 output from Snort will be read into two seperate lists (AlertList and LogList) as the unified2 log file is processed. Elsewhere in the Barnyard2 code, all the relavent information is stored into a buffer for creating the Sguil database entry for the alert (summary of event) and the log (offending packet) prior to firing off the output logging. The debugging output shows you that the SPECIAL style output is going to be used for the event/packet combo that was pulled out of the unified2 output file:

spi_unified2.c:151: Header: Type=7 (52 bytes)
spi_unified2.c:159: Reading record type=7 (52 bytes)
spi_unified2.c:320: Type: Event -------------------------------------------
spi_unified2.c:322:   sensor_id          = 0
spi_unified2.c:324:   event_id           = 4
spi_unified2.c:326:   event_second       = 1260520646
spi_unified2.c:328:   event_microsecond  = 383469
spi_unified2.c:330:   generator_id       = 1
spi_unified2.c:332:   signature_id       = 2009236
spi_unified2.c:334:   signature_revision = 5
spi_unified2.c:336:   classification_id  = 21
spi_unified2.c:338:   priority_id        = 1
spi_unified2.c:353:   ip_source          = 192.168.1.5
spi_unified2.c:356:   sport_itype        = 57019
spi_unified2.c:359:   ip_destination     = 71.191.147.210
spi_unified2.c:361:   dport_icode        = 80
spi_unified2.c:364:   ip_protocol        = 6
spi_unified2.c:366:   packet_action      = 0
spi_unified2.c:151: Header: Type=2 (244 bytes)
spi_unified2.c:159: Reading record type=2 (244 bytes)
spi_unified2.c:403: Type: Packet ------------------------------------------
spi_unified2.c:405:   sensor_id          = 0
spi_unified2.c:407:   event_id           = 4
spi_unified2.c:409:   event_second       = 1260520646
spi_unified2.c:411:   linktype           = 1
spi_unified2.c:413:   packet_second      = 1260520646
spi_unified2.c:415:   packet_microsecond = 383469
spi_unified2.c:417:   packet_length      = 216
spi_unified2.c:422:   packet             = 18 01 bb 24
decode.c:113: Decoding linktype 1
decode.c:314: Packet!
decode.c:314: caplen: 216    pktlen: 216
decode.c:341: 0:21:9B:69:E0:9 -> 0:18:1:BB:24:4F
decode.c:345: type:0x800 len:0xD8
decode.c:355: IP datagram size calculated to be 202 bytes
decode.c:2648: Packet!
decode.c:2822: IP Checksum: OK
decode.c:2899: IP header length: 20
decode.c:3023: TCP th_off is 5, passed len is 182
decode.c:3103: TCP Checksum: OK
decode.c:3107: tcp header starts at: 0x80dcd9e
spooler.c:655: Firing SPECIAL style (Packet+Event)

So the debugging shows us only firing off once with SPECIAL style (Packet+Event). But if we look at the output presented to STDOUT, we see that the same alert inserted twice into the Sguil server (we have omitted packet contents for brevity):

sguil: sending "RTEVENT 0 1 199 sguil 4 4 {2009-12-11 03:37:26} 1 2009236 5 {ET USER_AGENTS Pigeon.AYX/AVKill Related User-Agent (CTTBasic) } {2009-12-11 03:37:26} 1 trojan-activity 3232235781 192.168.1.5 1203737554 71.191.147.210 6 4 5 0 202 2472 2 0 128 21319 {} {} {} {} {} 57019 80 309364297 2715104879 5 0 24 16425 7600 0 {} {}"
sguil: Received: Confirm 199
sguil: sending "RTEVENT 0 1 200 sguil 4 4 {2009-12-11 03:37:26} 1 2009236 5 {ET USER_AGENTS Pigeon.AYX/AVKill Related User-Agent (CTTBasic) } {2009-12-11 03:37:26} 1 trojan-activity 3232235781 192.168.1.5 1203737554 71.191.147.210 6 4 5 0 202 2472 2 0 128 21319 {} {} {} {} {} 57019 80 309364297 2715104879 5 0 24 16425 7600 0 {} {}"
sguil: Received: Confirm 200

So this lead us to inspect src/spooler.c which lead us to src/plugbase.c CallOutputPlugins() function. While reviewing it, we notice that if the OUTPUT_TYPE__SPECIAL (which Sguil is) is set, then it will process idx-func() once for the entry in the AlertList and once for the LogList:

void CallOutputPlugins(OutputType out_type, Packet *packet, void *event, uint32_t event_type)
{
    OutputFuncNode *idx = NULL;

    if (out_type == OUTPUT_TYPE__SPECIAL)
    {
        idx = AlertList;
        while (idx != NULL)
        {
            idx->func(packet, event, event_type, idx->arg);
            idx = idx->next;
        }

        idx = LogList;
        while (idx != NULL)
        {
            idx->func(packet, event, event_type, idx->arg);
            idx = idx->next;
        }
    }

So if we remove the processing the second time around for the LogList, we are able to stop the double entries from being created in the database. Below is what the patch (which you can download here) looks like. Obviously, you can just delete the lines with the single minus sign in front of them that are located within the CallOutputPlugins() function of src/plugbase.c:

--- plugbase.c  2009-10-17 06:08:55.000000000 -0400
+++ plugbase.c.new      2009-12-11 21:59:22.000000000 -0500
@@ -543,13 +543,6 @@
                idx->func(packet, event, event_type, idx->arg);
                idx = idx->next;
        }
-
-        idx = LogList;
-       while (idx != NULL)
-       {
-               idx->func(packet, event, event_type, idx->arg);
-               idx = idx->next;
-       }
     }
     else
     {

To apply the patch, move it to the src/ directory within the Barnyard2 v 1.7 distribution directory and perform the following then compile/install as normal:

#patch plugbase.c < plugbase.c.patch

Additional things we discovered during the troubleshooting process were how to enable the debugging within Barnyard2. You must first compile it with the --enable-debug option, then prior to running it you must set the environment variable BARNYARD2_DEBUG to one of the numbers listed in src/debug.h (if you want everything, and that IS a lot, just do export BARNYARD2_DEBUG=4294967295).

Integrating NetWitness and Sguil – Take One

We will be deploying NetWitness soon and we have been looking for how to leverage it for the packet capture portion of our new centralized Sguil deployment instead of sancp or daemonlogger. We have come up with a way, all be it a bit hackish, of modifying the Sguil client to allow you to view the pcap/session data from within NetWitness Investigator.

First, we modified client/sguil.tk and added the following line under the following line underneath the section of code notated by the comment # Xscript Menu:

$eventIDMenut add command -label "NetWitness" -command "NetWitness"

This will provide us with a NetWitness menu option where you normally see your Wireshark and Get Transcript options within the Sguil client:

Sguil and NetWitness

Now that we have that, we need code that will do something when this option is selected. For that we need to add the following to the end of the client/lib/extdata.tcl file:

proc NetWitness { } {
    global ACTIVE_EVENT SERVERHOST XSCRIPT_SERVER_PORT DEBUG CUR_SEL_PANE XSCRIPTDATARCVD
    global socketWinName SESSION_STATE WIRESHARK_STORE_DIR WIRESHARK_PATH
    if {!$ACTIVE_EVENT} {return}
    set selectedIndex [$CUR_SEL_PANE(name) curselection]
    set sidcidList [split [$CUR_SEL_PANE(name) getcells $selectedIndex,alertID] .]
    set cnxID [lindex $sidcidList 1]
    set sensorID [lindex $sidcidList 0]
    set proto [$CUR_SEL_PANE(name) getcells $selectedIndex,ipproto]

    set srcIP [$CUR_SEL_PANE(name) getcells $selectedIndex,srcip]
    set srcPort [$CUR_SEL_PANE(name) getcells $selectedIndex,srcport]
    set dstIP [$CUR_SEL_PANE(name) getcells $selectedIndex,dstip]
    set dstPort [$CUR_SEL_PANE(name) getcells $selectedIndex,dstport]
    if { $CUR_SEL_PANE(format) == "SSN" } {
       set timestamp [$CUR_SEL_PANE(name) getcells $selectedIndex,starttime]
    } else {
       set timestamp [$CUR_SEL_PANE(name) getcells $selectedIndex,date]
    }

    exec wscript c:/users/user/test.vbs "nw://test?collection=test&time=All+Data&more-states=&more-all-states=&name=$srcIP+%3E+$dstIP+%3A+$dstPort&where=ip.src%3D$srcIP+%26%26+ip.dst%3D$dstIP+%26%26+tcp.dstport%3D$dstPort&view=session"
}

Now you will notice at the second to last line we are executing a vbscript called test.vbs in c:\users\user\. The contents of that file are as follows (and yes, all those quotes are necessary as you escape a quote with another quote when writing vbscript):

Set objShell = Wscript.CreateObject("Wscript.Shell")
Set ArgObj = WScript.Arguments

Cmd = """" & "c:\windows\system32\explorer.exe" & """" & " " & """" & WScript.Arguments.Item(0) & """"

objShell.Run Cmd

When this gets executed, it will have the NetWitness url (nw://<url>) with the source ip, destination ip and destination port, passed to the Windows shell (explorer.exe). We will be going back and adding time into the mix as well once our actual NetWitness deployment is up and running. We are currently just testing and demonstrating for proof of concept using the free version of NetWitness Investigator 9:

SguilandNetWitness2

Now, this definately does not seem like the most direct or correct way to do this. However, we discovered some odd behavior that lead us down this path. If you attempt to pass the URL directly to the NwInvestigator.exe binary, it will crash it. If you attempt to pass the URL directly to explorer.exe from within the TCL script, it only opens up explorer but it does not open up NetWitness Investigator. I believe it has something to do with the quoted arguments and how they are passed, but I could not fix it as I know little of TCL and even less about how it works on Windows.

jSguil

We really do love Sguil, but the client and server lack a few desirable things. As far as I can tell, there is only one SQL connection shared between the server and all the clients connecting to it. Obviously if someone runs a SANCP query that is a little over the top, until it comes back everyone else cannot query the database. This would make sense as the Sguil server requires the non-threaded version of TCL to work. LAMP based applications don’t run into this single connection for all users bottleneck as Apache and MySQL are multithreaded and each request will create its own (or multiple) database connection for the POST/GET and then close it on completion. I already knew about SQuerT, but it lacks a few things, such as an authentication mechanism.  There also is a web client directly associated with the Sguil project, but it was never fully completed and most of the application is a mock up. Lastly, the current Sguil clients will not be that easy to integrate with our upcoming NetWitness deployment. The combination of which, should be quite awesome.

So I have decided to start developing, what I am calling for now, jSguil. It will be along the lines of SQuerT in that it is not to be a function for function replacement for the standard TCL Sguil client. This basically gives me an excuse to actually buckle down and learn JSON/jQuery/webtwodotoh. It will be written in PHP and utilize jQuery/jqgrid. Development so far has been slow and painful as I continiously learn how to actually write PHP/JavaScript (sort of). It end up with me having to redo the entire thing I just spent two hours on due to discovering how to do something in a much better manner. Below is a screenshot of just the SANCP queries you can run. You can sort the results of each column by clicking on it. You may also notice the data is paginated and is currently allowing you to view 50/200/500 records at a time. Every time you sort or get a new page, another query is executed for only the number of  records you have chosen to display. This keeps the response times quite fast, even on large resultsets.

jSguil

Sguil Client Reverse DNS Causes Client To Freeze?

If you have ever tried to use the Sguil client’s reverse DNS under the IP Resoluation tab and noticed that it caused the application to be unresponsive, here is the reason why. Tcl uses TCP for DNS by default. So if your DNS server does not allow TCP DNS, the client just sits there endlessly attempting to create the TCP socket connection everytime it tries to do a gehostbyaddress(). You can review the configuration by doing the following inside of tclsh:

# tclsh
% package require dns
1.3.2
% dns::configure
-loglevel warn -nameserver 192.168.1.1 -port 53 -protocol tcp -search {} -timeout 30000

If you want the client to do UDP DNS queries, you have to ensure you have the tcludp package installed. With Ubuntu, the package is named libudp-tcl. So the following should get you Ubuntu guys where you need to go:

# apt-get install libudp-tcl
# tclsh
% package require dns
1.3.2
% dns::configure
-loglevel warn -nameserver 192.168.1.1 -port 53 -protocol udp -search {} -timeout 30000

Or, alternatively, you can always just open up 53/TCP on your DNS server.

Configuring Napatech Cards to Perform Hashed Load Balanced Streaming

There is quite a lot of documentation provided with the Napatech cards if you are a customer, but the  default configs provided aren’t what you want to use to hit the ground running for IDS setups.  To configure the card to split the traffic up into 8 streams by hashing the headers, create a /opt/napatech/config/custom.cfg file that contains the following. We of course are assuming you have installed the necessary hardware/software and compiled basic tools like tcpdump against the Napatech provided libpcap:

#=NTPL=#
DeleteFilter=All
HashMode=Hash5TupleSorted
SetupPacketFeedEngine[TimeStampFormat=PCAP;DescriptorType=PCAP;MaxLatency=1000;SegmentSize=4096;Numfeeds=8]
PacketFeedCreate[NumSegments=16;Feed=(0..7)]
Capture[Priority=0;Feed=(0..7)] = ALL

Now start the driver up:

[user@host]# /opt/napatech/bin/load_driver.sh ntxc0=/opt/napatech/config/custom.cfg

You should now be able to see that the streams are accessible by running the tcpdump with the -D flag:

# tcpdump -D
1.eth0
2.ntxc0:0 (NT adapter 0 feed 0)
3.ntxc0:1 (NT adapter 0 feed 1)
4.ntxc0:2 (NT adapter 0 feed 2)
5.ntxc0:3 (NT adapter 0 feed 3)
6.ntxc0:4 (NT adapter 0 feed 4)
7.ntxc0:5 (NT adapter 0 feed 5)
8.ntxc0:6 (NT adapter 0 feed 6)
9.ntxc0:7 (NT adapter 0 feed 7)
10.any (Pseudo-device that captures on all interfaces)
11.lo

init.d Script for Napatech Cards

Just something thrown together quickly for use with our Ubuntu 8.04 LTS systems to initialize the card and configure it on boot. You must set CONFIG to be your config file or else the script will just exit. This init script assumes you have only one card in the box and it is ntxc0. Don’t forget to create your symlinks S##napatech and K##napatech into your /etc/rc*.d/ directories. Also don’t forget to ensure that your IDS processes are starting up after this gets loaded or else the ntxc0:# streams won’t be available to monitor. The “status” command pulls the log entries from the card. If running that status command yeilds >>> Error: No adapters could be found., then the driver is not loaded.

#!/bin/sh -e
#### BEGIN INT INFO
# Provides:             Napatech
# Required-Start:       mountkernfs $local_fs
# Required-Stop:        $local_fs
# Default-Start:        2 3 4 5
# Default-Stop:         S 0 1 6
# Short-Description:    Loads Napatech network card
# Description:          Napatech kernel driver and configuration
### END INIT INFO
#
# Author:               Eoin Miller (eoin[dot]miller[at]trojanedbinaries[dot]com)
#
set -e
PATH=/bin:/usr/bin:/sbin:/usr/sbin:/opt/napatech/bin
LOAD="/opt/napatech/bin/load_driver.sh"
UNLOAD="/opt/napatech/bin/unload_driver.sh"
UTIL="/opt/napatech/bin/bash_loadunload"
CONFIG="/opt/napatech/config/customconfig.cfg"
DRIVER="/opt/napatech/driver/ntki.ko"
if [ ! -x $LOAD ];then
        echo "File: $LOAD missing or not executable!"
        exit 1
fi
if [ ! -x $UNLOAD ];then
        echo "File: $UNLOAD missing or not executable!"
        exit 1
fi
if [ ! -e $UTIL ];then
        echo "File: $UTIL missing!"
        exit 1
fi
if [ ! -e $CONFIG ];then
        echo "File: $CONFIG missing!"
        exit 1
fi
if [ ! -e $DRIVER ];then
        echo "File: $DRIVER missing!"
        exit 1
fi
. /lib/lsb/init-functions
case "$1" in
    start)
       log_daemon_msg "Starting Napatech network card:" "Napatech"
       $LOAD ntxc0=$CONFIG > /dev/null
       log_end_msg $?
    ;;
    stop)
       log_daemon_msg "Stopping Napatech network card:" "Napatech"
       $UNLOAD > /dev/null
       log_end_msg $?
    ;;
    status)
      DriverLog -mask=0x04
    ;;
    restart)
       $0 stop
       $0 start
    ;;
    *)
       echo "Usage: /etc/init.d/napatech {start|stop|status|restart}"
       exit 0
    ;;
esac
exit 0

After this file has been put into /etc/init.d/napatech, you can create your symbolic links as so to stop/start the card and driver as appropriate:

ln -s /etc/init.d/napatech /etc/rc2.d/S12napatech
ln -s /etc/init.d/napatech /etc/rc3.d/S12napatech
ln -s /etc/init.d/napatech /etc/rc4.d/S12napatech
ln -s /etc/init.d/napatech /etc/rc5.d/S12napatech
ln -s /etc/init.d/napatech /etc/rc0.d/K12napatech
ln -s /etc/init.d/napatech /etc/rc1.d/K12napatech
ln -s /etc/init.d/napatech /etc/rc6.d/K12napatech

VSS Monitoring Stream Capable Load Balancing Taps

Had a meeting today and someone clued me into the existance of VSS Monitoring makes taps that use a hashing algorithm to distribute the load of 10G taps across several monitoring ports. This method ensures that all the packets of a TCP session is distributed to the same monitoring port. This is much like what stream capable cards from vendors such as Endace and Napatech perform. This definately caught my attention as this is the first tap I have seen with this level of functionality. In my previous post I wrote about using a single stream capable card that uses a hashing algorithm to be combined with Daemonlogger and quite a few quad head network cards to create a “traffic splitter”. Well it appears VSS Monitoring has actually already created a tap to do just this. I don’t know about the pricing of the devices (standard tap, a stream capable card and commodity server/nics is probably going to be cheaper) but stripped down specialized hardware can have its advantages. Here is a podcast they did outlining the functionality of the taps:

Unfortunately you have to dig into this level to see that this is the functionality and even in the podcast they keep going over filtering. They go over what load balancing is on their site, but they do not have a list of which of their taps support it. As best I can tell, any 10G capable distributed tap they sell has this functionality.

Sguil Icons

Took a little time today to create a 128×128 vector based logo for Sguil. Below is a PNG version for you to preview it on the web:

sguil-icon

You can download the vector based SVG type icon here! Or for you Windows guys, here is a Vista/Windows 7 icon. We delivered a copy of it over to the Sguil maintainers and they may add it in to the CVS, so check in the tree and you may already have it.