Java—love it or hate it, it isn’t going anywhere. Despite being hailed as “the biggest vulnerability for US computers” by CSO magazine, it’s currently back in pole position as the most popular developer language on the market. Of course, this has mostly to do with the rise of Android, as traditional Java web apps have been steadily losing market share to newer languages and stacks over the years. However, Java is still popular with developers and cyber attackers alike: it’s well understood, extensively documented, and unfortunately highly exploitable.
And ubiquitous. According to Oracle:
- 97% of Enterprise Desktops Run Java
- 89% of Desktops (or Computers) in the U.S. Run Java
- There are 9 Million Java Developers Worldwide
- Java is the #1 Choice for Developers
- Java is the #1 Development Platform
- 3 Billion Mobile Phones Run Java
- 100% of Blu-Ray Disc Players Ship with Java
- There are 5 Billion Java Cards in Use
- 125 million TV devices run Java
- 5 of the Top 5 OEMs Ship Java ME.
The following are 10 critical Oracle Java security vulnerabilities and how to fix them.
Table of contents
- SQL Injection
- Brute Force
- Data Exfiltration
- Compromised Default Passwords
- Denial of Service
- Malicious Applets
- Problems With Sandbox and Security Manager
1. SQL Injection
In SQL injection attacks, malicious SQL statements are entered into a web form field causing nefarious actions to be run on the backend database. Web apps should therefore be run with the minimum privileges necessary for supporting its functions, and should not connect to the database(s) with the default database administrator account.
2. Brute Force
Password crackers like John the Ripper can methodically test a single character at a time against a password file until the correct values are generated. This makes web application front-ends especially vulnerable, as brute force attacks can be carried out repeatedly by remote attackers. For example, Oracle solutions will typically provide management interfaces such as the Oracle Java Web Console and Oracle Database Enterprise Manager for easy web-based management. Tools like OraBrute can be used to test the strength of Oracle passwords to bolster against brute force attacks.
3. Data Exfiltration
Data Exfiltration involves the unauthorized transfer of data or sensitive information from a targeted database. In many cases, Oracle Java’s own tools are used to carry out these exploits. For example, Oracle possesses a package named UTL_TCP that can make connections to additional servers. In data exfiltration, an attacker will use UTL_TCP to send a data stream from a server to a remote host to capture privileged data. Additionally, the DBMS_OBFUSCATION_TOOLKIT and DBMS_CRYPTO package can be used by hackers to hide the contents of a hijacked data stream. To mitigate data exfiltration, mechanisms should be put in place to monitor and analyze incoming/outgoing data packets—this would typically be an IDS/IDPS or similar security solution.
4. Compromised Default Passwords
Oracle’s default passwords are widely known and should be changed immediately upon installation (and routinely thereafter). Additionally, Oracle can be configured to accept complex database passwords only, requiring users to create strings that can provide reasonable protection against intruders. This list of default Oracle passwords created and maintained by Oracle security expert Pete Finnegan is indispensable for determining which default passwords need to be changed.
5. Denial of Service
Java in particular possesses a myriad of Denial-of-Service (DoS)-related vulnerabilities that can allow an attacker to interrupt or suspend a web application’s service. Malicious Java servlets can often initiate remote DoS attacks or directly crash the server—for this reason, untrusted clients should be restricted from uploading servlets.
6. Malicious Applets
Safe and trusted applets are signed and validated for their authenticity; unsigned applets typically spell trouble and should be disabled. However, various exploits have been used in the past to create self-signing certificates for tricking users into running harmful applets. Saved applets should be analyzed and removed/blocked if suspicious, and unsigned applets should be avoided outright. Additionally, older instances of Java should be updated, as later versions incorporate more stringent applet security measures.
7. Problems With Sandbox and Security Manager
Vulnerabilities in Oracle Java’s sandboxing mechanism can allow untrusted bytecode to circumvent the restrictions imposed by the security manager. For example, a vulnerability in the Reflection API allows attackers to achieve a complete Java security sandbox bypass on a target system. Staying on top of Java updates is key to remediating flaws in the sandboxing, security manager, and other critical Java components.
As of this writing, Oracle Java has 413 documented vulnerabilities per the CVE database. While updating Java on a machine may be an easy fix, fixing all vulnerable Java instances across environments is another story. Remediation requires visibility as a precursor—in order to bolster Java, you must know where it resides, what package versions are installed, what dependencies exist, and so forth. To this end, ScriptRock can scan for and identify vulnerabilities in highly disparate environments, ensuring that exploitable versions of Java are always updated and free from security gaps.