After we got to know what is SAP and why SAP Security is important, we are ready to take the next step, to learn a history of SAP Security and the most significant research findings made so far. Now, in 2016, we can celebrate a kind of 10-year anniversary or REAL SAP Cyber Security, however, traditional SAP Security dates back earlier than 2006. Let's trace the history of SAP Security.

Before New Era

In the beginning, it was SOX. SOX, or Sarbanes-Oxley,  was enacted on July 30, 2002, also known as the "Public Company Accounting Reform and Investor Protection Act." SOX is a United States federal law that set requirements for all U.S. public company boards, management and public accounting firms. Simply saying, it makes companies responsible for the information they report. The most contentious aspect of SOX is Section 404, which requires management and external auditors to report on the adequacy of a company's internal control over financial reporting; and this is how SOX is connected with SAP.

What should you learn next?

From SOC Analyst to Secure Coder to Security Manager — our team of experts has 12 free training plans to help you hit your goals. Get your free copy now.

Get Your Plan

SAP stores and processes all this financial data, which means that you need to control who can have access to different kind of data. Of course, you should have done it before, but SOX made it an obligatory measure. After that, all companies started to think about access control and Segregation of Duties.

SoD, or Segregation of Duties, is an important factor when dealing with different responsibilities and job positions within an enterprise. In any enterprise, there are various functions and these functions are performed together by a set of roles/responsibilities. The conception of SoD means that the set of roles/responsibilities should be assigned in such a way that any individual should not have end-to-end access rights over any function. Segregation of duties (SoD) assures that no one individual has the physical and system access to control all phases of a business process or transaction: from authorization to custody to record keeping. Thus, in a way it advocates Maker–Checker concept at various levels. An employee should not have responsibility for more than one of these three transactions components: authorizing transactions (approval), recording transactions (accounting), and handling the related asset (custody). For example, persons who can authorize purchase orders (Purchasing) should not be capable of processing payments (Accounts Payable). So, in other words, SoD aims to prevent issues that may happen when a user can do so many things in the system so that he can commit fraud.

Since the number of different conflicts such this amounts to hundreds and the number of users of the system comes to thousands, to deal with all this stuff is quite a complicated duty to do it manually. Some companies started to develop a set of solutions to automatize this task. One of these products was Virsa Systems. This solution was initially developed by PricewaterhouseCoopers, known as SAFE, which was purchased by Virsa in December 2004. The SAFE was a preventative, automated tool to control the granting and management of access within SAP. On 3 April 2006, SAP AG announced its decision to acquire Virsa Systems and later released its SAP GRC – an SAP System to check whether other SAP Systems are configured securely regarding access control. So, before 2006 and, to tell the truth, for some companies even until now, SAP Security was a synonym for SOX and SoD. However, it's only a small part of SAP Security.

The New ERA of SAP Security – SAP Cyber Security

All those SoD things are undoubtedly very important, but what's the use of SOX compliance if your SAP System has a buffer overflow vulnerability? Now let's come to the real SAP Cyber Security History.

Born in Germany

One of the first public posts on SAP cybersecurity was about the concept of a potential SAP virus written in ABAP language. The idea was pretty simple. There was nothing groundbreaking, but it was proven ABAP used by SAP as a programming language can be used to write a virus likewise any other programming language. This article was an example of this virus. The story is so old that now it's even hard to find the original post, except news on heisse.de.

2002

Later, another article titled "Wir hacken eine SAP Datenbank" (in German) was published. It provides the most detailed technical information how SAP is configured, how to identify SAP systems in the network, collect publicly available information and use default passwords to break into SAP database. In 2002, most of the SAP Systems used Oracle database as a storage for all data and the common way to get access to data stored there was to connect directly to an Oracle database via its default credentials and insecure configuration such as a remote OS authentication. This misconfiguration still affects many SAP installations even now, in 2016, and it remains one of the top 3 most common vulnerabilities which can be used to hack an SAP system.

2003

In 2003 another article, and again in German, titled "SAP Password Security" ("SAP Password Sicherheit") was published by Frank Dittrich. It didn't provide a detailed vulnerability description, but it contained information that SAP passwords were transmitted insecurely via a network. So, how the password encryption algorithm works was revealed.

