IDS (Intrusion Detect Systems) must one of the more painful inventions - for
hackers. Luckily ID systems are seldomly properly configured. ID systems
looks for patterns or signatures in data streams. If the pattern in the
data stream matches that of a pattern in the IDS's database (that is marked
as "bad") the IDS reacts. Reaction can be logging the offensive packet, but
it could also be sending a combination of RST packets, ICMP redirects/port
unreachable/host unreachable packets back to the offending party. In other
words - if you send naughty packets the IDS will kill your connection.
Running a whisker scan against a machine that is monitored by an IDS will
cause the IDS to go ballistic.
Luckily RFP build some interesting "cloaking" techniques into his scanner.
Read his documentation to find out how it works. Whisker has 10 different
cloaking methods, and the basic idea is that you camouflage the URL in
different ways, hoping the IDS won't recognize the malicious pattern. The -S
switch decides what method would be used. Add it when you are not getting
results - it might be an IDS killing all your requests.
An interesting point to note is that it does not make sense to use anti-IDS
techniques when you are attacking an SSL- enabled site. The traffic is
encrypted remember? (if the IDS is running on the host itself...what comes
1st - the IDS or the decryption? After a lengthy discussion on the Vuln-dev
mailing list, it was clear that IDS does not work with SSL. The bottom line
- if you are having troubles with IDS - go for the SSL-enabled sites 1st.
Obviously all of the above techniques can be used in conjunction with each
other. Doing data mining with anti-IDS on a SSLv2 site that use Basic
Authentication is thus entirely possible (although the SSL bit wont make any
sense..).
hackers. Luckily ID systems are seldomly properly configured. ID systems
looks for patterns or signatures in data streams. If the pattern in the
data stream matches that of a pattern in the IDS's database (that is marked
as "bad") the IDS reacts. Reaction can be logging the offensive packet, but
it could also be sending a combination of RST packets, ICMP redirects/port
unreachable/host unreachable packets back to the offending party. In other
words - if you send naughty packets the IDS will kill your connection.
Running a whisker scan against a machine that is monitored by an IDS will
cause the IDS to go ballistic.
Luckily RFP build some interesting "cloaking" techniques into his scanner.
Read his documentation to find out how it works. Whisker has 10 different
cloaking methods, and the basic idea is that you camouflage the URL in
different ways, hoping the IDS won't recognize the malicious pattern. The -S
switch decides what method would be used. Add it when you are not getting
results - it might be an IDS killing all your requests.
An interesting point to note is that it does not make sense to use anti-IDS
techniques when you are attacking an SSL- enabled site. The traffic is
encrypted remember? (if the IDS is running on the host itself...what comes
1st - the IDS or the decryption? After a lengthy discussion on the Vuln-dev
mailing list, it was clear that IDS does not work with SSL. The bottom line
- if you are having troubles with IDS - go for the SSL-enabled sites 1st.
Obviously all of the above techniques can be used in conjunction with each
other. Doing data mining with anti-IDS on a SSLv2 site that use Basic
Authentication is thus entirely possible (although the SSL bit wont make any
sense..).
No comments:
Post a Comment