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

Security Geeks Introduction to SAP – Vulnerabilities

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

As I mentioned in my first post in this series, the typical reaction of a business when asked about the security of their SAP systems is to refer to the SoD checks they do. That is the testing they do to ensure proper Segregation of Duties is enforced; which is, the system has the logic in place to prevent fraud – so the person who submits an expense report cannot approve it as well, for example.

Given 10 years of dealing with buffer overflows, ClientSide attacks, SQLi and numerous other ways to exploit weaknesses in how systems have been coded and implemented, I was more than a little surprised to learn that the testing of the underlying SAP applications and their configuration was not common practice.

There are numerous presentations and articles online that talk about the day SAP released 500 notes; and those that talk about the current rate at which SAP releases their notes. Suffice it to say that SAP is a large and mature technology that has the typical amount of issues of any large and mature technology.

Continue reading

Share Button

Security Geeks Introduction to SAP

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 past 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 role 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.

I know that more and more ‘traditional’ security professionals are being asked to evaluate the security posture and risk of a business’s SAP system; which makes sense as SAP typically runs the most critical processes and workflows for an organization, as well as housing the most important data. Given the amount of time and effort it is taking me to learn SAP I thought it would be beneficial to publish a little resource for other professionals making the same jump.

So, SAP? For those like me who need to know what an acronym stands for it is Systems, Applications and Products in data processing, also it is never said as a single word, but spelled out S-A-P. It started in and is still based in Germany and according to Wikipedia has a revenue of over 16 billion Euro in 2012 – so not a small company by any stretch of the imagination.

Continue reading

Share Button

Securing SAP Mobile Platforms: Beyond the Device

Mobile security is definitely a hot topic in our industry. However, it’s quite hard to find people talking about mobile security beyond managing/securing the device itself. Most industry solutions are focused in deploying a secure BYOD strategy and ensuring the devices cannot be exploited with malware.

While this approach is highly important, I have found it difficult to find solutions that actually look at the security of the backend servers that are used by such mobile devices. These servers vary from simple Apache, IIS or Tomcat application servers with Web mobile apps to highly proprietary components.

If your company is using SAP mobile applications in you employees’ tablets or smartphones, then you have SAP servers exposed to the Internet to serve such devices, which already puts them in a more risky situation (Internal threats mentioned on previous blog). With 6000+ customers already using them and being one of the fastest growing product line for SAP AG, it’s highly likely that you are or soon will be empowering your users with SAP-branded apps.

In this scenario, an attacker only needs to perform an external scan to discover such components, and – be sure about it – he is not limited to the functionality that the SAP mobile app is providing your users. He can interface with such SAP servers with a variety of attack tools and try to exploit vulnerabilities in them. The result? He may be able to compromise your entire SAP infrastructure, remotely over the Internet.

This was a growing concern in many of our leading customers, and I’m glad to announce that we responded quickly: Onapsis X1 is now the first-and-only product in the market equipped to detect & assess vulnerabilities affecting SAP Mobile Platforms (Sybase Unwired Platforms), SAP NetWeaver Gateway and SAP Fiori apps.

We are going to be showcasing this new version at booth #231 during the Black Hat Conference this month in Las Vegas as well as hosting a 2 day SAP Security In-Depth training.

Remember that your mobile apps are probably connecting to a backend system in your network. If it’s SAP, we got you covered.

 

Share Button

External vs Insider Threats: Why there are no “internal” SAP systems

I would like to reflect on a common situation that I have repeatedly heard over the past few years when talking and training on the topic of SAP security:

When I ask the question:

  • “How are you dealing with the cyber-threats affecting your SAP platform?”

Most commonly I get the answer:

  • “Oh, our SAP system is internal, so we are fine.”

I humbly believe that many people have a misconception about this statement, and it is about time that we clarify that the old paradigm of “external vs. internal” has not applied in information security for a long time. It doesn’t apply when we talk about networks, and therefore, it does not apply when we talk about threats. And specifically, it does not apply to SAP environments.