Then the revolutionary moment in SAP Cyber Security history came. In 2003, FX Linder was the first who publicly exploited a remote vulnerability in SAP System and presented it at the security conference CCC – Chaos Communication Congress – the largest hacking event in Europe. The presentation in itself was not about SAP, but about new methods of vulnerability exploitation but just as an example he found a vulnerability in SAP and used this solution. Multiple memory corruption vulnerabilities he discovered in SAP's ITS service can be remotely exploited to get access to SAP System without authentication.

World history of SAP Cyber Security

All of those events and findings were very significant for SAP Cyber Security history, but whitepapers in German and talks in European Conference even the biggest one were known only "locally," so the real history started in 2006.

2006

In 2006, there was the first presentation at security conference about SAP Security. Steve Lord's "Mo' Budget, Mo' Problems" provided an overview of multiple issues in SAP architecture and described how hackers could get access to SAP and specifically how typical users could escalate their privileges by using legitimate SAP Transactions. Some default SAP transactions provide functionality to read files from OS, read tables from the database and even execute OS commands via the special interface which is similar to a command line in UNIX. If you have access to this program, you can access database on SAP and obtain all business-critical data.

This presentation changed history. After that, security researchers started their studies of SAP Security (and so did I).

2007

In 2007, another presentation about SAP Security was delivered. This time, at the BlackHat conference in the USA. A researcher from Argentinian company CYBSEC presented information about different vulnerabilities in SAP Gateway service – the core of SAP. This vulnerability allows bypassing security restrictions and performing any OS command on SAP Server.

2008

This year was important because of a tool release. Popular password decryption tool John The Ripper made SAP Passwords decryption easier. This was another significant moment after which research community realized that SAP Systems Security is an important topic remaining almost uncovered. As you know, researchers enjoy accepting such challenges and examining how systems work, so, SAP became one of the main research objects and remains the same.

2009

Since 2009, the number of SAP Security talks increased significantly, there were four talks in 2009 and 32 talks in 2012 according to the SAP Security in Figures report.

In 2009, researchers presented a couple of general talks such as "SAP Pentesting" or my talk "Technical Aspects of SAP Security". Also, two very remarkable research and publications about specific areas of SAP Security were published. The whitepaper "Attacking SAP Clients with SAPSploit" was my first public research about SAP Security and was the first study focusing on attacks against SAP client applications. While all publications about SAP Cybersecurity were mostly dedicated to server-side attacks, I thought that when server-side attacks would become harder to perform because people start to care about server-side security; thus attackers would search for easy ways to attack clients. You may ask what the purpose of attacking user workstations is, and I will tell you. If you have access to a workstation which sometimes connected to the server, you can inject your commands as a legitimate user or simply steal login credentials of this user and connect to the server by yourself.

Another publication titled "Method of decompression of SAP's DIAG protocol & sniffing clear text passwords" was published by independent researcher Dennis Yourichev. This publication was a big step to simplify Penetration Testing of SAP Applications. Before, there were no details of methods used by SAP to compress traffic between clients and Server. Researchers knew that it was not encryption, and it was possible to recover SAP passwords and usernames from network traffic, but this publication not only sheds a light on methods and algorithms used by SAP to compress traffic. It delivered a tool for pentesters to present weaknesses of this protocol for their clients and prove that protocol is vulnerable not only in theory.

2010

Security community kept attention to specific areas of SAP in 2010, and 12 talks about different SAP Security issues were published. Three of them are worth mentioning. The first one was the series of talks about attacks on SAP Clients.

After my first publication, I conducted additional research regarding attacks on SAP Clients. In 2010 one interesting attack happened, we all know about it. I'm talking about Stuxnet. While it's not directly related to SAP Security (Stuxnet virus targeted SCADA systems), the similar attack was very likely to happen against SAP Systems. Stuxnet worm used a chain of vulnerabilities; and the attack went from the client application to the server application, so the worm acts as a legitimate client. This idea together with my previous research about attacks on SAP client applications gave me the insight to prepare my research "Attacking SAP users with SAPSploit". The results were presented at the HITB conference together with my colleague Dmitry Chastuhin – another popular SAP Security researcher who did a lot to promote the SAP Security topic.

Other two noteworthy talks described SAP applications, namely "Attacks on SAP Router" and research about SAP Backdoors.

2011

