Each year companies dedicate millions of dollars for IT and security budgets to prevent cyber security breaches. However, these budgets are only effective if part of the budget is allocated to preventing new and advanced threats, closing security gaps in your business infrastructure and monitoring the systems for intrusions and malicious activities.
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).
Last week a new vulnerability was reported, affecting the GNU C library (glibc). This vulnerability affects a wide range of Linux distributions, among which are some supported by SAP products as stated in SAP Note 171356.
It's important to understand that even though this vulnerability does not directly affect any SAP application, it affects a lower layer, the operating system, allowing any application to potentially use the vulnerable function.
The world of profile parameters in SAP is vast and complicated as a user can change the entire behavior of the SAP by modifying some of these parameters. But just when we thought that we knew everything about profile parameters, we recently discovered something very interesting. SAP Security Note 1979454 is related to a vulnerability in transaction SHDB (a very sensitive transaction since it’s used to create recordings) which introduced a new profile parameter called “bdc/shdb/auth_check”.
Enforcing a new password policy on an SAP system isn't always an easy task. Most of the existing SAP implementations have been running in production for many years, and since that moment SAP password-related profile parameters evolved to provide enhanced security based on the complex and always changing compliance requirements (SOX, PCI, HIPAA, etc). The problem is, basically, the fact that by default user passwords are compliant to the policies only when created/changed. If the user is never forced to change the password they could potentially have ever-lasting non-compliant passwords.