Chinese most likely using one of top three most common SAP exploits, as identified by Onapsis, to compromise US agencies

The Hill publication reported on November 3, 2014 that Chinese hackers roamed around unnoticed for months inside the network of USIS, is the biggest commercial provider of background investigations to the federal U.S. government.[1] In fact, two of the company’s biggest customers were the Department of Homeland Security (DHS) and the Office of Personnel Management (OPM).

The company performs several thousands of secret background investigations per month; however, this fact became noticed by the public after two renowned cases: the background investigations on Aaron Alexis (Washington Navy Yard shooter) and Edward Snowden (for disclosing top secret materials from the National Security Agency).

On August 6th, 2014, USIS published a press release stating they were hacked by an external entity, and the suspicion that it was a state-sponsored attack (


Much has been said about this breach, especially the consequence of suspending government contracts with federal agencies (DHS, OPM), causing USIS the loss of millions of dollars and laying off thousands of investigators [1]. Initially, the date and scope of the attack, as well as the exposed information, were not specified. However it was later confirmed that the internal records of at least 25,000 employees of Department of Homeland Security as well as undercover investigators were exposed during this attack, including Social Security numbers, education and criminal history, birth dates along with marital information, other relatives and friends, names and addresses [2].

After the breach, USIS hired the digital forensics company Stroz Friedberg to perform the investigation. On September 2014, a letter from Stroz read: “The initial attack vector was a vulnerability in an application server, housed in a connected, but separate network, managed by a third party not affiliated with USIS.”

Earlier this week, this attack became noticed again when Nextgov [3] published some details about the report produced by the forensics firm on December 2014.

The original report claimed “Forensic evidence shows the cyberattacker gained access to USIS systems through an exploit in a system managed by a third party, and from there migrated to company managed systems. . . . Our findings were largely informed by a variety of logs, including, firewall logs, security event logs, VPN logs, and SAP application trace logs.” USIS spokeswoman, Ellen Davies, also said in the report “the third-party contractor was hacked and the hacker was then able to navigate into the USIS network via the third party’s network.”

According to THE HILL [4], the forensics report points out an SAP vulnerability as the hackers’ door in. Moreover, several sources [1][4][9][10] highlight that this state-sponsored attack is related to Chinese hackers. On March 2014, hackers who have penetrated computers at the Office of Personnel Management were traced to China; that attack was targeted to the files of tens of thousands of employees who have applied for top-secret security clearances [5]. This time, investigators are saying the USIS attack has several hallmarks to past Chinese intrusions like the one at OPM [1].

This breach illustrates a reality that often is not reported in mainstream news: the impact of cyber-attacks on SAP Systems to retrieve critical and confidential information. Attackers were able to access the USIS network in late 2013 but weren’t discovered until June 2014[6]. This means that the attackers had at least 6 months of access to internal and sensitive information without being noticed. The damage is difficult to estimate and shows the current lack of awareness around how SAP systems must be protected and monitored.

The report states that the vulnerability is “present in a widely used and highly-regarded enterprise resource planning (‘ERP’) software package”, however, there aren’t any details about the specific vulnerability or set of vulnerabilities that were used to compromise the SAP System.

Since the attack originated in late 2013, it is important to analyze the known vulnerabilities that were patched by SAP at that time, as well as the vulnerabilities patched after that date, which indicates the possibility of using 0-day exploits. Since the details are unknown, there is no way to specify whether the attackers used an exploit that was still not still patched by SAP, or if it was USIS who didn’t patch a well-known vulnerability.

According to the articles and research, USIS attackers exploited this SAP vulnerability externally in order to access the company network. Once inside the network they used it to pivot to other systems. Onapsis also recently released a study on top 3 SAP Cyber Attacks with one focused on “pivoting” [11][12][13][14], . This is a common approach used by attacker’s to gain access to employee data, customer information or even credit card data “Pivoting” Between SAP Systems. The attack begins with a pivot from a system with lower security such as a development or QA system, to a critical system in order to execute remote function module in the destination system. SAP systems are connected to the Internet and a single weak link is required for the attackers to start pivoting between systems and to then begin moving through the internal network. This appears to be the behavior described for the USIS hackers.

SAP systems have always been a target for hackers as they run the most critical and sensitive processes for the largest companies and government agencies in the world. Examples such as the USIS breach are showing the importance of protecting our SAP Systems and eradicates the false idea of business critical applications being “internal and isolated” as we often hear from SAP administrators. SAP itself has acknowledged the criticality of this topic, while presenting at its own conference, SAP TechEd 2014 as well as presenting cyber-crime related talks at SAP SAPPHIRE 2015, “SAP Runs SAP – How to Hack 95% of all SAP ABAP Systems and How to Protect them”.

It seems that hackers are knocking on the doors of our business-critical applications. As these kind of attacks are increasing, companies should move towards to the next steps in business critical applications security.

Onapsis Research Labs, experts since 2006 has been tracking other examples in the wild of this common attack vector and will be publishing a report at a later date. In the meantime, attackers are moving faster and companies and governments need to be prepared; automated, continuous monitoring and real-time security measures are the next step to solve and mitigate these ever evolving threats.

To discuss this issue in greater detail, Onapsis will be hosting a webcast on Thursday May 21st at both 9:00 A.M. EST and 2:00 P.M. EST. For more information, or to register please click here.












[11]: Onapsis SSID – Volume IV: The Invoker Servlet – A Dangerous Detour into SAP Java Solutions

[12]: Onapsis SSID – Volume V: Our Crown Jewels Online – Attacks targeting SAP Web Applications

[13]: Onapsis SSID – Volume VI: Securing the Gates to the Kingdom – Auditing the SAProuter

[14]: Onapsis SSID – Volume VII: Preventing Cyber-attacks Against SAP Solution Manager


Share Button

SKIP-TLS/FREAK Vulnerabilities and SAP Systems

A few days ago, an important set of bugs that affect the suites of protocols TLS/SSL were published in These protocols are mainly used as the security layer underlying the HTTP(s) protocol, but many other protocols may be affected. The described vulnerabilities have received specific names: SKIP-TLS and FREAK. These bugs affect different implementations of the TLS/SSL cryptographic algorithms, but they are not vulnerabilities in the protocols themselves.

SKIP-TLS can be described as an implementation error in how the client and server manage unexpected messages in the protocol state machine. Different cipher suites require different messages in particular orders. This bug leverages this complexity by sending messages in an specific order to skip all messages related to key exchange and authentication as described in the paper (

The FREAK attack to the TLS/SSL protocol implementation attempts to degrade the cipher quality, giving an attacker the possibility of downgrading the cipher suite strength of a TLS/SSL connection. This means that a resourceful attacker performing a man-in-the-middle attack could trick the client to select a weaker cipher suite that could then be broken in during a later stage of the attack (like those marked as EXPORT).

In this blog post we will focus on understanding the security impact of SKIP-TLS/FREAK for a group of SAP products.

Continue reading

Share Button

Logging IP addresses in the Security Audit Log

Hi! I was reviewing some events coming from the Security Audit Log and noticed an interesting behavior.

For those who never heard about it, the Security Audit Log (a.k.a SAL) allows SAP security administrators to keep track of the activities performed in their systems. In a future post we will discuss how to enable and configure it.

By default the SAL facility logs the “Terminal Name” which is either the Terminal Name defined by the computer which performed the logged action as the source of events; the “Terminal Name’ if no “Terminal Name” value is sent then the IP address of the computer performing the actions is used.

Continue reading

Share Button

The Ignored World of SAP Cyber Security: How organizations are waking up to attacks targeting their SAP cyber-layer

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:

  1. 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.”

Continue reading

Share Button

Don’t be hoisted by your own petard

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.


Share Button

A Simple Method for Fingerprinting SAP BusinessObjects

The main component of a BusinessObjects installation is the Central Management Server (CMS). It’s rarely changed and default TCP port is 6400. A simple way to identify if you are communicating with a BusinessObjects installation is to make a socket connection to the remote server and send the string ‘aps’. If everything is running correctly you should receive the IOR of the CMS.

Note that the hostname of the server is given at the end of the response which is useful in further attacks. Furthermore, if you parse the IOR you will get the IP and port of the CMS’s dynamic listening port which can be added to your Reconnaissance data.

A note on Defense

The most critical point of prevention is firewalling the CMS from unauthorized connections.

Share Button

Security Geeks Introduction to SAP – SAProuter and you

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

Continue reading

Share Button

How Malware is evolving into the first step of attacks against SAP systems

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.

Continue reading

Share Button

SAP HANA Security: Do You Want a Basic or Secure Implementation?

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…

Continue reading

Share Button

Complementing GRC – Testing the Forgotten Layer of SAP

For those of us old hands in the security industry we know that when security is done right processes flow smoothly, issues are rare, identified and mitigated before there is any real public perception of the potential for an issue; and businesses continue to achieve their goals of profitability and sustainability. In those circumstances security is often invisible; leading those not connected to the security team to speculate quietly or loudly about the value or worth of the security team to the business.

When security is done poorly the results are obvious and painful. Publicly announced loss of customer information or intellectual property; inefficient processes and costly internal remediation to shore up holes that are identified. Worse still is the effect on the relationship between security and the business; because security isn’t seen for the enablement function it can be the security team may have to force itself into projects – trying to force consistency and security where it didn’t previously exist. Because those (unfortunate) security teams are playing catchup the recommendations delivered for projects often come at the end of the project, causing delays in go-live dates and increased project costs. As a result the security team is seen as the “no-team”, gaining a negative imagine within the organization. So teams with projects try to hide them from security, only disclosing them to security at the last possible minute – causing the cycle of “security team generated delays” to continue.

When I am at conferences a common theme from my peers is to discuss how we can better show the business the positive results that a healthy relationship with security can bring. From more efficient processes, decreased risk and a healthier bottom line; consistently and intelligently applied security has numerous benefits any intelligent business would want to reap.

SAP is a company that understand the importance of security to its customers. It has introduced a regular monthly cycle of releasing patches, notes and other information about new vulnerabilities that effect their software components. Also, SAP proactively publishes security guidance for SAP software; providing customers with the information they need to ensure they are doing all they can to secure their SAP installations.

And for good reason, I am not sure it is possible to calculate the value of the business processed and enabled by SAP systems every day; but given the range of companies that run SAP I am sure it is a more than respectable percentage of the world’s GDP.

Continue reading

Share Button