In 2011, the total number of talks increased again and became twice more than in 2010. Most of the talks were focused on unique analysis. After the first wave of researchers who took their first steps on general aspects of SAP Cyber Security, the other researchers who also wanted to participate in this new interesting subject chose small areas of SAP Solutions to conduct an in-depth research. Researchers decided to explore specific fields of SAP security and presented the results of at various conferences.

A wide range of interesting researches were presented, for example, the following:

• Architectural problems in ERP systems
• Attacks on SAP WEB applications
• Buffer overflows in ABAP
• Session Fixation в SAP
• SQL Injection in ABAP
• J2EE engine security

Let's look closer at some of them. Two talks about SQL Injection vulnerabilities in ABAP and Buffer Overflow Vulnerabilities in SAP Kernel Functions were the first public presentations at international cyber security conferences discussing very critical topic– vulnerabilities in custom applications. Before, with the help of researchers, people became aware of SAP misconfigurations and technical vulnerabilities and what there is a need to analyze SAP configuration and implement patches. But these talks clarified that even if you configure SAP properly and implement the latest updates, you are still at risk of cyberattacks because your custom programs written by your developers, not SAP, may have vulnerabilities (such as SQL Injections) as well that can be used by attackers to get unauthorized access to the system.

It was a milestone in SAP Cyber Security approach, a new topic added to the whole picture. Now, SAP Security became a combination of SoD, Vulnerability Management, and Custom Code security.

The other significant step in SAP Cyber Security was my presentation at the BlackHat security conference about vulnerabilities of SAP J2EE Engine. Why is it important? In 2011, SAP had two main platforms on which their solutions were built, namely, SAP NetWeaver ABAP and SAP NetWeaver J2EE. SAP NetWeaver ABAP was and still is the main SAP Platform. Almost all business applications that are developed to automate different business processes such as Enterprise Resource Planning or Supply Chain Management are based on SAP NetWeaver ABAP Platform. Those systems are mostly located in a corporate network under secure perimeter, all research papers, and publications were focused on vulnerabilities of ABAP Platform. However, SAP also delivers SAP NetWeaver J2EE platform. It's usually considered an additional platform for integration purpose and was not as popular as ABAP since those solutions did not store critical data directly. However, they were used to connect ABAP platforms and thus were responsible for transferring this critical data, so in theory, attacks on those solutions may be used to modify critical data and connect to ABAP systems which may be securely configured from direct attacks. The most popular solution based on SAP J2EE platform was SAP Portal. On the one hand, SAP Portal provides connection to ERP systems based on ABAP engine, and, on the other hand, SAP Portal was open to attacks from the Internet. My research Architecture and program vulnerabilities in SAP's J2EE engine was the first one that described in detail the security of J2EE engine and critical vulnerabilities that can be used to attack an SAP landscape form the Internet. Vulnerabilities in J2EE Engine discovered in 2011 are still the most critical vulnerabilities in SAP Portal and still can be found on real systems in large organizations.

2012

If you think that in 2011 it was said too much, you'd better look at what happened in 2012. It appeared to be a real competition between security researchers from different companies who could discover more bugs in SAP and present them on Security Conference. More than 30 talks on different aspects of SAP Cyber Security were delivered. There was not a particular direction of research; the Security boffins just looked at different elements of SAP applications and technologies to discover vulnerabilities. By the end of 2012, every SAP module, every application, every protocol, every service were discovered to be plagued with vulnerabilities.

Here is the list of topics which were covered in 2012

• SAP (in)security: Scrubbing SAP clean with SOAP
• SAP Slapping - A pentesters guide
• Cyber-Attacks & SAP systems:
• Real SAP Backdoors
• The SAP Platform's Brain: Attacks to SAP Solution Manager
• Top 10 most interesting vulnerabilities and attacks in SAP
• Systems Applications Proxy Pwnage
• SSRF vs. Business Critical Applications
• Uncovering SAP Vulnerabilities: Reversing and Breaking the Diag Protocol
• Penetrating SAP with IronSAP
• Breaking SAP Portal

Before 2012, the significant part of the talks were delivered by 3-4 companies focused on SAP Security. Those researchers were a kind of cornerstones on which ideas how important SAP Cybersecurity is was based. They also did a lot in 2012, but there appeared new players in this game. SAP Security became an attractive topic and many researchers who were worked on absolutely different areas of Cyber Security now started research in this field. So it's worth mentioning them as well.

