lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
From: lcamtuf at ghettot.org (Michal Zalewski) Subject: Bypassing "smart" IDSes with misdirected frames? (long and boring) Morning, I have a question regarding smart IDS or IPS systems (either working in parallel mode, or, in some cases, as an in-line bridge - but not as a gateway). The question is a result of a thought experiment, and perhaps is worth some further research, for which I regrettably do not have time at the moment. I think a clever attacker may be, in some circumstances, fool IDS/IPS systems that perform protocol reassembly / tracking to detect anomalies or reduce false positive rate - I think both Okena and Intruvert fall in this category, among others. A potential attack scenario involves attacker A, who happens to be on a logical network (VLAN) local to the IDS system (just a LAN workstation within an enterprise), and targets machine X. There is a IDS/IPS node D listening on a span port of a switch somewhere down the road, or just bridging two devices together. For the purpose of this discussion, let us assume the IDS has a detector designed to detect malicious SMTP commands sent to a remote server. The detector looks for "DEBUG" command in these commands, but not when the session is in BODY mode (because we do not want to trigger alerts whenever developers exchange mails with references to debugging). This is a naive example, but should be good enough. Our attacker, A, establishes a connection by performing a normal handshake with X, and sends a couple of typical commands first. Then, an extra attack step involves host A sending an IP packet addressed to host X and containing a valid message (be it a DATA command, or RST frame, or whatnot), but to a bogus hardware-level address (belonging to host Y, some broadcast/multicast group, or just nobody in particular). This command is, of course, never received by the recipient (or, if sent to a broadcast address, will likely be ignored). The attack then continues as planned. Now, an IDS that sees all network traffic but performs TCP stream analysis building on top of a traditional proto / saddr / daddr / sport / dport stream identification method (discarding hardware address data) - as I would expect it is almost always the case - would run into serious problems. Seeing a valid, correctly addressed "DATA" or RST packet with correct sequence numbers, the system has no reason not to interpret it, and to disable detection of abnormal SMTP commands temporarily or permanently. The next packet from the attacker is then sent to a correct IP and hardware address, both belonging to X. The packet contains the actual attack code, the "DEBUG" command, but when noticed by the IDS/IPS, would be: - Deemed to be coming from the past, because the sequence number is lower than now expected. This packet would likely be ignored as a result of network hiccup corrected by retransmission. - Even if not ignored, the command would not be interpreted as an attack, because the connection is now in DATA mode, supposedly. Naturally, I have taken several shortcuts - a paranoid protocol analyzer may also be checking for SMTP responses before accepting data mode, and so forth; an ultra-paranoid IDS may also trigger alerts upon receiving data past RST or strange retransmissions, at a cost of generating plenty of false positives. But although there may be protocol-specific remedies in this particular case, the attack itself appears to be exploitable using a number of vectors. The most obvious solution appears to be the inclusion of hardware addresses as a stream identifier - so that a packet sent to a different hardware address would not be considered as belonging to the same connection. There is a catch, however: this enables the attacker to use an opposite attack, and send a malicious command in a packet addressed to a broadcast address, or a secondary NIC of a machine, and hope it will be accepted by the recipient, but ignored by the IDS as a stray ACK. It appears to me that only those systems that specifically look for "MAC addresss jumping" effect within a connection may be capable of providing a good mean of detecting those problems. Naturally, even if my assumptions are right, this is not a shocking discovery. IDS avoidance is as ancient as IDSes themselves; modern solutions can do quite well to stop those attacks, however, whereas this approach may be a bit more difficult for them to handle. The exposure is quite simple: an rogue entity on your network (be it a malicious user, or an infected computer) may be able to avoid triggering alarms or having his attacks stopped, despite of efforts to reassemble and track protocols to avoid more traditional avoidance techniques. So, would anyone be willing to comment or this or test it any further? I am not as much looking for a hyphotetical discussion, but rather for feedback on specific products and their vulnerability. It is obvious you may configure some networks to mitigate such attacks, deploy third-party solutions to detect them, or accept some false positives in certain environments. Thanks, -- ------------------------- bash$ :(){ :|:&};: -- Michal Zalewski * [http://lcamtuf.coredump.cx] Did you know that clones never use mirrors? --------------------------- 2004-05-27 21:18 -- http://lcamtuf.coredump.cx/photo/current/
Powered by blists - more mailing lists