Business Logic at the Client

I’m con­stantly amazed at how I can start search­ing for one thing on the web and end up in a totally dif­fer­ent area. This isn’t a giant leap, but it still got me think­ing. I started out search­ing for auto­mated ways of deob­fus­cat­ing javascript. In my role as an inci­dent han­dler, and as a gen­eral geek, I am noth­ing short of elated to see javascripts that con­tain eval fol­lowed by hun­dereds of hex, ascii, uni­code, or html encoded char­ac­ters. I believe that as a stu­dent of com­puter engi­neer­ing and com­puter secu­rity I’m nat­u­rally inclined to be inquis­i­tive. Cur­rently, when­ever I come across a script like this I write a cus­tom perl script to han­dle the source file under inspec­tion. I was think­ing that I should write a “mega” script to han­dle all types of cases that I’ve run into. The prob­lem with that of course is that it’s actual work. And if I were to release it, I’d have to make it mod­u­lar in such a way that it can eas­ily be expanded for addi­tional obfus­ca­tion techniques.

Long story short.… I ended up on a web devel­oper forum where the ques­tion was asked as to how a devel­oper can hide their busi­ness logic from the end user, since it’s in javascript.

Busi­ness logic does NOT belong on the client side!

First of all, any­thing sent to the client can be seen by the client. If the data is sent in a way such that Inter­net Explorer or Fire­fox can under­stand what to do with it, it can be seen and under­stood by a capa­ble ana­lyst. If this logic is your secret sauce, than you absolutely should not just give it away to every GET received on port 80.

Sec­ondly, the secu­rity impli­ca­tions could be huge if any of the data sent back to the server is trusted. Since this per­son is putting their logic in client side code, it would not sur­prise me to find out that the server side code trusts the data it receives from the busi­ness logic with­out check­ing for valid val­ues, length, etc. By using a sim­ple pro­gram such as Paros Proxy it is pos­si­ble for a mali­cious end user to inter­cept and mod­ify all val­ues both incom­ing and out­go­ing. A capa­ble user could set the results of the busi­ness logic to be what­ever value they wanted, skip­ping all of the client side data val­i­da­tion techniques.

Finally, the big pic­ture that is painted by this lit­tle exam­ple is that an appli­ca­tion, espe­cially a web appli­ca­tion, should never trust ANY input from the client. Client side val­i­da­tion is con­sid­er­ate for the end user, but does noth­ing in terms of secur­ing the site. All data to be processed by the appli­ca­tion needs to be val­i­dated and cleansed on the server side. This even goes so far as to val­i­date HTTP Header fields if they are to be used. There is noth­ing stop­ping a per­son from chang­ing any value in the HTTP sec­tion of the packet to any other arbi­trary value. As would hope­fully be the norm, always val­i­date against a whitelist when­ever pos­si­ble. It’s much safe to know exactly what type of infor­ma­tion you’re expect­ing rather than try­ing to guess to next mali­cious value the attack­ers will discover.

So remem­ber, don’t trust client data, and val­i­date, val­i­date, validate!

Spam Analysis

The other day I received a piece of spam that sur­prised me. First, because I was sim­ply shocked that I got a piece of spam. I haven’t received a sin­gle piece of spam at that address in years! This led to my sec­ond obser­va­tion: the spam was sent to one per­son and car­bon copied to three oth­ers, all at the same domain name. Now that’s tricky! Here lots of spam­mers are try­ing to use PDFs or images to get their spam through, and this per­son just made it look like a typ­i­cal busi­ness email.

SPAM Message

If you both­ered to take a look at the image above, you noticed a link to www [dot] med123window [dot] org. Now I’m always up for an adven­ture, so I logged into my trusty *nix box and pulled the page down with wget. Using cat to look at the con­tents, I noticed that it con­tained noth­ing but a big encoded JavaScript. Take a look at it here.

The script would use the JavaScript func­tion unescape to turn the hex val­ues into ASCII and then pass that result on to the eval func­tion for it to be loaded and exe­cuted at run­time. Maybe it’s because I look at mal­ware all day, but is it just me, or is there no good rea­son for eval to exist?

