Vulnerabilities are the talk of the town lately but you sometimes wonder ‘is there really any substance to these reports, or it is hype?’
With networks running AV and hardened firewalls in place, surely vulnerabilities cannot have that much of an effect… or can they?
What are vulnerabilities? There are different types, but in the majority of cases, vulnerabilities are bugs in a program’s code that, in general, make it behave in a way the original developer never intended it to.
This behaviour could result in information being disclosed or the program could execute code that an attacker would have injected remotely. Firewalls, anti-virus and other security barriers, generally, can’t do much to mitigate the exploitation of vulnerabilities.
Why is that?
Let’s take Heartbleed as an example. This vulnerability causes the target system to disclose information that is stored in memory. What the attacker does is send a specifically crafted packet to a vulnerable SSL implementation.
In most cases the vulnerable SSL implementation would be an HTTP secure server connection that is designed to service clients on the internet. Since a firewall is designed to allow similar packets through, attacks of this type would not be stopped by a firewall.
Since no software would be deployed on the target machine, an AV solution will not do anything either.
Another vulnerability worth discussing is CVE-2014-1776 (unfortunately, not all vulnerabilities get a cool name). This exploit uses an Internet Explorer vulnerability of the use after freed type.
In this case, software can be made to reuse an address after this has been freed and, generally, causes the program to crash. If this is coupled with a heap spray (loading specific shell code on the heap and then having that freed pointer jump to your shell code) it is possible to have the target software execute code of your choice. This is how CVE-2014-1776 was exploited.
The vulnerability is exploited when the victim visits a malicious HTML page while browsing. Once again, the firewall is not designed to block browsing traffic; no software is used that an AV can scan because the shell code is injected directly into memory.
What happens next? Anything the attacker wants to do; provided there is enough space. The attacker can siphon information, install a backdoor or use the code to create a new account.
Are we helpless then?
In most cases, a firewall or AV solution will not come to your rescue if these vulnerabilities are exploited. The solution, you may say, is patch management. After all, we patch to shore up holes in our systems, especially if it’s done properly and frequently.
This is true to a certain degree. However, there is, as always, an exception or two.
Creating a patch takes time and while bona fide researchers are willing to wait for a vendor to release the patch before they disclose what they found, the same cannot be said for hackers.
If malicious hackers know of a vulnerability and exploitation code already exists in the wild, details of that vulnerability will come out long before a patch is made available.
Another important point is that vulnerabilities can also affect devices and, generally speaking, there are no patch management strategies that businesses employ for devices.
When devices are patched – if ever – it is nearly always the case that system administrators had to manually perform firmware upgrades because it was necessary and not part of a strategy.
Patching devices is just as important as patching software. While most administrators will make sure that their systems are updated with the latest patches, unless they are aware of a vulnerability on a device, it will most likely never get patched.
What are you risking?
What is the risk to a network and, by extension the company, if vulnerabilities are ignored? Simple answer: you risk losing all the information that is stored on your network at any point in time. Note that I’m referring to the whole network, not just computers. Vulnerabilities like
Heartbleed can be used to compromise / read data on devices as well. You need to think beyond computers: there are routers, network printers, NASs and so on.
Vulnerabilities can be exploited and leveraged to read what is being printed on network printers, to read which credentials are used to log onto the NAS and to read those files that are on the NAS (when a file is accessed, it is cached in memory and therefore available to attackers).
There is also the risk that attackers could potentially read the memory contents on your email server/client and gain access to emails.
They could read the memory on your web server potentially lifting your certificates which, in turn, could be used to impersonate your web site. They could potentially read credit card details as they’re processed or disclose your customers’ personal information.
If that’s not enough, you will have to deal with the fallout. If user credentials / credit card details have been leaked or stolen, you are legally-bound to inform your customers and hope they don’t ignore your warnings and do change their credentials and credit cards.
If they don’t and those credentials are used by the bad guys, then you had better be prepared to handle customer complaints stemming from unauthorised activity on their account or requests for refunds of expenses for services the attacker charged to their account.
On top of this you would also have to win back your customer’s trust because some will take their business elsewhere.
One final point. It is easy to dismiss vulnerability management and argue that it is only done by large enterprises: “Oh, but that’s not something I need to do; I don’t even run my own web server”.
Vulnerabilities are found in all software and they are not limited to servers and enterprise software. They can be found in the smallest program as well as in the most complex systems. Any data that passes through your hardware / software, whether it is permanently stored or not, is at risk.
The last thing any business, small or large, wants is their data falling into the wrong hands. Vulnerability management should be high up on the list of every sys admin or IT team. Ignore it at your own peril.
By Emmanuel Carabott, Security Research Manager, GFI Software