Let’s encrypt – but let’s also decrypt and inspect SSL traffic for threats
- 11 February, 2016 02:26
This vendor-written tech primer has been edited by Network World to eliminate product promotion, but readers should note it will likely favor the submitter’s approach.
Ever since Edward Snowden’s revelations in 2013 SSL encryption has become all the rage with application owners, and that, in turn, has lead to the rise of attacks hiding in SSL traffic. What’s more, movements like Let’s Encrypt, the free, automated and open certificate authority (CA) provided by the Internet Security Research Group (ISRG), have inadvertently created a new set of vulnerabilities. Attackers are able to exploit Let’s Encrypt to generate their own seemingly legitimate SSL certificates to sign malicious code or to host malicious HTTPS sites.
Encryption allows hackers to conceal their exploits from security devices like firewalls, intrusion prevention systems and data loss prevention platforms. Some of these products cannot decrypt SSL traffic without degrading performance, while others simply cannot decrypt SSL traffic because of their location in the network.
To counter the threat posed by SSL encryption, organizations need to decrypt and inspect inbound and outbound traffic with a dedicated SSL inspection platform that enables third-party security devices to eliminate the blind spot in corporate defenses. Let’s look at three ways malware developers use encryption to escape detection:
* Zeus Trojan. First identified in 2007, Zeus Trojan is one of the many types of malware that incorporates encryption. It continues to be one of the most prevalent and dangerous pieces of financial malware around, responsible for compromising approximately four million PCs in the U.S. as of December 2014. The Zeus attack toolkit is widely used by countless criminal groups, enabling them to develop variants that are even more sophisticated. This led to the formation of the Gameover Zeus botnet, which leverages encrypted peer-to-peer communication for both malware distribution and command and control (C&C) communications. The FBI estimates that Gameover Zeus has been responsible for the theft of more than $100 million.
* Command and control updates from social media sites. Some new malware strains use social networks, such as Twitter and Facebook, and Web-based email for command and control communications. For instance, malware can receive C&C commands from Twitter accounts or comments on Pinterest, which encrypt all communications. To detect these botnet threats, organizations need to decrypt and inspect SSL traffic, otherwise security analysts might view client machine access to social media sites as harmless.
* Remote Access Trojan (RAT). G Data Software, a German security research firm, discovered a remote access Trojan (RAT) they named Win32.Trojan.lcoScript.A receiving C&C commands through Yahoo Mail. Since then, G Data – as well as consultants at Shape Security – have discovered additional Icoscript strains receiving C&C updates from Gmail draft messages. One form of the malware works by using a python script to retrieve commands and other code from the drafts folder, which stays hidden despite being open. With both Gmail and Yahoo Mail encrypting traffic, malware is able to use them to evade detection from IDS or DLP solutions. If organizations don’t decrypt and inspect traffic to email sites, they’re raising their risk of infection from these types of malware.
Encryption today accounts for roughly one-third of all Internet traffic, and it’s expected to reach two-thirds of all traffic next year when Internet powerhouses like Netflix transition to SSL. As a result, encrypted traffic will become the “go-to” way of distributing malware and executing cyber-attacks simply. To detect malicious activity, organizations should decrypt and inspect SSL traffic. Otherwise, malware could be passing them by.
To solve this issue and gain SSL insight, organizations can deploy SSL inspection platforms to decrypt SSL traffic and forward it to third-party security devices for analysis. For outbound traffic, organizations own the end points but not the SSL certificates and keys. An SSL inspection platform can decrypt traffic when configured as a transparent forward proxy or an explicit proxy.
Decrypting inbound traffic destined to internal application servers is different than decrypting outbound traffic because organizations own the SSL keys. There are two main ways to decrypt inbound SSL traffic sent to internal servers:
- Reverse proxy mode: SSL traffic is terminated on the SSL inspection devices and sent in clear text to inline or non-inline security devices. This mode is also referred to as “SSL Offload.”
- Passive non-inline or inline mode: SSL traffic is decrypted using a copy of the server SSL keys. SSL traffic is not modified by the SSL inspection platform except—potentially—to block attacks.
In passive non-inline mode, the SSL inspection platform can be installed transparently without needing to update network settings. However, organizations won’t be able to effectively block all attacks, including single-packet attacks. The biggest flaw, however, is that passive mode fails to support strong encryption methods like Perfect Forward Secrecy (PFS) because the SSL inspection platform does not actively participate in the SSL key negotiation.
Whether sharing a malicious file on a social networking site or attaching malware to an email or instant message, many attacks will be cloaked in SSL. It’s time organizations invest heavily in data protection and don’t forget to decrypt and inspect all SSL traffic.
A10 Networks is a leader in application delivery networking and security, providing a range of high-performance application networking solutions that help organizations ensure that their data center applications and networks remain highly available, accelerated and secure. Founded in 2004, A10 Networks is based in San Jose, Calif., and serves customers globally with offices worldwide.