As with the second Tuesday of every month, today SAP released its monthly Security Notes to keep your SAP infrastructure secure. This month, SAP published 18 new security notes, and released 11 security notes that were published after May 9th (last patch tuesday), totaling 29 notes that will be analyzed in this post. For the second month in a row there aren’t any notes tagged as Hot News; the most critical risk category that SAP has catalogued for newly discovered vulnerabilities.

In this month’s SAP Security Notes, it’s noticeable that the priority of the majority of security notes are higher compared to previous month.

Today SAP published 23 Security Notes, making a total of 32 notes since last second Tuesday of November, considering several notes that were published outside of the normal publishing schedule. As with every month, the Onapsis Research Labs have an impact on how SAP Security evolves. This month, 6 SAP Security Notes were reported to SAP by our researchers Sergio Abraham, Nahuel Sanchez and Emiliano Fausto (all of them recognized in SAP Webpage).

Today, Onapsis Research Labs released 15 advisories related to SAP HANA and some building components, as well as Internal Communication Channels (also known as TREXNet). This is the first launch of more than 40 advisories we will be publishing in the following month including several vulnerabilities we have discovered in business critical application such as SAP and Oracle. In this blogpost, we'll analyze two different vulnerabilities affecting SAP HANA.

Not too long ago I published a blog which discussed operationalizing your SAP cybersecurity strategy. In that post I discussed the confusion around division of responsibilities, who should own SAP security, and how SAP security gets operationalized within the organization as this is a common problem my team and I have noticed across organizations.

Recently, I published a post on the SAP Security Gap. This post discussed the present disconnect between security professionals and business executives on the vulnerability of their SAP systems. With SAP Cyber-Security continuing to be a topic of concern making mainstream headlines, it is critical that organizations begin to think about this notion in more detail if they wish to truly secure their enterprise applications such as SAP or Oracle.

It feels like déjà vu all over again!

Back in the early 2000’s, I was involved in the widely publicized, EMC Business Continuity survey – which indicated a very large disparity between IT and business executives regarding the vulnerability of their business-critical data. Fast forward to today and I’m seeing a very similar scenario play out again. But this time, it has to do with the vulnerability of an organization’s business-critical SAP systems.

Hi! In this post I want to summarize you another little-known behavior of SAP Gateway, which is its ability to act as a proxy. Basically when we want to perform an RFC connection two parameters are specified: the IP of the gateway and the IP of the application server. But wait... Is not the gateway always located in the same host than the application server? Yes, usually... but there are some specific cases where you need to use these parameters with different values.

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.".

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.