I could have used a JavaScript based sand­box approach that would allow the code to be unescaped and dis­played in a textarea, but I’ve heard reports that some mali­cious code is wise to that attempt and can defeat it. So I went with a method they can’t defeat. It’s called perl. And it’s beautiful!

The method I used here was to take input off of STDIN, find all occur­rences of \x??, con­vert each to the cor­re­spond­ing ASCII value, and then finally parse that result for use of HTML encod­ing that uses hex in the form %??. Here’s the result­ing pro­gram.
(** Note: In both exam­ples above the ques­tion marks would be replaced with a hex value 0–9 or A-F)

Here’s the out­put after both rounds of con­ver­sion through my script.

Spam Analysis - Round 2

Thank­fully, this tries to load a page off of non-standard port 8088 which is blocked by default in my gen­eral egress rule set. It’s blocked in yours too, right?

If we use a machine that does have access to the port we can view this site by pro­vid­ing a fake sub­do­main match­ing the pat­tern the script above would use. When I saw it I was actu­ally fairly impressed. The design and lay­out was very well done, looked pro­fes­sional, and dare I say even bet­ter than some legit cor­po­rate web sites!

The main site: Spam Analysis - Main Site The Check-Out Cart: Spam Analysis - Check Out

Now here’s what’s always baf­fled me about these sites.…. They are sell­ing drugs, right? So why are peo­ple will­ing to pay large sums of money for drugs when they could get from their doc­tor for a co-pay if they really needed them? Also, who says this dealer can be trusted?! They are an annoy­mous web­site that uses shad­ing mar­ket­ing tac­tics to get peo­ple to their site. What’s to say that the check out isn’t just to col­lect credit card num­bers and never send you a sin­gle pill? Even more dire, what’s to stop them from putting arsenic in every pill? It’s not like they are reg­u­lated by the FDA.

* shrugs * I may not under­stand why peo­ple go to these sites, but I can at least accept that some­one must, oth­er­wise there wouldn’t be so much effort put into get­ting the adver­tise­ment out.

College Classes and Security

As men­tioned in my About sec­tion, I’m cur­rently work­ing on my Mas­ter of Sci­ence in Com­puter Secu­rity. Fun­da­men­tally its only a hand­ful of classes dif­fer­ent from the MS in Com­puter Sci­ence so I’m tak­ing a slew of pro­gram­ming cen­tric courses.

This week I received the book for next semes­ter and started read­ing through it. I’m very happy to say that writ­ing code with secu­rity in mind was men­tioned sev­eral times. And it’s not all just your stan­dard stuff about buffer over­flows either. This selec­tion below is from the preface:

Hav­ing a solid under­stand­ing of com­puter arith­metic is crit­i­cal to writ­ing reli­able pro­grams. For exam­ple, one can­not replace the expres­sion (x<y) with (x-y<0) due to the pos­si­bil­ity of over­flow. One can­not even replace it with the expres­sion (-y<-x) due to the asym­met­ric range of neg­a­tive and pos­i­tive num­bers in thetwo’s com­pli­ment rep­re­sen­ta­tion. Arith­metic over­flow is com­mon source of pro­gram­ming errors, yet few other books cover the prop­er­ties of com­puter arith­metic from a programmer’s per­spec­tive.1

1 Bryant, Ran­dal E. and David R. O’Hallaron. Com­puter Sys­tems: A Programmer’s Per­spec­tive.
        New Jer­sey: Pear­son Edu­ca­tion, 2003.

Unblocking “Dangerous” Attachments in Outlook 2007

I recently came across an email that had an attach­ment of a very spe­cific file type. I was expect­ing this email and the attach­ment. Out­look how­ever, didn’t know about this file exten­sion and decided that it should be blocked. After some search­ing I came across this KB Arti­cle that describes how to reme­di­ate this issue in Out­look 2000.

Some minor tweaks and it works for Out­look 2007 too!

Name: Level1Remove
Type: REG_SZ
Data: List of file exten­sions sep­a­rated with a comma includ­ing the period. (Ex: .mdb,.xnk)

If you want to block exten­sions nor­mally allowed mod­ify Level1Add instead of Level1Remove.

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 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:

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:

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)