*Please note that this does not include the multitude of configuration errors (disabled by default checks like POST search/bad preprocessor configurations like minimum fragment length) nor network vs. host-based issues like fragment reassembly.
For configuration errors by default, please check http://cvs.snort.org....cgi/snort/doc/ and read appropriate preproc documents for disabled checks. By host, please check snort.conf. By network vs. host based issues, please google ids evasion.*

Today we're going to be taking a look at Snort signatures that are pushed by the public (amateur/community) and by professional signature writers. This paper will take a look at how to bypass these signatures once we have access to them and prove that modern signatures are as useful as modern antivirus engines. In particular, Snort signatures will be looked at as it is likely the most popular ids/ips solution and a lot of its content is made publicly available. We will start off with the mentality of signature writers and the mistakes they usually make. While this focuses on Snort, consider other IDS/IPS solutions and how these techniques may benefit you in other secured environments.



### Amateur/Average User Signatures ###

First off, before any kind of details against specific signature arguments are seen, let's get generic. People writing signatures are typically on a timeline. Also, people writing these signatures aren't necessarily vulnerability researchers and may not even understand the vulnerability or bug being presented to them. Because of this, it should be obvious that your attack should deviate from the public exploit as much as possible. Sometimes there are community exploit detections that are released just to say you have a signature so some company can keep feeling secure (happens ALL the time) against the skiddles. Look at the recent overlapping ranges DoS attack on Apache for a perfect example. When the new technique for this bug came out everyone was scampering for rules to appeas corporations and/or the public. So some of the newest content that comes out will likely be pushed to production in haste.

On to the bug itself, the overlapping ranges attack is rather humerous. The attack pattern is something like:

Range: bytes=0-,0-20,1-20,2-20,3-20...

These ranges can be added any number of times and will generate a new request in memory for every range requested. Any range that is unhandled will request all bytes until end of file. So 0- is 0-EOF. The server code handling these ranges is not very optimized, so hundreds of requests can be made causing high memory utilization. Sending hundreds of packets for hundreds of range requests that is not optmially handled will result in memory starvation rather quickly.

Here is the initial signature discussion on full disclosure:
http://seclists.org/...re/2011/Aug/289

1.) alert tcp $EXTERNAL_NET any -> any 80 (msg:"INBOUND Apache Killer script: Local web server is under attack."; content:"Range:bytes=0-"; classtype: denial-of-service; threshold: type threshold, track by_src, count 5 , seconds 20; sid:3000005;)

2.) alert tcp any any -> any $HTTP_PORTS (content:"Range"; nocase; http_header; pcre:"/(\d\,){6,}/xH"; http_header; msg:"Apache DOShttp://seclists.org/fulldisclosure/2011/Aug/175"; reference:cve,2011-3192 )

3.) pcre: "/^Range:bytes\s+\d+-\d?,\d+-\d+,\d+-\d+,\d+-\d+,\d+-\d+,\d+-\d+,/xH"; http_header;

The first signature is very easy to bypass. This was made for the public exploit and specifying a number other than 0- will allow you to bypass the signature. Not only that, but nocase was never specified. This would mean that ByTes would bypass this signature. Also, spacing between the header and argument is going to invalidate the signature. Spacing is actually a huge menace to signatures trying to be specific for optimization reasons, more on this in later sections.
The second signature would actually not work on any exploit attempt for this bug. The pcre does not check for a dash, only a character followed by a comma six sequential times. As no consideration for the dash is in there, this would never fire. I'm glad this was seen because people do push signatures out to the public that do not work on the exploit in question.
The third signature is more interesting to us in a bypass sense. The regex looks for any amount of digits followed by a dash and any amount of digits. /xH stands for ignore whitespace characters (in the regex expression) and H is specific to Snort PCRE. In the Snort manual H is specified as:

"Match normalized HTTP request or HTTP response header (Similar to http header). This modifier is not allowed with the unnormalized HTTP request or HTTP response header modifier(D) for the same content. For SIP message, match SIP header for request or response (Similar to sip header)."

What normalize does not do is be case insensitive (/i). So mixing case values will invalidate this signature and effectively allow you to bypass it.

**Don't give the guy on the list shit, he gave out free information and made a valiant attempt at detection. That's more than I can say for a lot of people.



### Community/Official Signatures ###

Alright, let's step up our targets and stop picking on amateur/novice writer signatures. Let's take a look at the emerging threats community signatures. A very popular choice for free signatures. Most companies will sign up for these signatures and place them in their environment as is. Also, sometimes people who write their own signatures will see that one is already created for it and not even bother to validate or write their own. These emerging threats community rules are freely distributed at:

