1 2 3 14 Previous Next

Security

200 Posts

SAP has released the monthly critical patch update for February 2016. This patch update closes 23 vulnerabilities in SAP products including 15 SAP Security Patch Day Notes, 1 update to a previous Security Note, 2 Support Package Notes released on this SAP patch day and 5 Notes released after the second Tuesday of the previous month and before the second Tuesday of this month.

13 of all closed Notes have a high priority rating. The highest CVSS score of the vulnerabilities is 7.5.

SAP Security Notes February 2016 by priority

Most of the discovered vulnerabilities belong to SAP NetWeaver J2EE applications security.

SAP Security Notes February 2016 by platforms

The most common vulnerability type is Cross Site Scripting and Missing authorization check.

SAP Security Notes February 2016 by vulnerability type

This month, four critical vulnerabilities found by <removed by moderator> researchers Dmitry Chastuhin and Vahagn Vardanyan were closed.

 

Cyber Security issues for SAP Manufacturing

 

One of the issues closed by <removed by moderator> researchers deserves attention. We speak about a directory traversal vulnerability in SAP xMII (Manufacturing Integration and Intelligence). This solution plays a vital role in Cyber Security of Manufacturing, Oil and Gas, Energy and Utility companies. SAP xMII provides a connection between shop-floor systems and enterprise business applications. This solution is designed to collect and aggregate plant and production information and then to display this data to management on nice dashboards based on ERP, BI, and other systems. Despite all the benefits, SAP xMII also may put enterprises at risk. Vulnerabilities affecting SAP MII can be used as a starting point of multi-stage attack aiming to get control over plant devices and manufacturing systems. <removed by moderator> researchers demonstrated how to perform similar attack vectors against Oil&Gas companies at the recent BlackHat conference. The directory traversal vulnerability is another entry point for hackers to penetrate into plant floor and Operational Technology networks where ICS and SCADA systems are located.

 

Issues that were patched with the help of ERPScan

 

Below are the details of the SAP vulnerabilities that were found by <removed by moderator> researchers.

 

  • A Directory traversal vulnerability in SAP Manufacturing Integration and Intelligence (CVSS Base Score: 4.0). Update is available in SAP Security Note 2230978. An attacker can use a Directory traversal to access arbitrary files and directories located in an SAP server filesystem including application source code, configuration and system files. It allows obtaining critical technical and business-related information stored in a vulnerable SAP system.

 

  • An SQL injection vulnerabilities in SAP UDDI (CVSS Base Score: 6.8). Update is available in SAP Security Note 2101079. An attacker can use an SQL injection vulnerability with specially crafted SQL queries. He can read and modify sensitive information from a database, execute administration operations on a database, destroy data or make it unavailable. In some cases, the attacker can access system data or execute OS commands.

 

  • An Information disclosure vulnerability in SAP Universal Worklist Configuration (CVSS Base Score: 5.0). Update is available in SAP Security Note 2256846. An attacker can use Information disclosure vulnerability to reveal additional information (system data, debugging information, etc) that will help him to learn about a system and to plan other attacks.

 

  • A Cross-site scripting vulnerability in SAP Java Proxy Runtime (CVSS Base Score: 4.3). Update is available in SAP Security Note 2220571. An attacker can use a Cross-site scripting vulnerability to inject a malicious script into a page. More information about XSS vulnerabilities in SAP systems is available in <removed by moderator>’s research.

Other critical issues closed by SAP Security Notes February 2016

 

Some of our readers and clients asked us to categorize the most critical SAP vulnerabilities to patch them first. Companies providing SAP Security Audit, SAP Vulnerability Assessment, or SAP Penetration Testing services can include these vulnerabilities in their checklists. The most critical vulnerabilities of this update can be patched by the following SAP Security Notes:

 

  • 2273881: SAP TREX has an OS command execution vulnerability (CVSS Base Score: 7.5 ). An attacker can use OS command execution vulnerability to execute operating system commands without authorization. Executed commands will run with the same privileges as the service that executed them. The attacker can access arbitrary files and directories located in an SAP server filesystem including application source code, configuration, and critical system files. It allows obtaining critical technical and business-related information stored in a vulnerable SAP system. Install this SAP Security Note to prevent risks.

 

  • 2266565: SAP SAPSSOEXT has a Denial of service vulnerability (CVSS Base Score: 5.0). An attacker can use a Denial of service vulnerability to terminate a process of a vulnerable component. For this time, nobody can use this service, which negatively influences on business processes, system downtime, and reputation. Install this SAP Security Note to prevent risks.

 

  • 2272211: SAP HANA Extended Application Services SAPUI5 has a Cross-site scripting vulnerability (CVSS Base Score: 4.3 ). An attacker can use a Cross-site scripting vulnerability to inject a malicious script into a page. Install this SAP Security Note to prevent risks.

 

It is highly recommended to patch all those SAP vulnerabilities to prevent business risks affecting your SAP systems.

 

SAP has traditionally thanked the security researchers from <removed by moderator> for found vulnerabilities on their acknowledgment page.

 

Advisories for those SAP vulnerabilities with technical details will be available in 3 months on <removed by moderator>.com. Exploits for the most critical vulnerabilities are already available in <removed by moderator> Security Monitoring Suite.

Standard protection products’ signature-based, one-size-fits-all approach cannot deal with the custom nature of targeted attacks and their dedicated perpetrators. Advanced attack groups utilize malware, social engineering, and hacker techniques specially customized to the task of evading your defenses and successfully attaining their goals against your company.

 

By design, they will defeat standard security products utilizing generic signatures. Combating these custom attacks requires a custom defense a new strategy that recognizes the need for a specific approach and relevant intelligence that is uniquely adapted to each organization and its attackers. A custom defense solution augments an organization’s standard security by detecting and analyzing advanced threats targeting the organization, immediately adapting protection against the attack, and enabling a rapid remediation response.

 

SAP systems are “high value targets” for an attacker and the data of SAP ERP system can be described as mission critical for every company. Therefore, attacks on such systems should be prevented or at least recognized in an early stage of an attack.

 

SAP introduced a new solution SAP Enterprise Threat Detection to detect internal or external threats against the business system landscape. The solution detect attacks based on pre-delivered patterns, which monitors the system landscape based suspicious user or system behavior. There are various ways how to attack a SAP system. This could be standard attack techniques like a brute force attack, internal misuse of permission or development rights, exploit unsecure system configuration and identity theft.

 

Identity theft itself is a very widespread attack and is starting on the employee’s device of a company and not directly against the business system. If an attacker was able to infect a device (personal computer, mobile device …) of an employee with access to the SAP systems, it is possible to steal the SAP credentials and download or manipulate sensitive business information with the permissions of the stolen credentials.

 

To prevent these kind of threats, it makes sense to integrate modern security solutions like SAP Enterprise Threat Detection and the Trend Micro solutions to combine each of their strengths. SAP Enterprise Threat Detection is specialized to detect threats against business system landscapes and Trend Micro is very strong on the network, infrastructure and endpoint level.

So let us start with an example of an identity theft attack. Modern attacks have often the following structure (simplified for our discussion):

 

Picture1.png

 

 

The picture above describes an attack against a device of a business user with high SAP access rights. The first step is to place malware on the device. There are various ways to do it like drive-by-exploits, phishing, mails, USB sticks. After the malware is on the device, it starts to get further instructions from the control server. The malware can monitor the user input and wait until the business user logon to a SAP system with its user and password. If the malware was able to steal the SAP credentials, it can try to emulate a user session against the SAP system.

 

To counter such attacks, modern security solutions like SAP Enterprise Threat Detection and Trend Micro Deep Discovery Inspector can be combined. Both solutions cover important tasks during an incident. Integration between security solutions is an important factor to fight modern attacks on IT infrastructure.

 

Picture2.png

 

The big picture of the integrated approach

 

The picture below shows a target attack against a company. Target is a PC of an employee in a company with a host of permissions in the business systems landscape. Trend Micro is able to collect information on the network level, email communication (in case the malware was send my mail) and endpoint information. Furthermore, Trend Micro can execute potential malware in a sandbox environment to analyze the behavior. SAP Enterprise Threat Detection is tracking the information flow in the business systems, which are in fact the end target of the attack. The solution monitors transaction behavior, add business context information, monitors the audit log (there are much more sources available).

In the end, both solutions provide the IT security team the insight on the infrastructure level and on application/business level to enable to right actions.

 

Picture3.png

 

 

What is Trend Micro Deep Discovery in detail?

 

