This week you will have seen from our twitter account, (@Onapsis) or other security news feeds like PacketStorm regarding the publication of information about six advisories discovered by the Onapsis Research Labs effecting SAP. In a past blog, Securing Your SAP Through Research, I talked about the importance and value of the security research we do here at Onapsis. Additionally, I have discussed the fact that we have seen automated, widespread attempts to compromise SAP systems as well as very targeted attacks and the implications of those attacks.
If you look at the latest six advisories released by the Onapsis Research Labs which are listed on our advisory page you will see they impact across a variety of SAP technologies that have very different delivery methods. There are three vulnerabilities effecting SAP HANA, two targeting the Extended Application Services (XS); one of which is XSS in the Administration Tool for SAP HANA XS and the third is an authentication bypass. A highlight for me was the discovery of a hardcoded user in SAP FI Manager Self-Service, which effects every installation of FI Manager.
It is very important that you stay informed by reading about the advisories we publish and also the monthly Security Notes releases by SAP and that you evaluate their relevance to your critical systems and the risk they represent to those critical systems.
SAP is a complex and ever changing system, whether because of changes introduced to your SAP implementation to better suit your business or applying Security Notes (Patches) to ensure that newly disclosed vulnerabilities are mitigated.
In order to provide a predictable and scheduled flow of vulnerability mitigation and security patches SAP releases their latest Security Notes information the second Tuesday of every month. Due to this regular disclosure of new security issues that could potentially weaken the security of SAP systems within an organization, it is highly recommended to carry out periodic assessments on a monthly basis in the least.
At Onapsis we are very concerned about not only our client’s SAP systems’ security but the state of SAP security in general, so, to assist SAP’s customers, we perform a detailed analysis of the monthly SAP Security Notes as soon as they are published. The goal of this effort is to provide SAP clients with detailed information about the newly released notes and vulnerabilities affecting their SAP systems and help guide their testing of these systems within their organization. Continue reading
Hi! Today I was reviewing some events generated for the Security Audit Log and noticed an interesting behavior.
For those who are not familiar with it, the Security Audit Log (SAL) allows SAP security administrators to keep track (via a log) of the activities performed in their SAP systems. In a future post we will discuss how to enable and configure this logging.
By default the SAL facility logs the “Terminal Name” which is either the Terminal Name (defined by the computer which performed the logged action) or the IP address of the computer that is the source of events. The IP address is only logged if the source computer does not transmit a Terminal Name with its communications.
This behavior can be abused by an attacker since filling the terminal name value in an RFC call is a task performed by the caller (the user’s machine). Having the ability to manipulate the “Terminal Name” means the attacker could try different attacks such as bruteforce attempts but have each transaction appear to come from a different terminal. Taken even further; the attacker could set an IP address (or cycle through a set of IP addresses) as the Terminal Name; meaning each request would appear to have originated from these IP addresses (as in the logs it is not possible to distinguish between an IP address that has been logged because no Terminal Name value was transmitted vs an IP addressed that has been logged as the Terminal Name).
By now I am sure you have seen the public posting with details and a how-to guide regarding an exploitable SAP vulnerability in a major organizations’ internet facing website. It is always disheartening to see a company exposed in this way. It is a cliché (though truth be told I tend to think clichés have an element of truth to them) but when I read about this type of event and the recent Target breach I look for the teachable moment or lessons I can learn. Good security is an ounce of prevention and a dash of luck, and the more you can learn about appropriate preventions the less luck you will need.
When thinking about this event I actually thought of five teachable elements I can use to provide support for my security approach and philosophy. I wanted to start a discussion about SAP and security, something which has only recently been discussed, and review the silent points from what has occurred thanks to the Full Disclosure posting and WooYun report from the Chinese hacker known as Finger.
This event touches on a couple important areas:
- Responsible disclosure
In the posting they cite the date 2013-11-21 as when they submitted a report to the vendor and 2014-01-05 as the date they published the details of the vulnerability and how to exploit it on NVIDIA’s servers, despite the vulnerability not having been addressed, due to a lack of a response. This is less than two months (during a busy holiday season) and it is unclear how many times they attempted to contact the security team. While I agree that it is important to get vulnerability information public so issues can be addressed I think it is more important to do so responsibly. Typically attackers/cyber criminals have less change control processes to go through and can weaponize and take advantage of this information long before organizations have been able to test and apply the remediation across their environment. In fact Mariano Nunez, Onapsis CEO, has said “It is critical when you have information that could cause harm to companies effected that you make best efforts to ensure that information is communicated to those companies along with the information needed to remediate those issues before making that information publicly known.”
In the closing stages of Victor Hugo’s Les Misérables the chief character, Jean Valjean, while carrying another key character seeks to evade the authorities. He does so by traveling through the sewers of Paris, while the search for him and other rebels is focused on the streets above him. In this way Valjean is able to use a critical but commonly forgotten part of the maintenance infrastructure of the city against the city itself.
As I reviewed the research into the Transport Management System (TMS) carried out by the world renowned Research Labs here at Onapsis the parallels of how organizations ignore their Transport Management System when considering the risk and attack surface of their SAP systems and the method employed by Valjean to evade capture were very striking to me. In both cases we have a system that has equal access to all points on the network, from Dev to QA and Productive systems.
The research team has boiled all the relevant risk information and best practices to secure the Transport Management System in this SAP Security In-Depth (SSID) publication. Understanding how to secure your TMS becomes critical when you understand the interconnected nature of a Transport Domain, and the level of access an attacker could gain to the entire landscape if they are able to get a foothold to just one system within the Transport Domain.
This SSID publication is just one in an ongoing series of educational publications researched and produced by Onapsis; all with the goal of providing SAP customers with the information they need to both understand the risks inherent in certain components and the best practices by which to manage these risks.