http://rules.emergingthreats.net/

We'll take a look at the same vulnerability. There are two rules in emerging threats related to this attack:

1.) alert tcp $EXTERNAL_NET any -> $HOME_NET $HTTP_PORTS (msg:"ET SCAN Kingcope KillApache.pl Apache mod_deflate DoS attempt"; flow:established,to_server; content:"Range|3a|bytes=0-,5-0,5-1,5-2,5-3,5-4,5-5,5-6,5-7,5-8,5-9,5-10,5-11,5-12,5-13,5-14"; http_header; fast_pattern:only; classtype:attempted-dos; reference:url,seclists.org/fulldisclosure/2011/Aug/175; sid:2013472; rev:2;)

2.) alert tcp $EXTERNAL_NET any -> $HOME_NET $HTTP_PORTS (msg:"ET SCAN Apache mod_deflate DoS via many multiple byte Range values"; flow:established,to_server; content:"Range|3a|"; nocase; http_header; content:"bytes="; http_header; fast_pattern; nocase; distance:0; isdataat:10,relative; content:","; http_header; within:11; isdataat:10,relative; content:","; http_header; within:11; isdataat:10,relative; content:","; http_header; within:11; isdataat:70,relative; content:!"|0d 0a|"; within:12; pcre:"/Range\x3a\s?bytes=[-0-9,\x20]{100,}/iH"; classtype:attempted-dos; reference:url,seclists.org/fulldisclosure/2011/Aug/175; sid:2013473; rev:1;)

The first one is obviously checking for the public exploit. Not only is it doing that, but it's even more specific (thus worse) to the public exploit than the amateur rule. This just goes to show that just because a rule may be in an 'official' release doesn't mean it's really all that good.
The second one is much more involved to the attack and is close to a hardened detection. There's a lot of junk to look at, but most of the signature is really only used for optimization before it hits the pcre engine as pcre is an expensive luxury to a sensor. The main meat of the signature is "pcre:"/Range\x3a\s?bytes=[-0-9,\x20]{100,}/iH";". /iH means normalize the url and do not worry about case sensitivity. The problem is normalization doesn't remove extra whitespace characters. While we look for valid whitespace in certain areas (between range/bytes and in the range itself), the signature does not check between bytes and the specified ranges. Also, note the valid attempt at checking for a space between Range: and bytes only checks for one whitespace character (\s?). So, to invalidate the regex, simply use "bytes = range-values".



### Professional Signatures ###

How about those companies with the budget for good signatures? Professional signatures usually have very good expressions because the authors work with them all the time. A good idea of professional signature quality lies in SourceFire's own VRT team:

http://www.snort.org/start/rules

New rules are released often and you can get them for free after the initial 30 days of release. This is a great service as it is current and the rules are usually decent. Of course, the rules have problems just like everyone else. Unfortunately, I can't give away any information on VRT rules that aren't past the 30 day mark. The example signature I want to use is in this 30 day, so I can't show their signature. Instead, let's consider a proof of concept attack for my made up protocol:

retrieve /happygoat
argument:nomnom=nom-mem.nom-mem.nom-mem.nom-mem.nom-mem.nom-mem
from pacmanfever.com

Now, let's say a professional pcre would look like:
pcre:"/^argument\x3anomnom=([\w\x20\x2D]+\x2e){4,}/Hsmi";

This would effectively check for the public attack. The regex grouping would catch our nom-nom attack appropriately. /Hsmi is case insensitive, allow . in expression to include a new line, treat string as line of characters, and normalize the url. However, none of these arguments strip or allow for excess whitespace. So, by placing a space between argument and \x31, \x3a and nomnom, or nomnom and =, then we would effectively bypass this signature.
These regex expressions are usually very detailed when it comes to the attack, however there is a lack of detail for variations in the legitimate portion of how it's called.



### depth ###

Now, to get away from rule writers and on to snort specifics. The problems usually lie when the writer wants to optimize their rules so it's not so taxing on snort to validate. A major problem lies in depth. According to the snort manual, depth is:

"The depth keyword allows the rule writer to specify how far into a packet Snort should search for the specified pattern. depth modifies the previous ‘content’ keyword in the rule.
A depth of 5 would tell Snort to only look for the specified pattern within the first 5 bytes of the payload."

I went ahead and just picked a random rule for an example. Here's a good one:

alert tcp $EXTERNAL_NET any -> $HOME_NET 3057 (msg:"WEB-MISC Borland StarTeam Multicast Service buffer overflow attempt"; flow:established,to_server; content:"GET AAAAAAAAAAAAAAAAAAAAA"; depth:25; reference:bugtraq,28602; reference:cve,2008-0311; classtype:attempted-admin; sid:16283; tag:session,5,packets; rev:1;)