The presentation "SAP (in)security: Scrubbing SAP clean with SOAP" by Chris John Riley was a good example of the tendency. A service called SAPHostCotrol was developed by SAP to configure SAP remotely easily. It was based on SOAP Protocol, a widely used one. The technology behind this platform was not SAP's Proprietary, which means that it was much easier to start research in this area with less SAP Background than it was needed to find vulnerabilities in SAP's proprietary protocols. This fact allowed researchers to start with something and then delivered more interesting talks. Another research that was conducted by non-SAP researcher Ian de Villiers was Systems Applications Proxy Pwnage. This guy from SensePost is a penetration tester who met SAP System in his daily job, and he decided to look at this system more closely. They created a public tool which can be used to decompress DIAG protocol and inject your packets into the network flow, which can be used by researchers during security assessment as well as for finding new vulnerabilities and conducting more research. Moreover, finally – Martin Gallo – researcher from Core Security took the baton and delivered his talk Uncovering SAP Vulnerabilities: Reversing and Breaking the Diag Protocol. It was another example of the trend when researchers focused on traditional applications started their investigation of SAP Security. He also created a toolset for DIAG protocol – so, one of the last fortes of SAP security was broken down - its proprietary protocol, which now became as easy to understand as HTTP.

2013

2013 was also an interesting time in the history of SAP Cyber Security.

SAP Forensics became the main theme discussed by leading SAP Security researchers. After a plethora of publications about attacks, information about identifying them became very relevant. For instance, a talk titled "SAP Forensics" - a high-level guide to SAP Forensics in general - and another about specific forensic and anti-forensic methods for SAP Portal applications by Dmitry Chastuhin.

I did my first research about SAP Forensics much earlier, but it was not approved by any conference as I started my work on this topic much earlier than the critical mass of SAP Cyber Security vulnerabilities was reached. However, in 2013, one thing happened after which the SAP Forensics topic became much more relevant.

With the help of our friends from anti-virus company who had found an interesting version of Banking Trojan, which had functionality uncommon for these types of malware. The latest version of this Trojan could identify whether SAP Client application is installed on an infected workstation and if so, this Trojan sniffs usernames, passwords, and other credentials. It was the first malware designed for SAP Applications. This was a game-changing moment that made people understand that Attacks on SAP Systems was a real target of cyber-attacks and malicious people may exploit some 0-day vulnerabilities. Moreover, that is why we should pay day attention to SAP Forensics

2014

In 2014, we saw fewer talks than in 2013 regarding old SAP Systems. The focus has shifted to new SAP systems such as SAP HANA. Although there were still a lot of research on SAP in general, SAP HANA talks in 2014 and SAP Mobile talks in 2015 became a hot topic.

As SAP was planning to build all their new solutions on HANA, researchers started to spend their time on deep analysis of new SAP Platform and they succeeded. SAP HANA platform was created when SAP became much more aware of vulnerabilities, and this solution was a bit more secure by default than SAP NetWevaer ABAP Platform. However, there were found multiple vulnerabilities in this platform starting from program errors and ending with architecture vulnerabilities in the key management process.

2015

In 2015, SAP HANA research continued and multiple critical vulnerabilities affecting this platform were discovered. Also, researchers switched to other SAP's platforms – SAP Afaria and SAP Mobile platform. Dmitry Chastuhin from ERPScan again became the first researcher to talk about a new topic of SAP Security. He delivered the first presentation about SAP Mobile platform at the Troopers conference where he described vulnerabilities in SAP Mobile platform. There should be a talk by him at BlackHat APAC about extremely critical vulnerability in SAP Afaria that can be exploited to wipe clean and lock about 130m mobile devices worldwide, but the talk was revoked as SAP didn't manage to close these issues. Anyway, the talk was delivered at HackerHalted conference later and was covered by Wired. It is notable that any SAP Cyber Security research hadn't been mentioned in such well-known media before

Conclusion

So, this was the latest history of SAP Cyber Security. I've tried to keep it short, but, of course, it's not easy to tell about hundreds of presentations delivered in last ten years in a short article, but this information is enough to understand what has happened and where we are now. There are many things left to do there, and I hope that one day, you, reader, will contribute.

To conclude our discussion about SAP history, just look at the statistics gathered by us after reviewing most popular conferences where SAP talks were delivered. It shows only the number of new, unique presentations at international conferences.

Stay tuned for the next part of our SAP Security for Beginners series.