Difference between revisions of "Impedance mismatch attacks"

Latest revision as of 12:03, 7 May 2012

Intrusion Detection and Prevention systems are designed to determine if an action or condition is benign or malicious. They do this in a manner that is essentially external or independent to whatever they are monitoring. This adds an additional layer of security to whatever they may be protecting by being external or independent of the things they protection. This is sort of like have a bodyguard.

IDS/IPS are generally not part of the thing they are monitoring. Again, the bodyguard analogy. They are not the person being protected, they are another person protecting this person (a bodyguard). This has the added advantage that the "protectee" can also participate in their protection, in addition to the bodyguard. Its a win-win.

For example, a network based intrusion detection system (NIDS) works by "listening" or capturing network traffic as it moves over the network. The NIDS is actually the source, or the destination for this traffic. So its not "part" of the conversation, nor is it the application sending or receiving the traffic. So it does not automatically understand the things its seeing. It needs context, or the ability to put all that information back together in a way that tells it whats being said between the two systems, and what that conversation means.

IDS/IPS systems do this in a number of ways, but in general this is very hard to do. IDS/IPS systems do a reasonable job or piecing together whats going on, but they have no knowledge of the logic in the applications themselves. So there is a certain amount of assumption that does into this process, and its these assumptions that can sometimes create opportunities to bypass an IDS/IPS. Think of this as a "failure to translate correctly" problem. Imagine someone speaks a language natively, and they are also speaking with someone else in that language. These two people have known each other a long time, and they speak not only with regional dialects that may not be part of the "main stream" language, but they also have a lot of inside jokes that an outsider may not understand. If someone were listening in on this conversation they might not fully understand the conversation, important details may miss their attention or they may just not understand the context of the conversation at all.

This can happen with IDS/IPS systems, they may not fully understand what they are seeing and as a result they can miss things. Attackers will often use this try to bypass IDS/IPS'. These are called "impedence mismatch attacks". To help prevent these kinds of attacks, IDS/IPS systems will generally have fail safes that will try to detect when a conversation is not following convention, and either alert or prevent the out of spec session from passing. Because the IDS/IPS can't fully understand the session, its best to not allow it as it will not be able to detect any attacks in that session. Most protocols are somewhat reasonably well defined, so an IDS/IPS can be configured to enforce that the protocol follow well understood conventions without adverse impact to reasonably well written applications. This helps to prevent impedance mismatch attack

Impedence Mismatch attacks only effect IDS'/IPS' that are external, and not IDS/IPS systems that are built into an application. This is not always possible, but in some cases it is, for example ASLs kernel intrusion prevention system is built into the kernel and is not vulnerable to impedance mismatch attacks because it knows the applications logic, in this case the kernel. Whereas WAFs, such as modsecurity, are "built into" Apache so they have some context, but as it is are not built into the web applications it is protecting impedence mismatch attacks are still possible.

So this discussion does not apply in every case, but most IDS' and IPS' are "external" to whatever they may be monitoring and are vulnerable to impedence mismatch attacks. To prevent these attacks from being successful, a good IDS/IPS will try to detect these conditions and will prevent sessions from being established that it can not adequately monitor. If an IDS/IPS component detects one of these possible attacks, its best to leave the IDS/IPS' configuration alone and not disable this feature. Rather, the application(s) causing this condition should be examined to ensure they are working correctly, and if they are should be modified to comply with the protocol as defined by the IDS/IPS.