Trend Micro Deep Discovery is an advanced threat protection platform that enables you to detect, analyze, and respond to today’s stealthy, targeted attacks. Using specialized detection engines, custom sandboxing, and global threat intelligence from the Trend Micro Smart Protection Network, Deep Discovery defends against attacks that are invisible to standard security products.

 

Deployed individually or as an integrated solution, Deep Discovery solutions for network, email, endpoint, and integrated protection provide advanced threat protection where it matters most to your organization.

 

Trend Micro Deep Discovery Inspector is a network appliance that monitors traffic across all ports and more than 100+ protocols. Using specialized detection engines and custom sandboxing, it identifies the malware, C&C, and activities signaling an attempted attack. Detection intelligence aids your rapid response.

This is how Deep Discovery Inspector detects attacks & threats and how it reacts (basic overview):

 

Picture4.png

 

How to integrate Trend Micro Deep Discovery with SAP Enterprise Threat Detection on a technical level

 

Below a screenshot of Trend Micro Deep Discovery. The solution found a suspicious activity (targeted attack detection) on a PC of an employee. There is one host involved. The goal is now automatically send the information to SAP Enterprise Threat Detection, to raise the sensitivity of the system for all events in relation to the host or to provide the security team the possibility to identify any potential harm in the business landscape.

 

Picture5.png

 

It is easy to configure Trend Micro Deep Discovery to send alerts to other systems. The goal is now to enable SAP Enterprise Threat Detection to understand the CEF messages from Trend Micro.

 

To be useful in SAP Enterprise Threat Detection, the information from Deep Discovery must be normalized, so that it can be used in the forensic lab. This is where threats are analyzed and attack detection patterns are created.

 

In this blog, I am going to describe how this can be achieved in SAP Enterprise Threat Detection 1.0 SP02. There are two main tasks:

 

  1. Importing and running a project on to the SAP Event Stream Processor
  2. Preparing the SAP Enterprise Threat Detection knowledge base with the appropriate attributes for the CEF Threat Log

 

For the latest information, the file for preparing the knowledge base, and the ESP project, refer to SAP Note 2237819 - Integration with Trend Micro.

The Common Event Format (CEF) is one of the syslog formats that Deep Discovery Inspector supports to enable integration with third-party systems. Referring to the Trend Micro Syslog Content Mapping Guide we can see an example of what this looks like in the CEF Threat Log:

 

CEF:0|Trend Micro|Deep Discovery Inspector|3.8.1175|20|Malware URL requested - Type 1|6|act=10 .201.156.143 dvcmac=00:0C:29:A6:53:0C dvchost=ddi38-143 deviceExternalId=6B593E17AFB7-40FBBB28-A4CE-0462-A536 rt=Mar 09 2015 11:58:25 GMT+08:00 app=HTTP deviceDirection=1 dhost=www.freewebs.com dst=216.52.115.2 dpt=80 dmac=00:1b:21:35:8b:98 shost=172.16.1.197 src=172.16.1.197 spt=12121 smac=fe:ed:be:ef:5a:c6 cs3Label=HostName_Ext cs3=www.freewebs.com fname=setting.doc fileType=0 fsize=0 act=not blocked cn3Label=Threat Type cn3=1 destinationTranslatedAddress=216.52.115.2 sourceTranslatedAddress=172.16.1.197 cnt=1 cs5Label=CCCA_DetectionSource cs5=GLOBAL_INTELLIGENCE cn1Label=CCCA_Detection cn1=1 cat=Callback cs6Label=pAttackPhase cs6=Command and Control Communication

 

1. Importing and running a project on to the SAP Event Stream Processor

 

SAP Event Stream Processor (ESP) is part of SAP Enterprise Threat Detection. All events will be later stored in the SAP HANA database but first they will be send to ESP.

The adapter for the CEF threat Log, the ESP project trendmicro_events_over_tcp_in_etd, takes the input over TCP, parses the data, and then distributes the data to the relevant fields of the LogHeader and LogDetail structures. The transfer of the resulting data to the SAP HANA database is done by an existing project, transfer_log, on the SAP Event Stream Processor. The diagram below is of the project trendmicro_events_over_tcp_in_etd.

 

Picture6.png

 

All you need to do is to import the project trendmicro_events_over_tcp_in_etd into the SAP ESP Studio, adjust the cluster in the CCR file to correspond to the SAP ESP server, make sure that the transfer_log project is already running and then run the project for Trend Micro.

Import

 

Picture7.png

 

Adjust the cluster on the cluster and bindings tabs:

 

Picture8.png

 

Run the project:

 

Picture10.png

 

You can test that the project is working by opening the InputStream for manual input and pasting the example for the CEF Threat Log into the Text field.

 

Picture11.png

 

 

2. Preparing the SAP Enterprise Threat Detection knowledge base with the appropriate attributes for the CEF Threat Log

 

In SAP Enterprise Threat Detection 1.0 SP02, the appropriate attributes for the Trend Micro integration need to be created in the SAP HANA database. The way described here uses the Knowledge Base user interface of SAP Enterprise Threat Detection.

 

In short, you will start the Launch Pad in SAP Enterprise Threat Detection and click on the Knowledge Base tile. You will then go to the ATTRIBUTES tab of the Knowledge Base and maintain the attributes for Trend Micro CEF Threat Log.

 

Launchpad:

 

Picture12.png

 

Knowledge Base ATTRIBUTES Tab:

 

Picture13.png

 

There are already some attributes visible. You are going to add some new ones.

 

Open the CSV file containing the attributes. You will copy and paste the values into the Knowledge Base. The Name (Column B) and Data Type (Column D) must be used as is. You may adapt the other values.

 

Picture14.png

 

For each attribute that you want to be able to use in the Forensic Lab, create the attribute in the Knowledge Base user interface.

 

Picture15.png

 

Leave the Is Role Dependent field empty. Select Active for the Status (you can change this latter if you do not want the attribute to be visible in the Forensic Lab).

Finally check that you can see the attributes in the Forensic Lab. The attributes should start with DDI.

 

Picture16.png

 

Conclusion


As a result of the integration, the security team can filter in the forensic lab all events from Trend Micro. The host information of the events can be combined with all available information in SAP Enterprise Threat Detection. Example: Show me all infected devices from Trend Micro and show me all RFC  calls from this host to the SAP landscape to find out any data breaches. The security team can create easily patterns without any programming, so they can get automatically alerted in future in similar situations.

Do you think you need a well renowned security expert to do threat modeling? I don’t think so. Sure it would be fun to do a Threat Modeling workshop with a guy like Bruce Schneier, but the sad truth is that he likely is not available or affordable once you think you need him.

 

Sure, you need security know how to do a good Threat Modeling workshop. But as an engineer, I also follow the idea that I do not need to know everything, only the place where I can find the answer. It is sufficient to start with a decent security know how and a very good knowledge base.

 

That is one of the reasons why we have centered Threat Modeling@SAP on our product standard security. It is a huge knowledge base that has many requirements and threats in it. As such, I do not need to know everything, to a great extent, I can rely on this list.

 

The product standard security has quite a bit of history at SAP. Introduced around the year 2000, it evolved from a questionnaire with roughly 20 security questions into a collection of around 50 security requirements. As per requirement etiquette they typically start with “SAP Software shall / shall not…”.

 

Our internal standard maps easily to the Open Web Application Security Project (OWASP) top ten and Application Security Verification Standard (ASVS) or Common Vulnerabilities and Exposures (CVE), two other potential sources you could use as a knowledge base. For the time being we stick to our internal representation as most of our security processes in development are centered on this, including threat modeling. And of course our product standard is a living thing and gets updates twice a year with information from external and internal sources (including OWASP, CVE et al…).

 

But you might wonder, a requirement is not a threat. Well, you are right. A requirement is not a threat.

On the other hand if you change your viewpoint slightly, you can easily find a threat behind a requirement. E.g. “SAP software shall be free of data query and manipulation language injection vulnerabilities” turns into “Can I manipulate a query by injecting manipulated language snippets”.

 

Is our product standard complete? Hmm – a difficult question. I would rather answer it is up to date (at least after an update) to counter the well-known security issues.

 

Is there a chance that an ingenious hacker finds a new way to do harm? Maybe, but that should not stop us from striving for coverage of the known. Threat modeling is not safe against black swans, as any risk oriented methodology. That should not stop you from hindering all the white swans to bite you.

 

To summarize you might be able to do a pretty good job with a decent security expertise and well established security knowledge base. Let’s spare hiring Bruce for a subsequent run, once we discussed all known threats…



 

Author: Oliver Kling

