Monday, March 22, 2010

Kinds of evasions

Now the next point to consider is ... do all IDS systems have common evasions?

When we read the paper on fixing the evasions through FSM, snort was the system under consideration ... there is no specific information provided regarding to what extent where the evasions present in the system were identified ... how can we confirm that if we have identified certain types of evasions we have addressed all that present in the specific IDS system.

Now concentrating on the basic evasion types as described in the case of SQL injection ... next question is ... if we use snort ... what kinds of intrusions in general it would address ...

http://en.wikipedia.org/wiki/Intrusion_detection_system_evasion_techniques ... talks about vulnerability scanners that also incorporate IDS evasion techniques

http://www.mail-archive.com/issforum@iss.net/msg02072.html --> "ADMmutate is a shellcode mutation engine, can evade NIDS

A way of breaking into a system. An exploit takes advantage of a weakness in a system in order to hack it. Exploits are the root of the hacker culture. Hackers gain fame by discovering an exploit. Others gain fame by writing scripts for it. Legions of script-kiddies apply the exploit to millions of systems, whether it makes sense or not. Since people make the same mistakes over-and-over, exploits for very different systems start to look very much like each other. Most exploits can be classified under major categories: buffer overflow, directory climbing, defaults, Denial of Service."

Wednesday, March 17, 2010

thoughts on evasion identification

Possible study that should be undertaken:

When we draw an FSM for a specific situation which gets translated to a ruleset , all that we can identify is that the evasive path ... what could a possible evasive path ? Is it not the state where-in the alarm trigger is expected and there is no alarm raised for an attack ... so in this scenario ... even if we are able to generate test cases from the FSM ... how far is this going to be towards our goal of identifying evasions in the IDS system from the users point of view ...

Now let us consider a situation ... where-in we are aware of the possible modes of evasion available for a kind of attack ... say sql-injection ... would it not be beneficial to identify a testing technique ... that mainly assess the IDS system if it is evasive ... and then maybe compare the systems for check which one performs better with respect to a given evasion ...

Is it not better to have a tool developed which would automatically test the IDS systems for the evasions and check what all evasions it is vulnerable to ? Coz for a developer before he/ she uses the IDS system they want to understand if it is prone to known evasions ... this could also be done from the IDS system developer point of view ... they need a tool to identify ... now the next question is how is this different from the AGENT tool developed ... as we understand the tool is mainly used to generate automated test data which can be run on the IDS system there-by identifying possible evasions by going through the code ... now what we want to avoid is reading through the code to understand the evasions ...

first point we need to be clear is who we are targetting this application ... if it for the IDS system developers ... then there is a possibility that there might be new evasions ... if we are targetting for the developers who are going to use the IDS system then ... we can assume that the evasions that needs to be checked are mostly known ... hence the tool should directly test the IDS system for those evasions ... ?

FSM for SQL injection

SQL Injection attack is found to be one of the most vulnerable in the case of websites. Identity thefts seem to be happening often due to the support of the attack.
Hence the white paper "The SQL Injection and Signature Evasion" discusses the possible evasion techniques that are prevalent and also quotes how the products of Impervia may suit protection against them.

Our focus here is mainly to understand the various evasion techniques available. This is done by using the SQL injection example quoted by them, drawing FSM for the situation and deriving test cases and checking if the specific evasion flow could be identified from the list of test cases drawn for the situation.

The example used in the paper is a SQL injection attack on a healthcare website
--> one of the module lists the SSN of all the family members based on the gender
If the query is genuine, then the web address looks like
http://www.superhealth.com/show_members.asp?gender=m

and the query looks like
selet SSN, Name from PATIENTS where FAMILY = XXX and gender='m'

This indicates that the query is done at particular family level and that the person trying to retrieve the information should have permission to perform the query. So based on this initial understanding we can try to come up with rule sets that the IDS system should be have been built upon to prevent a basic attack. Lets not worry about the evasion or any problem associated there-off.

r1 --> user login attempt with username
r2 --> user login attempt with password
r3 --> guest user / no login required / can access the website login page ... and browse through for information on the products that are available etc ... and plan for registration
r4 --> registered user logs in successful/ login attempt succeeded
r5 --> registered user login attempt failed
r6 --> registered user query database for SSN information for their family/ no alarm raised
r7 --> guest user query database for SSN information for their family / alarm should be raised
r8 --> server decodes the query to assess the quality and genuineness of it/ responds back

some tips on IPS testing from CISCO
http://www.cisco.com/web/about/security/intelligence/cwilliams-ips.html