Strikes over SSL: Detecting encrypted exploits is hard (but can be made easier)
Get ready, I’m going to climb up on a soapbox for a minute!
One of the things the Ixia BreakingPoint team takes pride in is the realism of our strikes. We strive to provide the most effective security device testing possible by emulating all the different methods attackers can use to exploit a vulnerability. This includes—but is not limited to—multiple protocols for file delivery, various data encoding schemes, shuffling the order and size of data packets, and randomizing the location of malicious values. All these variations raise the bar for testing security devices. To help truly mitigate a vulnerability a security device must be able to prevent its exploitation, regardless of the form it takes. In some cases, not all security devices are capable of accurately detecting an exploit in all its forms (think compressed Java applet/.jar). We believe that these examples can and should serve as valuable product differentiators.
There are some cases where no current security device can accurately protect against a vulnerability exploitation. In some cases, an exploit is semantically indistinguishable from normal traffic, or the traffic is over an encrypted channel. In these cases we have to weigh the current capabilities of our customers with the reality of an exploit vector. In situations where you can reasonably argue that a vulnerable device or application can be exploited over a clear channel, we tend to write a strike that is sent out over the clear channel. But there are cases where an application only communicates via encrypted channel (think SSH or HTTPS).
In these examples, there are no realistic scenarios where the exploit traffic can be sent in the clear, and so the strike we write for that vulnerability emulates that encrypted behavior. While we are aware that this will prevent most security devices from detecting the attack, we make the choice to use this encrypted channel based on reality: the vulnerability is only exploitable via an encrypted channel. Emulating the attack via clear-channel would not be realistic.
Rather than penalizing an entire class of security devices, we look at it as another example of realism raising the bar: just because current technology is not capable of accurate detection, does not mean that accurate detection is not needed. Attackers are aware of this blind spot, and rather than writing strikes that conform to the current capabilities of inline-security devices, we plan to continue realistically emulating network-based vulnerability exploitation.
As attacker methodologies adopt new forms, so will our strikes. Hopefully this will continue to help spur change in the security device industry—just because neither you nor your competitors can natively detect an attack does not mean it should be ignored. This should result in better/newer/different technology approaches that can accurately detect these types of attacks.
(That concludes my impassioned soapbox sermon on why we make life so difficult for security device vendors, and why we plan to continue to do so.)
While we are committed to providing the most realistic strikes possible, we realize that the transition to newer/better/different technology will not happen overnight. And there are ways of getting access to the decrypted contents, one of which is certainly within the realm of current security-vendor capabilities, namely SSL decryption.
Using a tool like Application and Threat Intelligence (ATI) Processor – provide you have the keys – traffic can be decrypted either inline (via proxy) or offline for inspection by security devices. BreakingPoint supports either option: encrypted network traffic packet captures can be exported for offline inspection, or the default certificates used to encrypt the traffic can be loaded onto the device as an Evasion Option (see image below).
For those that don't want to configure a CTM for this type of operation or just want a more simplified approach to inspecting SSL-encrypted traffic, we are introducing several enhancements with ATI-2015-17.
The first is a new Evasion Option: SSL::DisableDefaultStrikeSSL. This evasion option disables the default SSL used for certain strikes.
Figure 1: DisableDefaultStrike SSL evasion option
We have also included a smart StrikeList: “Default SSL Strikes”, which includes all the strikes that make use of SSL by default (currently numbering 8). These strikes descriptions are updated to note that they run by default over SSL (as well as noting the port used). They can be found by searching for the newly added keyword “default_over_ssl”.
And finally, we have made the default BPS server certificate and key file available for copying from a CTM. The files are located in the resources dir – you can use secure-copy to copy the files from the /resources directory: