Heartbleed Persistence Shows Why Firms Must Go Beyond Patches

“All in all, the Heartbleed bug is an excellent example of why security scanning is just the tip of the iceberg and it must be paired with vulnerability management to guarantee IT security, whether it’s in the case of network security (such as with Heartbleed) of web security,” Nidecki writes.

Old bugs persist for various reasons, such as continued use of vulnerable software. This can happen when vulnerable software has been customized – for example by modifying the OpenSSL library.

“Many IoT devices use OpenSSL for TLS handling and such devices introduced between 2012 and 2014 would be vulnerable to Heartbleed. Some of them may not have firmware updates at all and in the case of others, the owners of the devices might choose not to do such updates,” says Nidecki.

In such cases, a direct patch may not be possible; the company must then reintroduce their custom code into the new version of the library. This is often why web open-source software such as WordPress is not immediately updated by companies even if critical new bugs are found, he explains.

Small companies might simply not even be aware that the software that they use needs a security update — especially if their web server is administered externally, or by no one at all. Some firms, regardless of size, may simply feel that defending against potential hack attacks is not worth the trouble. This can happen easily if a team has a lot of software to manage but not enough resource.

Heartbleed takes advantage of a vulnerability in Heartbeat, an extension of the OpenSSL library. The developers failed to introduce a check on whether the size of the data specified in the Heartbeat message represents the actual amount of data. It’s similar to a buffer overflow vulnerability, in that the attacker receives random memory content, which can (by chance) include sensitive information such as SSL certificates, encryption keys or credit card numbers.

“It turns out that in the original Heartbeat implementation, the client could declare any data size and the server would treat it as valid. The vulnerability appears if the declared size exceeds the real data size. In such a case, the server sends back the message with extra information,” writes Nidecki.

Read the full blog in Acunetix’s Web Security Zone.