This post by SAP Product Security Response Team shares information on Patch Day Security Notes* that are released on second Tuesday of every month and fix vulnerabilities discovered in SAP products. SAP strongly recommends that the customer visits the Support Portal and applies patches on a priority to protect his SAP landscape.

 

On 9th of February 2016, SAP Security Patch Day saw the release of 16 security notes.

____________________________________________________________________________________

 

Security Notes vs Vulnerability Type - February 2016

VT.PNG

Security Notes vs Priority Distribution (September - February 2016)**

ND.PNG

 

Patch Day Security Notes are all notes that appear under the category of "Patch Day Notes" in SAP Support Portal

** Any Patch Day Security Note released after the second Tuesday, will be accounted  for in the following SAP Security Patch Day.


To know more about the security researchers and research companies who have contributed for security patches of this month visit SAP Product Security Response Acknowledgement Page


Do write to us at secure@sap.com with all your comments and feedback on this blog post.

 

Yours,

SAP Product Security Response Team

Last time I outlined our simple three steps methodology: Understand, Analyze and Prioritize. Sounds too simple? It may or may not be so simple depending on your viewpoint.

 

Let’s dive a bit deeper on the topics.

 

We aimed for a methodology that has no preconditions. The more preconditions required, the higher the entry hurdle for the development teams and you may end up in workshops where the preconditions are not met.

Having made that statement, there are still some implicit preconditions.

 

The first implicit precondition is doing workshops with experienced architects and developers of the product in scope. A big portion of the success of our approach and for Threat Modeling over all, is the fact that it can be a high quality white box approach, testing the internal structures of an application, rather than the functionality. If you have the right guys in the workshops you have great insights into the architecture, design and coding at hand. From my view point the main reason for its high efficiency and effectiveness.

The second implicit precondition is to have an architecture and clear understanding of the use case at hand. The right guys will have the knowhow for sure, but only if you are not early in development and trying to hit a moving target, which is at the very least time consuming. It is not an expectation to have an architecture diagram at hand, as it is a great activity if you draw the diagram during the workshop. (We will follow up on timing of a workshop in a separate blog also).

 

Last, but not least, the third implicit precondition is some security know how for the workshop. It should be noted that if the workshop moderator has security know how, the workshop experience was very good for all attendees. Be careful in the choice of the moderator, because not every security expert is a good moderator, or vice versa!

 

We let the guys from the development team explain their use case and their business background. Typically a standard presentation used in development for stakeholder management is sufficient as a high level starting point. Be sure that we dive much deeper – but one step after the other.

 

If there are multiple use cases we start with one this is security critical.

 

Phase 1, the understanding phase, allows for learning about what valuable assets you are protecting and where these assets are located in the architecture. This analysis consists of a mix of drawing the architecture diagram, noting down the data flow on this architecture, including the single steps and pointing out data in motion and at rest.

 

Interestingly you do not need to go down to the lowest level of design in the understand phase. It is sufficient if the external party or moderator understands the basics. Again we will dive deeper with each successive step.

 

Assuming we now have the architecture and a description of the use case, we start phase 2, analyzing the architecture element by element.

 

Per element we have a set of threats assigned generically. Keep in mind that the threats are our security requirements from a threat perspective.

A first check is if the threat is applicable or not. Though it is a yes / no decision it is not that simple, but I will discuss this in a later blog.

 

If the threat is applicable, we try to understand if there is an unmitigated risk. As an example, think about a potential SQL-Injection. If the infrastructure is not taking care of that and many do not do, you have an unmitigated risk. This is nothing that can be solved easily during design, so clearly a task for the development phase. We evaluate the risk and note it down for further processing.

 

As such we go through all elements and all assigned threats and once we have completed the exercise, which takes typically a few hours we are done with phase 2.

 

This approach sounds mechanical and checklist based. You might even think that you make or break threat modeling here. If you do threat modeling in a checklist style, you will be doomed. The participants will disengage from the workshop and turn to more interesting things like their smartphone or email. On the other hand the checklist is essential as it gives you a base line and an insurance that you cover the known things in your threat knowledge base. But do not stop here if you do not have an obvious threat. You should twist and turn it to check if a closely related attack is possible on the threat at hand and invite the team for brain storming.

 

For brevity I would like to refer again to a later blog where we discuss this in more depth. You need to know that the participants attention, collaboration and thinking in this really needed in this phase.

 

Once you are done with this phase, you can conclude the workshop. One item to be aware of is you might spend too much time in a given day for any phase. As the discussions on security in design are so intense, everyone’s brain will reach a point (typically that happens for me around 3 hours of discussion), where it’s hard to focus on the discussion. My brain starts prickling and one can easily observe that point in time, it is the moment I as a moderator start rushing through the checklist. Stop here. Postpone to another time slot…

 

Depending on the tooling you use, you might need to press a single button to get a full Threat Modeling report, or possibly you must write a report manually (that is the fun part of Threat Modeling).

 

Ideally as a rule, the moderator writes the report close to the when the workshop ended. Once the report is available it is handed over to the development team for further processing. Ensure that the project team feels the ownership of the report and are encouraged to follow up on the actions required from the threats found in the report.

 

Now comes the final phase, where the team discusses the findings again. This time they are deciding on how to handle the risk, with the options of accept, mitigate or delegate the risk. Each rish should be placed on their backlog list and prioritized against functional requirements.  If it is not on the backlog list, a product owner might assume that there is no effort involved, and that the developers can work on it in their spare time…

 

So our methodology is simple as it is really based on three phases or steps. It is a complex choreography of architecture, design and technology know how, combined with security expertise and know how. It takes these two for the threat modeling tango.

 

As I did last time, I would like to conclude with a question. If you are doing threat modeling what tools do you rely on?

 

In our next blog I would like to introduce our threat knowledge base / the SAP product standard security.

 

 

Author: Oliver Kling

After reading the Top 10 ABAP crimes — which  is a great resource for anyone who writes ABAP code —

I would like to add some security specific hints.

Since we all want our business critical software to run securely we need to avoid among others

some common implementation security bugs such as SQL injection or path traversal.

To catch these, SAP developed the so-called NetWeaver Add-on for Code Vulnerability Analysis (CVA),

for developers (in- and ) outside SAP. CVA has been available since 2013 with regular feature enhancements.

Today there are in excess of 50 different CVA checks.

With the recent version you can also use CVA to check developments in older basis releases (SAP_BASIS > = 7.00 )

using Remote Code Vulnerability Analysis in ATC

The checks will highlight potential implementation bugs – the results are integrated directly in the ABAP Test Cockpit

or in your editor – ABAP in Eclipse or SE80.

CVA provides comprehensive guidance and fix recommendations for each finding allowing you to make the final choice.

Additionally, some guideline you may find helpful – Secure Programming – ABAP.

If you would like to know more I recommend to read this book (from my colleagues Thorsten Dunz and others - currently in German only):

Besseres ABAP: Schnell, sicher, robust - … (SAP PRESS, link is to Amazon.de )

 

Below you find a description of the CVA security checks grouped by type.

Inspired by the OWASP Top 10 security weaknesses from 2013 we can combine the

available CVA checks in the following groups:

 

SQL Injections

This threat and its mitigation are well described in the ABAP secure programming guide section SQL Injections .

Some good and bad coding examples have also been published in this SAP Insider Article by Patrick Hildenbrand in 2013.

Correction instructions can be found in the online documentation for findings.

For example the following vulnerability patterns are checked by CVA (among many others) :

SQL Injection for dynamic WHERE clause

UPDATE dtab.. WHERE (iv_where).

DELETE dtab WHERE (iv_where).

 

ABAP Code Injections

ABAP has some powerful statements allowing to dynamically generate and execute code.

The statements are INSERT REPORT and GENERATE SUBROUTINE-POOL.

CVA checks if user input is used to insert the coding to be generated.

There are some good recommendations in Horst Keller’s ABAP programming guidelines.

 

OS Command Injections

The ABAP – Keyword Documentation describes this vulnerability pattern as follows:

A system command injection is an attack method that can result from insufficiently secure input from outside. A System Command Injection forwards malicious operating system statements, which enter a program from an external source, to the operating system. In ABAP, this can occur when the following programming techniques are used:

  • On the application server
    • Input forwarded from an external source to the parameters of the function modules used to call operating system statements using the SXPG framework
    • When the addition FILTER of the statement OPEN DATASET is used and some or all of the specified operating system statement originates from outside the program.
    • Using the internal statement CALL for the special system function SYSTEM if part of the specified operating system statement or some or all of its parameters come from outside the program.
  • On the presentation server
    • Input forwarded from an external source to the parameters of the method, the class, or the function module .

