Wednesday, 16 January 2013

Java Vulnerability

The security patches, issued by Oracle, correct Java vulnerabilities that have lingered in Web browsers. Two Java security vulnerabilities that can affect Java used within popular Web browsers received emergency patches Jan. 13 from Oracle to prevent unsuspecting users from being affected by malicious processes from attacking Websites.

In a weekend post on The Oracle Software Security Assurance Blog, spokesman Eric P. Maurice wrote that the company released Security Alert CVE-2012-0422 to fix two vulnerabilities in the Java code. A fix for an older issue, CVE-2012-3174, was also included.

"These vulnerabilities do not affect Java on servers, Java desktop applications or embedded Java," Maurice wrote. "These vulnerabilities, which only affect Oracle Java 7 versions, are both remotely exploitable without authentication and have received a CVSS Base Score of 10.0," meaning they have the highest severity scores on the Common Vulnerability Scoring System (CVSS) scale used by the National Vulnerability Database, which is maintained by the U.S. Department of Homeland Security. "Oracle recommends that this security alert be applied as soon as possible because these issues may be exploited 'in the wild' and some exploits are available in various hacking tools."

For either vulnerability, a successful attack on users' computers must "trick an unsuspecting user into browsing a malicious Website," Maurice wrote. "The execution of the malicious applet within the browser of the unsuspecting users then allows the attacker to execute arbitrary code in the vulnerable system. These vulnerabilities are applicable only to Java in Web browsers because they are exploitable through malicious browser applets."

As part of the security alert, Oracle is also switching Java security settings to "high" by default, Maurice wrote. "The high security setting requires users to expressly authorize the execution of applets which are either unsigned or are self-signed," he wrote. "As a result, unsuspecting users visiting malicious Websites will be notified before an applet is run and will gain the ability to deny the execution of the potentially malicious applet."

If users don't patch their Java code immediately, they can also disable Java in their Web browsers by going through the Java Control panel on their computers, he wrote.

"These vulnerabilities may be remotely exploitable without authentication, i.e., they may be exploited over a network without the need for a username and password," according to the security alert. "To be successfully exploited, an unsuspecting user running an affected release in a browser will need to visit a malicious Web page that leverages these vulnerabilities. Successful exploits can impact the availability, integrity and confidentiality of the user's system."

Both vulnerabilities are found in the Java Runtime Environment component of Oracle Java SE (subcomponent: Libraries), according to Oracle. "Supported versions that are affected are 7 Update 10 and before. Easily exploitable vulnerability allows successful unauthenticated network attacks via multiple protocols. Successful attack of this vulnerability can result in unauthorized operating system takeover including arbitrary code execution."

Mozilla, the organizers of the Firefox Web browser, posted information Jan. 11 on the Mozilla Security Blog to advise users that due to the recent vulnerabilities, Firefox will not automatically load the Java applet for users. Instead, users will have to overrule Firefox on their own to use the Java applet through the "Click to Play" safeguards built into Firefox since last fall, according to the post by Michael Coates, Mozilla's director of security assurance.

Click to Play "ensures that the Java plugin will not load unless a user specifically clicks to enable the plugin," Coates wrote. "This protects users against drive-by exploitation, one of the most common exploit techniques used to compromise vulnerable users. Click To Play also allows users to enable the Java plugin on a per-site basis if they absolutely need the Java plugin for the site."

The Click to Play feature has been activated by Mozilla for recent versions of Java on all platforms (Java 7u9, 7u10, 6u37, 6u38), he wrote. "Firefox users with older versions of Java are already protected by existing plugin blocking or Click To Play defenses."

On Jan. 11, security experts were again calling for computer users to disable the Java Web browser plugin and uninstall the software on their systems, following the discovery of a zero-day vulnerability in the latest version of the Java Runtime Environment.

Information about the vulnerability emerged Dec. 10, after a security professional discovered an exploit using the security hole to compromise systems. The vulnerability, which appears to only affect Java Runtime Environment (JRE) 1.7 and not prior versions, had not previously been known but appears to be similar to other Java security issues found in August 2012.

A security researcher finds that seven exploit kits have added an attack for a previously unreported flaw in the latest version of the Java Runtime Environment.
Security experts are again calling for users to disable the Java browser plug-in and uninstall the software on their systems, following the discovery of a zero-day vulnerability in the latest version of the Java Runtime Environment.

Information about the vulnerability emerged Dec. 10, after a security professional discovered an exploit using the security hole to compromise systems. The vulnerability, which appears to only affect Java Runtime Environment (JRE) 1.7 and not prior versions, had not previously been known but appears to be similar to other Java security issues found in August 2012, said Jaime Blasco, labs manager at security-monitoring provider AlienVault.

The vulnerability allows a piece of Java code to break out, or escape, from the protected software container, or sandbox, that is a critical part of Java's security model, said Blasco, who had verified that the exploit worked.

"The most important thing about this is that it is a sandbox escape, not a memory exploitation or something similar, so most of the mitigations are not effective," he said.

The security professional who published details about the exploit, France-based security manager Charlie Hurel, worried that remaining quiet about the issue could lead to a large number of compromises.

Attacks against ICS industrial Control System on the rise

