Finshake

Funny ‘Hacker’ Story

Funny ‘Hacker’ Story.

A funny story about a hacker named “bitchchecker”, proving his mad skills by attacking someone on the Internet.

Using the IP: 127.0.0.1

Watch out for this guy.

¶ Posted 10 March 2010 † Joel § funny § morons § security § websites ‡ Comments (0) °

VRT: APT: Should your panties be in a bunch, and how do you un-bunch them?

VRT: APT: Should your panties be in a bunch, and how do you un-bunch them?.

I don’t know how to say it anymore than this:

Matt Olney wrote a damn, a DAMN good post about APT on the VRT blog, and if you read my blog, and you don’t go over to the VRT blog and read that post.. Heck I don’t care if you don’t read another post by the VRT that they have written in the past (although, you SHOULD! They put a LOT of time into their posts!) you should read this one.

Matt, whom I play Xbox with nearly every night, talk to on a regular basis, and consider to be my friend.. I just wanted to let you know, seriously…

Damn fine job sir.

¶ Posted 09 March 2010 † Joel § Snort § Sourcefire § VRT § blogs § security § software § updates § websites ‡ Comments (3) °

10 reasons to avoid talking on the phone

10 reasons to avoid talking on the phone – The Oatmeal.

This is an awesome comic, pretty much sums up talking on the phone correctly.

Click through, it’s awesome.

¶ Posted 09 March 2010 † Joel § funny § websites ‡ Comments (0) °

Sourcefire VRT Labs: MS to SID mappings

Sourcefire VRT Labs.

For those of you that are using Sourcefire VRT rules to protect your network with your Snort IDS/IPS installation, (as you should!). There are mappings from MS vulnerability number to SID number, in the past, you either had to be a Sourcefire customer (we make this super easy in the Policy Editor GUI) or you had to be very patient and grep your way through the rules.

However, VRT put these mappings in a super easy to use interface at the link above. Check it out.

Update:

Nigel corrected me, these mappings have always been on Snort.org, VRT just moved the hosting. Duh.

¶ Posted 07 March 2010 † Joel § Microsoft § Snort § Sourcefire § VRT § logs § security § websites ‡ Comments (0) °

Usability participants needed for Outlook:Mac

go ahead, mac my day : usability participants needed for Outlook:Mac study in March.

