In January, Oracle published a Critical Patch Update (CPU) with 19 vulnerabilities affecting JAVA SE (among other products): http://www.oracle.com/technetwork/topics/security/cpujan2015-1972971.html#AppendixJAVA
SAP has its own specific JAVA virtual machine implementation called SAPJVM, which according to SAP documentation: “…is derived from Sun’s HotSpot VM and JDK implementation … the SAP JVM is only targeting server-side applications. Certain features related to client environments are intentionally omitted or are not supported for general use.”.
This information could be important to identify whether or not the vulnerabilities are affecting the SAP JVM because only 4 out of the 19 are affecting the server-side functionality of the Oracle JVM: CVE-2015-0383, CVE-2015-0410, CVE-2014-3566 and CVE-2014-6593. However, that information is not conclusive.
As a company, Onapsis is focused on the security of business-critical applications such as SAP and Oracle. While our focus has been on SAP applications, we have also been actively researching, identifying and reporting critical vulnerabilities facing Oracle business applications. In this sense, Oracle is different from SAP, specifically in the way and timing that security patches are released and available to end users.
In this post, I will go through an analysis of Oracle’s January 2015 Critical Patch Update (aka CPU). The goal is to provide Oracle customers with detailed information about the newly released vulnerabilities affecting their business critical applications, and to help them to better understand and prioritize the testing for vulnerabilities on these systems within their organization.
In January 2015, Oracle published 169 vulnerabilities affecting 48 different Oracle products. Oracle uses the Common Vulnerabilities and Exposures standard (CVE) to uniquely identify the vulnerability and Common Vulnerability Scoring System V2 (CVSS) to measure the risk implied by the vulnerability in terms of different aspects such as exploitability, complexity and impact, to name a few.
An important aspect of this month’s CPU is the fact that more than 59% of these vulnerabilities are affecting business-critical applications. This means that companies have to be aware of these vulnerabilities and take immediate actions to mitigate the risks implied by them.
Hello! Today’s post can be considered as a appendix to our previous post. We will learn how to validate the strength of SAP passwords by trying to crack them. We’ll focus on the password hashes coming from the SAP JAVA Application Server.
The JAVA Application server stores the passwords in the form of hashes encoded in BASE64. The hash algorithm used is salted SHA-1, also known as SSHA1 .
SAP JAVA “stack” password hashes are stored in a database table called UME_STRINGS. The JAVA password hashes can be filtered by the “attr” field (attr = ‘j_password’). We can get the user name along with its corresponding hash by executing the following SQL query:
SELECT pid, val FROM UME_STRINGS WHERE attr = 'j_password'