Let’s analyze why:

  1. Who’s on your “local” network? Several decades ago your local network would only be hosting very few and trustworthy employees. Today, the local network must be considered as harmful as any other untrusted network. Surprisingly, many large organizations still have the SAP platform deployed in networks which are directly reachable from the end-user network (no internal DMZ), significantly increasing the attack surface.

Furthermore, because most large organizations are outsourcing the management of their SAP platforms to 3rd party contractors, less controls can be enforced. Just in the last training we held at Black Hat USA, three students commented privately that they had suffered a breach in their SAP systems, having a disgruntled outsourced contractor as the perpetrator.  

  1. That one application. It’s not rare to hear from Information Security peers that they were not aware (most of the time, were not informed) of that one application that actually exposes SAP components to suppliers, partners or customers. Because of modern business requirements, many SAP systems are effectively used to provide online access to business processes, usually through Web applications (could be running on top of SAP itself) or Mobile platforms.
  1. Your internal users have email access. Even if there is no SAP Web application to exploit directly, malicious attackers would of course not give up. For several years now, they would just use client-side exploits in spear phishing attacks: sending malware through a malicious PDF or MS Office document to any internal employee. Upon opening it, your internal user would surrender the entire “local” network to an attacker who may be sitting thousands of miles away. From there, the attacker has effectively established a presence inside your network and can just fire at will at the SAP systems (back to point 1!).
  1. Your SAP system is online. I’m sorry for the bad news, but don’t kill the messenger. SAP AG provides support services (such as EarlyWatch) remotely from specific locations. In order for them to do so, you need to deploy a component called SAProuter that will proxy the remote support connections to your “internal” SAP systems.

Ideally, it should be set up through a VPN connection with SAP AG only, but more often than not it’s possible to find them directly exposed to the Internet. An unsecured SAProuter could be completely exposing your SAP platform to the world. Read this SAP Security In-Depth publication for more information regarding the SAProuter.

In order to mitigate the risks that affect our SAP platform, we first need to understand the threats we are facing. We need to accept that our SAP systems are in fact connected to rouge and untrusted networks. With that mindset change, we can then analyze how to holistically protect it from cyber-attacks.

 

 

Share Button

Assessing a SAProuter’s Security with Onapsis Bizploit: Part II

In our previous post, we were able to understand the topology and configuration in place, useful whenever you want to analyze how secure a SAProuter implementation is. In this article, we’ll check if our SAProuter is secure or whether it would be possible for an attacker to retrieve information and connect to our internal network.

Using SAPRouter Agents

We have already retrieved useful information from the SAProuter, which is potentially connected to an untrusted network. But that’s not all of it. If the SAProuter is mis-configured, then it would be possible for a remote attacker to access the internal network and connect to arbitrary systems and services, even beyond standard SAP protocols.

The SAProuter has a special feature that enables it to route arbitrary protocols, which is called “native routing”. Refer to our SAProuter SAP Security In-Depth publication, specifically section 3.3, for further information on this topic.

Continue reading

Share Button

Assessing a SAProuter’s Security with Onapsis Bizploit: Part I

Hello there, my name is Nahuel D. Sanchez and I work as a Security Researcher at the Onapsis Research Labs.

The idea behind this post is to uncover and understand the options we have while performing a security assessment of the company’s SAProuter implementation using the open source ERP Penetration Testing framework, Onapsis Bizploit.

For more information about vulnerabilities affecting the SAProuter, attacks and countermeasures, you should have a look at our SAP Security In Depth publication Securing the Gate to the Kingdom: Auditing the SAProuter.

Basic Concepts

Before we dig into the interesting stuff, it’s necessary to review some basic concepts. If you’re already familiar with the SAProuter, you can jump straight to the “Security Assessment Techniques” section.

Continue reading

Share Button