There are two interesting bypasses here to look at. The first is with the attempted content match. Depth is stating that the content match must be found within the 25 bytes from offset 0 into the payload (which the author misjudged as the start of the command). However, if something could be inserted into the payload before GET, while causing no problems to the injection itself, then it would bypass the depth limit and invalidate the signature.
So the goal becomes finding a byte or more that can be introduced into the payload before the injection. Unfortunately, \x20 would reveal a bad request error and not allow us to execute the wanted command. However, a new line can be introduced before the GET sequence to bypass the depth restriction. In fact, many new line characters can be used. I tested this out with a simple raw socket python script that looks for return method back. Appropriate line:

import socket
from time import sleep

payload = ("\x0d\x0a"*3)
request = "GET /news.php HTTP/1.1\r\nHost: securityoverride.com\r\n\r\n"

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect(("206.214.216.120", 80))
s.send(payload+request)
sleep(1)
reply = s.recv(25)
if (reply.find("200") != -1):
if (raw_input("200 OK found, verify? (y/n):\t") == "y"):
dumpbuff = s.recv(2048) # increase for verification content
print(dumpbuff)
s.close()


The raw bytes coming across (to make sure the byte is actually coming through in our payload):
0d0a 0d0a 0d0a 4745 5420 2f6e :nR.......GET./n

And, validation response:
HTTP/1.1 200 OK (looked through payload, appropriate page seen)

Of course, a simple fuzzer in the payload portion can find characters that can be placed in front of the method to check for allowed characters to use. We could also see what types of encodings are allowed and see if we can expand our usable characters. This way we aren't getting trapped by (byte){x,} type signatures in the future. Speaking of \x20 (space), we can issue this inbetween the http method and the actual URI request.

GET \x20\x20\x20\x20/news.php HTTP/1.1 is as valid as:
GET /news.php HTTP/1.1

*Originally proved using an FTP signature. These are all over.


### within ###

Within is defined 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 ( See Section 3.5.1 ). It’s designed to be used in conjunction with the distance (Section 3.5.6) rule option."

Please read the depth section for issues with within modifiers. Take note that both depth and within are highly used in snort signatures.



### Takeaway Lessons ###

Remember, more and more signatures are always being written. Despite what you think or what people tell you, more signatures isn't a good thing. More signatures means that Snort and other systems will have a heavier load while processing, parsing, and analyzing packets. PCRE is an expensive operation as well, so verification will be attempted as much as possible before PCRE is done so it doesn't need to load the engine. Given this, ways to optimize will keep coming out and that will include hard-defined pointers to start looking for specific content and even where to stop looking. Mess with the protocol and see what kind of valid bytes you can throw before/after commands/injections, before/after arguments, in the middle of arguments/commands and etc. Simple bypasses are going to want to include mixing cases, including spaces wherever possible, and obviously deviating from the public exploit as much as possible.
The more interesting mutations are going to be created by fuzzing the protocol the attack is on, inserting bytes into the attack call and seeing if the injection still fires. Of course, depending on how the exploit works, you don't have to test with an exploit but valid commands and see if they still fire. I will be going more into this idea on future articles with backing scripts.

Also, not mentioned above, internal attacks are much easier to get passed ids/ips. Because of said optimization, lots of rules are defined as external traffic coming to internal hosts so they don't have to bother with parsing further into ALL traffic to/from a host in your home network. Internal network attacks against applications (layer 7) are not usually defined to even check for such attacks. Most signatures for such services are like:

alert $EXTERNAL_NET any -> $HOME_NET any
$EXTERNAL_NET can also be defined as !$HOME_NET 

Introduction
This article/tutorial assumes you have some common sense and some knowledge.
I won't be explaining what shell code, DLL's, Memory Adresses etc...
You should know that before starting on this.

Environment
Initially we will be focusing on creating Windows Assembly; however, Linux is really
good for developing assembly and shell code. But because we are on windows we'll
use Cygwin.

Download the Cygwin installer from here:
http://www.cygwin.com/setup.exe

During the Cygwin installation you will be asked to select wich packages you wish
to install. The following packages are usefull for creating assembly and shellcode.

* Devel > binutils
* Devel > gcc
* Devel > make
* Devel > nasm
* Devel > gdb
* Editors > hexedit
* Editors > vim
* Net > netcat
* System > util-linux

