The Heartbleed bug, still troubling computers despite a fix that’s now been around for years, demonstrates the ongoing difficulty in keeping widely distributed software up to date, notes Acunetix in its Web Security Zone blog.
Tomasz Andrzej Nidecki, technical writer for security specialist Acunetix, says that the 2012 Heartbleed bug, which many might think would no longer be found in production systems, still lingers – years after the key fixes were issued. View a report on Shodan.
“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.