A Humorous RFC

Pub­lished in April of 2003, RFC 3514 defines an “evil” bit. The RFC requires that any packet sent on a net­work MUST set this bit to 1 and that any non mali­cious pack­ets MUST set the bit to 0. The goal of course is to make defend­ing sys­tems eas­ier since “Fire­walls, packet fil­ters, intru­sion detec­tion sys­tems, and the like often have dif­fi­culty dis­tin­guish­ing between pack­ets that have mali­cious intent and those that are merely unusual.”

If the bit is set to 0, the packet has no evil intent. Hosts, net­work ele­ments, etc., SHOULD assume that the packet is harm­less, and SHOULD NOT take any defen­sive mea­sures. (We note that this part of the spec is already imple­mented by many com­mon desk­top oper­at­ing systems.)”

Sure, I may be about 4 years late to this but it’s still an enter­tain­ing read. It’s not quite up there with RFC 1149, Stan­dard for the Trans­mis­sion of IP Data­grams on Avian Car­ri­ers, but it’s good. As for how I came across this gem on the wide and vast inter­web?? Perus­ing through the Reverse Engi­neer­ing Wik­i­book of course!

Detailed WMF Analysis

As a fol­low up to the pre­vi­ous post I thought it might be use­ful to give an exam­ple of how these mul­ti­ple sets of infor­ma­tion could be used.

Here’s the process:
1) Snort Alert about WMF NumOb­jects being 0
2) I’m unable to deter­mine if the machine is patched
3) I look at net­work ses­sions lead­ing up to and then after the WMF file was accessed, noth­ing I wouldn’t expect
4) Look at event logs on the affected host and con­clude there was no abnor­mal activ­ity on the host

At this point I’m pretty sure the alert was a false pos­i­tive. But I’d like to know for sure. My plan of action then becomes to pull the pull the sus­pect file out of my full con­tent col­lec­tion sys­tem onto a *nix box. From there it can be eas­ily sent to www.virustotal.com for a quick check, as well as man­u­ally ana­lyzed by me.

Here’s some com­mands I ran and their respec­tive results.

  • file attach.wmz results in attach.wmz: gzip com­pressed data, from Win/32, max speed
  • gzip –dvf –suf­fix .wmz attach.wmz replaces it with attach
  • file attach results in attach: ms-windows meta­font .wmf
  • xxd attach pro­vides the fol­low­ing out­put:
    wmf_code

From here I was able to ver­ify that the file did indeed have a (ZERO) in the Num­berO­fOb­jects field using the infor­ma­tion pro­vided at this site: http://wvware.sourceforge.net/caolan/ora-wmf.html

Didier Stevens kindly pro­vided some assis­tance through the Secu­rity Cat­a­lyst Com­mu­nity by pro­vid­ing a tem­plate for the 010 Edi­tor. The tem­plate along with my analy­sis of the file is coming…

Alerts are Just the Beginning

I’ve some­times heard that some peo­ple treat their Intru­sion Detec­tion Sys­tems (IDS) as both the begin­ning and end of their inves­tiga­tive process for net­work secu­rity. Alerts gen­er­ated by these sys­tems should be treated like alarms from phys­i­cal secu­rity sys­tems. They trig­ger a response process. Some­times that response is short after con­clud­ing the alert was a false pos­i­tive, but some­times it can be quite lengthy; like in the case of a real intrusion.

Here’s a quick list of some items to look into after receiv­ing an IDS alert and is by no means totally inclusive.

  • Deter­mine the OS Type and Ver­sion with what the attack requires and check this against the tar­get machine
  • Deter­mine if the services/applications required for the attack are installed
  • Deter­mine if the services/applications are at a patch level that makes them vul­ner­a­ble to the attack
  • Look at host based logs for any signs of a for­eign exe­cutable run­ning on the sys­tem (Process Exe­cuted in Win­dows for example)
  • Look at AV/HIPS logs for any allowed or denied actions
  • Look at web proxy logs for any sub­se­quent con­tact or multi-stage down­loads com­ing from the tar­get machine
  • Pull traf­fic from a full con­tent sys­tem to man­u­ally ver­ify any mali­cious code ( be care­ful with this! don’t acci­den­tally run it on your own system)

A Fresh Look for a Fresh Start

A while ago my web­site http://rarmknecht.net got cat­e­go­rized by Web­sense as mali­cious.  This came about the same night I posted an entry about how to use a perl script to deob­fus­cate some sim­ple eval()‘d javascript.  They saw the code, assumed it was mali­cious and black listed me.  From now on I’ll be post­ing screen­shots of code, and not code directly.  This should skirt the Web­sense issue.

My other issue has been find­ing time to post due to many per­sonal hap­pen­ings sur­round­ing my every­day life. I’m freed up once again and get­ting ready to start a new term in my Master’s pro­gram.  I’m excited and hope to share much of my strug­gles and tri­umphs here.

As before, this blog is pri­mar­ily a dump­ing ground for my thoughts sur­round­ing tech­ni­cal and cor­po­rate issues. Gen­er­ally, they will be secu­rity related as it is not only my cur­rent job but my pas­sion as well. I look for­ward to a promis­ing jour­ney and the abil­ity to share it online.  It’s my hope that some­one some­where will find what I have to say help­ful. If not, at least it’ll help me :)