CVA checks will highlight potential OS command injections.

Mitigation is mostly avoiding CALL ’SYSTEM’ or CALL cfunc, or in case absolutely necessary replacing by the SXPG framework.

 

 

Cross-Site Scripting (XSS)

XSS is the name of a class of security vulnerabilities that can occur in Web applications.

It summarizes all vulnerabilities that allow an attacker to inject HTML Markup or JavaScript into the affected Web application's front-end client.

The threat and its mitigation are reasonably well described in Secure Programming: Cross-Site Scripting

This vulnerability type is also checked for Business Server Pages (BSP’s).

Since BSP’s are not pure ABAP coding, you can call the checks out of BSP maintenance (SE80)

using the option Check using ABAP Test Cockpit (do not forget to switch on the flag Security Check for BSP )

Remark – In addition to all the standard ABAP vulnerability patterns, CVA can also check BSPs  for obsolete design, missing XSRF protection, potential unvalidated URL redirect or use of obsolete escape methods.

 

Insufficient protection against directory traversal attacks

Directory or Path Traversal is one of the well known vulnerabilities in applications and is listed in both OWASP and CWE.

Conceptually it is a consequence of insufficient input validation.

This threat and its mitigation are well described in the ABAP secure programming guide section DirectoryTraversal.

The ABAP application server provides standard mitigation methods such as using Logical File Names.

 

Backdoors

Backdoors (see OWASP definition) are a somewhat fuzzy vulnerability type – all ABAP code that can be used

to intentionally modify program flow, for example to bypass authorization checks,  would fall in this category.

CVA checks for hardcoded usernames, passwords, system IDs, clients and system variables check against hard-coded values.

Note, any dynamic coding influenced by user input could be used as backdoor -   and is being checked by CVA

as Code Injection.

 

Missing or incorrect authorization checks

In ABAP systems authorizations are checked both implicitly (for example before starting a transaction) and at program level

using the statement AUTHORITY-CHECK.

When doing own developments you may need Programming own Authorization Checks.

CVA can help you to find missing authority-checks in reports or remote-enabled function modules (aka RFC’s ) or before statement CALL TRANSACTION.

Language enhancements allow you to use statement CALL TRANSACTION with addition WITH AUTHORITY-CHECK or WITHOUT AUTHORITY-CHECK to suit your business scenario.

It also check against such a simple, but nasty implementation bug as SY-SUBRC not evaluated after

statement AUTHORITY-CHECK or other critical functions performing authorization checks (customizable).

 

 

Additional useful reading:

  1. Securing Remote Function Calls (RFC) is a very important topic if you want to harden an ABAP system - the paper from my colleague Christian Wippermann describes the concept, tools and approach how to succeed.
  2. ABAP keyword documentation (link to version 7.40)

 

Final words: Thanks to my colleagues Tanja Schaetz-Kruft, Steve Hookings and Sooraj Kamath, who reviewed and helped me to correct the text.

SAP has released the monthly critical patch update for January 2016. This patch update closes 23 vulnerabilities in SAP products (including ones closed after the second Tuesday of the previous month and before the second Tuesday of this month). Among them, there are 20 Patch Day Security Notes and 3 Support Package Security notes. 13 of these Notes have a high priority rating. The highest CVSS score of the vulnerabilities is 6.4.

SAP Security Notes January 2016 by priority

Most of the discovered vulnerabilities belong to JAVA security.

 

SAP Security Notes January 2016 by platforms

The most common vulnerability is Cross Site Scripting.

SAP Security Notes January 2016 by vulnerability type

This month, five critical vulnerabilities found by ERPScan researchers Mathieu Geli and Vahagn Vardanyan were closed.

Issues that were patched with the help of ERPScan

 

Below are the details of the SAP vulnerabilities that were found by ERPScan researchers.

 

  • Log Injection and Denial of service vulnerabilities in SAP HANA Extended Application Services Classic (XS) (CVSS Base Score: 5.0). Update is available in SAP Security Note 2241978 (version of the note: 2). An unauthenticated attacker can create specially crafted HTTP requests to SAP HANA Extended Application Services Classic debug function. This allows forging additional entries in the trace files of the XS process and thus consuming disk space of the HANA system. Also, the attacker can use a denial of service vulnerability to terminate processes of the vulnerable component. During this time nobody can use this service, this fact negatively influences on business processes, system downtime and, as a result, business reputation.

 

  • A Cross-site scripting vulnerability in SAP RWB (CVSS Base Score: 4.3). Update is available in SAP Security Note 2206793 (version of the note: 2). An attacker can use a Cross-site scripting vulnerability to inject a malicious script into a page. More information about XSS vulnerabilities in SAP systems is available in ERPScan’s white paper.

 

  • A Cross-site scripting vulnerability in SAP PMI (CVSS Base Score: 4.3). Update is available in SAP Security Note 2234918 (version of the note: 2). An attacker can use a Cross-site scripting vulnerability to inject a malicious script into a page.

 

  • An Information disclosure vulnerability in SAP User Management Engine (CVSS Base Score: 3.5). Update is available in SAP Security Note 2191290 (version of the note: 3). An attacker can use Information disclosure vulnerability to reveal additional information (system data, debugging information, etc.) which will help to learn more about the system and to plan other attacks.

 

The most critical issues closed by SAP Security Notes January 2016

Some of our readers and clients asked us to categorize the most critical SAP vulnerabilities to patch them first. Companies providing SAP Security Assessment, SAP Vulnerability Assessment, or SAP Penetration Testing services can include these vulnerabilities in their checklists. The most critical vulnerabilities of this update can be patched by the following SAP Security Notes:

 

  • 2246277 (version of the note: 2): SAP on ORACLE database has an Implementation flaw vulnerability (CVSS Base Score: 6.4 ). Depending on the problem, an implementation flaw can cause unpredictable behaviour of a system, troubles with stability and safety. Patches solve configuration errors, add new functionaluty and increase the system stability. Install this SAP Security Note to prevent risks.

 

  • 2248735 (version of the note: 3): SAP System Administration Assistant has an OS command execution vulnerability (CVSS Base Score: 6.0). OS command execution vulnerability allows an attacker to run arbitrary commands on the target OS. The commands will run with the same privileges as the service that executes them. The attacker can access arbitrary files and directories located in an SAP server filesystem including application source code, configuration and critical system files. It allows them to obtain critical technical and business-related information stored in the vulnerable SAP system. Install this SAP Security Note to prevent risks.

 

  • 2233550 (version of the note: 12): SAP HANA Database has an Encryption issues vulnerability (CVSS Base Score: 5.8 ). The communication encryption in SAP HANA multi-tenant database container feature does not work as expected. Install this SAP Security Note to prevent risks.

 

It is highly recommended to patch all those SAP vulnerabilities to prevent business risks affecting your SAP systems.

 

SAP has traditionally thanked the security researchers from ERPScan for found vulnerabilities on their acknowledgment page.

This post by SAP Product Security Response Team shares information on Patch Day Security Notes* that are released on second Tuesday of every month and fix vulnerabilities discovered in SAP products. SAP strongly recommends that the customer visits the Support Portal and applies patches on a priority to protect his SAP landscape.

 

On 12th of January 2016, SAP Security Patch Day saw the release of 20 security notes.

____________________________________________________________________________________

 

Security Notes vs Vulnerability Type - January 2016VT.PNG

 

Security Notes vs Priority Distribution (August - January 2016)**

NP.PNG

 

Patch Day Security Notes are all notes that appear under the category of "Patch Day Notes" in SAP Support Portal

** Any Patch Day Security Note released after the second Tuesday, will be accounted  for in the following SAP Security Patch Day.


To know more about the security researchers and research companies who have contributed for security patches of this month visit SAP Product Security Response Acknowledgement Page


Do write to us at secure@sap.com with all your comments and feedback on this blog post.

 

Yours,

SAP Product Security Response Team

This past year we as an SAP community have had some great discussions around adequate logging in SM19/SM20, e.g.:

 

http://scn.sap.com/docs/DOC-60743

 

...and

 

http://scn.sap.com/community/security/blog/2015/10/05/sap-security-audit-logs-auditor-wants-me-to-switch-all-on-here-is-what-i-told-him

 

Setting log levels in SM19 and SM20 appropriately is important; I’ve personally be involved in several instances where adequate logging allowed customers to go back and place retroactive mitigating controls to research potential security gaps; for example, we found users access that allowed SODs but we were able demonstrate that it was not taken advantage of by reviewing historical activity.

 

