More than two-thirds of ERP systems were breached in 2018 and 2019 according to a 2019 survey conducted by IDC for Onapsis.
Content, in particular, is being used as a threat vector, whether it’s structured content in the form of user input in forms and applications, or unstructured content in the form of file uploads and downloads.
And the trouble is, these vectors cannot be shut down. You can’t simply close the input vector. You cannot close the file upload vector if that’s what the application needs to function.
But considering how mission-critical SAP applications are, and the sheer volume of data they access, protecting these assets should be a top priority of every organization that uses them.
This guide shows you how to protect your SAP applications from content-based attacks. You’ll learn:
SAP applications are popular targets for hackers because they are, by definition, business-critical. Whether we’re talking about S/4HANA, CRM, ERP, PLM, SCM or SRM, SAP applications store and process a lot of information that is of interest to attackers. This information ranges all the way from social security numbers to employee names and addresses to supplier and customer data, all the way up to financial data payment information subject to regulations (PCI, GDPR and HIPAA, for example).
SAP applications are also popular targets because they model and implement business processes with internal and external resources. They control procurement, production, inventory, sales of products and more.
The Ponemon Institute estimates that the average cost of an SAP intrusion, including direct costs, clean-up costs and loss of business opportunities, is $4.5 million.
The Chief Information Security Officer from a food and beverage company in Switzerland estimates that if their SAP system has to be taken offline due to a security breach, his firm will lose $22 million per minute. This is obviously a huge number that doesn’t apply to every organization, but the lesson for every organization is that breaches of SAP systems cause serious financial damage.
According to Onapsis, the types of data being compromised represents a wide spectrum of the information assets held by today’s enterprises, including:
It is imperative to make sure that this information is not being compromised or tampered with.
Sabotage is also a popular motive for attacking SAP systems. SAP systems control human resource and financial information. And they are used to create reports and generate business intelligence that ultimately serves as the basis for business decisions. If that information is altered by attackers, the long-term repercussions for the business could be dire.
In many cases, SAP applications are a single point of access to a lot of other applications that are behind these applications, such as the enterprise portal or the NetWeaver gateway required by almost every new, user-friendly and mobile enabled FIORI application in order to access data stored on backend systems (on premise or further down into your corporate network).
Allegedly hacked by the hacktivist group Anonymous. A zero-day attack on SAP leveraged a vulnerability for which no patch was yet available. The hackers said they will use that success to attack other SAP applications.
Hackers modified a banking Trojan that typically extracts banking credentials to extract SAP user credentials instead. This was clearly a preparatory step for attackers to make sure they gained legitimate SAP credentials to access systems in a second phase of the attack.
We saw Nvidia, the video chip maker, taking their customer website offline after hackers exploited an SAP bug. This is a vulnerability that SAP had issued a patch for, but the hackers capitalized on the fact that many organizations do not deploy patches immediately.
This breach was made to a private company used by the US Department of Homeland Security to perform security screenings of its staff. The system was compromised, and a lot of sensitive information was exposed and extracted.
For the first time, the United States Computer Emergency Readiness Team issued a warning that SAP applications as well as Oracle applications are increasingly becoming the targets of attacks by malicious third parties.
Let’s take a quick look into SAP content and content-based attacks. What are they? How do they work?
If you put your SAP application front and center, you notice that there are a couple of content vectors. These are the ways that content gets into your SAP application. And there are two kinds of content: unstructured content and structured content.
Unstructured content is basically files. This is information that SAP applications are not going to dig deep into. Applications just use this content as one object and store it somewhere. They do not extract any information that is inside the file. For example, if someone uploads their CV as part of an application or recruiting process, the application doesn’t parse this file or extract information from it.
Structured content is anything that a user enters into a form, whether it’s a Dynpro form, a WebDynpro, a BSP or a Fiori web-based application. The application has some understanding of what this information means. The application knows that data in the first-name field, for example, corresponds to the first name of the person. And while the same information may be present in the unstructured content, in the CV file, the application would not extract that information.
Attacks against unstructured content include viruses and malware. This is what everybody thinks about right away when they think of cyberattacks. If you upload a file, you want to make sure it contains no malware. That’s a valid concern, but it’s a concern that will not have an impact on the SAP application itself.
If someone uploads a malware-infected file, then yes, ultimately, it may cause damage at the receiving end of this business process, when someone screens this file or extracts it. They might be hit by the malware that’s included in that file. If the party hit is an external entity, questions about liability and damages may be the consequence. However, ultimately, the malware doesn’t affect the SAP application itself because it doesn’t process the content of the information.
But there are other types of content-based attacks that target the SAP application itself, circumventing the file-type filters in place. The filters that SAP put inside the product with regards to filtering files based on their type are very, very limited. Ultimately, it comes down to the file name extension. If you take notepad.exe file, for example, and you rename it to “notepad.PDF” and upload it to an SAP application, SAP will recognize this as a PDF file. Even if you put in place a filter that allegedly filters by MIME type, which suggests that SAP analyzes the content of the file, it does not.
There’s a mapping inside SAP (the MIMETYPES-table) that maps every file extension to a MIME type so that notepad.PDF will be a PDF file for your SAP application, which ultimately is bad because you do not want any executable content being uploaded into your SAP application.
Active content is content that is usually embedded in files that trigger some action whenever the file is displayed. This includes macros, which have regained popularity in the malware-writing scene, lately especially as a prevalent way to propagate ransomware, such as Locky, WannaCry, Ryuk, etc..
There is a lot of social engineering that goes into luring people into activating macros. For example, in pretend job applications, attackers would craft a Word document pretending to have been created with a more recent version of Microsoft Word, or pretending to have been saved with “additional security features enabled” in order to protect sensitive personal information or comply with a new regulation, like GDPR. Unsuspecting users will be directed to click the “Enable Content” button, which activates macros stored in the document. Then, the ransomware runs in the background and encrypts the content of the hard disk.
Even if you do not accept any types of macros, there are other types of active content that are at least as dangerous, things like JavaScript and Java in a whole set of different files. For instance, you could have JavaScript embedded in PDFs, in SVG (vector graphic files), in HTML and in XML. The problem with active content and with JavaScript in these types of files is that they are not malware. So, even if you have a virus scanner in place that will do the scanning for you, these files will not be caught as malware because they are, by definition, not malware (except for ransomware, of course).
It is impossible to determine the file type of a chameleon or polyglot file. These are files that ultimately will satisfy the identification criteria of not one, but two or more file types. It is, for instance, possible to combine two file formats, such as a GIF image with a Java archive. A GIF is benign, and you wouldn’t have any concerns allowing a GIF to be uploaded to your bulletin-board, forum or Wiki application.
But you certainly would not want a Java archive to be on a web server, but GIFAR files combine the GIF image and the Java archive in such a way that if you show the file in a browser, it will show you the GIF image. If you call the exact same file using “java -jar” or reference it with an APPLET tag, an EMBED tag or an OBJECT tag, the default Java classes will be executed. It is difficult to make the differentiation.
Then there are SAPCAR-based attacks. Especially in the SAP context, the proprietary SAPCAR archive format is inherently trusted by administrators. Unbeknownst to most, virus scanners cannot analyze the content of SAPCAR archives, making them a potent threat vector for malware and file-based directory traversal attacks.
If an SAP admin gets a SAPCAR file, typically they are not as cautious as if they would be getting something like a zip archive or something from an external source. Everybody with access to the SAPCAR executable (installed on every SAP server by default – including the openly available trial versions) can create SAPCAR archives, and the problem with SAPCAR archives is that virus scanners cannot look into them. It’s a proprietary SAP format, so the virus scanners cannot open SAPCARs and cannot look into the content of these files.
In a cross-site scripting (XSS) attack, hackers insert code, typically JavaScript, into the application markup rendered by the user’s (the victim’s) browser. As a simplified example, a results page of a search function may include the term the user searched for. So if the user searched for the term “XYZ”, the results page would contain “Your results for XYZ”. In some cases, applications fail to properly “sanitize” that user input, resulting in a vulnerability (called “reflected XSS”) where JavaScript sent to the application as part of the (maliciously crafted) request is then reflected back to the user and executed in their browser. Attackers will typically embed such maliciously crafted links in cleverly socially engineered emails.
In other cases, the malicious JavaScript may even be stored in the application and subsequently sent to every user viewing the part of the application displaying that did not properly sanitize the data before storing it. As another simplified example, you may think of an online guestbook, where visitors can leave comments. Attackers would leave a malicious JavaScript as such a persistent guestbook entry (Hence the term “persistent or stored XSS”). Every subsequent visitor of the guestbook would be served the JavaScript along with the comments of previous visitors – no email, no clicking on a link required.
In both cases, the user and the rendering client have no way of determining that the malicious script is not a legitimate part of the application.
What hackers do with this kind of attack is deface the application. This applies to any web application. This is not specific to SAP, but it is prevalent in SAP. Hackers will steal credentials and pop up an authentication window that tricks the user into entering their details. They also hijack sessions by extracting session IDs and other markers and cookies that automatically authenticate a user to an existing session as long as it’s been running. In more targeted attacks, the JavaScript may execute actions in the SAP application – leveraging the user’s credentials. Attackers could be able to release payments, create user accounts or manipulate data.
With SQL injections, attackers enter malicious data in order to read or manipulate database content. You may be thinking that SAP uses openSAP, the open SQL language, which is much less susceptible to SQL injections than others, which is true. But many applications occasionally use “native SQL” or even openSQL queries that are vulnerable to injections, ultimately giving attackers varying levels of unauthorized access.
This vulnerability ultimately allows for “data sabotage,” which is becoming much more prevalent. This type of attack is much less about deleting the database or dropping entire tables, and more about sabotaging and modifying information in the database to create long-term damage that’s less immediately visible than an attack that takes down a system.
There are two ways users can do directory traversal: by using application URLs and by using files. Typically, this is about breaking out of the context of the application and accessing files in locations where the user should not have access. Directory Traversal Attacks can expose passwords, allow attackers to overwrite (and loosen) access control lists, or give them access to application modules or functions they shouldn’t have access to.
OS command injection (also known as shell injection) is a web security vulnerability that lets attackers execute arbitrary operating system (OS) commands on the server that is running an application and typically fully compromise the application and all its data or even the entire server.
Open redirect is a security flaw in an application that causes legitimate users to be redirected to a resource under the attacker’s control. So, a user accesses their trusted (SAP- or other) web application and is redirected to a malicious page. Such malicious pages could either mimic the original application to trick users into exposing their credentials, or transfer malware to the user’s machine before re-redirecting them to the legitimate applications (“drive-by downloads”).
Open redirect vulnerabilities occur, when redirect URLs are part of the URL parameters, allowing attackers to craft malicious links and use social engineering to lure users into accessing those. Even cautious users fall victim to such attacks because the human-readable part of the URL is in fact legitimate while the target of the redirection can be obfuscated in a way making it unreadable to the average user.
When SAP patches come out, there is a window of increased vulnerability. This is because once cyber attackers are alerted to the vulnerability, they reverse-engineer the fix and exploit the vulnerability.
Yes, SAP devotes most of its focus to high-risk vulnerabilities. To date, SAP has released over 4,000 security notes, adding an extra 20 or more every month. Like clockwork, SAP releases its security notes every month, along with any needed patches. From there, it’s up to each company to install their own patches. And this is where things fall apart.
If everybody applied the patches as soon as they were released, this wouldn’t be as much of an issue. But they don’t. Most SAP customers do not regularly apply SAP security notes. In a survey conducted by Protect4S, 30% of respondents said they apply SAP security notes every month. Most apply them every six months, and an alarming 13% don’t apply them at all.
Standard anti-virus solutions can’t address malware, cross-site scripting attacks and active content cybersecurity vulnerabilities within SAP applications. Standard anti-malware solutions are designed to protect file-systems and only a small subset of the content vectors (as described in “How Do SAP Content-Based Attacks Work?”). In order to address those blind spots, SAP created NW-VSI, a virus-scanning and content-security interface embedded directly in the application infrastructure.
Anti-Virus for SAP Solutions from bowbridge is the only content-security software built solely for SAP applications. It works seamlessly in the background, securing ABAP and Java-based SAP applications as well as SAP Business Objects and new solutions built on SAP HANA and UI5/FIORI.
No code changes are required. With over five thousand installations both on premise at leading enterprises worldwide and in leading cloud infrastructures, bowbridge Anti-Virus is the de-facto standard for malware protection and content security for SAP applications.
Because modern SAP applications, such as FIORI apps, are commonly exposed to untrusted users and untrusted devices, enterprises must implement security controls on the data-flows into and out of these applications.
Our latest development, bowbridge Application Delivery Controller for SAP Solutions, will ensure the availability, integrity and performance of web-exposed SAP applications for on-premise and cloud-based SAP implementations. Protecting against common and targeted attacks while improving the delivery of the application, it will optimize both the user experience and the efficiency of application server resource-utilization.
bowbridge Application Delivery Controller for SAP Solutions will achieve this by combining and optimizing key functionalities for which SAP customers typically deploy multiple (generic) solutions:
Unlike competing solutions, bowbridge Application Delivery Controller for SAP Solutions will be software-only, cloud-ready and built specifically for SAP applications, making it the market’s only software-based Application Delivery Controller for SAP applications.
For many organizations, SAP is the crown jewel when it comes to IT assets. Protecting this system and its applications is crucial. By understanding SAP-specific vulnerabilities to content-based attacks, and the ways cyber attackers take advantage of these vulnerabilities, you’re taking the first step toward protecting this mission-critical system—with bowbridge’s help.