Generic SQL Injection

[andrew.bagley]

Hi, regarding IDS signature 5930. This appears to be an old signature re-released with the recent asproxy vulnerabilities in mind. We have seen this fire with subsig 5 (asprox) and subsig 4 which detects " AND 1=1" in HTTP arguments. However when we look at the captures for subsig 4 alerts we are unable to find this argument in the capture anywhere (TAC currently raised).

Also, what is the best method of protecting against these vulnerablities - is it just a case of te developers ensuring that the code is not vulnerable? There is an MS test tool available to help with this http://support.microsoft.com/kb/954476.

Does anybody have any similar thoughts on this and the best way to defned against this?

Thanks

[mhellman]

subsig 5 is probably legit (e.g. asprox, something trying to inject SQL). I'm quite surprised you've actually seen subsig 4 fire. I don't get why an attacker would use "AND 1=1" because it would evaluate to false. "OR 1=1" is the more classical example makes more sense because if it works it will evaluate to true. The regex is pretty basic though:

(%20|\x2b)[aA][nN][dD](%20|\x2b)1=[12]

Therefore, it won't match unless it sees " and 1=1" or " and 1=2".

do you have just the contextual data, or do you have the trigger packet and/or log packets?

If you're inline, you could use a drop action. If promiscuous, you might be able to use TCP resets. The real fix is to use a "white list" approach to filter input in your web applications.

[mhellman]

I'm also confused why the regex looks for the encoded value of '+' (\x2b), but not the encoded value of '='. It works either way:

"+and+1%3D1" <-- fires

"+and+1=1" <--fires

If I change the regex to:

(%20|[+])[aA][nN][dD](%20|[+])1=[12]

It fires on either the literal '+' or the encoded version:

"%2Band%2B1%3D1"