Industrial control system (ICS) It is a general term that encompasses several types of control systems used in industrial production, including supervisory control and data acquisition (SCADA) systems, distributed control systems (DCS), and other smaller control system configurations such as skid-mounted programmable logic controllers (PLC) often found in the industrial sectors and critical infrastructures.

ICSs are typically used in industries such as electrical, water, oil, gas and data. Based on information received from remote stations, automated or operator-driven supervisory commands can be pushed to remote station control devices, which are often referred to as field devices. Field devices control local operations such as opening and closing valves and breakers, collecting data from sensor systems, and monitoring the local environment for alarm conditions.

Industrial control system technology has evolved over the decades. DCS systems generally refer to the particular functional distributed control system design that exist in industrial process plants (e.g., oil and gas, refining, chemical, pharmaceutical, some food and beverage, water and wastewater, pulp and paper, utility power, mining, metals). The DCS concept came about from a need to gather data and control the systems on a large campus in real time on high-bandwidth, low-latency data networks. It is common for loop controls to extend all the way to the top level controllers in a DCS, as everything works in real time. These systems evolved from a need to extend pneumatic control systems beyond just a small cell area of a refinery.

The PLC (programmable logic controller) evolved out of a need to replace racks of relays in ladder form. The latter were not particularly reliable, were difficult to rewire, and were difficult to diagnose. PLC control tends to be used in very regular, high-speed binary controls, such as controlling a high-speed printing press. Originally, PLC equipment did not have remote I/O racks, and many couldn't even perform more than rudimentary analog controls.

SCADA's history is rooted in distribution applications, such as power, natural gas, and water pipelines, where there is a need to gather remote data through potentially unreliable or intermittent low-bandwidth/high-latency links. SCADA systems use open-loop control with sites that are widely separated geographically. A SCADA system uses RTUs (remote terminal units, also referred to as remote telemetry units) to send supervisory data back to a control center. Most RTU systems always did have some limited capacity to handle local controls while the master station is not available. However, over the years RTU systems have grown more and more capable of handling local controls.

The boundaries between these system definitions are blurring as time goes on. The technical limits that drove the designs of these various systems are no longer as much of an issue. Many PLC platforms can now perform quite well as a small DCS, using remote I/O and are sufficiently reliable that some SCADA systems actually manage closed loop control over long distances. With the increasing speed of today's processors, many DCS products have a full line of PLC-like subsystems that weren't offered when they were initially developed.

This led to the concept of a PAC (programmable automation controller or process automation controller), that is an amalgamation of these three concepts. Time and the market will determine whether this can simplify some of the terminology and confusion that surrounds these concepts today.

 In 2012, energy, water and commercial control systems faced numerous attacks, including the use of a search engine to find thousands of exposed systems.
Industrial control systems came under increasing scrutiny and attack in 2012, with almost 200 documented incidents, according to a report released last week by a component of the U.S. Department of Homeland Security.

Energy firms accounted for more than 40 percent of the 198 incidents reviewed by the Industrial Control Systems (ICS) Cyber Emergency Response Team (CERT), and water utilities took a distant second place with 15 percent of the incidents. While some of the cases were caused by security researchers using the Sentient Hyper-Optimized Data Access Network (SHODAN), a regularly updated directory of ports, to find exposed industrial control systems, the majority were serious breaches, the report stated.

The group took part in responding to almost two dozen attacks on oil and natural gas firms, discovering that sensitive information on the operations of the supervisory control and data analysis (SCADA) systems had been accessed by the attackers.

"Analysis of the targeted systems indicated that information pertaining to the ICS/SCADA environment, including data that could facilitate remote unauthorized operations, was exfiltrated," the report stated.

Researchers and security professionals have focused on threats to industrial control systems and critical infrastructure for nearly a decade. However, the Stuxnet attack on Iranian uranium-processing equipment galvanized the critical-infrastructure industries into taking such threats seriously.

Yet change has come slowly: A year ago, researchers found that systems that use SCADA, an architecture for networked control systems, were still widely vulnerable. In November 2012, two rival vulnerability research firms underscored the issue by finding almost four dozen vulnerabilities in major SCADA products.

Such vulnerabilities seem to be the rule among industrial control products. ICS-CERT coordinated with more than 55 industrial-control system makers to report 171 vulnerabilities. The issues ranged from buffer overflows to input validation issues to cross-site scripting attacks. Products including hard-coded passwords accounted for seven of the security issues, the ICS-CERT report stated.

The group increased the pressure on the suppliers to fix their products' security failings in a timely manner, allowing ICS-CERT to publish details of a partic
ular vulnerability 45 days after notifying the vendor of the issue.

Suppliers were not alone in exposing security problems. One researcher using the SHODAN search engine to find Internet-accessible industrial control systems discovered about 20,000 systems accessible via the Internet.

"A large portion of the Internet facing devices belonged to state and local government organizations, while others were based in foreign countries," the ICS-CERT report stated. "(We) worked with partners as well as 63 foreign CERTs in the effort to notify the identified control system owners and operators that their control systems/devices were exposed on the Internet."

The ICS-CERT noted six incidents involving the nuclear sector but stressed that the group was not aware of any network breaches.