Preface
SSL and network monitoring aren’t the most compatible of partners – even with the most sophisticated detection infrastructure in the world, you’ll not derive many useful indicators from the barren randomness of encrypted traffic. Consider the plight of the Sguil sensor shown below:
The webserver’s use of SSL means that network-based incident detection is problematic. No amount of tuning of the sensor’s Snort instance will help it detect intrusion attempts – the only traffic it will see is HTTPS. Also, if an incident is detected by other means (e.g., customer notification, web server log file monitoring, etc.) the investigative value of Sguil’s full packet capture is greatly diluted.
There are a number of ways to get back the visibility stolen by SSL, including the following. You could:
Each approach has its pros and cons; this article will show you how to leverage the latter technique to restore the eyesight of your blind Sguil sensors.
SSL Decryption
We first need to understand a little about the mechanics of SSL decryption; you can read about it in depth here. In a nutshell there are two conditions that must be met before we can proceed:
The latter point means that the only SSL decryption we’re going to be able to pull off is decryption of traffic to and from servers that we own – we’re not going to be able to magically decrypt arbitrary SSL traffic (darn!) However, this is quite adequate from the viewpoint of intrusion detection and network forensics.
Now, where did I leave my keys…?
Getting the server’s private key onto the Sguil sensor could take a bit of work. The key might be stored in a .pem file somewhere on the server, making it child’s play to copy it to the Sguil sensor. However, certain operating systems like Windows store certificates and keys in a “certificate store” instead of .pem files. In order to get the private key, we need to first export the certificate and key together as a PKCS12 file (read about that here). Once we’ve got the exported certificate, we can proceed to extract the private key using openssl like this:
When prompted, enter the password you gave when you exported the certificate and key. The file myExportedCertificate.pem will contain a block of text that looks like this:
- —–BEGIN PRIVATE KEY—–
- MIIEvQIBADANBgkqhkiG9w0BAQEFAASCBKcwggSjAgEAAoIBAQCvHJFIpFwXZJ0x
- 2DzEY2B4MDBBu/+jbfUriFI+GKh6Q5oEGTAARh3OAP+UMedNf2t8/MVJdEEAM7TQ
- EZq3TiCB3e+GSjVRorB0YGvDzHR1V098LEPOvPIKNMcLCC4lGQeTg+usZmtcx4VI
- wGI70e4Byd+Lba0lUKY8UIU=
- —–END PRIVATE KEY—–
Windows also has the concept of a non-exportable private key; a key stored in this way cannot normally be exported by the Windows certificate management tools (although tools like Jailbreak claim to be able to do it).
A word of warning
As noted in the article on decrypting SSL, your server’s private key is a very sensitive thing indeed. With it, an attacker can decrypt the server’s SSL traffic or use it together with the server’s certificate in order to masquerade as a legitimate site. You must take extreme care with the handling of the private key – don’t leave copies of it lying around in temporary directories, make very sure it doesn’t end up on the Internet by accident, and make certain that the Sguil sensor you copy it to is as locked down as much as possible. Leaking a private key is too high a price to pay for visibility into your SSL traffic, so take care!
Putting the key to work
Private key in hand, we could clearly point Wireshark at Sguil’s full-content capture directories. This approach hardly lends itself to efficient network security monitoring; it would be much better if we could pipe our decrypts straight into Sguil in near real-time, leveraging the benefits of Snort, SANCP, PADS, and whatever else you’ve got running.
Dmitry Plashchynski’s viewssld package is just the tool for the job. I’ve recently made some additions to the code to ease integration with Sguil and to produce richer decrypts. Conceptually, viewssld looks like this:
viewssld listens on a given interface via the usual libpcap for nominated SSL traffic. The captured frames are then passed on to Atomic Labs’ libdssl library which handles the actual decryption (the latest version of libdssl at the time of writing is 2.1.1, available via svn here).
The output of the libdssl code is the decrypted packet contents only (no headers or anything like that), so libnet is used to build a “fake” traffic stream containing the decrypted SSL. This fake stream is pumped out through the output interface, where Sguil is listening.
Earlier versions of viewssld would only output the client->server traffic (e.g., HTTP requests). My modifications to viewssld include:
The first three points help to keep Sguil’s SANCP instance happy, since viewssld’s output is now a reasonably well-formed TCP stream with a defined beginning and end. Point four reminds us that although the decrypted traffic is available to Sguil, it is a complete fabrication – no such traffic ever existed in this form on the network. By tagging decrypted IP datagrams with an ident of 0xd551 you can sort the recorded facts from the decrypts.
Point five aids with integrating viewssld and Sguil as shown in the diagram below:
It goes like this:
Sguil/SANCP/Snort/PADS/etc. therefore see both the encrypted and the decrypted traffic, as shown in the screenshot below. In the background you can see a SANCP query with two rows of results. The first row is the raw SSL traffic captured by Sguil on port 443; the second row shows Sguil capturing the corresponding fake decrypted stream output by viewssld on port 80. The two transcript windows tell the rest of the story:
Another word of warning
There are a couple of things to consider when employing viewssld on a Sguil sensor:
Supplement
* How to Decrypt SSL and TLS Traffic using Wireshark
* How to decrypt an SSL or TLS session by using Wireshark
* Wireshark wiki - Secure Socket Layer (SSL)
沒有留言:
張貼留言