Tools
Once you have the Cygwin environment setup, download the following tools. Save them within your
Cygwin environment, copy them to something like: C:\cygwin\home\Administrator\shellcode\
(Where Adminstrator is your username)

xxd-shellcode.sh
Parses xxd output to extract raw shellcode
http://www.projectsh...xd-shellcode.sh

shellcode-compiler.sh
Automatically compiles the assembly code, extracts the raw shellcode, creates a Unicode encoded version of the raw shellcode, injects your encoded shellcode into a "Template Exploit" (ms07-004) for testing, creates a C test program containing your shellcode, and then compiles it ready to execute!
http://www.projectsh...de-compiler.zip

arwin.c
Win32 DLL address resolution program
http://www.vividmach...ellcode/arwin.c

shellcodetest.c
http://www.vividmach...shellcodetest.c

findFunctionInDLL.sh
Finds which DLLs on your system contain a specific Windows function
http://www.projectsh...unctionInDLL.sh

Start up a bash shell from the start menu and CD to your 'shellcode directory', such as:

cd /home/Administrator/shellcode

You now need to compile arwin.c by using the following command:

gcc -o arwin arwin.c

You should now be able to run arwin by typing ./arwin to display the usage information.
We don't need to compile shellcodetest.c at this stage. Once we have created our shell code,
then place the shellcode into shellcodetest.c and compile it. This allows us to run shellcodetest
to execute our shellcode.

If you followed along you should now be ready to start developing shell code. 

This utility scans the passwords stored by popular Windows applications (Microsoft Outlook, Internet Explorer, Mozilla Firefox, and more...) and displays security information about all these passwords. The security information of every stored password includes the total number of characters, number of numeric characters, number of lowercase/uppercase characters, number of repeating characters, and password strength. You can use this tool to determine whether the passwords used by other users are secured enough, without watching the passwords themselves  


System Requirements
This utility works on any version of Windows, starting from Windows 2000 and up to Windows 7.  


Supported Applications  
Internet Explorer 4.0 - 6.0
Internet Explorer 7.0 - 9.0
Mozilla Firefox (All Versions)
Dialup/VPN passwords of Windows
MSN/Windows Messenger
Microsoft Outlook
Windows Live Mail
Support for more applications will be added in future versions. 


Download: http://www.nirsoft.net

Comodo Internet Security Pro 2012 which is priced at $49.99. This promo will allow users to use the latest pro version completely free for a year.

Free Comodo Internet Security Pro 2012

Key Features of Comodo Internet Security Pro 2012:

• Antivirus, Anti-Spyware, Anti-Rootkit & Bot protection
• Defends your PC from Internet attacks
• Detects and eliminates viruses
• Prevents malware from being installed
• Auto Sandbox Technology™
• Easy to install, configure and use
• Remote Security & System Support

Follow below steps to get Free Comodo Internet Security Pro 2012 one year license key

1. Download Comodo Internet Security Pro 2011 Here -> one-year special installer
2. Install and start Comodo 2011. Navigate to “More” -> “About” -> Serial Number -> “Copy”.
3. Save the serial number on your PC, you will need this serial to activate the 2012 version.
4. Download and Install Free Comodo Internet Security Pro 2012. During installation, enter the serial number that you received from the 2011 version.

Official GNOME Shell Extensions Available In The WebUpd8 GNOME 3 PPA For Ubuntu 11.10

The latest official GNOME Shell Extensions (version 3.2.0) are now available in the WebUpd8 GNOME 3 PPA for Ubuntu 11.10 Oneiric Ocelot. This PPA is an attempt to have all the stable GNOME 3.2 packages that aren't available in the official Ubuntu 11.10 repositories in a single place. Please note that I did not package this. I'm only uploading these packages to a single PPA.

Install GNOME Shell Extensions pack in Ubuntu 11.10 Oneiric Ocelot

sudo add-apt-repository ppa:webupd8team/gnome3
sudo apt-get update

sudo apt-get install gnome-shell-extensions-alternate-tab

sudo apt-get install gnome-shell-extensions-user-theme gnome-tweak-tool

sudo apt-get install gnome-shell-extensions-workspace-indicator

sudo apt-get install gnome-shell-extensions-apps-menu

sudo apt-get install gnome-shell-extensions-drive-menu

sudo apt-get install gnome-shell-extensions-system-monitor

sudo apt-get install gnome-shell-extensions-places-menu

- Dock extension: shows a dock-style task switcher

To customize the dock extension, install dconf-tools (sudo apt-get install dconf-tools), then launch "dconf-editor", navigate to org > gnome > shell > extensions > dock and here you can specify the dock position (left or right), enable or disable autohide, specify the hide effect or set the hide duration.