However, as the internal controls for SAP customers have matured, customers are becoming aware of the external threat sources out there – the black hat hackers, gray hat hackers, and, yes, even state actors with an awareness of SAP and common vulnerabilities that can be used to gain access to systems and sensitive data. External attacks on SAP systems, for the most part, will occur without executing a single transaction code or report. What types of logging can we enable to later identify suspicious network-based activity and, better yet, proactively monitor to alert on attacks as they are happening?

Logging Activity for Critical SAP Services

 

This list is meant to be comprehensive for the NW ABAP stack; that said if I miss anything please feel free to comment. I come across a lot of SAP customers that have these enabled; that said, I still find systems out there without logging enabled for these services.

 

The following services should be logged and, ideally, proactively monitored for suspicious activity:

 

  • Ensure SAP Gateway logging is configured. Maintain the profile parameter "gw/logging" with appropriate logging activated in transaction SMGW; more information is available in SAP note 910919.
  • Enable SAP message server logging. This is configured via profile parameter ms/audit; I haven’t found good overview notes on this but note 1831927 is helpful.
  • ICF logging – in my experience, you can activate at the service level, but a “noisy”, brute-force attack looking for, say, vulnerable Apache or IIS systems (i.e., services that don’t exist in ICF) will not be logged. In this case I’d recommend implementing logging at the Web Dispatcher level if used. This is configured using the parameters icm/HTTP/logging_<xx> and icm/HTTP/logging_client_<xx> within the Web Dispatcher instance(s). More information is available here: https://help.sap.com/saphelp_nwpi711/helpdata/en/48/406e93ca2331c3e10000000a42189d/content.htm
  • Ensure table change logging is enabled, especially for the productive client. This is not necessarily focused on external threats but is sometimes missed. This is set via profile parameter rec/client; more information is available in note 1106605. Some customers are reluctant to set this based on older notes that indicate a performance impact; this is worth testing but in my experience, I haven’t detected notable performance impacts on newer systems. And, of course, the performance impact on HANA-based systems is negligible.
  • And, of course, don’t forget to enable SM19/SM20 logging. You can always read Frank Buchholz and Ertunga Arsal’s write-ups on these!

Is it critical that I log these? And how much is enough?

The answer, of course, is “it depends”. Many customers out there have a clear compliance mandate to log system activity – PCI, for example, has an entire requirement (Requirement 10 – Track and Monitor all access to network resources and cardholder data) dealing with logging and monitoring. If you have PCI obligations and aren’t logging activity for these services, you are risking this showing up as a finding. And given PCI is a leading practice standard, continually updated based on changes to the threat environment, it’s a great standard that customers concerned with external threats can use to identify

 

For those of you out there with the Onapsis X1 or OSP platforms or for those considering researching Onapsis, some of these will show up as HIGH or MEDIUM risk issues. That said, if the services in question are available externally, and given risk = impact * likelihood, then your likelihood goes up by orders of magnitude (along with your risk).

Welcome to the second part of SAP Security for CISO series. This time, we will speak about SAP in particular and start from SAP Security for beginners. So, what is SAP? First of all, SAP is a German company that develops and sells business software. SAP is famous for its ERP system - the most widespread business application. However, SAP provides much more than just an ERP. In 2005, it introduced its SAP Business Suite – a number of integrated business applications such as ERP, CRM, PLM, SCM, and SRM. These business applications consist of different components. For example, ERP includes several basic modules such as FI/CO – finance and controlling, SD – Sales and Distribution, MM – Material Management, PP – Production Planning, HR – Human resources. SAP also delivers a scope of applications to fulfill specific industry requirements such as SAP modules for Oil, Gas or Retail companies, but basically, all those modules are just add-ons for their main platform, and they only introduce some business functionality while the platform is the same in terms of technical features. All these solutions have made SAP the world-renowned business application vendor with 250000 customers worldwide including 83% of Forbes 500.

 

SAP Security for beginners

 

So, when people talk about ERP Security they are likely to mean SAP because it’s the most common ERP System. However, there are many other systems developed by other companies such as Oracle, Microsoft, and Infor and these systems also deserve attention.

SAP NetWeaver

 

Now, let’s see how SAP ERP system looks like from user’s point of view. Simply saying, SAP ERP is a client-server application consisting of SAP NetWeaver ABAP application server and SAPGUI application as a client interface. SAP GUI tool connects users with the central SAP server. All data are transmitted between a client and server using DIAG protocol. This is a proprietary protocol developed by SAP. Looking ahead, this protocol doesn’t provide necessary security level by default and transfers data almost in the plain text. Only a kind of compression is in place, but there are tools that can decode it and, for example, obtain user passwords transmitted, as mentioned before, in the plain text.

 

When a user connects to the server, he can execute different functions. To perform any action, for example, create payment order, new user or fill in a form, he needs to execute a particular transaction that is responsible for this functionality. To execute this transaction, he needs to write a particular transaction name in SAP menu. The system will open a dialog window where the user can specify different parameters. For instance, if a user executes transaction SU01 which is used to create new users in the system, he will see a screen where he should fill in a form with all details about new user and then click the “Create” button. If he enters the information correctly, the new user will be created in the system. In case existing functionality is not enough, SAP customers can extend it by writing programs via SAP’s proprietary language called ABAP. Customers can write their own transactions using ABAP language, for example, if they have specific requirements for some forms that are used to create payment order or if they have specific business processes relevant only for their industry. Those programs, by the way, may have vulnerabilities because of developers’ mistakes, but we will cover it later.

 

However, connecting via SAPGUI and running transactions is not the only way to perform SAP functionality. As you will see later, SAP systems are very complex and the same action can be done by multiple ways, and needless to say, all those ways should be somehow secured. For example, the other ways how to execute functionality in SAP system are the following:

 

  • Running background job using RFC function (like RPC in Windows).
  • Calling the same function via SOAP interface – a web-based interface to run RFC programs remotely.
  • Executing Web Dynpro application. Web Dynpro is a web-based frontend for SAP System that can be used if users don’t have a client application and only have a web-browser.

SAP Services

 

Apart from SAP GUI application and SAP NetWeaver application server, SAP infrastructure includes multiple services that provide some management functionality. In real life, there are multiple application servers in one SAP System. The users connect to SAP Message Server first and then message server redirects their requests to one or another Application server.

 

SAP Message Server is a kind of Load balancing system, which role is to balance load on different application servers. In large organizations, there can be thousands of users connected with dozens of application servers via Message Server.

 

Another service which would be useful to know is SAP ICM, or Internet Communication Manager. It allows running transactions via web interface.

SAP Gateway is a separate service, which is usually enabled by default. It allows performing some functionality as a background job. It means that you don’t need to interactively log into the system. You can run a simple script that will automatically connect to SAP Gateway and perform some functionality. All the functionality is provided by means of RFC Functions. There are 30k+ RFC functions in SAP that can be called to perform almost every function in the system: from technical (such as create user and read table) to business ones (such as create vendor or payment order, close financial period, and so on).

 

There are many other services enabled in SAP by default and not very well described in the documentation. However, sometimes they provide very critical functionality. We will speak about them soon, but here is the first lesson, keep in mind that SAP is a very complex system with multiple services, so the first step in SAP Security should be analyzing if these services are enabled in your system and understanding all potential risks associated with them.

SAP terminology: Landscape, Instance, Client

 

Now let’s define some other SAP terms you need to know. The first and main one is an SAP Landscape. Usually, SAP Landscape is identified by three-symbol name – SID (System ID). As in traditional network, you need to have an identification to connect multiple systems in one network such as domain name, in SAP world we have SID that identifies so-called SAP Domain.

 

Traditionally, for each system there are 3 or 4 landscapes called production, quality assurance, test, and development. In most cases, Quality assurance and Test are combined in one Test landscape. Usually, all new programs and changes are developed in a development landscape. The development landscape is where consultants do the customization as per the company's requirement. When new development is done, companies transport these changes into the test landscape. In the test landscape the core team members and other members test the customization on the copy of real data. If everything is OK, they transfer all changes to Quality assurance landscape, where users can test everything on real data which are a copy of production data. After all tests, new programs are transferred to the production landscape where the live data of the company are recorded.

 

Now let’s talk about Instances. If you have a small system, you usually have one instance, which is actually one application server. If you have many users and want to enable some load balancing, you add more application servers (SAP Instances). Because the system should somehow differentiate application servers, each of them has an instance number. The instance number is a two-digit value from 00 to 99. SIDs of all application servers of one system are the same. It is important that every application server can be configured differently and some services can be enabled or disabled. It means that you need to check each and every application server to be sure that your landscape is secure.

 

