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

Weakest link safety: Oracle Fail Safe Backup

Intro

We all know it, it is nothing new, the level of security in an organization is equivalent to the weaklist link of the chain.

On this blog post we are going to study how an attacker can compromise an SAP system by taking advantage of a simple database vulnerability.

To give more context about this vulnerability, first we need to start defining what is “Oracle Fail Safe Backup” and what is its relationship with SAP.

According to Oracle’s site:

Oracle Fail Safe it is a high availability software, integrated with Microsoft Failover Cluster, that provides a fast, easy, and accurate way to configure and verify Windows clusters and to automatically fail over Oracle databases and applications.

In the event of a system failure, Oracle Fail Safe works with Microsoft Failover Cluster to restart Oracle databases and applications on a surviving cluster node.

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

Checking SAP passwords strength – part II (JAVA)

Hello! Today’s post can be considered as a appendix to our previous post. We will learn how to validate the strength of SAP passwords by trying to crack them. We’ll focus on the password hashes coming from the SAP JAVA Application Server.

The JAVA Application server stores the passwords in the form of hashes encoded in BASE64. The hash algorithm used is salted SHA-1, also known as SSHA1 [1].

SAP JAVA “stack” password hashes are stored in a database table called UME_STRINGS. The JAVA password hashes can be filtered by the “attr” field (attr = ‘j_password’). We can get the user name along with its corresponding hash by executing the following SQL query:

SELECT pid, val FROM UME_STRINGS WHERE attr = 'j_password'

Continue reading

Share Button

Checking SAP password strength – part I (ABAP)

There are reasons why you might want to check the security (strength) of an SAP implementation’s passwords. Maybe during an external SAP security assessment or during an internal review.

If it is an SAP security assessment and the successful exploitation of a vulnerability is able to provide OS command execution in the application server, the command shell might not be sufficient to prove the impact of the vulnerability. Sometimes the most effective way to do it is to retrieve valid credentials (SAP user credentials) in order to prove a real threat. This can evidence the ability to connect to the system, obtain business information and explain to our customer the real problem behind a given vulnerability. The impact is clearer, from the customer’s perspective, when there is a chance to access business data and it’s exposed with valid (SAP) user credentials rather than performing command execution and showing a command shell, although the latter could potentially cause more damage.

Other scenarios where password cracking could be necessary is on complex landscapes with several systems interconnected. If an attacker is able to obtain valid user credentials in low-criticity systems such as sandbox or development systems it is likely that the same user and password will be configured in productive systems as well, being able to “jump” from the initial system (probably much less secured) to the most critical systems.

Continue reading

Share Button

Latest SAP Security Vulnerabilities – Including an SAP CVSS 10

In this post, I’ll cover some of the latest vulnerabilities reported to SAP by Onapsis and published last week.

Last week we released advisories regarding several vulnerabilities affecting SAP platforms. Some of these vulnerabilities are in fact very critical, and their exploitation could lead to a full-compromise of the entire SAP implementation – even by completely anonymous attackers. Following our responsible disclosure policy, SAP released the relevant SAP Security Notes (patches) for all these vulnerabilities a long time ago, so if you are an SAP customer make sure you have properly implemented them!

These are the advisories for the published vulnerabilities, along with a small description of the real business impact of an exploitation of the vulnerabilities:

By exploiting this vulnerability, a remote unauthenticated attacker might be able to access or modify all the business information processed by the ERP system. This would result in the total compromise of the SAP infrastructure.

By exploiting this vulnerability, a remote unauthenticated attacker might be able to access or modify all the business information processed by the ERP system. This would result in the total compromise of the SAP infrastructure.

By exploiting this vulnerability, a remote unauthenticated attacker might be able to access or modify all the business information processed by the ERP system. This would result in the total compromise of the SAP infrastructure.

By exploiting this vulnerability, an internal or external attacker would be able to perform attacks on the Organization’s users through weaknesses in the SAP system. Upon a successful exploitation, he would be able to obtain sensitive information from legitimate users through complex social engineering attacks and/or exploit vulnerabilities in their systems in order to take control of them.

By exploiting this vulnerability, an attacker would be able to perform a sabotage attack over the service used to deploy and change software components in the SAP AS Java. This would prevent legitimate developers and administrators from performing and maintain required business and technical activities.

By exploiting this vulnerability, an internal or external attacker would be able to perform attacks on the Organization’s users through weaknesses in the SAP system. Upon a successful exploitation, he would be able to obtain sensitive information from legitimate users through the exploitation of vulnerabilities in their systems.

We think it is a very important set of vulnerabilities, as one of them is the first vulnerability ever ranked by SAP with a CVSSv2 risk 10! Actually, Onapsis also reported the second vulnerability ranked with a CVSSv2 10, and this advisory will be released next month.

We are going to be demonstrating some of these vulnerabilities live in our upcoming posts and presentations.

Share Button