In 2017, we predict that as Flash phases out, JScript will take its place as the leading browser-exploitation vector.
Here’s **not** a news flash: Adobe Flash is riddled with vulnerabilities. The plugin which allows for interactive multimedia content is the number one vehicle for browser exploitation. In turn, browser exploitation can lead to a drive-by download attack or the execution of malicious code within a PDF.
There are a number of reasons why threat actors are leeching on to Adobe:
- Extremely popular – as of October 2016, Flash was used by 7% of all websites. The more users the attackers can cast their net on the better.
- It’s the one-for-all-exploit – attackers don’t need to create an exploit per browser or even application. They can use the same code to attack Chrome, Firefox, or Internet Explorer. It’s the same code they can use to target Acrobat Reader or other interactive web applications.
- Has a huge and complex code base – that code is old! It’s huge, it’s complex, and any developer can get lost in that. The more lines of code, the more incomprehensible the code. “Spaghetti code” would be the apt term when it comes to Flash. Developers are avoiding touching it to avoid code breaks. The result? Extremely high susceptibility to vulnerabilities.
- Flash is a virtual machine – this means that once a vulnerability is found, the threat actor achieves a lot of flexibility in terms of attack implementation. For instance, the attacker can easily overcome anti-exploitation measures through arbitrary Read-Write memory chunks. And from there, it’s game over.
Threat actors know all this and so do the browser developers. Apple with its Safari 10 release disabled Flash, requiring manual Flash activation if requested. In August, Google announced that as of December, their browsers will default to HTML5, and later on in 2017 will block Flash ads altogether.
Removing Flash from the browsers will invariably eliminate a very attacker-friendly attack vector. More so, browser developers are working on backup solutions so that even if a browser vulnerability is exploited, malicious code will have a hard time escaping the sandbox.
But we are far from breathing a sigh of relief. Attackers will continue to use browsers as their first choice of attack vehicle. After all, browser exploitation is still the most convenient attack vector since it requires less manual intervention and easily hits the masses. That’s exactly the point of waterhole attacks. Take the case of an attacker who hosts malicious code on a popular website (say, through a malvertisment or exploitation of a Web application vulnerability), and that code also exploits a certain browser vulnerability. Anyone surfing that site with the particular affected browser would get hit with malware. Certainly it’s a much easier attack vector than sending a malicious PDF that users would be wary of opening, where the file passes through scans or might not even be opened with Adobe Reader. It’s clear to say that browsers will not be immune from attacks.
So, yes, attackers will not have that technology that is independent of browser, but they will create attacks that target particular browsers. Take Chrome for example. The code base behind Chrome is a large one, prone to many vulnerabilities — vulnerabilities that can be exploited either through other plugins or directly.
The technology that will replace the attack vector? JScript. The reason is that JScript has a complex virtual machine. So similarly to Flash, vulnerabilities abundant.
What can organizations do?
- Be prepared to be compromised. This prediction serves as another reminder that there are too many doors to be able to effectively block attackers from coming in. If we can’t stop them from coming in though we should focus on preventing them from achieving their goal of data theft or tampering (as in ransomware), once the attackers are within. There are a few ways to do this as shown in the next steps.
- Segment the network. The idea here is to block off communications from a threat actor to prevent lateral movement. Or taking it to the extreme, create air-gapped networks (networks that aren’t connected to the Internet). A threat actor residing on one device, wouldn’t be able to move to another device on another network segment. In essence, the threat is contained to a single network segment. One of the downsides? Segmenting the network won’t help in cases of ransomware where the malware can block access to the computers on the network segment it resides on.
- Detect the threat. Several technologies now offer threat detection solutions – be it through user or network behavior analytics, or even through deception focused on the attack itself, such as with a honeypot. Unfortunately, these measures may come into play too late to effectively prevent a breach. For example, a threat actor’s goal may be to retrieve sensitive documents from the CEO’s device. Detecting the threat on the CEO’s device is too late because the damage is likely already done.
- Full Application Whitelisting. This measure prevents the introduction of malicious code into the system by allowing only a single pre-defined set of applications to run on the computer. Unfortunately, IT and security administrators quickly run into manageability issues trying to control all applications required by the organization, which leads to a limited deployment within the organization.
- Focus on the benefits of each measure. We need to take the benefits of each of the above approaches, while focusing on preventative measures and removing the disadvantages of each measure. For instance, although whitelisting the applications is tedious, it is possible to minimize the scope to what is really important - those communicating applications. Then, once the scope of threat has been reduced to authorized communicating applications, it is possible to sharpen the focus further on the authorized – but abused - applications and block their outgoing connections. Similarly, it is possible to deal with ransomware by blocking the abusing file handling processes.