The last thing we are going to talk about is SAP Clients. Assume you need to manage two or more separate business entities in one system because you don’t have enough resources to install two systems on a separate hardware. SAP Clients can resolve this issue. With this solution, you can manage multiple business entities in one system. Clients are essentially self-contained business entities or units within each SAP system. Using a web browser or one of SAP's special user interfaces, you log into a client in SAP to actually access and use the system. The client has its own separate master records and own set of "tables". The best way to grasp this idea might be to imagine a really large company like ExxonMobil, General Motors, or Honeywell. Within each of these large multinational organizations, you might have three or more other companies or business units. Each SAP client might be tied to a different business unit. Really big companies might have two or even three production clients for a single SAP component like ERP. For example, the company might structure its clients around discrete business groups (Chevrolet, Cadillac, and GMC) or by geography (Americas, Europe, and Asia). When you log into SAP, you choose the specific client you need to log in. Each one is assigned a unique three-digit number (from 000 to 999), which you are required to know and type in at login time. This makes it easy to distinguish between clients.

 

In theory, users of one business unit are connected with one client and restricted to access any data of other business unit located in the separate client, but in reality there are multiple ways how they can escalate their privileges and get access to OS or Database directly where all data are stored without any separation. You also need to know that there are some clients which are installed by default such as clients 000 001 and 066 and there are some default users preconfigured in those accounts, usually it’s the most common and, unfortunately, dangerous vulnerability.

 

SAP Platforms

 

SAP uses multiple platforms to build their business applications. While NetWeaver ABAP platform (the core of ERP) is the most widespread system, and previous information was mainly about SAP NetWeaver ABAP, there are many other platforms. On top of those technical platforms SAP provides different business applications. Here is a list of SAP Platforms:

 

  • SAP R/3 (old and not supported)
  • SAP NetWeaver ABAP (still the most widely used)
  • SAP NetWeaver J2EE (less Popular)
  • SAP Business Objects (for data analytics)
  • SAP HANA (will be the most common soon)
  • SAP Mobile Platform (for mobile access)
  • SAP Afaria (for mobile device management)
  • Etc.

 

SAP NetWeaver ABAP is the main SAP Platform. Almost all business applications, which are developed to automate different business processes of an organization such as Enterprise Resource Planning or Supply Chain Management are based on SAP NetWeaver ABAP Platform. Their security is of a great importance, once somebody gets access to these applications, he can stop mission-critical business processes, commit industrial espionage of even fraud.

SAP Netweaver J2EE is usually considered as an additional platform mainly for applications used by IT department. The objective of such applications is primarily the integration of different business systems based on ABAP engine. Examples of systems based on SAP NetWeaver J2EE include SAP Portal (a starting point for access to all SAP and non-SAP applications, or SAP Process Integration, a system that simplifies data transfer between different systems. Although those systems usually don’t store critical data directly but transmit them or provide access to them, if somebody can compromise, say, SAP PI system, he can get control over all mission-critical processes, so the consequences may be even more hazardous comparing to attacks on particular ABAP-based system such as SAP ERP.

 

SAP Business Objects is less popular platform and mainly used in analytics tools such as SAP Business Intelligence. If an attacker hacks this system, he can modify some analytics results so that a management will take wrong decisions.

 

SAP HANA is a new but quite popular platform with more than 6400 installations. SAP HANA is, first of all, an in-memory database but it also contains application server called SAP HANA XS. Later it will be a base platform for every SAP Business application (Currently supports ERP, CRM, HR…) and will replace the old SAP NetWeaver ABAP platform. If somebody can compromise this platform, consequences will be the same as after hacking SAP NetWeaver ABAP – espionage, sabotage, and fraud.

 

Here are some resources that can help you to know more about SAP systems and now, since you have already known what SAP is, we are ready to talk about SAP Security in particular.

 

Related sources

 

Well this is a continuation of my previous blog on XSS (Cross-Site Scripting) - Overview and Contexts and this time I will continue with attack methodology and solutions. Actually if we think closely we can realize that each attack should have a methodology through which an attacker try to bypass a context or any filter. If we can follow this below methodology we can be at least sure that whether there is an XSS or no XSS in the particular Injection Point.

 

Though the examples shown here are from PHP but are applicable to any sever side languages. And using the help of this methodology we can later able to achieve a secure solution or XSS sanitizer. Let's proceed it on the basis each contexts showing simple examples.

 

Attack Methodology:

 

Script Context Attack Methodology

 

scnewdiagram.JPG

 

We would use simple scripting to bypass the context and here it has been consider as 3 step process. So here the Injection point has been reflected back as a part of variable of a script tag and there could be two possibilities as from server wither use single or double quotes. Semicolon in the beginning is statement terminator here and terminate the variable value (variable declaration has been closed), any event handler can be use like  alert, confirm or prompt but in real life scenario the attacker never use such simple, so this is only a proof-of-concept for JavaScript execution. The last semicolon in the injection point will take care of the end of variable declaration.

 

If the first two injection point fails then we can also prematurely closing the script tag as the variable value  and execute JavaScript of our choice like in the third step. If any of the steps could not bypass the context then there is no bypass possible for this context. All these steps here are browser independent but we need to consider as well that chrome has a XSS Filter and not good for the testing.

 

So just by looking into the source code we can find out the context and based on the context we can apply the respective attack methodology to find whether there is a XSS bypass. For a example we can check Edit fiddle - JSFiddle

 

 

Attribute Context Attack Methodology

 

acdiagram11111.JPG

 

In a very similar way we can check the Attribute Context which is again a 3 step process. Here we use a Div tag and class as an attribute. Injection point is reflected back in the value of the class attribute the injection will land here. We can use any event handler, here it has been use onmouseover just to show the proof of concept. The first two steps are browser independent but not the last one as back tick works on old Internet Explorer only.

For a example we can check Edit fiddle - JSFiddle

 

 

 

Style Context Attack Methodology

 

forslides.JPG

 

Modern browsers does not allowed you to execute via style so in spite of 3 step process it is more specific to old Internet Explorer. The injection point has been reflected back as the value to the attribute style. This is actually a dynamic CSS. First step is simple calling of event handler where in the next step multi line comment has been use as an old trick. The 3rd and 4th steps steps are only use case of encoding, 3rd step encoded in hex or decimal form as both start with & sign while last step is CSS escaping.

 

 

 

URL Context Attack Methodology

 

Picture1.jpg

 

Injection point here has been reflected back as a value of href or as a URL. Here to make it better we use different encoding options.

First step is plain JavaScript based URI, second is bit complicate JavaScript based URI with small and lower cases and encoded the parenthesis as URL encoded form. Html5 encoding has been used in the third step inside the word JavaScript. Fourth one is database URI and last one a vbscript.

By using all these steps it can be find out that whether the context is XSS by-passable or not. All of the steps are browser friendly except the last one.

 

Encoding is also need to get consider when there is a explicit decoding from server die response otherwise it doesn't make sense. There are huge numbers of ways to encode and this it itself a different interesting topic to discuss.

 

Picture1.jpg

 


Solutions:

 

Custom XSS Solutions:

They are very common and use by many applications around these days as they are widely and easily available specially on Github.

Let's check how strong are these solutions:

 

RemoveXSS:

 

1.jpg

 

 

Can be found in the Github, first array consist of blacklisted words, second list consist of event handler for explicitly mentioned these keywords. The main purpose is to filter these keywords from the input. Are also popular as  filterXSS or noXSS.

 

But if we use the exemption then it could be bypassed easily which we have seen also in the attack methodology as there are number of ways to change this keywords.

 

width: ex/**/pression(alert(1))

ja&Tab;vasc&NewLine:ript&colon;alert&lpar;1&rpar;

 

 

cleanInput:

 

2.jpg

 

Very popular on the Github. It consist of array of 4 elements, first look for script tag, second for <> tag, while third looking for style tag and the fourth one for multi line comment and whenever this filter found these elements then it just remove it. This filter works on the basis of the understanding the input would contain any of these elements for XSS.

 

But this could be again bypassed by using a half open tag as below.

 

<img src=x id=confirm(1) onerror=eval(id)

 

 

 

sanitizeCSS:

 

3.jpg

 

This filter can only use in the style block and this state, the first regular expression look for URL and second try to capture the small left parenthesis.

To understand the code we use the tool regexpert, so when we input the regular expression then we can visualize the regular expression as well.

 

4.jpg

5.jpg

 

Bypass is possible for this filter as well as per the below example

 

width:expression&#x28;alert&#x28;1&#x29;&#x29;

 


detectXSS:

 

6.jpg

 

In this filter the first array looks for event handler while the second looks for the keyword with it's own way. Bypass is possible here as well as given below.

 

7.jpg

 

 

Summary of Bypasses:

 

8.jpg

 

As we can see from the last examples, not only these the most used best 10 customized solutions currently by the web applications are by passable.

If you see the above summary you can even noticed which context is valid. So one should carefully consider these solutions and these are not fool proof. It is always better to test as per the attack methodology shown above and develop our own solution based on these custom solutions then our filter will be more stronger. We should also keep in mind that filters and solutions should be in layers starting from WAF, client side validation, server side validation and sanitization.

 

Based on the attack methodology and contexts if we can add the below solutions with the customs one our filter would definitely become stronger. Some of them are shown below:

 

Picture1.jpg

 

Like attributeContextCleaner where the filter just replace 3 elements to prevent the XSS in attribute context.

Picture2.jpg

 

Another one with styleContextCleaner where the filter just replace 6 elements to prevent the XSS in style context. Id we just follow the attack methodology we will able to understand how we could restrict the XSS.

 

Picture3.jpg

 

Similarly we can have urlContextCleaner, which is little different from the other contexts. In order to protect JavaScript execution we are going to use regular expression which will force us to use http or https or even ftp in way where we can’t execute JavaScript.

 

 

Currently there are others injection points as well like files, images, video, other things to upload it has been clear that more injection points means more chances to XSS. So we have to carefully provide option in out web applications. for example WISIWYG (What You See Is What You Get) editor are more close to vulnerability.

 

100.jpg

 

 

Further model to prevent XSS can find in  XSS (Cross Site Scripting) Prevention Cheat Sheet from OWASP

 

The attack methodology and solutions shown here may not work with HTML5 as it has various new options but as a whole still iit has not been used in huge number of web applications yet. you may see the HTML5 Security Clean Sheet  and  HTML5 Security Cheat Sheet from OWASP for the further options.

 

 

Happy XSSing!

 

(Most of these details, screenshots and explanation has been shared from Ashar's Talks) If you want to know more over the XSS I would definitely recommend to visit the slides from the Ashar's Talks (Presentations by Ashar Javed)  and the blogs(on XSS) where he nicely explains over his works, findings and his bypasses.

XSS - Cross-Site Scripting is no more new in the world of IT Security in fact one of the most popular and common vulnerabilities. There are many blogs, clean sheets, security tips/tricks, advices and other resources available in the web. This blog is a share of my learning which I am currently doing for the last few months with my colleague and friend Dr. Ashar Javed ( A well known Security Researcher, Speaker of Black Hat, DeepSec, OWASP.... an XSSer .. an Ethical Hacker). Well to be frank I am not all from security background (SAP Consultant/Developer) but my learning make me much aware over security now and I can also say that I am also responsible for security. Let's begin..

 

I believe we heard the definition of  XSS, at least in this SCN Space, we have seen some common definitions from the web:

as per Wikipedia "XSS enables attackers to inject client-side script into web pages viewed by other users".

 

as per  OWASP (the free and open software security community) "Cross-Site Scripting attacks are a type of injection problem, in which malicious scripts are injected into the otherwise benign and trusted web sites."

 

There are many more, one such is candidate definition and for me it is the Developer's Definition: "An XSS attack occurs when a script from an untrusted source is executed in rendering a page"  These questions come  to our mind when we follow this definition and are quite valid.

 

  • Script. JavaScript, any web-enabled script language, or any character sequence that sort of executes in the browser?
  • Untrusted. What does trusting and not trusting a script mean? Who expresses this trust or distrust?
  • Source. Is it a domain, a server, a legal entity such as Google, or the attacker multiple steps away in the request chain?
  • Executed. Relates to "Script" above. Does it mean running on the JavaScript engine, invoke a browser event, invoke an http request, or what?
  • Rendering. Does rendering have to happen for an attack to be categorized as XSS?
  • Page. Is a page a prerequisite for XSS? Can XSS happen without a page existing?

 

Rendering also involves communicating to Server specially when there is input option in client side.

 

So what is XSS or more precisely what can an Attacker do with XSS? Let me show you a basic diagram on this, may be too much "basic" for you but it's the truth.

 

Capture.PNG

XSS is nothing but a security bug that can affect web applications. It can allow an attacker to add their own malicious code (through JavaScript, VBScript, Flash, HTML, JSON, ActiveX etc.) onto the HTML pages displayed to your users. And once executed by the victim's browser, this code could then perform actions such as completely changing the behaviour or appearance of the application, stealing private data, execute commands/malicious scripts or performing actions on behalf of the user.

 

Ex. Attacker steal the session cookie of the Admin and login as admin and can change everything. Others typical possibilities are port scanning, phishing, keylogging etc. And it become more dangerous when its get saved to the Databases as it shown in the diagram, also known as Stored XSS or Persistent XSS which requires server side interpretation of the query and data storing.

 

 

But why XSS? There are also other vulnerabilities. Le's see some facts

 

According to latest White-hat Security report, 47% of web applications have XSS vulnerability:

vulnability.JPG

 

 

According to Google Vulnerability Reward Program's Statistics, XSS is the most reported issue:

vulnability-2.JPG

 

According to "Open Sourced Vulnerability Database"  XSS is at #1:

vulnability-3.JPG

 

 

Believe me there are lot of these facts which state XSS is currently the popular one.

 

 

And its is clear now a days that XSS vulnerabilities most often happen when user input is incorporated into a web server's response (i.e., an HTML page) without proper escaping or validation. I think what we all are interested to know is how we can fixed them or stop the attackers. Before we come to any conclusion let's see some important aspects of understanding XSS

 

 

Injection Points: These are the user input available in web applications through which the Attacker can enter or injects scripts

  • Insert /Edit Text
  • Insert/Edit Image
  • Insert/Edit URL
  • Set Attributes
  • Insert/Upload File
  • Insert/Upload Video


Context is an environment where user-supplied input or input from other application(s) eventually ends-up or starts living.

 

“Context Is King for All Areas of IT Security”  At simple it means attackers use these Injection points to send their scripts and whatever they input in web app ends up somewhere and where it ends up called as context. Actually all the attacks and bypasses are based on these contexts. So let's first understand the contexts briefly:

 

(All examples are based on PHP and standard HTML)

 

HTML Context:

htmlcontext.JPG

 

In this context the user inputs ends up or will be reflecting back in html tag.To understand it let's see an example.

 

Let's say we are searching a string "xyz" in the following web http://www.ea.com/search?q=“xyz

From the source code of the result we can see that here the user input (searched string) is reflect back into a <span> tag and <title> tag or more speciously in a HTML tag

 

ea1.JPG

ea2.JPG

indiatimes_1.JPG

 

 

 

Attribute Context:

 

attribute_1.JPG

 

In this context the user inputs ends up or will be reflecting back as a part of attribute value.To understand it let's see an example.

 

Here we search a string "JUNK" in the web http://www.ea.com/search?q=“JUNK  and when we see the source code we found that the input reflected back in the value of an attribute like "title" or "href" of Anchor tag <a>


 

attr1.JPG

attr2.JPG

 

 

 

Script Context:

 

scripblock.JPG

 

In this context the user inputs ends up or will be reflecting back as a part of variable in script tag.To understand it let's see an example.

 

Here we search the string "xxxxxxxxx" in the web  http://search.health.com/results.html?Ntt=xxxxxxxxxx and when we see the source code we find that the input reflected back as part of variable declaration searchString and searchTerms

 

In both example quotes are different, it may be single quote or double quote.

scr1111.JPG

scr3333.JPG

 

 

 

URL Context:

 

urlcccc.JPG

 

In this context the user inputs ends up or will be reflecting back as a value of href of anchor tag. Even it can be iframe tag and source attribute. All Content Management System support url context.

 

Now a days it is a common feature specially in an wysiwyg editor "What You See Is What You Get" to insert a link and in this way user supply URL directly.

 


wysiwygimp.JPGwysiwyg3.JPG



 

Style Context:

 

 

stylecdef.JPG

 

In this context the user inputs ends up or will be reflecting back as part of the style attributes or style tags. So in this below example we can see a developer guide from ebay where user can input a style. And it provide option to attacker to input style to bypass.


stylec.JPG

ebbbbbbbbbbayyy (1).JPG

 

 

 

Let's summarize all the contexts so normally when an user provide any input to the Injection points in an web application, it goes to the the server and from there it reflect back to the user's page with different contexts. It can be one of contacts mentioned above.

 

contextdiagram.JPG

 

 

Not only Contexts we also need to know over the Attack Methodology as well, all these would help us to understand the XSS very deeply.. which I will publish in my next blog.

 

I also come across with some nice series of blogs by Alexander Polyakov on Securing SAP Systems from XSS vulnerabilities. It is always good to know over different aspects of those things which you are interested to learn.

 

(Most of these details, screenshots and explanation has been shared from Ashar's Talks) If you want to know more over the XSS I would definitely recommend to visit the slides from the Ashar's Talks (Presentations by Ashar Javed)  and the blogs(on XSS) where he nicely explains over his works, findings and his bypasses.

Welcome back to our Threat Modeling blog. I think it is quite interesting and helpful to talk about the introduction of Threat Modeling @ SAP.

 

In 2012 my boss asked me to lead a project introducing Threat Modeling into SAP development. I had initial conversations with a colleague who was driving the topic for quite some time. To get an overview I asked that colleague to give me an explanation on a whiteboard who is now and should be involved in this project. After 10 minutes the whiteboard was full with teams, names of persons, and organizations that where involved so far. Looking at this complex stakeholder landscape, it was clear to me that a project setup involving many people spread across different organizations is not what I wanted to manage. So I raised a thought provoking question to my colleague, if you could work with just one person to drive this topic, who would you pick?

 

The answer to the question was him and I, which in the end, disappointed other colleagues that were not included. Unnoticed by me, I became quite famous with this 2 person working arrangement, but unfortunately not the fame you typically seek. A year after the project started, while speaking with a colleague, he stated: we have not previously met, but I was very disappointed when you stopped collaborating with us on Threat Modelling. Luckily, I did not know about unwanted fame in the beginning, which would have bothered me. Not knowing in the beginning allowed us to complete the outlining of the basic concept for Threat Modeling @ SAP in a few working sessions.

 

We came to the conclusion that the methodology needs to have some basic characteristics. It should be self-contained to avoid a huge number of preconditions to be met before a development team starts using the process. It should be time boxed to achieve concrete results in an acceptable time frame. It should be done with the architects and developers that work in the heart of the product. It should center on our existing security product standard. It needs to fit into any development process and approach. And last but not least, it should help increase the efficiency in code scans and testing.

 

The result was a simple three step methodology consisting of 1) understanding the architecture of a use case, 2) analyzing this use case’s threats in detail (based on the product standard requirements converted into threats), and finally, 3) prioritize the identified threats on the products backlog.

 

We did not spot the obvious obstacle (at least from hindsight) right from the beginning. When we applied the methodology in the first workshops we immediately saw that you cannot easily scale this approach across a huge product. Eating such a huge product piecewise will take a considerable amount of time. With this in mind, we concentrated on the use case based approach for the time being, and ignored a high level architecture approach for later on.

 

Overall, we did more than a hundred different Threat Modeling workshops across the SAP product portfolio and the basic idea of our methodology works very well.

 

Next time let me talk about this methodology in detail, but in closing let me pose the following question to you. Should Threat Modeling be mandatory in your opinion?

 

 

 

Author: Oliver Kling

SAP has released the monthly critical patch update for December 2015. This patch update closes 26 vulnerabilities in SAP products (19 Patch Day Security Notes and 7 Support Package Security notes), 16 of which are high priority. This month, two critical vulnerabilities found by ERPScan researchers Alexander Polyakov, Mathieu Geli and Vahagn Vardanyan were closed.

 

The largest part of vulnerabilities closed by this update relates to the "other" type according to SAP’s blog post. This is quite typical for business applications such as SAP. Due to their uniqueness and complexity, there are much more uncommon vulnerabilities comparing to traditional software where, as our research Analysis of 3000 SAP Security notes revealed, configuration issues constitute only 2%. Last year we analyzed SAP Security Notes by type, and about 300 vulnerabilities of almost 3000 were defined as configuration issues and about 150 were uncategorized.  Configuration and other unusual issues in SAP are 5 times more common than in traditional products, thus a significant part of security measures falls on shoulders of administrators.

 

Issues that were patched with the help of ERPScan

 

Below are the details of the SAP vulnerabilities  that were found by ERPScan researchers.

 

  • An Authentication bypass vulnerability in SAP Mobile Platform SysAdminWebTool servlets (CVSS Base Score: 6.8). Update is available in SAP Security Note 2227855 (version of the note: 4). An attacker can use Authentication bypass vulnerability to access a service without any authorization procedure and use service functionality that has restricted access. This can lead to information disclosure and privilege escalation. Also, it can be exploited for remote file overwrite, denial of service, SMB relay attack, etc.
  • An Implementation flaw vulnerability in SAP Log Viewer (CVSS Base Score: 4.6). Update is available in SAP Security Note 2240946 (version of the note: 3). Depending on a problem, an implementation flaw can cause unpredictable behaviour of a system, troubles with stability and safety. Patches solve configuration errors, add new functionaluty and increase system stability.

The most critical issues closed by SAP Security Notes December 2015

Some of our readers and clients asked us to categorize the most critical SAP vulnerabilities to patch them first. Companies providing SAP Security Assessment, SAP Vulnerability Assessment, or SAP Penetration Testing services can include these vulnerabilities in their checklists. The most critical vulnerabilities of this update can be patched by the following SAP Security Notes:

 

  • 2234226 (version of the note: 2): SAP TREX/BWA has an OS command execution vulnerability (CVSS Base Score: 7.5 ). An attacker can use this vulnerability to run operating system commands without authorization. Executed commands will run with the same privileges as the service that executes them. The attacker can also access arbitrary files and directories located in the SAP server filesystem, including application source code, configuration, and critical system files. They can obtain critical technical and business-related information stored in the vulnerable SAP system. Install this SAP Security Note to prevent risks.
  • 2067570 (version of the note: 3): SAP BI Servers, security & CrystalReports viewing in BI platform has a denial of service vulnerability (CVSS Base Score: 7.1). An attacker can use a Denial of service vulnerability to terminate a process of the vulnerable component. For this time nobody can use this service, this fact negatively influences on business processes, system downtime and, as a result, business reputation . Install this SAP Security Note to prevent risks.
  • 2227169 (version of the note: 3): SAP 3D Visual Enterprise Author, Generator and Viewer has a remote command execution vulnerability (CVSS Base Score: 6.8 ). An attacker can use Remote command execution vulnerability for unauthorized execution of commands remotely. Executed commands will run under the same privileges as the  service that executed the command. The attacker can access arbitrary files and directories located in a SAP server filesystem including application source code, configuration and critical system files. They can obtain critical technical and business-related information stored in the vulnerable SAP system. Install this SAP Security Note to prevent risks.
  • 2165583 (version of note: 7): SAP HANA has an incorrect system configuration vulnerability (CVSS Base Score: 6.6). SAP HANA internal services could be accessed without authentication if the HANA system is insecurely configured and no other security measures are in place. This could endanger system availability, data confidentiality and integrity. It is recommended to install this SAP Security Note to prevent risks.

 

It is highly recommended to patch all those SAP vulnerabilities to prevent business risks affecting your SAP systems.

 

SAP has traditionally thanked the security researchers from ERPScan for found vulnerabilities on their acknowledgment page.

This post by SAP Product Security Response Team shares information on Patch Day Security Notes* that are released on second Tuesday of every month and fix vulnerabilities discovered in SAP products. SAP strongly recommends that the customer visits the Support Portal and applies patches on a priority to protect his SAP landscape.

 

On 8th of December 2015, SAP Security Patch Day saw the release of 19 security notes. Additionally, there are 7 updates to previously released Patch Day Security Notes.

____________________________________________________________________________________

 

Security Notes vs Vulnerability Type - December 2015

VT.PNG

Security Notes vs Priority Distribution (July - December 2015)**

ND.PNG

 

Patch Day Security Notes are all notes that appear under the category of "Patch Day Notes" in SAP Support Portal

** Any Patch Day Security Note released after the second Tuesday, will be accounted  for in the following SAP Security Patch Day.


To know more about the security researchers and research companies who have contributed for security patches of this month visit SAP Product Security Response Acknowledgement Page


Do write to us at secure@sap.com with all your comments and feedback on this blog post.

 

Yours,

SAP Product Security Response Team

Actions

Filter Blog

By author:
By date:
By tag: