- Email: [email protected]
The Java vulnerability landscape
FEATURE A whitelist of normal behaviour can be built-up over a long period of time, which will assist in identifying the ‘low and slow’ exfiltration attempts. Identifying a payload that has been concealed using stenography can seem difficult, but when logic and context are applied, it becomes relatively easy. Within log files, the hidden data would be an image call: however this would be out of context unless the image was created within a crafted HTML web page. When it has a pixel size of 0x0 it would not appear on the page but could still be browsed for, downloaded and finally, delivered to the APT attacker. Simply, it is unlikely a .jpg image would be referenced without being delivered by an HTML page in a browser session and the chances are, therefore, that it is part of a payload.
Conclusion While APTs are designed to be highly elusive, with the right mechanisms in place they can be identified and removed. However, in order to do so, advanced security intelligence that combines 360-degree visibility into all network activity and an analytics driven defence is required.
It is imperative to have an in-depth understanding of ‘normal’ activity on the network, along with the ability to understand events in relation to each other. By analysing richer sets of data, and applying context, it is not only more likely that irregular activity will be flagged immediately, but it will also reduce the number of false positives. Through this level of pervasive visibility it is possible to spot anomalous activity – such as suspicious data transfers or excess network usage – and stop an APT in its tracks. Given that very few organisations can say with full confidence that they have not been compromised by an APT now, or at any other point, it is imperative that the correct tools and systems are put in place now so the potential damage of a successful attack is minimised.
About the author Ross Brewer is vice president and managing director for international markets at LogRhythm, a position he has held since 2008. Brewer has more than two decades’ experience within sales and management, with more than 10 years spent in the information security sector where he has had a successful track record of building and managing international operations. Prior to joining LogRhythm, Brewer was
vice president and managing director for EMEA at LogLogic.
References 1. ‘Keeping the UK safe in cyber space’. Gov.uk, 23 Jan 2014. Accessed Feb 2014. https://www.gov.uk/government/policies/keeping-the-uk-safe-incyberspace. 2. ‘2013 Cost of Cybercrime Study: Global Report’. Ponemon Institute, Oct 2013. Accessed Feb 2014. www.hpenterprisesecurity.com/collateral/report/ Ponemon2013CyberCrimeReport_ Global_1013.pdf 3. ‘Prevention Is Futile in 2020: Protect information Via Pervasive Monitoring and Collective Intelligence’. Gartner, May 2013. 4. ‘Managing Information Security Risk: Organisation, Mission, and Information System View. National Institute of Standards and Technology, Mar 2011. Accessed Feb 2014. http://csrc.nist.gov/publications/nistpubs/800-39/SP800-39final.pdf. 5. ‘2013 Data Breach Investigations Report’. Verizon, Apr 2013. Accessed Feb 2014. www.verizonenterprise. com/DBIR/2013/.
The Java vulnerability landscape Harry Sverdlove, Bit9
Harry Sverdlove
Java has been a trending security concern for several years. Recently, however, there has been a significant rise in Java-related vulnerabilities and attacks. According to Kaspersky Lab, in 2012 Java surpassed Adobe Reader as the most exploited endpoint software in real-world attacks. Specifically, the 2012 annual Kaspersky Security Bulletin noted that: “Throughout the year Kaspersky Lab’s experts registered both large-scale and targeted attacks utilising vulnerable software, with Oracle Java being the most frequently targeted (50% of attacks). Adobe
April 2014
Reader ranked second (28%) and Adobe Flash player occupies the fourth place with only 2% share, thanks to efficient automatic updating system that promptly closes security holes.” In August 2013, F-Secure anti-malware analyst Timo Hirvonen reported finding an in-the-wild exploit actively targeting an unpatched vulnerability in Java 6. According to vulnerability informa-
tion provider Secunia, the bug could be “exploited by malicious local users to disclose certain sensitive information, manipulate certain data, and gain escalated privileges and by malicious people to conduct spoofing attacks, disclose certain sensitive information, manipulate certain data, cause a DoS (denial of service), bypass certain security restrictions, and compromise a vulnerable system.” No doubt, Java has become a primary gateway for hackers to enter today’s businesses.
Network Security
9
FEATURE are taking advantage of a security vulnerability on the same day that the vulnerability becomes generally known, giving developers zero days to address and patch the vulnerability.
Most concerning problem
Key findings from Bit9’s research on Java vulnerabilities.
In September 2013, F-Secure’s Threat Report H1 2013 found that Java exploits for about half of the detections reported to its systems, up from one-third in the prior six months. F-Secure notes that it’s not surprising Java is an appealing target since 10
Network Security
“next to the Windows operating system (also a popular target for exploits), Java is probably the second-most ubiquitous program in an organisation’s IT setup.” What’s worse, these attacks are increasingly zero-day exploits, meaning hackers
Java’s vulnerabilities and prevalence combine to make it perhaps the single most concerning security problem today. So it is important to closely explore the breadth and state of its deployment across enterprises. Research from Bit9 uncovered some surprising findings that can result in greater security risks across organisations, including: UÊ ÃÌÊiÌiÀ«ÀÃiÃÊ >ÛiÊÕÌ«iÊÛiÀsions of Java, the most prevalent versions of which are highly vulnerable. This finding was supported by Websense research which found that, as of August 2013, 81% of Windows machines were not running the latest version of Java, leaving their users wide open to known exploits. UÊ ÌÌ>ViÀÃÊV>ÊvÌiÊÌ>À}iÌÊ`]ÊÛÕiÀable Java versions installed on the endpoint. According to Websense, exploits CVE-2013-2473 and CVE-2013-2463 are successfully targeting PCs running outdated versions of Java. UÊ iÜiÀÊÌ >Ê£¯ÊvÊÀ}>Ã>ÌÃÊ >ÛiÊ installed the latest version of Java. Clearly, cyber-criminals know there is a Java update problem for many organisations, and they are eager to exploit it. So let’s take a look at the state of Java in the enterprise and examine the reasons behind Java’s new favoured status among attackers and a history of Java-related attacks. We’ll also offer recommendations for reducing Java-related risks in today’s organisations. The hope is that by shedding light on the reasons Java is so widely targeted, enterprises will have a deeper understanding of the issues involved and be better equipped to make decisions and take actions to remediate this important threat.
The current state of Java In July 2013, Bit9’s research team analysed Java deployment statistics on
April 2014
FEATURE approximately one million endpoints at hundreds of enterprises worldwide. Highlights of the findings include: UÊ / iÊ>ÛiÀ>}iÊÀ}>Ã>ÌÊ >`ÊÀiÊ than 50 distinct versions of Java. Some 5% of organisations have more than 100 versions of Java installed. Typically, organisations that have fewer total versions of Java within their environment are those with more fixed-function devices, which usually do not have any version of Java installed. UÊ ÃÌÊi`«ÌÃÊ >ÛiÊÕiÀÕÃÊÌiÀ>tions of Java installed, in part because the Java installation and update process often does not remove old versions. UÊ ÌÌ>ViÀÃÊV>Ê`iÌiÀiÊÜ >ÌÊÛiÀsions of Java an enterprise is running and target the oldest, most vulnerable versions. UÊ / iÊÃÌÊ««Õ>ÀÊÛiÀÃÊvÊ>Û>ÊÀÕning on endpoints analysed by Bit9 is version 6 update 20, which is present on 9% of all systems and has 96 known vulnerabilities of the highest severity. UÊ iÃÃÊÌ >Ê£¯ÊvÊiÌiÀ«ÀÃiÃÊ>ÀiÊÀÕning the latest version of Java. The blame for not removing old versions of Java cannot be laid entirely at the feet of user organisations. A big part of the problem is the failure of Java installation and update software to remove previous versions. In other words, installing a new version of Java will not remove older versions of the software and the installation process allows for redundant instances of Java on a given endpoint.
“It seems likely that older endpoints carry more and older versions of Java, which can result in greater security risk across each organisation” The Java updater, on the other hand, will attempt to remove the most recent previous version in favour of the newer version, but not other prior versions of the software. For example, running the Java update process when version 6 Update 13 is installed will cause the update process to attempt to remove version 6 Update 13 and install the latest
April 2014
Oldest Java instances by age and deployment.
version (Java 7 Update 45, as of October 2013), but it will not remove version 5 update 22 if that version also had been installed previously. Only Java 7 version installers and some versions of Java 6 installers remove minor versions within that major version (version 6 installers do not uninstall version 5 installations, for example).
Greater risk Bit9’s analysis found that each endpoint had an average of 1.6 versions of Java installed. Considering that many deployments comprised mostly of server, point-of-sale or other fixed-function endpoints never have Java installed, the average number of versions is quite likely much higher when looking strictly at typical end-user desktop environments. Approximately 42% of endpoints have more than two versions of Java installed at the same time. And approximately 20% of endpoints observed had more than three versions of Java on each system. It seems likely that older endpoints carry more and older versions of Java, which can result in greater security risk across each organisation. Some 93% of organisations are running a version of Java at least five years old and 51% have a version that is between 5 and 10 years old. Only 7% of organisations do not have Java versions five years or older installed in their
environment. The fact that so many environments apparently use significantly out-of-date versions of Java points to potential issues in how well the average organisation manages its software. In addition, the fact that older major versions of Java are not removed during installation of newer versions has led to continued high prevalence of very old and vulnerable versions of Java remaining on a high percentage of endpoints.
“Even as fewer websites and web applications require Java in order to operate properly, the technology is pervasive on virtually every end-user system. For this reason, Java also has become a platform that is highly vulnerable to attack” Of all Java versions, Java 1.6.0 (version 6) is the most vulnerable since it is very prevalent (present on 82% of the endpoints surveyed in Bit9’s research) and attackers and researchers alike clearly have incentive to find flaws in the most prevalent versions of software. There are virtually no modern versions of Java without any known severe vulnerabilities, and vulnerabilities found in one version of Java often exist in a large number of older versions as well. Only a minority of Java versions that were found installed on endpoints do not have a large number of severe vulner-
Network Security
11
FEATURE
Java version vulnerabilities.
abilities, and these are restricted to the very old and unpopular 1.4- and 1.3-based versions. It is important to note that while Java has many vulnerabilities, their exposure is primarily a problem when Java is used as a client-side web technology. Many products contain their own embedded versions of Java, and these instances are generally not made available to the browser, and so do not expose the same threat surface as a typical standalone Java installation. Internally developed non-web applications also can use Java outside the browser. However, since Java poses such a significant risk when used as a client-side web technology, caution must be exercised to ensure that Java instances that are made available for such applications are not also made available to the browser.
Java’s favoured status among hackers Java was originally released with the slogan “write once, run anywhere,” which was intended to underscore its cross-platform capabilities. Over time, Java has become ubiquitous on endpoints, so ‘run anywhere’ can be interpreted as referring to its ubiquity. Even as fewer websites and web applications require Java in order to operate properly, the technology is pervasive on virtually every end-user system. For this reason, Java also has become a platform that is highly vulnerable to attack. A piece of evidence demonstrating Java’s 12
Network Security
favoured status among attackers is how frequently it is integrated into various exploit kits such as Blackhole, Cool and Redkit. These kits represent the evolution of publicly available scripted attacks into relatively mature, supported products that often are sold on the underground market. Exploit kits are typically used to implement browser-based attacks by deploying them on compromised or attacker-staged web servers, and include a variety of exploits for use against client systems. Because vulnerable versions of Java are so pervasive and severe, the inclusion of Java exploits in these kits provides a high probability of successful compromise. It is perhaps not well known outside the security research community that malicious Java code can target outdated instances of Java even after the most recent version of Java has been installed on an endpoint. Sometime during the Java 6 family of updates, the Java updaters began removing some older versions of Java. However, an installer for a major version of Java does not remove versions of Java from older major versions. The fact that older major versions of Java are not removed during installation of newer versions has led to continued high prevalence of very old and vulnerable versions of Java remaining on a high percentage of endpoints. Essentially, Java represents an extremely large surface area for potential attacks in many organisations. In spite of this, organisations continue to be behind the curve on patching
Java. Typically, it takes an organisation between three and nine months to apply Java patches due to the extensive quality assurance testing they need to conduct before applying each patch. Were it not for the fact that hackers have been paying close attention to Java vulnerabilities, this would be less of an issue. Earlier this year, Java vulnerabilities prompted US-CERT to encourage the public to disable Java unless it is necessary. However, disabling Java is not as easy for some organisations as it sounds. It’s similar to the fact that it’s easy for home users to upgrade their Windows OS overnight, but it often takes corporations years to plan for and implement such a move. This fact has led to products, such as the open-source JavaRa tool, whose sole purpose is to help users deal with the problem of identifying and removing old versions of Java. While these products will mitigate some percentage of attacks, many users will not understand the warning and may choose to allow the code to execute under the old vulnerable version. In addition, so-called ‘click bypass’ vulnerabilities often are discovered in Java, allowing attackers to prevent the mitigating interactive messages from ever being seen by the user.
“The relative ease of creating malware in Java, and the ability to construct it with only a modest amount of platformspecific code, may have aided the attackers” In July 2013, a vulnerability was found that affects Java major version 7 update 21, the newest version as of Bit9’s data collection, as well as earlier versions. This vulnerability allows for attackers to bypass the Java click-2-play security warning dialogue box without user interaction. According to Packet Storm, this means that attackers can still target an older version on an endpoint, without user notification. The latest version at the time of Bit9’s research, Java 7 Update 25, goes further and will not allow users to select older versions to run against. It remains to be seen if clickbypass vulnerabilities become more difficult to uncover, however.
April 2014
FEATURE
A history of Java-related attacks There are many examples of attacks involving Java that a simple web search will show. The following are some attacks that have unique and interesting aspects. In early 2012, trojan malware was discovered infecting Macs and creating a botnet of Mac-based endpoints. This malware was notable for being the largest scale threat to the Mac platform to that date, according to Macworld. The relative ease of creating malware in Java, and the ability to construct it with only a modest amount of platform-specific code, may have aided the attackers. Similarly, a cross-platform trojan called ‘Minecraft Hack Kit’, a password stealer, affected both Mac and Windows users. Another cross-platform trojan, Mal/ JavaJar-B, even attacked Linux systems as well as Mac and Windows. Another example of threats related to Java in the wild was identified in May 2013. This attack targeted a zeroday vulnerability in Internet Explorer. However, the first action taken by the malicious code, according to AlienVault Labs’ analysis, was to enumerate all of the Java versions on the affected endpoint. Quite likely this reconnaissance step was intended to ensure the ability to compromise the host again in the future if, for example, the zero-day vulnerability was patched via the Windows update mechanism. It also is interesting to note that the attackers apparently used code directly taken from the Java Deployment Toolkit.
How to reduce Java-related risks So, what can be done to reduce the likelihood of a Java-related attack? First, evaluate whether Java is necessary for your organisation. Many in the security community urge the widespread and complete removal of Java from all endpoints. This option is often difficult to implement in practice, however, because tools for managing Java in the enterprise are lacking. In addition, it is often challenging for organisations to fully assess the impact of removing Java in their environment.
April 2014
However, there is both anecdotal and quantitative evidence that some organisations are choosing to remove Java from their environments altogether, as many in the security industry have recommended. According to the collected data, some large organisations have successfully reduced the average number of installed Java instances per endpoint to as low as one instance per 50 endpoints (0.02 versions per endpoint).
“Consider using network security solutions such as those with layer 7 visibility to look for evidence of browser-based Java. You should also monitor for unexpected installation and use of Java in the environment” If removal is chosen, develop a plan. Consider tools that can block execution of software based on name or hash on the endpoint as a quick first step toward the eventual goal of removal. Use software management tools to remove instances of Java. In addition, close the loop – that is, audit the software in your enterprise to confirm Java’s removal. Finally, consider using network security solutions such as those with layer 7 visibility to look for evidence of browser-based Java. You should also monitor for unexpected installation and use of Java in the environment. However, there is no need to go overboard with controlling or removing Java. Many products contain a version of Java embedded that is not made available to the browser, and thus poses little risk of web-based infection. When using NIST data to find vulnerability information, keep in mind that software and vulnerabilities may not always be recorded in a consistent manner. Product names are not well normalised. For example, some vulnerabilities are reported under the product ‘Java’, while others (most in fact) are reported under the product ‘JRE’. Version strings in reports sometimes contain spaces where others do not (‘Update 19’ versus ‘Update19’, for example). The CPE names reflect these inconsistencies using corresponding redundant ‘Update_19’ and ‘Update19’ strings.
In addition, the change to the version format of Java introduced reporting inconsistencies, with some vulnerabilities being reported, for example, against ‘version 6 Update 10’, and some being reported against ‘version 1.6.0 Update 10’. Java ranks number 16 (as Sun/JRE) in the list of Top 50 Products By Total Number of ‘Distinct’ Vulnerabilities, with 397 vulnerabilities. However, if the data quality issues above were addressed, this number would far exceed 500 and put Java in the top 10.
Conclusion For the past 15 years or so, IT administrators have been under the misperception that updating Java would address its security issues. They have been told that to improve security, they should continuously and aggressively install Java updates on all of their endpoints. Unfortunately, installing is not the same as updating. Until very recently, those installations have failed to deliver the promised security upgrade because they have not removed older, highly vulnerable versions of Java they were intended to replace. As a result, most organisations have multiple versions of Java on their endpoints, including some that were released at the same time as Windows 95.
“Most organisations have no idea what’s running on their endpoints and servers – they lack visibility into those systems. And traditional security solutions, including anti-virus, can’t protect them from modern threats” Not only is Java widely installed in most enterprises, in most instances it is highly vulnerable. Java continues to be a required technology for many companies, but its ubiquity seems to be out of proportion with its current business use cases. Some enterprises appear to be choosing to remove Java from their environments, and the facts revealed in Bit9’s research underscore the rationale for doing so. Bit9’s data also seems to show the reasons behind Java’s new favoured status
Network Security
13
FEATURE among attackers. Many enterprises have so far been slow to respond appropriately to this trend, despite evidence that doing so would, for many, substantially reduce their exposure to today’s most common successful attacks. It’s not surprising that most companies are unaware of all the versions of Java on their systems. Most organisations have no idea what’s running on their endpoints and servers – they lack visibility into those systems. And traditional security solutions, including antivirus, can’t protect them from modern threats. While the industry appears to be making efforts to mitigate some of the issues that have brought us to where we are today, those efforts will have little impact on remediating the current situation. Traditional security solutions can’t necessarily protect organisations from all modern threats.
Recent high-profile attacks continue to demonstrate that enterprises should view Java as a major security risk. Enterprises can benefit from better characterising and understanding the applications running on the endpoints in their environment, so they can evaluate the risks to those endpoints and more effectively prioritise remediation efforts. Moving forward, real-time visibility and protection for endpoints and servers will be essential.
About the author Harry Sverdlove, Bit9’s chief technology officer, draws from two decades of application design and analysis with industryleading IT enterprises. He regularly publishes threat intelligence research, including: ‘Java Vulnerabilities Write Once, Pwn Anywhere’ (2013), ‘Pausing Google Play: More Than 100,000 Android Apps May
Pose Security Risks’ (2012) and ‘The Most Vulnerable Smartphones’ (2011). Prior to joining Bit9, Sverdlove was principal research scientist for McAfee, where he supervised the overall architecture of crawlers, spam detectors and link analysers. He joined McAfee through its 2006 acquisition of SiteAdvisor, where he was chief scientist and developed systems for testing, detecting and analysing any Windowsbased application. Prior to SiteAdvisor, Sverdlove ran his own consulting company specialising in Windows automation and spam detection. He also was director of engineering at Compuware Corporation (formerly NuMega Technologies). Prior to NuMega, Sverdlove was principal architect for Rational Software, where he designed the core automation engine behind Rational Robot. He earned a bachelor’s degree in electrical engineering from the Massachusetts Institute of Technology.
Unveiling the dark web Danny Bradbury The dark web is a secretive, anonymous place where shadowy users access hidden services. It can be used for good or bad – but can it be cracked? And if so, how? The media is littered with discussions of the deep web and the dark web, but they are different entities. The former consists of web pages accessible on the public Internet, but not via search engines such as Google. Search engines crawl the Internet using search bots that index data, these days using robots.txt files as guides that tell them what data to index, under the 1994 Robots Exclusion Standard.1,2 Web crawlers cannot index deep web content. It is usually accessible only when a user searches a specific database, meaning that there is no explicit link for it.3 The dark web, on the other hand, is often publicly available – you simply have to know how to find it, because it exists on an alternate layer of the Internet. This alternate layer is often constructed by a community that wants to preserve anonymity, autonomy, or perhaps an ideology. 14
Network Security
Such communities can use the dark web for a variety of activities, both good and bad. Dark webs have been used for criminal activities such as the distribution of child pornography, hacking rings, money laundering, and sales of weapons and drugs.4 However, they have also been used as tools to help citizens route around censorship measures enforced in non-democratic states, such as China.5
A tour of Tor One of the most commonly-used mechanisms for creating dark webs is Tor, a routing mechanism designed to preserve anonymity by creating an alternative mechanism to DNS for routing traffic. Tor uses a concept called onion routing, which was first created by the US Naval Research Laboratory.6
Danny Bradbury
Tor uses a selection of relay machines running freely available, open source software. The sender of a piece of traffic will find an entry point and choose a random routing path through a selection of relays to obfuscate their point of origin. Traffic routed along this path will be encrypted until it leaves the last relay, to be sent to a specific IP address on the public Internet. This means that the traffic will appear to have originated from the IP address of that last relay. Tor can also be used to host websites as ‘hidden services’ online. These services use seemingly incomprehensible names, with the suffix ‘.onion’. The names are derived from public keys provided from a key pair, provided by the hidden service. Unlike traditional DNS routing, the path to communication between a client and a Tor-based hidden service is not explicit. The system is designed to preserve the
April 2014
Conclusion While APTs are designed to be highly elusive, with the right mechanisms in place they can be identified and removed. However, in order to do so, advanced security intelligence that combines 360-degree visibility into all network activity and an analytics driven defence is required.
It is imperative to have an in-depth understanding of ‘normal’ activity on the network, along with the ability to understand events in relation to each other. By analysing richer sets of data, and applying context, it is not only more likely that irregular activity will be flagged immediately, but it will also reduce the number of false positives. Through this level of pervasive visibility it is possible to spot anomalous activity – such as suspicious data transfers or excess network usage – and stop an APT in its tracks. Given that very few organisations can say with full confidence that they have not been compromised by an APT now, or at any other point, it is imperative that the correct tools and systems are put in place now so the potential damage of a successful attack is minimised.
About the author Ross Brewer is vice president and managing director for international markets at LogRhythm, a position he has held since 2008. Brewer has more than two decades’ experience within sales and management, with more than 10 years spent in the information security sector where he has had a successful track record of building and managing international operations. Prior to joining LogRhythm, Brewer was
vice president and managing director for EMEA at LogLogic.
References 1. ‘Keeping the UK safe in cyber space’. Gov.uk, 23 Jan 2014. Accessed Feb 2014. https://www.gov.uk/government/policies/keeping-the-uk-safe-incyberspace. 2. ‘2013 Cost of Cybercrime Study: Global Report’. Ponemon Institute, Oct 2013. Accessed Feb 2014. www.hpenterprisesecurity.com/collateral/report/ Ponemon2013CyberCrimeReport_ Global_1013.pdf 3. ‘Prevention Is Futile in 2020: Protect information Via Pervasive Monitoring and Collective Intelligence’. Gartner, May 2013. 4. ‘Managing Information Security Risk: Organisation, Mission, and Information System View. National Institute of Standards and Technology, Mar 2011. Accessed Feb 2014. http://csrc.nist.gov/publications/nistpubs/800-39/SP800-39final.pdf. 5. ‘2013 Data Breach Investigations Report’. Verizon, Apr 2013. Accessed Feb 2014. www.verizonenterprise. com/DBIR/2013/.
The Java vulnerability landscape Harry Sverdlove, Bit9
Harry Sverdlove
Java has been a trending security concern for several years. Recently, however, there has been a significant rise in Java-related vulnerabilities and attacks. According to Kaspersky Lab, in 2012 Java surpassed Adobe Reader as the most exploited endpoint software in real-world attacks. Specifically, the 2012 annual Kaspersky Security Bulletin noted that: “Throughout the year Kaspersky Lab’s experts registered both large-scale and targeted attacks utilising vulnerable software, with Oracle Java being the most frequently targeted (50% of attacks). Adobe
April 2014
Reader ranked second (28%) and Adobe Flash player occupies the fourth place with only 2% share, thanks to efficient automatic updating system that promptly closes security holes.” In August 2013, F-Secure anti-malware analyst Timo Hirvonen reported finding an in-the-wild exploit actively targeting an unpatched vulnerability in Java 6. According to vulnerability informa-
tion provider Secunia, the bug could be “exploited by malicious local users to disclose certain sensitive information, manipulate certain data, and gain escalated privileges and by malicious people to conduct spoofing attacks, disclose certain sensitive information, manipulate certain data, cause a DoS (denial of service), bypass certain security restrictions, and compromise a vulnerable system.” No doubt, Java has become a primary gateway for hackers to enter today’s businesses.
Network Security
9
FEATURE are taking advantage of a security vulnerability on the same day that the vulnerability becomes generally known, giving developers zero days to address and patch the vulnerability.
Most concerning problem
Key findings from Bit9’s research on Java vulnerabilities.
In September 2013, F-Secure’s Threat Report H1 2013 found that Java exploits for about half of the detections reported to its systems, up from one-third in the prior six months. F-Secure notes that it’s not surprising Java is an appealing target since 10
Network Security
“next to the Windows operating system (also a popular target for exploits), Java is probably the second-most ubiquitous program in an organisation’s IT setup.” What’s worse, these attacks are increasingly zero-day exploits, meaning hackers
Java’s vulnerabilities and prevalence combine to make it perhaps the single most concerning security problem today. So it is important to closely explore the breadth and state of its deployment across enterprises. Research from Bit9 uncovered some surprising findings that can result in greater security risks across organisations, including: UÊ ÃÌÊiÌiÀ«ÀÃiÃÊ >ÛiÊÕÌ«iÊÛiÀsions of Java, the most prevalent versions of which are highly vulnerable. This finding was supported by Websense research which found that, as of August 2013, 81% of Windows machines were not running the latest version of Java, leaving their users wide open to known exploits. UÊ ÌÌ>ViÀÃÊV>ÊvÌiÊÌ>À}iÌÊ`]ÊÛÕiÀable Java versions installed on the endpoint. According to Websense, exploits CVE-2013-2473 and CVE-2013-2463 are successfully targeting PCs running outdated versions of Java. UÊ iÜiÀÊÌ >Ê£¯ÊvÊÀ}>Ã>ÌÃÊ >ÛiÊ installed the latest version of Java. Clearly, cyber-criminals know there is a Java update problem for many organisations, and they are eager to exploit it. So let’s take a look at the state of Java in the enterprise and examine the reasons behind Java’s new favoured status among attackers and a history of Java-related attacks. We’ll also offer recommendations for reducing Java-related risks in today’s organisations. The hope is that by shedding light on the reasons Java is so widely targeted, enterprises will have a deeper understanding of the issues involved and be better equipped to make decisions and take actions to remediate this important threat.
The current state of Java In July 2013, Bit9’s research team analysed Java deployment statistics on
April 2014
FEATURE approximately one million endpoints at hundreds of enterprises worldwide. Highlights of the findings include: UÊ / iÊ>ÛiÀ>}iÊÀ}>Ã>ÌÊ >`ÊÀiÊ than 50 distinct versions of Java. Some 5% of organisations have more than 100 versions of Java installed. Typically, organisations that have fewer total versions of Java within their environment are those with more fixed-function devices, which usually do not have any version of Java installed. UÊ ÃÌÊi`«ÌÃÊ >ÛiÊÕiÀÕÃÊÌiÀ>tions of Java installed, in part because the Java installation and update process often does not remove old versions. UÊ ÌÌ>ViÀÃÊV>Ê`iÌiÀiÊÜ >ÌÊÛiÀsions of Java an enterprise is running and target the oldest, most vulnerable versions. UÊ / iÊÃÌÊ««Õ>ÀÊÛiÀÃÊvÊ>Û>ÊÀÕning on endpoints analysed by Bit9 is version 6 update 20, which is present on 9% of all systems and has 96 known vulnerabilities of the highest severity. UÊ iÃÃÊÌ >Ê£¯ÊvÊiÌiÀ«ÀÃiÃÊ>ÀiÊÀÕning the latest version of Java. The blame for not removing old versions of Java cannot be laid entirely at the feet of user organisations. A big part of the problem is the failure of Java installation and update software to remove previous versions. In other words, installing a new version of Java will not remove older versions of the software and the installation process allows for redundant instances of Java on a given endpoint.
“It seems likely that older endpoints carry more and older versions of Java, which can result in greater security risk across each organisation” The Java updater, on the other hand, will attempt to remove the most recent previous version in favour of the newer version, but not other prior versions of the software. For example, running the Java update process when version 6 Update 13 is installed will cause the update process to attempt to remove version 6 Update 13 and install the latest
April 2014
Oldest Java instances by age and deployment.
version (Java 7 Update 45, as of October 2013), but it will not remove version 5 update 22 if that version also had been installed previously. Only Java 7 version installers and some versions of Java 6 installers remove minor versions within that major version (version 6 installers do not uninstall version 5 installations, for example).
Greater risk Bit9’s analysis found that each endpoint had an average of 1.6 versions of Java installed. Considering that many deployments comprised mostly of server, point-of-sale or other fixed-function endpoints never have Java installed, the average number of versions is quite likely much higher when looking strictly at typical end-user desktop environments. Approximately 42% of endpoints have more than two versions of Java installed at the same time. And approximately 20% of endpoints observed had more than three versions of Java on each system. It seems likely that older endpoints carry more and older versions of Java, which can result in greater security risk across each organisation. Some 93% of organisations are running a version of Java at least five years old and 51% have a version that is between 5 and 10 years old. Only 7% of organisations do not have Java versions five years or older installed in their
environment. The fact that so many environments apparently use significantly out-of-date versions of Java points to potential issues in how well the average organisation manages its software. In addition, the fact that older major versions of Java are not removed during installation of newer versions has led to continued high prevalence of very old and vulnerable versions of Java remaining on a high percentage of endpoints.
“Even as fewer websites and web applications require Java in order to operate properly, the technology is pervasive on virtually every end-user system. For this reason, Java also has become a platform that is highly vulnerable to attack” Of all Java versions, Java 1.6.0 (version 6) is the most vulnerable since it is very prevalent (present on 82% of the endpoints surveyed in Bit9’s research) and attackers and researchers alike clearly have incentive to find flaws in the most prevalent versions of software. There are virtually no modern versions of Java without any known severe vulnerabilities, and vulnerabilities found in one version of Java often exist in a large number of older versions as well. Only a minority of Java versions that were found installed on endpoints do not have a large number of severe vulner-
Network Security
11
FEATURE
Java version vulnerabilities.
abilities, and these are restricted to the very old and unpopular 1.4- and 1.3-based versions. It is important to note that while Java has many vulnerabilities, their exposure is primarily a problem when Java is used as a client-side web technology. Many products contain their own embedded versions of Java, and these instances are generally not made available to the browser, and so do not expose the same threat surface as a typical standalone Java installation. Internally developed non-web applications also can use Java outside the browser. However, since Java poses such a significant risk when used as a client-side web technology, caution must be exercised to ensure that Java instances that are made available for such applications are not also made available to the browser.
Java’s favoured status among hackers Java was originally released with the slogan “write once, run anywhere,” which was intended to underscore its cross-platform capabilities. Over time, Java has become ubiquitous on endpoints, so ‘run anywhere’ can be interpreted as referring to its ubiquity. Even as fewer websites and web applications require Java in order to operate properly, the technology is pervasive on virtually every end-user system. For this reason, Java also has become a platform that is highly vulnerable to attack. A piece of evidence demonstrating Java’s 12
Network Security
favoured status among attackers is how frequently it is integrated into various exploit kits such as Blackhole, Cool and Redkit. These kits represent the evolution of publicly available scripted attacks into relatively mature, supported products that often are sold on the underground market. Exploit kits are typically used to implement browser-based attacks by deploying them on compromised or attacker-staged web servers, and include a variety of exploits for use against client systems. Because vulnerable versions of Java are so pervasive and severe, the inclusion of Java exploits in these kits provides a high probability of successful compromise. It is perhaps not well known outside the security research community that malicious Java code can target outdated instances of Java even after the most recent version of Java has been installed on an endpoint. Sometime during the Java 6 family of updates, the Java updaters began removing some older versions of Java. However, an installer for a major version of Java does not remove versions of Java from older major versions. The fact that older major versions of Java are not removed during installation of newer versions has led to continued high prevalence of very old and vulnerable versions of Java remaining on a high percentage of endpoints. Essentially, Java represents an extremely large surface area for potential attacks in many organisations. In spite of this, organisations continue to be behind the curve on patching
Java. Typically, it takes an organisation between three and nine months to apply Java patches due to the extensive quality assurance testing they need to conduct before applying each patch. Were it not for the fact that hackers have been paying close attention to Java vulnerabilities, this would be less of an issue. Earlier this year, Java vulnerabilities prompted US-CERT to encourage the public to disable Java unless it is necessary. However, disabling Java is not as easy for some organisations as it sounds. It’s similar to the fact that it’s easy for home users to upgrade their Windows OS overnight, but it often takes corporations years to plan for and implement such a move. This fact has led to products, such as the open-source JavaRa tool, whose sole purpose is to help users deal with the problem of identifying and removing old versions of Java. While these products will mitigate some percentage of attacks, many users will not understand the warning and may choose to allow the code to execute under the old vulnerable version. In addition, so-called ‘click bypass’ vulnerabilities often are discovered in Java, allowing attackers to prevent the mitigating interactive messages from ever being seen by the user.
“The relative ease of creating malware in Java, and the ability to construct it with only a modest amount of platformspecific code, may have aided the attackers” In July 2013, a vulnerability was found that affects Java major version 7 update 21, the newest version as of Bit9’s data collection, as well as earlier versions. This vulnerability allows for attackers to bypass the Java click-2-play security warning dialogue box without user interaction. According to Packet Storm, this means that attackers can still target an older version on an endpoint, without user notification. The latest version at the time of Bit9’s research, Java 7 Update 25, goes further and will not allow users to select older versions to run against. It remains to be seen if clickbypass vulnerabilities become more difficult to uncover, however.
April 2014
FEATURE
A history of Java-related attacks There are many examples of attacks involving Java that a simple web search will show. The following are some attacks that have unique and interesting aspects. In early 2012, trojan malware was discovered infecting Macs and creating a botnet of Mac-based endpoints. This malware was notable for being the largest scale threat to the Mac platform to that date, according to Macworld. The relative ease of creating malware in Java, and the ability to construct it with only a modest amount of platform-specific code, may have aided the attackers. Similarly, a cross-platform trojan called ‘Minecraft Hack Kit’, a password stealer, affected both Mac and Windows users. Another cross-platform trojan, Mal/ JavaJar-B, even attacked Linux systems as well as Mac and Windows. Another example of threats related to Java in the wild was identified in May 2013. This attack targeted a zeroday vulnerability in Internet Explorer. However, the first action taken by the malicious code, according to AlienVault Labs’ analysis, was to enumerate all of the Java versions on the affected endpoint. Quite likely this reconnaissance step was intended to ensure the ability to compromise the host again in the future if, for example, the zero-day vulnerability was patched via the Windows update mechanism. It also is interesting to note that the attackers apparently used code directly taken from the Java Deployment Toolkit.
How to reduce Java-related risks So, what can be done to reduce the likelihood of a Java-related attack? First, evaluate whether Java is necessary for your organisation. Many in the security community urge the widespread and complete removal of Java from all endpoints. This option is often difficult to implement in practice, however, because tools for managing Java in the enterprise are lacking. In addition, it is often challenging for organisations to fully assess the impact of removing Java in their environment.
April 2014
However, there is both anecdotal and quantitative evidence that some organisations are choosing to remove Java from their environments altogether, as many in the security industry have recommended. According to the collected data, some large organisations have successfully reduced the average number of installed Java instances per endpoint to as low as one instance per 50 endpoints (0.02 versions per endpoint).
“Consider using network security solutions such as those with layer 7 visibility to look for evidence of browser-based Java. You should also monitor for unexpected installation and use of Java in the environment” If removal is chosen, develop a plan. Consider tools that can block execution of software based on name or hash on the endpoint as a quick first step toward the eventual goal of removal. Use software management tools to remove instances of Java. In addition, close the loop – that is, audit the software in your enterprise to confirm Java’s removal. Finally, consider using network security solutions such as those with layer 7 visibility to look for evidence of browser-based Java. You should also monitor for unexpected installation and use of Java in the environment. However, there is no need to go overboard with controlling or removing Java. Many products contain a version of Java embedded that is not made available to the browser, and thus poses little risk of web-based infection. When using NIST data to find vulnerability information, keep in mind that software and vulnerabilities may not always be recorded in a consistent manner. Product names are not well normalised. For example, some vulnerabilities are reported under the product ‘Java’, while others (most in fact) are reported under the product ‘JRE’. Version strings in reports sometimes contain spaces where others do not (‘Update 19’ versus ‘Update19’, for example). The CPE names reflect these inconsistencies using corresponding redundant ‘Update_19’ and ‘Update19’ strings.
In addition, the change to the version format of Java introduced reporting inconsistencies, with some vulnerabilities being reported, for example, against ‘version 6 Update 10’, and some being reported against ‘version 1.6.0 Update 10’. Java ranks number 16 (as Sun/JRE) in the list of Top 50 Products By Total Number of ‘Distinct’ Vulnerabilities, with 397 vulnerabilities. However, if the data quality issues above were addressed, this number would far exceed 500 and put Java in the top 10.
Conclusion For the past 15 years or so, IT administrators have been under the misperception that updating Java would address its security issues. They have been told that to improve security, they should continuously and aggressively install Java updates on all of their endpoints. Unfortunately, installing is not the same as updating. Until very recently, those installations have failed to deliver the promised security upgrade because they have not removed older, highly vulnerable versions of Java they were intended to replace. As a result, most organisations have multiple versions of Java on their endpoints, including some that were released at the same time as Windows 95.
“Most organisations have no idea what’s running on their endpoints and servers – they lack visibility into those systems. And traditional security solutions, including anti-virus, can’t protect them from modern threats” Not only is Java widely installed in most enterprises, in most instances it is highly vulnerable. Java continues to be a required technology for many companies, but its ubiquity seems to be out of proportion with its current business use cases. Some enterprises appear to be choosing to remove Java from their environments, and the facts revealed in Bit9’s research underscore the rationale for doing so. Bit9’s data also seems to show the reasons behind Java’s new favoured status
Network Security
13
FEATURE among attackers. Many enterprises have so far been slow to respond appropriately to this trend, despite evidence that doing so would, for many, substantially reduce their exposure to today’s most common successful attacks. It’s not surprising that most companies are unaware of all the versions of Java on their systems. Most organisations have no idea what’s running on their endpoints and servers – they lack visibility into those systems. And traditional security solutions, including antivirus, can’t protect them from modern threats. While the industry appears to be making efforts to mitigate some of the issues that have brought us to where we are today, those efforts will have little impact on remediating the current situation. Traditional security solutions can’t necessarily protect organisations from all modern threats.
Recent high-profile attacks continue to demonstrate that enterprises should view Java as a major security risk. Enterprises can benefit from better characterising and understanding the applications running on the endpoints in their environment, so they can evaluate the risks to those endpoints and more effectively prioritise remediation efforts. Moving forward, real-time visibility and protection for endpoints and servers will be essential.
About the author Harry Sverdlove, Bit9’s chief technology officer, draws from two decades of application design and analysis with industryleading IT enterprises. He regularly publishes threat intelligence research, including: ‘Java Vulnerabilities Write Once, Pwn Anywhere’ (2013), ‘Pausing Google Play: More Than 100,000 Android Apps May
Pose Security Risks’ (2012) and ‘The Most Vulnerable Smartphones’ (2011). Prior to joining Bit9, Sverdlove was principal research scientist for McAfee, where he supervised the overall architecture of crawlers, spam detectors and link analysers. He joined McAfee through its 2006 acquisition of SiteAdvisor, where he was chief scientist and developed systems for testing, detecting and analysing any Windowsbased application. Prior to SiteAdvisor, Sverdlove ran his own consulting company specialising in Windows automation and spam detection. He also was director of engineering at Compuware Corporation (formerly NuMega Technologies). Prior to NuMega, Sverdlove was principal architect for Rational Software, where he designed the core automation engine behind Rational Robot. He earned a bachelor’s degree in electrical engineering from the Massachusetts Institute of Technology.
Unveiling the dark web Danny Bradbury The dark web is a secretive, anonymous place where shadowy users access hidden services. It can be used for good or bad – but can it be cracked? And if so, how? The media is littered with discussions of the deep web and the dark web, but they are different entities. The former consists of web pages accessible on the public Internet, but not via search engines such as Google. Search engines crawl the Internet using search bots that index data, these days using robots.txt files as guides that tell them what data to index, under the 1994 Robots Exclusion Standard.1,2 Web crawlers cannot index deep web content. It is usually accessible only when a user searches a specific database, meaning that there is no explicit link for it.3 The dark web, on the other hand, is often publicly available – you simply have to know how to find it, because it exists on an alternate layer of the Internet. This alternate layer is often constructed by a community that wants to preserve anonymity, autonomy, or perhaps an ideology. 14
Network Security
Such communities can use the dark web for a variety of activities, both good and bad. Dark webs have been used for criminal activities such as the distribution of child pornography, hacking rings, money laundering, and sales of weapons and drugs.4 However, they have also been used as tools to help citizens route around censorship measures enforced in non-democratic states, such as China.5
A tour of Tor One of the most commonly-used mechanisms for creating dark webs is Tor, a routing mechanism designed to preserve anonymity by creating an alternative mechanism to DNS for routing traffic. Tor uses a concept called onion routing, which was first created by the US Naval Research Laboratory.6
Danny Bradbury
Tor uses a selection of relay machines running freely available, open source software. The sender of a piece of traffic will find an entry point and choose a random routing path through a selection of relays to obfuscate their point of origin. Traffic routed along this path will be encrypted until it leaves the last relay, to be sent to a specific IP address on the public Internet. This means that the traffic will appear to have originated from the IP address of that last relay. Tor can also be used to host websites as ‘hidden services’ online. These services use seemingly incomprehensible names, with the suffix ‘.onion’. The names are derived from public keys provided from a key pair, provided by the hidden service. Unlike traditional DNS routing, the path to communication between a client and a Tor-based hidden service is not explicit. The system is designed to preserve the
April 2014