Determining Heartbleed ExfiltrationProtecting Data After Secret Keys Have Been Stolen
"If an organization has some sort of network capture or monitoring device or software, it's possible that they could go back and look through that traffic and see if there is any form of malformed TLS (transport layer security protocol) handshaking going on where there's information leaking," says Dormann, vulnerability analyst with Carnegie Mellon Software Engineering Institute's CERT Coordination Center.
Dormann, in an interview with Information Security Media Group, says organizations that have deployed full-packet-capture network-logging systems might be able to determine if and when an attack occurred and what information was leaked. Otherwise, organizations could be out of luck.
"Because the vulnerability is simply just leaking extra information to an attacker, and it happened [during] the initial handshake of the TLS, there really isn't any logging occurring; you're not going to see an application crash," he says. "There's really no persistent evidence that particular vulnerability was being exploited in absence of any network logging capabilities."
The Heartbleed vulnerability exploits a flaw in a website's Open Secure Sockets Layer that could allow attackers to bypass encryption and steal critical data such as private keys that can expose untold amounts of data stored on web servers (see How to Treat the Heartbleed Bug and Heartbleed Discoverer Speaks Out).
Dormann says a solution exists, known as perfect forward secrecy, that could help minimize the damage in the case of a secret key leak by making it more difficult to decrypt already-captured network traffic. "Basically, it is preventing all the eggs being in the one basket of the secret key of the web server," says Dormann, who wrote the CERT vulnerability note on Heartbleed . "It just adds an additional aspect to the cryptography process."
In the interview, Dormann also:
- Offers lessons cybersecurity professionals and others can take away from Heartbleed;
- Discusses how organizations should address software vulnerabilities;
- Explains why it took two years to discover the flaw.
Dormann has been a software vulnerability analyst at CERT since 2004. His focus area includes web browser technologies, ActiveX and fuzzing, an application security testing process that provides invalid, unexpected or random data to the inputs of a computer program.