Install:

sudo apt-get install gnome-shell-extensions-dock

sudo apt-get install gnome-shell-extensions-native-window-placement

sudo apt-get install gnome-shell-extensions-xrandr-indicator

sudo apt-get install gnome-shell-extensions-auto-move-windows

sudo apt-get install gnome-shell-extensions-gajim

sudo apt-get install gnome-shell-extensions-windows-navigator

sudo apt-get install gnome-shell-extensions-alternate-tab 

gnome-shell-extensions-alternative-status-menu 

gnome-shell-extensions-user-theme 

gnome-tweak-tool 

gnome-shell-extensions-workspace-indicator 

gnome-shell-extensions-apps-menu 

gnome-shell-extensions-drive-menu 

gnome-shell-extensions-system-monitor 

gnome-shell-extensions-places-menu 

gnome-shell-extensions-dock 

gnome-shell-extensions-native-window-placement 

gnome-shell-extensions-gajim 

gnome-shell-extensions-xrandr-indicator 

gnome-shell-extensions-windows-navigator 

gnome-shell-extensions-auto-move-windows

 Regards

Adnan Anjum

Windows 7 has a nice security about kernel space

Many checks of size, integrity controls and access restrictions are available.For example the “security check” protect our stack if a string is used, many functions like “strcpy()” are deprecated (and some are disallowed) to force developers to have a secure coding.This is why, some attacks were presented as heap overflows in local exploitations (recently Tarjei Mandt)but we don’t see any remote exploitation like we saw in SRV.SYS or other drivers.This lack of remote exploits occurs partially because an ASLR (randomization of memory spaces) is enabled in kernel land. If a hacker doesn’t have any possibilities to jump and execute a payload (ROP, Jmp Eax …) exploitation of the bug isn’t possible. Only a magnificent BSOD could appear in most of the cases.This paper will try to explain how to bypass this protection and improve remote kernel vulnerabilities research!For the use of this document we will consider a remote stack overflow as the main vulnerability

Download PDF

Google App Engine is a great technology allowing web developers to develop their own web applications,test them in their internal framework, and deploy them to Google’s appspot.com domain.The Google App Engine framework allows developers to write their web site logic in Python, and offers several frameworks specially created for this. In addition, Google App Engine provides an SDK Console via web that acts as an administration console for the newly written application.This advisory lists 4 different vulnerabilities, one in admin console and three others in the Google python API, which allow a remote attacker to gain full code execution on the developer’s machine. These severe issues have been communicated to Google, and a fix was released last month on Sep 12, 2012 (in version 1.5.4).

Download PDF

1. This release contains over 120 bug fixes, 30 new tools and 70 tool updates.
2. The kernel was updated to 2.6.39.4 and includes the relevant injection patches.

Reverse Engineering Hacking Tutorial- Introduction to assembly language

EAX
EBX
ECX
EDX
ESI
EDI
ESP
EBP
EIP

High Memory Addresses (0xFFFFFFFF)
---------------------- <-----Bottom of the stack
|                          |
|                          |   |
|         Stack        |   | Stack grows down
|                          |   v
|                          |
|---------------------| <----Top of the stack (ESP points here)
|                          |
|                          |
|                          |
|                          |
|                          |
|---------------------|  <----Top of the heap
|                          |
|                          |    ^
|       Heap          |     |   Heap grows up
|                          |    |
|                          |
|---------------------| <-----Bottom of the heap
|                          |
|    Instructions    |
|                          |
|                          |
-----------------------
Low Memory Addresses (0x00000000)  

int main(int argc, char *argv[])                    {                     printf("Hello World!\n");                 return 0;           }    

0x8048384     push ebp                      <--- Save the EBP value on the stack
0x8048385     mov ebp,esp               <--- Create a new EBP value for this function
0x8048387     sub esp,0x8                 <---Allocate 8 bytes on the stack for local variables
0x804838a     and esp,0xfffffff0          <---Clear the last byte of the ESP register
0x804838d     mov eax,0x0                 <---Place a zero in the EAX register
0x8048392     sub esp,eax                  <---Subtract EAX (0) from the value in ESP
0x8048394     mov DWORD PTR [esp],0x80484c4     <---Place our argument for the printf() (at address 0x08048384) onto the stack
0x804839b     call 0x80482b0 <_init+56>                     <---Call printf()
0x80483a0     mov eax,0x0                 <---Put our return value (0) into EAX
0x80483a5     leave                              <---Clean up the local variables and restore the EBP value
0x80483a6     ret                                  <---Pop the saved EIP value back into the EIP register