This post was authored by Martin Zeiser with contributions by Joel Esler
At Talos we are constantly on the lookout for threats to our customers networks, and part of the protection process is creating Snort rules for the latest vulnerabilities in order to detect any attacks.
To improve your understanding of the rule development process, consider a theoretical remotely exploitable vulnerability in server software Server2010. A proof-of-concept exploit is developed, the server software set up on a virtual machine, traffic is captured on the network between attacker and victim, rule development can start, right?
But what if months or years later, the rule needs to be re-inspected, because circumstances have changed? This requires another vulnerable version of Server2010 to be found, reinstalled and reconfigured to the vulnerable parameters, to run tests again and again, so that network traffic can be inspected. Then when the server is installed, the particular exploit used does not work anymore, because the language it was written in has since changed and the code needs to be fixed accordingly. All this requires plenty of time, which is why it doesn’t happen that way. Instead, a vulnerability is identified, an exploit is written, the exploit is ran, and the attack captured using Wireshark. From then on, the traffic in said pcap file can be used to develop a correct rule. The traffic recorded in a pcap file can easily be put back on the wire using a tcp replay utility, or read directly by Snort. This is why rule developers generally work with pcaps of attacks, instead of exploits.
Regarding file-based vulnerabilities, the original process used to involve starting a local webserver and using a browser to download the exploit file, while recording the transfer using Wireshark. File2pcap revolutionized this requirement by simulating the traffic and creating the proper pcap without any hassles.