In my previous post I talked about the discovery of targeted malware embedded in physical scanners that were sold to shipping and logistics companies. Once operational the malware searched the victim’s network for ERP systems, compromised them (from the report it would appear all systems were compromised; and based on our own experience that has been the case in our engagements) and coped the data from these systems back to command and control servers, reportedly based in China.
It is tempting to think that this is an isolated problem only specific to one industry, but the reality is all businesses have hardware attached to their network that runs or has access to their critical systems and infrastructure. Counterfeit equipment is a long standing problem, with these fakes being hard to detect from the real thing. With the practice of the hardware being assembled by one company and the firmware being produced by another there is even more room for malicious software or instructions being added to printers, switches, routers and other equipment that exists in almost every network today.
Picture someone walking around a section of your business and simply scanning your business critical data, financial records and other ERP information away. It sounds like something out of Star Trek, but in a report published by Antone Gonsalves on CSO Online this has already happened to at least half a dozen large European and US Companies.
What happened? These companies all bought scanners from the same Chinese company for use in their shipping departments. These scanners were later discovered to have malware installed on them and when the scanners where connected into the businesses network and operated the malware was activated. This targeted malware, dubbed Zombie Zero, consisted of the three stage attack.
Stage one had the scanner look for and try to compromise any server with the word ‘finance’ in the host name. This searching and compromising activity would continue until the malware discovered and compromised the host, which each time was an ERP system. At this point stage two would begin.
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
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.
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.
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.
There has been a lot of attention in the news recently about vulnerabilities in SAProuter and how these vulnerabilities could be leveraged. The news spun out of a report that a piece of malware was actively learning about SAP systems known to any PC the malware infected. We wrote about this malware and the possible implications in a recent blog post; but the summary is it seems that the professional bad guy community is starting to take an interest in SAP.
So what is the SAProuter? It is a lot like the name suggests; an application produced by SAP which facilitates, logs (if enabled) and filters communications and network connections between different SAP systems, or between a SAP system and other networks or resources. However it is not a gateway/firewall technology; it only filters communications if the clients are configured to send their communication to the router; and not directly to the end point.
Because of this it should be used in conjunction with a firewall; or else a user who the SAProuter is configured to deny access to a specific backend SAP system could simply manually reconfigure their SAP client to attempt to connect directly with the sensitive SAP systems and start interacting with them directly; bypassing all the ACLs and controls in the SAProuter. A firewall is required to block those direct connections and only allow users to access SAP systems via SAProuter; thus allowing the SAProuter’s rules to be enforced (and connections to be logged).
When I talk to CISOs and other business leaders who are responsible for critical applications that rely on SAP a common question I get is how I would quantify the threat to their SAP systems. We talk about stories that have been shared with them by their colleagues, and the importance and value of following best practices. This morning I have been sharing with them an article showing some apparent reconnaissance activities being taken to discover deployed SAP systems.
The article describes a newly discovered Trojan that primarily targets gaining access to victims online banking accounts. What this malware does that is setting of alarm bells for everyone who is responsible for SAP systems is it analyses each machine the malware runs on to determine if that end user computer is used to communicate with SAP systems. This information is then passed back to the owners of the malware.
So what kind of information are we talking about? A PC with a SAP client installed will have configuration information for that client stored locally. This will contain at least the IP address of the SAP servers that the client connects to. If these clients are configured to login automatically those credentials are obtainable; if not then it is a simple matter to hook the application and capture the password the next time the user logs in.
Now, for those people who are itching to tell me that they don’t care is an external attacker learns the IP address of their internal SAP systems because they cannot reach these systems I would refer you to this blog post; which debunks the myth of “internal” systems. I’d also point out the reason why the attacker is able to learn the IP addresses of your internal SAP systems if because they have taken control of an internal machine on your network already. Of course if you think I am wrong then you are gambling with the safety and soundness of your SAP systems; which is a high stakes game to play.
Different software companies take different approaches to the security of their products after they have been sold to their customers. Some would prefer it if previously released software had no security research attention paid to it where as others take a more realistic and therefore positive (to their customers) attitude. This positive approach is not only to provide their customers with security guidance for each component but to also release vulnerability information to them along with patches or remediation information in a regular and predictable way that allows their customers to anticipate and plan for application of remediation.
SAP falls into the positive camp; as well as releasing vulnerability information for HANA and other SAP components on the second Tuesday of every month they also publish security guidance for best practices to securely install and maintain HANA deployments.
Now, you could try and argue that the ultimate best practice is for SAP to release completely perfect and secure code and products; and to not allow their customers to reconfigure it so it can run in an insecure manor. That and unicorn hamburgers would be fantastic; but I am not holding my breath for either to present itself to me any time soon…