Bomb #1

My cur­rent class assign­ment con­sists of reverse engi­neer­ing a piece of code writ­ten by the pro­fes­sor. Basi­cally the pro­gram reads in one line from STDIN at a time and checks to see if it’s the right phrase. If it is, that bomb is defused and it con­tin­ues to the next one. If the phrase is incor­rect that the bomb blows up and I’ll have to try again.

Below is my method­ol­ogy for Phase 1.

** Note that as a stu­dent we were given access to the source code of the “shell” pro­gram that calls the other func­tions that actu­ally do the com­pare. So I know that the func­tions are called phase_1() through phase_6(). The func­tion names could also be guessed by using obj­dump –t bomb.exe and look­ing at the func­tion names.

** Also, solutions.txt con­tains a sin­gle line with con­tent: test­ing

$ gdb bomb
(gdb) b phase_1
(gdb) dis­play /i $pc
(gdb) r solutions.txt

That runs the pro­gram until the break­point is hit. Once it’s hit I run disas to dis­play the assem­bly of the cur­rent func­tion. I notice that there is a call to strings_not_equal and fig­ure that the two val­ues pushed onto %esp are likely the argu­ments, and based on the func­tions name, are likely strings. I then use dis­play /a $eax to take a look at the address con­tained in %eax. Finally, I use x /s 0x405040 and x /s 0x404140 to look at the strings located at those addresses. One is the string I passed in, and the other is the win­ing string. I change my solutions.txt file to have the new string in it and test it to val­i­date. It works! Bomb 1 defused!

Bomb - Phase 1

Brain Dump: Ubuntu 7.04 Feisty Fawn, School, Giving Back, Blogging

I recently loaded up a new vir­tual machine with Ubuntu 7.04 Feisty Fawn (32-bit) run­ning on Vista Ulti­mate (64-bit) and have had no prob­lems thus far.  Every­thing works, dual mon­i­tors, sound, net­work­ing, etc…

I’m seri­ously impressed with the qual­ity of VMWare Work­sta­tion 6.  I’ve been a user of their prod­uct since ver­sion 4, and it’s done noth­ing but improve.  I’m also impressed with Ubuntu.  It took almost zero effort in order to get a work­ing sys­tem installed to disk. After the install a sim­ple sudo apt-get install build-essential was all I needed to get what I need for development.

My rea­sons for the linux vm are 2 fold. First of all I pre­fer it to win­dows as a “safer” plat­form to do my bank­ing and such on. Sec­ondly, I’ve started another class in my Master’s pro­gram at DePaul Uni­ver­sity, and it requires a linux sys­tem.  We’ll be learn­ing assem­bler from the programmer’s point of view; that is under­stand­ing what data struc­tures, con­trol state­ments, etc look like in assem­bler as well being able to take com­piled pro­grams and debug them at the assem­bler level to find/troubleshoot bugs.

I’ve also been spend­ing some time think­ing of ways to give to the secu­rity com­mu­nity.  One of my ways was recently men­tioned in a Secu­rity Cat­a­lyst Com­mu­nity forums post.  Basi­cally, cre­ate a matrix of secu­rity con­trols and com­mon imple­men­ta­tions cross ref­er­enc­ing them with all the dif­fer­ent secu­rity stan­dards out there. A per­son could for instance check all the con­trols they already have in place. The site would then list off the stan­dards they are already com­pli­ant with.  If they wanted, they could pick a stan­dard and it would list off both what they already have and what they are lack­ing. Not easy and not quick, but useful.

I’ve also been play­ing around with some type of more use­ful way to glean data from Check­Point fire­wall logs that have been exported to ASCII with the fwm log­ex­port –i <date> –o <date>.out –n –p –m raw com­mand. Specif­i­cally, I’m look­ing for ways to visu­ally make unusual activ­ity “jump” out at the ana­lyst. I’ve been able to cre­ate graphs of port usage over time, but haven’t got­ten the code into a state where com­par­i­sion against the stan­dard divi­a­tion is viable yet.  I also haven’t come up with a solid inter­face either.  Thus far its a hodge podge of perl scripts that can print graphs if STDOUT is redi­rected to a png file :) I’m debat­ing between open source, free soft­ware, web-based stuff and C# in a Win­dows App. The devel­oper in me wants to use C# since I’m very com­fort­able with the lan­guage, but the stu­dent in me wants to use perl, mysql, and php. Oh the choices!

Another inter­est­ing thing I’ve been mulling over is file carv­ing from libp­cap files. Often I find myself want­ing to grab a file that was sent over the net­work that I have a cap­ture of. I’ve been think­ing of 2 ways to solve this: (1) write my own parser for files as I need them or (2) con­tribute to the tcpx­tract project so that it works more accurately.

Well that’s my brain dump for now.  One of my goals is to use blog­ging as Richard Bejtlich has, and that’s as a per­sonal dump­ing ground to find thoughts, arti­cles, etc in case I need to refer back to them in the future. Let see how this works out!

Deobfuscating JavaScript at the Browser

The Web­sense Secu­rity Labs Blog has an inter­est­ing post up about one method of deob­fus­cat­ing JavaScript. As I’ve eluded to in pre­vi­ous posts, any code thats pushed to the client’s browser must even­tu­ally be under­stand­able by that browser. This is why the mali­cious scripts have to con­tain code to deob­fus­cate them­selves. The trou­ble of course is get­ting the script to run with­out actu­ally run­ning the mali­cious content.

My method has pri­mar­ily been repli­cate the scripts func­tion­al­ity and eval­u­a­tion of code with a perl script on a *nix com­mand line. If every­thing is get­ting printed to STDOUT instead of the source of an html file inside a browser there is no chance that the code could exe­cute. This has worked well be can often be tedious.

The method dis­cussed in the post above involves hook­ing the document.write func­tion of JavaScript inside the mshtml.dll. With this in place an ana­lyst can extract the deob­fus­cated code before it is fully processed by the browser. That’s clever!

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!