SAP takes their responsibility to help their customers be secure seriously. They have released the SAP HANA Security Guide to help their customers deploy HANA in a secure way. SAP Security Guides are nothing new, they help define a minimum benchmark of a securely deployed SAP system.
For those tasked with assessing a SAP HANA (or ABAP) system and determining the complete risk the system represents to the business, they know that just performing a SoD check is not enough (and for those that don’t the list of security guides from SAP and this blog should help explain why). SAP states that “[these] security guides provide information that is relevant for all lifecycle phases”. When auditing or assessing these SAP systems, and HANA in particular a logical place to start is to compare the system against SAP’s own security recommendations and benchmarks for HANA.
The SAP HANA Security Guide provides those minimum security recommendations. At 102 pages, the guide provides a lot of detailed information about the SAP HANA solution, common deployment scenarios and an overview of the communication paths used within a SAP HANA deployment and how they should be secured. This is further broken out into the following areas:
- SAP HANA User and Role Management
- SAP HANA Authentication and Single-Sign On
- SAP HANA Authorization
- SAP HANA Data Storage Security
- Auditing Activity in SAP HANA Systems
- Security Risks of Trace and Dump Files
- SAP HANA Additional Components
- Security for SAP HANA Data Provisioning Technologies
- Security Reference Information
Since the Sarbanes-Oxley (SOX) Act passed in 2002, an organizations’ emphasis on their internal controls and risk management has increased significantly. United States Federal Law set new standards for all publicly traded US company’s boards, management and for public accounting firms. As a result of SOX, top management of these companies must individually certify the accuracy of their reported financial information.
Different software has been developed in order to meet these new requirements. One of the most famous is the module designed by SAP, known as SAP GRC Access Control. The driving idea behind this Security module is to ensure segregation of duties (SoD), by defining an SoD Matrix and allowing risk analysis reports to be periodically generated. It also helps organizations detect if they have Super User accounts in Production Systems, a finding usually flagged during any traditional audit as this violation implies there is no controlled environment for the use of emergency users. The SAP GRC Access Control module ties into workflows for creating new users or modifying existing users, allowing the workflow to interact with the SoD Matrix and alerting administrators if they are granting accesses that would represent an SoD conflict as they grant that access. Finally, the design and configuration of users’ roles can be broken out into several approval steps. This means that risk analysis can also be made at the role level.
There has been a lot of discussion last week about CVE-2014-0160, also known as the Heartbleed vulnerability. For those unfamiliar with the vulnerability I recommend heartbleed.com and, for a light hearted explanation, XKCD. Along with impacting a good chunk of the Internet it has also taken a toll on a number of products including those from Cisco, VMWare, and Oracle to name just a few. As you can imagine we have been watching the issue pretty closely and performing testing in our lab in order to better understand the impact, if any to SAP and its customers. Here is our current understanding on the status of some of SAP’s products:
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).
In the latest Notes Tuesday Onapsis was credited with discovering and reporting almost half (10 out of 23) of the vulnerabilities addressed by SAP (or alternatively three quarters or one third, depending on how you do the math: there were only 13 Notes that were attributed to third party security researchers of which Onapsis discovered 10. And SAP released 23 security notes on Notes Tuesday; but had also released an additional 10 notes since the last patch Tuesday; bringing the total released during that period to 33).
Having received a number of messages of appreciation and additional questions about the work done by Onapsis Labs to find so many of the vulnerabilities remediated by SAP this month, I thought people should know about the effort and work done to discover and responsibly report these risks every month.
So how do we find these issues in the first place? There are a number of possible ways. It could be a result of a number of activities that the Onapsis Research Labs team or Professional Services team perform. It might be we discover the vulnerability during a services engagement for a client; or as the output from a dedicated bug hunting activity (where our labs team will take a deep dive with SAP technology and attempt to find previously unknown issues in SAP modules and applications) or they are born out of ideas that lead to “What if” and other brain storming conversations that take place internally.
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 system 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 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.
This month 33 Security Notes were published by SAP. Of these 33 notes, Onapsis Research Labs reported 10 of the underlying issues that have been addressed by SAP:
- 1791081 by Sergio Abraham
- 1768049 by Sergio Abraham
- 1920323 by Sergio Abraham
- 1915873 by Sergio Abraham
- 1914777 by Sergio Abraham
- 1911174 by Sergio Abraham
- 1795463 by Sergio Abraham
- 1789569 by Sergio Abraham
- 1738965 by Sergio Abraham
- 1939334 by Juan Pablo Perez Etchegoyen, Jordan Santarsieri and Pablo Muller.
As means of a background, I have been in the security field, specifically the pro-active testing (penetration testing) side of security for over a decade. As part of my role I would present at public and private conferences, helping to educate organizations about the benefits of pen testing or helping to educate pen testing teams about the latest techniques.
I say all of this in order to communicate that I would grade myself as having an above average knowledge of the security space and significant familiarity with commonly used terms in the industry. So when I recently took a product manager roles at Onapsis and was told I would have to learn about SAP and the security and risk implications around SAP in the enterprise I smiled and thought “well, I guess I know what I am doing the first couple of days”. As it turns out SAP is a world unto itself, with a lot of history and complexity.
This blog is the third in a series that documents the self-education that I have been undertaking as I learn about SAP, assessing the security of a SAP system and then implementing secure practices.
This blog builds on a webcast I was fortunate to take part in. My colleague Sergio Abraham has spent a considerable amount of time research RFC Destinations, the common ways they are configured and how various SAP components install RFC Destinations in order to function. I recommend in addition to this blog you view the webcast recording here and the corresponding question and answer session it generated here.
SAP is a complex and ever evolving implementation; whether that is through changes introduced to your SAP implementation to better serve the business or the newly disclosed vulnerabilities targeting SAP products. In order to provide a predictable and scheduled flow of security, vulnerability and mitigation information SAP releases their latest Notes and security information regarding their products on the second Tuesday of every month. Because of this regular disclosure of new issues that could potentially weaken an organizations security SAP security assessments should be carried out on a regular basis. In order to ensure our customers are testing for all the published vulnerabilities in their SAP implementations we perform a detailed analysis of the monthly SAP Security Notes as soon as they are published.
CVSS distribution for the Security Notes released in January 2014
In January SAP released a total of 34 Security Notes, of those Notes, six were the result of reports made to SAP by the Onapsis Research Labs.
Notes 1918333, 1917381 and 1894049 were reported by Nahuel D. Sánchez, 1922547 and 1910914 by Jordan Santarsieri and note 1931399 by Willis Vandevanter all from Onapsis Research Labs.
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.”
One of the features of BusinessObjects Launch Pad (formerly InfoView) is the ability to send a file to another user. By default, there are no restrictions on the types of files that can be sent. This can be handy on a Penetration Test when you might have Guest privileges and like to target specific users (e.g. the Administrator Group).
1. Login to the InfoView application. Go to Documents tab, New > Local Document. Make sure to add a convincing description. 2. Right click on the file and go to Send > ‘BI Inbox’ . Select who the file will be sent to. Notice, in the screenshot below we have selected the Administrators group. The ‘Use Specific Name’ field at the bottom can be used to rename the file. In this case we rename the file to ImportantDocument.zip (a similarly agnostic file type). In the third screenshot we show the file arriving with the title ImportantDocument.zip (rather than SuperSweetPayload.exe as it was originally named).
A Note on Defense:
An administrator can limit the types of files that can be uploaded using the CMC. In particular, limit the “Agnostic” file type to prevent executables.