Blog entry from one of the developers that works on the Office:Mac suite at Redmond, asking for usability testing volunteers to test Outlook for the Mac. (To be released this year IIRC.

If you are in or near Mountain View, California, and you wish to participate, you need to be eligible by:

use a Mac for work purposes
connect your Mac to an Exchange server
use mail and calendar on your Exchange server several times per week

¶ Posted 07 March 2010 † Joel § Microsoft § Outlook § apple § office ‡ Comments (2) °

Offset, Depth, Distance, and Within

Without going off the deep-end here and discussing every single Snort rule keyword, I just wanted to touch on a few modifiers that people sometimes misunderstand. They aren’t difficult, and hopefully after this explanation and a few examples, I can clear some of the air around these five modifiers.

The five modifiers that I am talking about are

Offset
Depth
Distance
Within
nocase

These five modifiers are not keywords of themselves, but rather they apply as modifiers to another keyword. That keyword is “content”.

The content keyword is one of the easiest pieces of the Snort rules language as all it does is look for a particular string. So for instance if I wanted to look for the word “joel” within a packet. A simple:

content:”joel”;

Would allow me to do that. The interesting part comes into play when you want to specify where inside of a particular packet you want the string “joel” to be looked for. If you are running just a plain content match with a simple string, and not specifying where in the packet to look for that string, your Snort instance will receive a ton of alerts, and then you, the analyst, are stuck looking through all of those alerts to try and pick out the alert that is needed. While a content match for “joel” might be pretty unique (that might not occur a lot on your network), but it will occur a bunch on mine.

Offset

Offset in the Snort manual is defined as:

The offset keyword allows the rule writer to specify where to start searching for a pattern within a packet.

So, given a certain packet, Offset tells the content match it’s modifying where to start looking, given an offset from the beginning of the data payload of the packet.

In the above example, if I wanted to find the word “GET” (highlighted). I would write:

content:”GET”; offset:0;

Meaning, start at the beginning of the data payload of the packet (offset:0;) and find the word GET. Now, in this example, the word “GET” is at the very beginning of the packet making the search very easy. However, if I wanted to match on the word “downloads” that is found a bit later in the above screenshot, I could still start my content match at the beginning of the payload (offset:0;) but the content match would be more accurate and less computationally expensive if I were to make the offset more accurate.

content:”downloads”; offset:13;

Would tell Snort to start looking for the word “downloads” at the 13th byte in the data portion of the packet. So, what if I chained these two together?

content:”GET”; offset:0; content:”downloads”; offset:13;

In other words, start looking for “GET” at the beginning of the data payload of the packet, and start looking for the word “downloads” at the 13th byte of the packet. Now, why would I do this? This example tells Snort, after the first content match, go back to the beginning of the packet, move over 13 bytes and then start looking again for a second content match. There are several things wrong with this example, -that I did on purpose-.

First off, if you are at the first content match in a Snort rule, or a content match you want to start at the beginning of the packet, you don’t have to write “offset:0;”. Any content match that doesn’t have a modifier after it automatically starts at the beginning of the data payload portion of the packet by default. Offset:0; is implied for this type of match.

Second, and a:

>Common Misconception<

Some tend to think that if they stack two contents next to each other, that Snort will look for those contents in the order they are provided. For example, if I were to write:

content:”GET”; content:”downloads”;

Some people generally think that in the above example, that the word “downloads” will have to occur after the word “GET” in the packet. This is Wrong. If no modifiers to contents are specified than the order of the matches within a given packet (or stream for that matter) doesn’t matter. ”downloads” could be first, then “GET”, and the rule will still fire.

So given the above exampled screenshot, if I wanted to force the word “downloads” to occur after the word “GET”. I could use a distance modifier. Which I will touch on a bit later.

2. Depth

Depth in the Snort manual is defined as:

The depth keyword allows the rule writer to specify how far into a packet Snort should search for the specified pattern.

So, given the above example again:

I want to match on “GET” but ONLY if it occurs as the beginning of the packet. Notice when I was describing offset above I said that offset tells Snort where to start looking. Not where to stop. If I don’t tell Snort where to stop using a content match, Snort will search the entire packet. If I want to tell Snort where to stop looking for a content match, I have to use something like depth.

So for the above example, if I want to match on “GET” but only at the beginning of the data portion of the payload:

content:”GET”; depth:3;

Notice some things.

I didn’t start with Offset:0;. Remember, if I am beginning a content search at the beginning of the data payload of the packet, offset:0; is implied.
Depth counts in positive integers. While offset starts counting at “0″ bytes, depth counts in positive integers, “GET” is three bytes long, so my depth is “3″.
Depth starts counting from the offset point. Not from the beginning of the packet. While, in the above “GET” example, the offset point IS the beginning of the packet, don’t get confused by this.
By telling Snort to only look in the first three bytes, if Snort is analyzing millions of 1500 byte packets, only matching on the first three bytes is a significant CPU saver.

3. Distance

Distance is defined in the Snort manual as:

The distance keyword allows the rule writer to specify how far into a packet Snort should ignore before starting to search for the specified pattern relative to the end of the previous pattern match.

(Emphasis added by me)

Distance says to us, “okay, relative to the end of the previous content match, when should I start searching for the second content match?”. So bringing back my previous example:

content:”GET”; depth:3; content:”downloads”;

If I were to do this:

content:”GET”; depth:3; content:”downloads”; distance:0;

That by itself would force the content match “downloads” to occur after the “GET” content match. Doesn’t matter where (distance:0;), just as long as the pattern match is AFTER the first one. However, if I wanted to be more specific and more specifically match on the screenshot that I provided above:

content:”GET”; depth:3; content:”downloads”; distance:10;

This says to the Snort engine, “match on GET, in the first 3 bytes of the data payload of the packet, then move 10 bytes relative to the end of GET and start looking for “downloads”".

Notice I said start looking. Not limited to. Kinda like putting an offset without a depth there… so we have within.

4. Within

Within in described in the Snort Manual as:

The within keyword is a content modifier that makes sure that at most N bytes are between pattern matches using the content keyword

Within allows you to specify a range between content matches, it also allows you to tell a second (relative) content match where to stop.

So, using the content matches we’ve built already:

content:”GET”; depth:3; content:”downloads”; distance:10;

The only problem here is “downloads” is being searched for in the entire packet, except for the first 13 bytes, essentially. How can we make downloads only be searched for at that specific spot? Within.

content:”GET”; depth:3; content:”downloads”; distance:10; within:9;

“Match on GET, in the first 3 bytes of the data payload of the packet, then move 10 bytes relative to the end of GET and start looking for “downloads”, however, “downloads” must occur wholly within the next 9 bytes.”

Could I say “within:10;”? Yes, I could, and then downloads could be in it’s present position, or if there was another byte in front of the actual content match.

Also notice that within, like depth, also works in positive integers (distance starts counting at “0″)

5. nocase

Finally, let me discuss “nocase”;. nocase, or “No case” simply means, for the content match specified, do not pay attention to case sensitivity. ”nocase” doesn’t make the Snort engine work any harder in the grand scheme of things, and it’s very handy for being able to make sure your rules do not get bypassed.

Example?

Let’s say I wanted to match the above screenshot, no matter what. Well, if I was an attacker, and I came to your webserver trying to access your “downloads” directory, as the rule is written, I could pass my “GET” string as lowercase “get” or mixed case “GeT”, and depending upon your webserver, it might accept it, and I have effectively bypassed your rule.

The easiest thing to do with this type of evasion is to use a nocase; statement.

content:”GET”; depth:3; nocase; content:”downloads”; distance:10; within:9; nocase;

So, I want you to notice a few things:

We went from very generic to very specific, your use case will vary.
Modifiers to contents come AFTER the content match. Not before, they won’t work, don’t try it.
Offset goes with Depth, distance goes with within. Don’t mix them.

Hopefully this helped someone clear up any confusion surrounding these keywords. For further information, please refer to the Snort Users manual. http://www.snort.org/start/documentation

–

SNORT and Sourcefire are registered trademarks of Sourcefire, Inc.

¶ Posted 02 March 2010 † Joel § Snort § Sourcefire § security § software ‡ Comments (2) °

Apple sues HTC for alleged infringement of 20 iPhone patents

AppleInsider | Apple sues HTC for alleged infringement of 20 iPhone patents.

…And so it begins… I was beginning to wonder when this was going to happen, of course, HTC, the makers of many phones, the most notable being the Google Nexus One, and the G1.

We’ll have to wait and see how this one shakes out.

¶ Posted 02 March 2010 † Joel § apple § iPhone ‡ Comments (0) °

Plugins add grunt to Google’s Quick Search Box

Plugins add grunt to Google’s Quick Search Box « Hawk Wings.

If you are a user of Google’s Quick Search Box (similar to QuickSilver), and is in active development, you can download and use these series of scripts in order to interact with the rest of your OS. (Things like sending a file through email in Mail.app).

Or, you can just stick with QuickSilver. It does all these things already.

¶ Posted 01 March 2010 † Joel § Mail § apple § software ‡ Comments (0) °

Hogging the Snort Host Attribute Table

Hogger is a new Snort supportive tool written in Perl. It takes Nmap output and makes a Host Attribute Table.

via Security – The Global Perspective: Hogging the Snort Host Attribute Table.

I talked about the above here.

¶ Posted 26 February 2010 † Joel § Snort § Sourcefire § security § software ‡ Comments (0) °

Writing Snort Rules Correctly

Let me start off by saying I’m not bashing the writer of this article, and I’m trying not to be super critical. I don’t want to discourage this person from writing articles about Snort rules. It’s great when people in the Snort community step up and explain some simple things out there. There are mistakes, it comes with the territory. If you choose to be one of the people that tries to write Snort rules, you also choose to be someone who wants to learn how to do it better. That’s why I write this blog post, not to bash the writer, but to teach.

I noticed this post today over at the “Tao of Signature Writing” blog, and to be honest I glanced over most of it figuring it was a rehash of things I’ve already read or things that have already been written from countless people about “Here’s how you write Snort rules!”. I scrolled down quickly skimming, not reading at all really, and noticed this part:

Now, let us look at the second question: “We have “aol” as the id and Import method name. Should we use “aol” along with “Import”?”. Just because we narrowed down to “clsid:” followed by CLSID number, does not mean that we have to narrow down in this case too. Just like how the Shellcode will change, the attackers might change the ID too, to just find out if they could evade the IDS/IPS. Why give them a chance? Hence, we should broaden our search to just the import method: content:”.Import(“. The reason why we have “.” and “(” around the key “Import” is to narrow the chances of triggering the signature on some term “Import” and to concentrate on the vulnerable method.

This post is about ActiveX and CLSID detection with a Snort rule, trying to detect an AOL 9.5 ActiveX 0day. Okay, fair enough, so the above paragraph is trying to find the Import command to call the javascript. So I kept reading.

Then I got to this part:

In here, I would like to position the CLSID before the method. This would help me trigger the signature specific to “AOL 9.5 ActiveX 0day Exploit (heap spray)“. I can do this ordering by using “Offset”. We cannot set the “Depth” in this case, since the position of CLSID or Method in a packet will change according to the packet size or the way in which it is sent. Hence, the content of final signature would look something like this:

content:”clsid:A105BD70-BF56-4D10-BC91-41C88321F47C”; nocase;content:”.Import(“; nocase; Offset:0;

The writer is correct in a couple things.

First, they say they want to position the CLSID before the method, so they want to do with using offset.
Second, they say they cannot set a “depth” because the position and method in the packet will change according to the packet size, which is partially correct.

However, the problem with this above signature is that the offset is placed after the second content match.

So here’s what would happen with the above signature so far. The CLSID content match is the longest, so it would be fed into the fast pattern matcher. If the fast pattern matcher came across a packet that matched the CLSID that is specified in the rule, <leaves stuff out>, then the packet would then be run through the detection engine (rule) for detection. Contrary to popular belief, unless an offset/depth/distance/within modifier is specified, there is no order for the packet to match. So if I were to write the above as this:

content:”clsid:A105BD70-BF56-4D10-BC91-41C88321F47C”; nocase;content:”.Import(“;nocase;

Snort doesn’t care which order the content matches are in. As long as both the contents are in the packet, then the rule will fire. So putting a content:”.Import(“; nocase; offset:0; does absolutely nothing. You can kind of think of offset:0; being implied, but if you don’t have any relative content matches, then it really doesn’t matter unless you are trying to be specific to a position match. However, as the author already stated, you can’t add a depth statement to the rule, so it plain, just doesn’t matter. I see this kind of thing all the time, so I figured common mistake. So I kept on reading:

Now, let us look into the direction of traffic. Client-side exploits generally flow from server to client: “flow:to_client,established;“.

The author explains that “Client-side exploits generally flow from server to client”. Okay, correct in this instance, but not always, so let me explain:

Flow has four direction operators you can specify:

to_server
from_server
to_client
from_client

What happens is when I hear from people is that they think “server” as that 2U thing back in the server room (hence the name), and client being “you”. But that’s not how Snort thinks about it. Snort thinks about client server in the “who initiated the conversation” term. So, at the beginning of a TCP conversation there is a 3-way handshake. SYN, SYN-ACK, ACK.

CLIENT -> SYN -> SERVER
CLIENT <- SYN, ACK <- SERVER
CLIENT -> ACK -> SERVER

The client is who initiated the conversation, the server is who is responding. So, in this case, since we are attempting to catch a web browser accessing a webpage and downloading a webpage which contains this CLSID, the flow would be to_client. (Or from_server) Correct. However, what if someone downloaded a PDF, and upon opening the PDF the PDF went and grabbed something off the internet. This is a client side exploit, however, the flow would be reversed. So, the author is correct in saying that “Client-side exploits are generally…” I wanted to explain to make sure no one was confused. The “established” keyword means the the session is established. So beginning on the 3rd part of the 3-way handshake.

In this case some folks might believe that CLSID is already in the “content” part of the signature, and that this is a repetition if we use it in PCRE once again. We are not using this PCRE to repeat the value in the content, but to ensure that we do not miss any possibilities of matching this exploit. Let us look into the PCRE part of this signature:

pcre:”/<OBJECT\s+[^>]*classid\s*=\s*[\x22\x27]?\s*clsid\s*\x3a\s*\x7B?\s*A105BD70-BF56-4D10-BC91-41C88321F47C/si”;

In here, the signature is telling the PCRE compiler that there is “< object” followed by strings and “>” with multiple-strings possibly following it followed by “classid” & “=” with the “clsid”, “:” and “{“. The true classid is then inserted into the PCRE. The PCRE ends with /i to indicate the case-insensitive nature of this regular expression.

The first paragraph is partially correct. If you check for a content match, you can use a pcre to clarify what you are looking for. This is done for a couple reasons. One, as the author states above, is to not miss the possibilities of matching the exploit, but more accurately, it’s to avoid obfuscation of the exploit. So for example, let’s go back and take a look at the content match before we look at the pcre portion.

content:”clsid:A105BD70-BF56-4D10-BC91-41C88321F47C”; nocase;

Problem with this content match is, well, I wouldn’t have put the specific “clsid:” in there. Reason? If I was an attacker and I wanted to bypass your rule, I would put “clsid: A105BD70-BF56-4D10-BC91-41C88321F47C”. (Notice the space after the colon.) Which completely bypasses the content match.

So let’s come back to the pcre and take a look at it.

Now, this PCRE format was written by the VRT and a lot of people have copied it blindly without understanding what it does. So let me explain, as what the author wrote in the second paragraph quoted above, is wrong. As I said, I’m not trying to be mean or whatever, I am simply trying to teach.

So, the pcre is this:

/<OBJECT\s+[^>]*classid\s*=\s*[\x22\x27]?\s*clsid\s*\x3a\s*\x7B?\s*A105BD70-BF56-4D10-BC91-41C88321F47C/si

(I am going to put double quotes around the things we are trying to match that are explicit, the quotes don’t actually exist in the regular expression unless specified)

So we are looking for “<OBJECT”

Then a whitespace (\s). That’s what “\s” is. (It says ‘followed by strings’ in the above quoted paragraph). Whitespace is a tab, (0×09), space (0×20), new line character, or a line feed (0×0A), or a carriage return (0×0D). The “+” sign after the “\s” means ‘any character directly proceeding it as many times, but there must be at least 1′. So there must be 1 or more “\s” there.

Then you see this “[^>]“, which the author says that we are positively looking for. The thing about character classes “[ ]” is, they allow you to do some nifty things. Range matching, ([0-9]), multiple matches, [abc] (this will look for either an a, b, or c, for one character), and you can also do negative matches. Or “lack of” matches. The way you specify a negative match within a character class is to use the carat within a character class. So “[^>]” means, “the next character after any amount of positively matched “\s” cannot be a “>”. Directly after that is a “*” character. The “*” is similar to a “+” but the difference is, while a “+” means you must have at least 1 match of the proceeding character (in this case the negative character class), the “*” means you don’t have to have a positive match. It means “0 or more”.

Following that we have a “classid\s*=\s*” match. So look for classid(maybeaspacehere,it’soptional)=(maybeanotherspacehere)

Then there is a “[\x22\x27]“. In regular expressions, if you want to specify a hex character you have to write “\x” before the hex. So, you might see a space specified like this: 0×20. You might see it specified in Unicode like this: %20. In regular expressions, it would be “\x20″. Since there are two characters within the character class, 0×22 is the hex for a double quote. ” and 0×27 is hex for a single tick. ‘

Since this is a run of the mill character class match (not a range or something more complex) this means that the next character that the “[\x22\x27]” pattern match is looking for is either a ‘ or a “. Notice the “?” after the character class? That’s a ‘lazy optional’. So without going into a long book about lazy and greedy (which, by the way, if you are interested, I suggest checking out the book “Mastering Regular Expressions” by Jeffery Friedl, it’s the bible), the “?” basically means “The Character that is directly in front of the “?” is optional”. So, it essentially means, when all put together the match is either a ‘ or a ” or not at all.

Then we have (maybesomewhitepacehere)clsid(maybesomemorewhitespacehere):(maybesomemorewhitespacehere){(optionally)(maybesomemorewhitespacehere)A105BD70-BF56-4D10-BC91-41C88321F47C.

Notice that I translated “\x3a” and “\x7B” (the latter of which has the “?” behind it, so it’s optional) above.

Then the modifiers of the whole Regular Expression at the end are “/si”.

“s” means “include new lines in the dot metacharacter”. However, there are no “.” metacharacters in the regular expression, so that was probably put there by habit (and good practice), and the “i” means “anything within the regular expression treat with case insensitivity” similar to the “nocase;” keyword in Snort’s regular rule language.

So the final signature that the write comes up with is:

alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any (msg:”ActiveX Exploit Signature Sample”; flow:to_client,established; content:”clsid:A105BD70-BF56-4D10-BC91-41C88321F47C”; nocase; content:”.Import(“; nocase; Offset:0;pcre:”/<OBJECT\s+[^>]*classid\s*=\s*[\x22\x27]?\s*clsid\s*\x3a\s*\x7B?\s*A105BD70-BF56-4D10-BC91-41C88321F47C/si”; reference:url,www.exploit-db.com/exploits/11204; rev:1;)

Which I am going to rewrite:

alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any (msg:”ActiveX Exploit Signature Sample”; flow:to_client,established; content:”A105BD70-BF56-4D10-BC91-41C88321F47C”; nocase; content:”.Import(“; distance:0; pcre:”/<OBJECT\s+[^>]*classid\s*=\s*[\x22\x27]?\s*clsid\s*\x3a\s*\x7B?\s*A105BD70-BF56-4D10-BC91-41C88321F47C/si”; reference:url,www.exploit-db.com/exploits/11204; rev:2;)

So, what did I do different? Removed the “CLSID” content match, it won’t speed up detection, and it checked for in the pcre anyway. So, if you are going to fire up the pcre engine to check the content match on the long content match, just knock out two birds with one stone.

What’s with the “distance:0;” stuff? I made the content match directly proceeding that relative to the previous content match. Since I don’t have a within, I don’t constrain the match.

Why did you keep the “.Import(” stuff? False positive reduction. It will do nothing to speed up the match.

So, be careful when writing rules. Unless you understand all the pieces and parts you can walk yourself right into a dark hole and do it wrong. You can do that to yourself, but take extra care that you don’t walk anyone down the hole with you.

Again, I post this, not to be mean, but to be constructive. VRT could probably write the rule better than I as well. I’m not a member of the VRT, and I can’t even pretend to be. (They’d kick my butt.)

¶ Posted 22 February 2010 † Joel § Snort § analysis § blogs § review § websites ‡ Comments (17) °