3

Are there known techniques to obfuscate IDS rules, so they can't be easily used by attackers to reverse-engineer the vulnerability that they detect?

Let me provide some context. Sometimes IDS vendors become aware of a zero-day vulnerability (one that has not yet been publicly disclosed). In that situation, one can create a rule to detect exploitation of that vulnerability and push it out to everyone, to try to prevent exploitation of the vulnerability... but this incurs a new risk. In particular, an attacker might be able to analyze the IDS rule and use that to gain some clues that make it easier for the attacker to identify the vulnerability and start using it to attack other systems. So, in a world where some people are slow to patch and don't use the IDS, there's the risk that pushing out such a new rule might (perversely) increase overall exploitation of the zero-day vulnerability, rather than decreasing it.

Are there any known techniques to mitigate this risk, and make it harder for attackers to learn anything useful from new IDS rules? For instance, is there a way to distribute the IDS rule in an obfuscated or encrypted form, so end users can still use it to detect attacks but attackers who aren't already familiar with the vulnerability can't use the rule to re-discover the vulnerability and start attacking others?

2
  • 1
    cs.princeton.edu/~dpw/obt/abstracts/obt12_submission_16.pdf
    – user49075
    Commented Aug 21, 2014 at 23:42
  • Thank you for pointing me to that paper, @RickyDemer! That's indeed highly relevant. On the merits: I don't believe that paper will work in practice. Their technique does not hide which module or function in the code is getting changed, so it would immediately point the reverse engineer to which part of the code has a bug, which would be a huge leg up enabling attackers to re-discover the bug. Also, I don't immediately see how to use this to obfuscate IDS rules. But thanks again -- a good find!
    – D.W.
    Commented Aug 22, 2014 at 3:59

1 Answer 1

1

With Snort you can compile your rules as "shared objects" that use C instead of the Snort language and can be obfuscated. See #2 here: http://blog.snort.org/2011/02/snort-shared-object-rules.html

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .