1 2 3 15 Previous Next

Security

213 Posts

Since March 2016 patch day, SAP has started to publish CVSS Base scores in security notes based on CVSS version 3.0 standard. As a result of complete adoption of CVSS version 3.0, including recommended prioritization, security notes that were classified as ‘High’ in version 2.0 may now be classified as ‘Medium’. Customers are strongly advised to review their internal guidelines to IT teams in interpreting and analyzing the note priorities released by SAP.

Adoption of CVSS version 3.0 in SAP:

Across all (almost) vulnerability types, SAP expects a slight increase in CVSS Base Scores in version 3.0, compared to version 2.0. The CVSS version 3.0 documentation includes a list of comparisons of public vulnerabilities scored via CVSS version 2 and version 3.0. Listed below are some reasons for these differences in my opinion.

The version 3.0 standard provides a comprehensive assessment of potential risks associated with a vulnerability with more factors to consider than the CVSS version 2 standard. For example, most cross-site scripting (XSS) vulnerabilities, when exploited allows an attacker to inject and run malicious code in victim's browser. CVSS version 2 does not have a way to capture the change in impact from the vulnerable web server to the impacted browser. In version 3.0, the Scope metric allows us to assess the impact to the browser where a differentiation is made between vulnerable component and impacted component.  A typical XSS vulnerability has a base score of 4.3 in version 2 whereas a base score of 6.1 is assigned in version 3.0.

Overall, SAP expects version 3.0 Base scores to be higher than CVSS version 2, but bear in mind that CVSS version 2 scores are always relative to the "target host operating system", whereas version 3.0 scores are relative to the vulnerable component, or the impacted component if there is a scope change. In other words, CVSS version 3.0 will provide a better indication of the relative severity of vulnerabilities because it better reflects the true impact of the vulnerability being rated in software components.


Why SAP provides only CVSS version 3 Base score in security notes?

The CVSS scores provided by SAP in security notes are CVSS Base scores. SAP does not provide Temporal or Environmental score for vulnerabilities fixed in the security notes. We believe the Temporal score would have limited value to customers where two of the three factors affecting the Temporal score would never change (The Remediation Level would always be "Official Fix", and the Report Confidence would always be "Confirmed"). Further, the third factor (Exploit code maturity) would be “Proof of Concept” in most cases. As a result, Base score deducted by a constant value of 0.7 (based on the above values) would always be the Temporal score. For example, a Base score of 7.0 will always yield to a Temporal score of 6.3. Finally, SAP cannot compute the Environmental Score because this score is specific to the customers' environment (about which SAP has no or very little insight).

Does SAP publish CVSS version 3.0 scores for all security notes released?

Starting from March 2016 patch day, All ‘patch day notes’ will carry CVSS version 3.0 Base scores. However, in extraordinary situations (like 0-day disclosures), the security note priority may be escalated to 'Very High' (Hot News) irrespective of the CVSS version 3.0 Base metric score.

For more information:

The CVSS version 3.0 documents are available online on FIRST’s website at https://www.first.org/cvss


Related blog posts:

Introduction to CVSS. How SAP uses it?

Changes to CVSS in version 3.0

CVSS Version 3.0:


CVSS version 3.0 was released on June 10th 2015 after been under development for 3 years. This was overseen by the CVSS Special Interest Group (SIG) with inputs from representatives of a broad range of industry sectors, from banking and finance to technology and academia.


What is new in CVSS version 3.0?


There are many improvements introduced in version 3.0. In this post I will cover only the major improvements in Base metric group, which is the metric group that SAP uses.


If you need more information about the Base metric group, please refer to CVSS version 3.0 specification document (section 2).


1) Scope, Vulnerable Component, and Impacted Component     


One of the major development goals for CVSS version 3.0 was to solve the ‘Scope’ problem. Let me explain what a ‘Scope’ problem is.


‘Scope’ problem: In CVSS version 2, vulnerabilities are scored in relation to the “target host operating system”. As a result, vulnerabilities which have severe impact to SAP applications but limited impact to the target host operating system are rated as less severe (‘partial impact’). For example, a vulnerability in SAP application allows an attacker to perform a Denial-of-Service (DoS) attack with impact to the availability to the vulnerable SAP application. Even with a total take down of the vulnerable SAP application would only result in a ‘Partial’ (impact) rating for Availability metric in CVSS version 2. A ‘Complete’ (impact) rating for Availability can only be given if the host operating system can be taken down as well, per CVSS version 2 guidance.


This is clearly a problem for many application software vendors, including SAP. As a result, a solution is introduced in CVSS version 3.

To address the issue, CVSS version 3 introduces ‘Authorization Scope’, or simply ‘Scope’ metric to the Base metric group.  This new metric allows us to capture the extent of a vulnerability with impact that extends beyond the vulnerable component.


The definition of scope refers to the collection of privileges defined by a computing authority (e.g. an application, an operating system, or a sandbox environment) which grant access to computing resources (e.g. files, CPU, memory, etc).


When we have two discrete components which manage privileges to computing resources separately, they represent separate (authorization) authorities. Referring back to our DoS attack example, let’s say the vulnerable SAP application is managed by "Authority A," while the host Operating System is managed by "Authority B."

scope_representation.png

(Credit: CVSS user guide) As depicted in the above diagram, CVSS version 3.0 leverages the Exploitability metrics to assess the vulnerable component in isolation. On the other hand, the Impact metrics are scored relative to the impacted component. When the vulnerable component is the same as the impacted component, there is no scope change. However, a scope change has occurred when there are impacts to components outside of the vulnerable component. In these cases, Confidentiality, Integrity and Availability impact metrics should be scored to reflect impact to either the vulnerable component, or the impacted component, whichever is most severe.


Going back to our DoS attack example above, in CVSS version 3, we can rate the Availability impact as ‘High’ (maximum score) to represent the real impact on the vulnerable application irrespective of its impact on Host Operating System. For cases where the Availability of the Host Operating System is also impacted, the increased severity is represented by the ‘Scope’ metric – scope changed.

Scope_calculation.PNG

(Credit: CVSS user guide) The diagram above illustrates the ‘Scope’ metric calculation.


2) Explanation of   Impact metric score calculation


a)  ‘Primary Impact’ versus ‘Reasonable Final Impact’


In version 3.0 the ‘Impact metric’ (CIA - Confidentiality impact, Integrity impact and Availability impact) calculation represents the ‘reasonable final impact’ possible caused by a successful vulnerability exploitation. In CVSS version 2, the impact calculation only considers the ‘primary impact’. CVSS version 3 is superior in considering the big picture in my opinion.


For example, a vulnerability resulting in disclosure of administrator credentials was rated with ‘partial’ impact to Confidentiality (with no impact to Integrity or Availability) in CVSS version 2. Yet, we should recognize the potential impact (or consequences rather) would lead an attacker to obtain administrative privileges. In version 3.0, the same vulnerability would be rated with ‘High’ impact to CIA.


b) ‘None, Partial, Complete’ versus ‘None, Low, High’


In CVSS version 2, the possible values for CIA impact were ‘None, Partial and Complete’ which are replaced by ‘None, Low and High’ in version 3.0. The new metric values reflect the overall ‘degree of impact’ caused by an attack. This is a departure from the overall percentage of the systems impacted by an attack in CVSS version 2. This change can be best explained via the ‘Heartbleed’ vulnerability (CVE-2014-0160). This ‘buffer over-read’ vulnerability which enabled an attacker to read up to 64 KB of victim’s memory is rated as having a Base metric score of 5.1 (NLN|PNN) in CVSS version 2. A successful exploitation of this vulnerability can result in only some (up to 64 KB) amount of information disclosure. However the ‘partial’ rating provided for ‘Confidentiality Impact’ does not consider the sensitivity of the data (or information) which is disclosed. Since CVSS version 2 cannot capture the sensitivity of data under attack, a vulnerability which results in disclosing information of lower sensitivity like version information of a web server, is also rated with the same Base metric score of 5.1. Yet in the ‘Heartbleed’ vulnerability, information of higher sensitivity like secret keys used for X.509 certificates, user names and passwords, emails, instant messages, business critical documents is disclosed. In version 3.0, ‘Heartbleed’ vulnerability has a Base metric score of 7.5 (NLNN|UHNN). You can see the Confidentiality impact is rated as ‘High’ considering the sensitivity\criticality of data under attack, even though the data is less than 64 KB.


3) Attack Complexity


Access Complexity (from CVSS version 2) conflated two issues: 1) Any condition beyond the attacker’s control that must exist or occur in order for the vulnerability to be successfully exploited (for example a software race condition, or a specific configuration setting), and 2) the requirement for human interaction (for example, requiring a user to click on a button or a link in case of ‘clickjacking’ or phishing attack scenarios). Therefore, Access Complexity has been separated into two metrics in CVSS version 3 - Attack Complexity (which addresses the former condition), and User Interaction (which addresses the later condition).


4) Privileges Required


The new metric – ‘Privileges Required’ replaces the Authentication metric of CVSS version 2. Instead of measuring the number of times an attacker must separately authenticate to a target system, Privileges Required captures the level of access required for an attacker to mount a successful attack. In CVSS version 2, rating of ‘Single’ for Authentication metric was unable to distinguish whether an attacker needs to have low level (for example read-only) privileges or high level (for example Administrator) privileges to successfully exploit a vulnerability.


Summary of all the changes introduced in CVSS version 3.0 compared to CVSS version 2 can be found here (section 2.9)


For more information:

The CVSS version 3.0 documents are available online on FIRST's website at https://www.first.org/cvss


Related blog posts:

Introduction to CVSS. How SAP uses it?

How to interpret SAP's CVSS score?

SAP has released the monthly critical patch update for April 2016. This patch update closes 26 vulnerabilities in SAP products including 19  SAP Security Patch Day Notes and 7 Support Package Notes. 8 of all Notes were released after the second Tuesday of the previous month and before the second Tuesday of this month.

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

SAP Security Notes April 2016 by priority

Most of the discovered vulnerabilities belong to the SAP ABAP applications security.

SAP Security Notes April 2016 by platforms

The most common vulnerability type is Missing authorization check.

SAP Security Notes April 2016 by type

This month, 5 critical vulnerabilities identified by ERPScan’s researchers Nursultan Abubakirov, Dmitry Yudin, and Vahagn Vardanyan were closed.

How 2 DoS vulnerabilities can allow full system compromise

 

Two of the off-schedule patches addressing Denial of Service vulnerabilities discovered by Dmitry Yudin ([1] and [2]) were released on March, 14. On March,16 at the Troopers Security conference ERPScan director of SAP cyber security services Dimitry Chastuhin showed how to execute code remotely using these 2 DoS, one configuration mistake, and race condition vulnerability.

 

His presentation titled “Exploiting the unexploitable” proved that even low-impact vulnerabilities can be used together to gain full administrative access to the system. Since patching process on a real SAP landscape is time-consuming and costly, the idea to fix only the most dangerous security issues seems rather tempting, but, as we can see, completely insecure.

 

According to responsible disclosure rules, we can’t give any details of this attack vector before 90 days after disclosure.

 

Issues that were patched with the help of ERPScan

 

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

 

  • A Denial of service vulnerability in SAP Enqueue Server (CVSS Base Score: 7.5). Update is available in SAP Security Note 2258784. 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, which negatively influences on  business processes, system downtime and business reputation.
  • A Denial of service vulnerability in SAP Internet Communication Manager (CVSS Base Score: 7.5). Update is available in SAP Security Note 2256185
  • A Denial of service vulnerability in SAP jstart (CVSS Base Score: 7.5). Update is available in SAP Security Note 2259547.
  • An XML external entity vulnerability in SAP UDDI (CVSS Base Score: 7.1). Update is available in SAP Security Note 2254389. An attacker can use an XML external entity vulnerability to send specially crafted unauthorized XML requests which will be processed by XML parser. An attacker can use an XML external entity vulnerability to get unauthorised access to OS filesystem.
  • A Cross-site scripting vulnerability in SAP UR Control (CVSS Base Score: 6.1). Update is available in SAP Security Note 2201295. 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 research.

 

Other critical issues closed by SAP Security Notes April 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:

 

  • 2262710: SAP HANA DP Agent has a Denial of service vulnerability (CVSS Base Score: 7.5 ). 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, which negatively influences on  business processes, system downtime, and business reputation. Install this SAP Security Note to prevent the risks.
  • 2262742: SAP HANA DP Agent has a Missing authorization check vulnerability (CVSS Base Score: 7.3 ). An attacker can use a  Missing authorization check vulnerability to access a service without authorization and use service functionality that has restricted access. This can lead to information disclosure, privilege escalation, and other attacks. Install this SAP Security Note to prevent the risks.
  • 2252191: SAP HANA XS Advanced Java Runtime has a Remote command execution vulnerability (CVSS Base Score: 7.3 ). An attacker can use a Remote command execution vulnerability to execute commands remotely without authorisation. Executed commands will run with the same privileges as the service that executed the command. An attacker can access arbitrary files and directories located in a SAP server filesystem including application source code, configuration, and critical system files. It allows obtaining critical technical and business-related information stored in the vulnerable SAP system. Install this SAP Security Note to prevent risks.

 

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

 

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

We (The SAP Product Security Response Team) have received many questions from our customers on how SAP uses the Common Vulnerability Scoring System, also known as CVSS. This blog is the first post in a series that aims to provide an insight into CVSS and how it is used in SAP.

Background: In the last 5 years, SAP has been using CVSS to communicate the severity of vulnerabilities fixed in SAP security notes. SAP security notes are released on the second Tuesday of every month, known as SAP security patch days. We also use CVSS to prioritize our engineering effort internally to triage product security vulnerabilities. SAP is an active member of the CVSS Special Interest Group (SIG), and actively contributes to the development of CVSS version 3.0, the latest CVSS version.

What is CVSS?

CVSS is an open, vendor-neutral, technology-independent framework for communicating the characteristics and severity of software vulnerabilities. In practice, CVSS scores can be used to rate the severity of security vulnerabilities. CVSS can be applied to a very wide-range of software products including operating systems, web applications, security products (like firewalls, antivirus software), databases, etc.

CVSS consists of three metric groups: Base, Temporal, and Environmental. In-depth details of these metric groups can be found here. SAP focuses on the Base metric group only, because we believe it will bring the most value to our customers, and represents the intrinsic characteristics of a vulnerability. The Base metric group is constant over time and across user-environments.

Evolution of CVSS

CVSS was initially announced in February 2005 on the U.S. Department of Homeland Security website. From its introduction, CVSS underwent two major revisions under the custodial ownership of FIRST (Forum of Incident Response and Security Teams). As of writing this blog, the current version is CVSS version 3.0 released in June 2015.

CVSS VersionReleased on
Version 12005
Version 22007
Version 32015

Why you should start using CVSS?

CVSS offers the following three benefits for a software vendor like SAP   to convey the severity of a fixed vulnerability to its customers:

1) It provides standardized vulnerability severity scores.  This helps an organization in making informed decisions to schedule an appropriate patch window based on vulnerability severity.

2) It provides an open framework. Users may be confused when a vulnerability is assigned with an arbitrary score by a third party. With CVSS, the individual characteristics used to derive a score are transparent.

3) CVSS helps in risk prioritization. When the CVSS Environmental metric score is computed (typically done by end-user organizations because they are best able to assess the potential impact of a vulnerability within their own computing environment), the vulnerability becomes contextual to each organization, and helps provide a better understanding of the risk posed by the vulnerability to the organization

Additional points to keep in mind:

  • Presence of un-patched vulnerabilities with a CVSS score of 4.0 or higher will have negative impact to PCI (Payment Card Industry Data Security Standard) compliance.
  • International Telecommunication Union (ITU) recommends the usage of CVSS for vulnerability severity rating.

How SAP uses CVSS?

To provide transparency to our customers, security note priority is now calculated entirely based on CVSS v3 Base metric score.

Security Note PriorityCVSS v3 Base score
Low0.1 - 3.9
Medium4.0 - 6.9
High7.0 - 8.9
Hot News9.0 - 10.0

Also, SAP uses CVSS version 3.0 Base score for vulnerability prioritization in our products. We believe it is critical for us to ensure time taken to provide a fix for vulnerability is in inverse proportion to the CVSS score of the vulnerability, such that a high CVSS score will yield to the least time to provide a fix to our customers. This prioritization also has an effect to the ‘downporting’ requirements – i.e. to how many legacy versions of the software we supply a patch.

For more information:

The CVSS version 3.0 documents are available online on FIRST’s website at https://www.first.org/cvss


Related blog posts:

Changes to CVSS in version 3.0

How to interpret SAP's CVSS score?

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 April 2016, SAP Security Patch Day saw the release of 16 security notes. Additionally, there are 3 Out-of-Band Security Notes released this month.


As of March 01, 2016, SAP Security Note prioritization is based on CVSS v3 Base score. The revised prioritization scheme is aligned with the industry’s best practice, and to provide better transparency to our customers. From March 2016 security patch day, all patch day security notes will carry CVSS v3 Base score and vector information to assist our customers in their risk assessment. For further details, please refer to our blog on CVSS v3.

 

___________________________________________________________________________________________

 

Security Notes vs Vulnerability Type - April 2016

VC.PNG

Security Notes vs Priority Distribution (Nov 2015 - April 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.

 


 

SAP Product Security Response Team



I remember one case where we did a threat modeling workshop for a product that consists of a rich client that allows editing of objects (e.g. contract, a file, a master data record, source code …). These objects are managed by the server and the server keeps track of all these changes and maintains the appropriate version history. To keep track of the changes each object gets a temporary unique identifier, which is assigned to the object in scope. With the identifier the server can verify and manage versioning.

From a pure functional view point any unique identifier serves the purpose. But in threat modeling we are not thinking in proper working solutions but we want to know how we can break things. Let’s switch the perspective from a developer to a hacker. Where the developer might think uniqueness is key and helps to achieve the objective of consistent versioning, the hacker in us thinks: Hey, there is an identifier, what can I do with it to do something unexpected?

It is easy to observe identifiers if you have access to the system as a normal business user. In our case we just need to touch a few objects in a row, it does not even matter if these objects hold sensitive information (let’s look at that later). It turned out that the identifiers are based on a sequence. The server just incremented the identifier by one with each request. As said, that is perfectly fine for the pure functional use case. But for the hacker in us it is an interesting hook. A sequence gives at one hand a clear view on the history of identifiers and allows on the other hand a simple prediction of upcoming identifiers.

Let’s look what happens if we change the identifier to an identifier that already has been used. How will the system behave in this case? It might be possible to overwrite an object that already was created. The same is true for an identifier yet to be used; you could change the identifier to the current value plus one to interfere with the work the next edit job is doing.

What can go wrong here? If the identifier is the sole barrier for consistency, an attacker can tamper with the records in the system. Depending on the object type this might allow anything between nuisance and criminal fraud.

On the basis of this abstract information we cannot conclude on that. In addition, we are not yet sure if the identifier in use is just an optimization, and tampering with the identifier is not working as the server does different other checks and will figure out that something is going wrong or simply will not allow any attempt to manipulate files or objects in that way.

But hey, we are in a threat modeling workshop, we do not start analyzing the server behavior ourselves, we just ask the developers in the room. And the question is as simple as that: What happens if an attacker is manipulating the identifier by incrementing it or using by using a past value?

And be sure, there will be silence for a moment, the developers will think about it. If they actually work on that for quite a while, you might get the answer fast. If the team is only responsible for the client, they might need to check with someone else or dive into that deeper later on.

But we found a potential vulnerability. Now all we need to do is to figure out how high the risk of the respective threat is and consider the need and cost of a mitigation.

Typically, I avoid discussing the mitigations in detail. But in this case there is a standard cure. Identifiers that have potential security relations (confidentiality, integrity…) should be based on cryptographically secure random numbers (be sure to use a secure random function). Having that in place, the chance of guessing or predicting and thus tampering with the identifier is basically gone.

What is my conclusion? Successful threat modeling requires a different perspective (how can I break it), curiosity (what can I do with that, even if it is not immediately an attractive hacking target), and then you just need to raise a few simple question – e.g. What happens if I increment the identifier manually on client side by one?

In my threat modeling workshop, the threat did not really materialize as the surrounding framework prohibited a feasible materialization of a successful attack. Is it worth attacking your identifiers? Let me know, happy to discuss your scenario with you.

In a threat modeling workshop for a specific scenario we discovered a message authorization issue. In the following I would like to repeat exemplarily the thinking that led to this discovery. The example I am using is completely fictitious and I have not verified if any existing product on the market is susceptible to this. Even if one would be susceptible – this is no hacking guide! Remember that we are on the good side.

 

The example I would like to dissect is home automation. Let’s assume we are building a home automation solution that allows amongst others controlling the heating system with temperature sensors and opening the door with a remote key.

What are we going to protect? Amongst other things we want to prohibit an attacker to open the door. Sure we do not want to give attackers a chance for tampering with the heating or other connected things either, but let’s concentrate on the door.

We can use basically any threat modeling methodology to analyze this scenario. For example we could use attack trees, where the attacker’s goal would be to open the door without the appropriate door opener. STRIDE (see also: https://msdn.microsoft.com/en-us/library/ee823878%28v=cs.20%29.aspx?f=255&MSPPError=-2147217396) would definitely work as well but I would like to use our SAP methodology for the time being.

Typically, we start with spoofing / authentication related threats.

Can we spoof the identity of a thing?

OK, we have temperature sensors and door openers (still looking at the subset only). How are they authenticating their identity against the central system? Our current design foresees that authentication uses a pre-shared key plus an object ID. From an attacker’s perspective (that is our current role) we want to get access to both. We want to have a valid ID and a valid key. As we have no access to the house where this stuff is located, access is difficult – but wait, the heating system relies on a sensor sending the outside temperature. Can we get access to that? Maybe we can reach the sensor without breaking into something. But we need physical access – quite a bit of a hurdle.

Assume we get access to the sensor, we would need to be able to get the ID and the key from it. Maybe the ID is printed on the case? Maybe we need to open the case and try to download the code from the processor? Let’s assume the ID is not printed on the case, but we are able to connect to the processor using some appropriate connection (might be an Arduino using an onboard USB or so). We use a tool to download the code from the unit and get the assembler code. Again that is quite a bit of a hurdle, as we need to be able to analyze and understand assembler coding. But let’s assume we are so clever, the code will eventually unveil the key and the ID to us. Now we can fake at least sensor data, if we are able to upload our own malicious code. At least we should be able to fake outside temperature and bring the heating system to heat up or switch off.

So we have broken authenticity. The next step is to check what we can do once we are in (authorization). As what we reached currently is not what we want.

Let’s ask further questions. What happens if we send an ‘open the door’ message using our sensor access? Let’s try. We can search for the correct format of the message in publicly available specifications. Now let’s just create and upload a program that does not sense temperature but sends an ‘open the door’ message.

As an attacker, let’s hope that we can trick the system to open the door. If it works, we have succeeded with our attack. But what went wrong from the design perspective?

 

The designers (we) missed to check the message authorization. We have implemented a two-step approach: 1) check the authenticity of the sender and 2) check if the message is well formed. If both conditions are met, we process the message. But we missed to verify if the ‘open-the-door’ message is coming from the door opener.

 

How big is this threat? Well, we need access to a device (no internet attack detected for the time being), we need to be able to download the code and analyze it (depends very much on the hardware in use). We need to be able to write a malicious program using the correct message format. Overall the attack is not so easy (we would label it at least ‘advanced’) but the impact would be severe: somebody could enter our house without leaving a trace. An advanced attack leading to a severe impact is a critical risk in our methodology. So we better try to fix this.

I know I skipped a lot of details, but in principal it is a design flaw we found already and not necessarily in IoT scenarios, though it makes up a good example.

 

What is your opinion on that? I would be interested for example in your view on the assorted risk. Happy to read your comments.

In the previous posts I talked about finding abnormal activities using the ETD. This time I like to talk about network threats and give you some example of advanced persistent threats (APTs). It is a summary of the presentation at the DSAG in Hamburg of Christian Wiegand, Wolfgang Beuermann and me on 17. February 2016. I am going to explain what APT means and why it’s so dangerous for a lot of companies. Afterwards I give you some examples, how the ETD can be used in order to detect a specific APT to your network.

 

1. Advanced Persistent Threats

Advanced Persistent Threats (APTs) are well prepared and long persistent attacks on certain targets. APTs are not a new phenomenon. Targeted attacks have always existed. New is just the fact that attackers have nearly unlimited resources in the term of

  • time,
  • money,
  • information,
  • development capacity.

 

It can be concluded that attackers are part of organized crime, industrial espionage or intelligence organizations. They have long-term goals and do not go for fast money or produce superficial damage. As a result, they stay in the network for more than 200 days undetected in average. After the first injection they stay inactive for weeks. Attackers observe the daily work (work process). Potential targets are companies with high level technology (e. g. car/ship manufacture, space travel or defence industry), authorities, public administration, government, research and banks.

An APT has a well-defined structure which you can see in the picture below.


overview.png

(Source: Die Lage der IT-Sicherheit in Deutschland 2015, BSI)

 

The first infection is nearly impossible to avoid. This attack often uses social engineering and spear phishing mails. The goal is to identify and exploit habits of the employees and to discover the company structure. One easy way is to send an application with a manipulated PDF or a ZIP file, with a manipulated document in it, to an employee. A classic email example for such an attack is the following:


Hello Mr. Schmidt,


we talked a few weeks before. Here is now my application. I added the needed documents to the attachments. Hope it’s everything you need.


Best Regards

Sarah Müller

 

This attack will work! In the picture below you see the number of critical vulnerabilities in software of the year 2015. The Adobe Reader had more than 60 vulnerabilities this year. As a result an application raises specific risks and offers attackers a pretty good target. In numbers: 60 vulnerabilities divided by 52 weeks (one year) makes up 1.15 new vulnerabilities per week.


Lagebericht2015_Seite_10.png

(Source: Die Lage der IT-Sicherheit in Deutschland 2015, BSI)


There are some things that can hamper the first attack. You as a defender need to have deep knowledge about your IT infrastructure and which elements are worth protecting. The most important thing is your employee’s awareness. Normal users and administrative users learn in employee awareness how easy they could be hacked and what they can do to protect themselves.


Security responsible staff should know how such attackers work and what their goals are. After the first infection an attacker tries to gain more privileges (on domain controller) and cover his tracks (each system that was visited). An attacker reaches these goals by so called “standard attacks” on/from the infected system. These may be brute force attacks on user credentials or pass the hash attacks. Some of these standard attacks use system features to retrieve user credentials. These features are neither bugs nor security issues. They are standard and import and functions that need special protection.


2. Detect an APT with the ETD

Every kind of standard attack implies somehow abnormal behaviour of user accounts or system functions. E.g. when an attacker gathers user credentials, he analyses the network layout and possibly connects to various other systems using hijacked credentials. This behaviour results in

  • user logins into unusual systems,
  • system communication with unusual systems,
  • login failures,
  • creation of new user,
  • continuous WAN traffic,
  • etc.

 

The ETD is able to detect this behaviour. To do so it needs to collect a lot of log files from various systems (SAP and Non-SAP systems). E. g. domain-controllers and firewalls need to be connected to the ETD, just as we did in the City-of-Wolfsburg project. Then you need to collect data for the initial data collection. Finally create patterns and charts in order to detect “standard attacks”. The picture below gives an example for the pattern of user logins from different local IP addresses. We have created these and other patterns in the City-of-Wolfsburg project. This kind of charts/patterns are very important since it is almost impossible to detect all zero day exploits in software. Therefore the best point in time to detect an APT is just after the first infection. This is why you need patterns for the “standard attacks”.

 

logonsOnDistinctIPs.png

 

In ETD it is possible to add company-specific patterns, which detect abnormal behaviour/activities and trigger alarms. I gave some examples for company specific patterns/behaviour in this post “Finding abnormal activities”.

 

Continuous collection and correlation of log data from different systems is essential. Normal antivirus software typically detects less than 40% of malware infections. The ETD is very good in finding these anomalies since it combines information from SAP systems and non-SAP systems (router, firewalls, proxy, …).

 

Normally hackers attack subsequently different systems. They often hack a Windows system first and continue potentially from there to SAP systems. The SAP ETD makes it possible to detect attacks at these both locations: After the first infection on the Windows systems or later at penetration of the SAP systems.

Eighty-eight percent of the respondents to the Global Information Security Survey (GISS), “Creating Trust in the Digital World”, conducted in 2015 by Ernst & Young (EY), do not believe that their information security fully meets the organization’s needs. But how can sufficient security concepts be adopted, implemented, and internalized? This paper, written by EY and SAP, examines how addressing threats and tackling information security proactively can create additional enterprise value.

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 March 2016, SAP Security Patch Day saw the release of 14 security notes. Additionally, there are 4 updates to previously released Patch Day Security Notes.


Announcement !

 

As of March 01, 2016, SAP security note prioritization is based on CVSS v3 Base score. The revised prioritization scheme is aligned with the industry’s best practice, and to provide better transparency to our customers. From March 2016 security patch day, all patch day security notes will carry CVSS v3 Base score and vector information to assist our customers in their risk assessment. For more information on CVSS v3, please refer to the following link

____________________________________________________________________________________

 

Security Notes vs Vulnerability Type - March 2016

 

VT.PNG

Security Notes vs Priority Distribution (Oct 2015 - March 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.

 


SAP Product Security Response Team

I reported in the past of the project in which my company and SAP Deutschland SE & Co.  KG (SAP) worked together in order to attach non SAP systems of the city Wolfsburg to their ETD instance. I created with colleagues some charts and patterns to detect attacks and system anomalies. I like to introduce in this post reasons for patterns/charts which bases on our experiences of different customers. I will tell also, why it’s necessary to adjust the system after the integration periodically.

 

Abnormal activities are very broad and different. Abnormal activates could be wrong configured systems which sends a lot of messages or they are potential threats for the network.

 

Initially I give you an example for a wrong configured system. We know this case from one of our customers. All clients of our customer had two DNS server addresses. This was manual configured and not pushed by DHCP. When our customer ordered new computers, a disc-image was used for the installation of 25 clients. This disc-image contained a typing error in the first DNS server address. As a result all clients asked the email server first for an IP look up and then the second DNS server. So the load balancing between the first and the second DNS server failed. This abnormal activity is harmless but necessary to detect.

 

Here is a definition of threats. Threats are split up in to two classes. “Regular threats” are for example infrastructure threads e. g. the heat in server rooms. This is a calculated threat and the air condition should regulate the temperature. An abnormal threat is known as attack on it infrastructures. We also distinguish these attacker threats into: unknown attackers from outside and known attacker from inside. The background of both is very versatile and I will not talk about the causes of in- and outsiders. From our experience an insider is not the exception. You often find unaware users being in charge. It is possible that in- and outsiders create abnormal activities in a network, which gives us the chance to detect them. But, what are these activities?


1. Abnormal activities

Abnormal activities indicate often something. You have to observe them and often correlate multiple events to find the root cause of the incident. Here are some indicators of abnormalities we recognized in the past.


1.1. Email activities

Here is a case where a customer’s employee stayed longer at work every Friday. The employee told colleagues that he would wait for his sport course to start. It turned out that he collected information about customers and sent this information to a contact of another company. Home office was not allowed in this company, so this happened every Friday approximately at eight o’clock for a long time. The employee thought that it would be more inconspicuous sending emails in this timeframe than during regular business at day. Especially since the employee had to scan various documents which is more suspiciously at day.

 

I give you another case where an employee’s pc was hacked probably by a bot network. As a result his email account sent a lot of emails every day to all contacts in his address book distributed over the whole world. It took some time, till an end-customer told this company that they spread spam mails.


1.2. Remote Logging

A lot of employees have remote access to their company network due to home office activities. Here is a case where a customer’s employee misused his home office notebook. The usual behaviour of this employee was starting remote access in the mornings and disconnecting in the evenings, from Monday till Friday. The employee was not in touch with customers or partners. He worked as a clerk only. Someday the employee started the remote connection on a Saturday at 11 pm o’clock and disconnected 20 minutes later. What has happen? The employee served guests with confidential information before deleting them. Deletion of this information brought the guests some advantages.


1.3. Suspicious user Logons

Here is another nice study case where user performed nightly logons. An employee went on a business trip. He needed some travel information, booted his computer, logged into his account, checked emails and printed some documents. When finished the employee turned off the computer and started his business trip. Although this was a legal action, an alarm was triggered because the detected logon time in general is abnormal. An account logon at night might be a hacker or thief.


2. Find this Abnormal Activities with ETD

In order to learn normal behaviour of a computer network, you need to collect log data for a few weeks. It is called initial data collection. During this process you may create basic charts in the ETD. When initial data collection is finished you are able to transform those charts into patterns and setup thresholds. In addition further charts may be layouted that are especially made for your specific network.


2.1. Email activities cases

The first case study was about sending of emails with confidential information to competitors. This case is quite difficult to map, but possible to detect. We created an overview chart for a defined period time and set the threshold for attachments to 1 or higher. Additionally we observed the time between 6 pm till 6 am (night time) only. Another option is attach the print-server to the ETD instance (which includes the scanner) in order to observe activities that happen not during the office hours.

 

Much more interesting is the other case. There an email account constantly sent out a lot of spam mails. In the project (see post ETD monitors non SAP systems) we have created a corresponding chart based on our experiences. We call it mails-per-user-chart. In this chart it is possible to see how many emails a user sends per day, week or month. The different periods of time are just a matter of configuration. Even though it is not a feature observing a specific user since the user names are pseudonymized. An analyst only sees for example the following label instead of the username: “TEEQL-73393”

 

Whenever a user sends out too many emails, we are able to recognize who he is. You just have to undo the pseudonymization process for that user. De-pseudonymization is only permitted for a specific ETD user account having granted the corresponding privileges. You should make sure that a high authority only may do this.


MailsPerUser.png


2.2. Remote Logging Case

We like to be informed, whether an employee establishes a remote connection in the evening, especially at the weekends. In ETD it is not possible to look at some specific days only (e.g. Saturday). As a result, we need to observe the whole week but within a certain time window (e.g. 6:00 pm to 6:00 am). Set a threshold in patterns to value higher than 0 and have an alarm triggered.


2.3. Suspicious user Logons

User-logons outside the office hours made from inside the office location is typical abnormal behaviour. Create a chart, count remote sessions and compare them with the domain controller logons. Correlate findings in the timeframe between 8 pm and 6 am. A threshold checks the number of remote connections and triggers an alarm, if they are less than domain controller logons (e. g. 0 remote connections < 1 dc logon =>  trigger alarm).

 

In the picture below we observed a full day.


WinDCvsRemoteConnections.png





There will be a one hour Webinar providing a preview of the new SAP Enterprise Threat Detection 1.0 SP03. We will focus on enhancements in the Forensic Lab, integration with SIEM or incident management systems, log learning and a significant improved sizing.

 

There are two options:

 

Friday, March 4th, 10:00 to 11:00 a.m. CET

Monday, March 7th, 5:00 to 6:00 p.m. CET

SP03 brings some significant improvements to SAP Enterprise Threat Detection. A major focus was on throughput, performance, and sizing. A visible manifestation of this is the disappearance of the details table and the expansion of the header table. However, in this blog I am going to mention two functional features that stand out.

 

SIEM Integration

Many security operations have already invested heavily in one or other SIEM solution and are looking to SAP Enterprise Threat Detection to cover the SAP part of their landscape. Ideally, the two solutions should be able to exchange information about what is happening in the areas that they are covering. SAP Enterprise Threat Detection alerts can now be sent (pulled or pushed) in JSON format.

This topic will be covered in more detail in the April edition of SAPinsider magazine.

 

Semantic Attributes

This a subject that deserves its own blog so I will merely touch upon it here. In SP02 we introduced semantic events. Now we have semantic attributes, which complete the meaning of semantic events. Events, concepts, and the relationships between them are standardized. Consistent use of events and attributes across sources makes it easier to do cross-log analysis. The bubble diagram shown in the screenshot is new way of displaying and quickly filtering the attributes in the forensic lab.

 

BubbleGraph.gif

Relevant SAP Notes

2192334 - Release Note SAP Enterprise Threat Detection 1.0 SP03

Hello everybody, I like to introduce myself first. My name is Patrick and I am a security consultant. Today, I like to talk about our first project “connecting non SAP systems to SAP ETD”. We and SAP Deutschland SE & Co.  KG (SAP) commonly have worked successfully together in order to attach non SAP systems of the city Wolfsburg to their ETD instance. The responsibility assignment between my company and SAP was the following:

 

My company connected several systems to the ETD. We used Syslog-NG for the log file transport on Unix systems and our Windows agent for transportation of Windows Event Logs. In addition, we created patterns and charts to visualize the behavior or to trigger alarms.


In the case of issues, we contacted our SAP partner and supported to reproduce these issues in both ETD instances, ours and SAPs. The team around SAP ETD created an update or fix within a few hours. An example has been not yet supported timestamp formats.


A schematic workflow of connecting non-SAP systems to the ETD is visualized in the following picture. In ETD SP3 version is it not necessary to create new attributes anymore. An almost complete list of attributes is available, which can be used in the log learning process.

 

workflow.png

 


 

1. ETD Configuration

Once the basic installation had been done, new log attributes were created in ETD. After creation of new log attributes, the system is ready to perform the log learning process.


Please note: Log attribute configuration has been included into the common ETD setup with SP3. Therefore no manual extra steps are necessary anymore.


1.1. Create necessary Attributes

Creation of log dependent attributes used to be necessary in SP2. In this version the ETD provided a few basic attributes only that could be taken into account for specific log characteristics (e. g. “ip address” or “port number”). These attributes provide an ETD-wide consistent semantic. Therefore an extraction and mapping of log file entries with ip address information to the ETD attribute “ip address” is necessary. It allows comparison and correlation of different log entries and source types. Since SP3 the ETD provides plenty more attributes out of the box.

 

For example, we added the following attributes during the ETD SP2 integration:

  • “Is Computer” (to decide is the log from a computer or a server)
  • “Log Level” (see the log level of a specific system)
  • “Rule ID” (to see which ID was taken of the system)
  • “Message Text” (for explanations of log files)



1.2. Start Log Learning

The final step of the ETD configuration is the log learning process. Log learning can be started from the main page of the ETD.

ETD-Dashboard-Loglearning.png


Log learning needs a small representative log file which contains a lot of different log events. It simplifies the learning process, because you do not have to deal with a bunch of trash messages. Therefore you can see just one entry in the mark-up table below. You typically retrieve more entries when using a regular syslog file. Then a deeper understanding of the log file and its structure is needed.


The windows agent log output meanwhile consists of well-structured key-value pairs. Matching of those to new or standard attributes to the values is a straight forward procedure.


ETD-Loglearning.png

When log file entries appear to be less structured a deeper experience in value-mapping is needed. In those cases a “value mapping” function is available. It allows usage of regular expressions for extraction of the corresponding values out of the log message text.

 

Final step in the log learning process is a test import. As soon as this import terminates successfully, the ETD is ready to import incoming online log streams.


2. Connecting non-SAP systems to the ETD

We connected the following systems to the ETD:

  • Unix systems and appliances
    • Email-Gateways
    • Firewall
    • Anti-Virus-Scanner
  • Windows systems
    • Windows Domain Controllers 2012 R2

 

2.1. UNIX preparation

Almost each Unix system runs a syslog daemon (e. g. Syslog-NG) that is able to send syslog files to a log management server. We used this feature to transfer log files of the various systems to the ETD. The configuration was quickly done: Just edit the Syslog-NG configuration file, add the destination IP address or host name and the destination port and restart the syslog daemon.

 

Please note: If one of the systems is part of demilitarized zone (DMZ) or attached to separated network segment, firewall policies, in terms rules for used ip addresses and ports, need to be adapted.


2.2. Windows preparation

Logging in Windows operating system is based on the Microsoft event log protocol. This and that we like to get more system information is why we developed our own agent. The agent transfers Windows event log messages to the ETD instance. The installation is quite easy: Just copy the installer to the target system, run the installer and configure the destination host. After restart, our agent transfers new log entries to the ETD instance.

 

Please note: If one of the systems is part of demilitarized zone (DMZ) or attached to separated network segment, firewall policies, in terms rules for used ip addresses and ports, need to be adapted.



3. Creating Patterns and Charts

Next step is the creation of specific patterns and charts. In the pilot project, data collection could be started just after one day of log learning process. One day of collected data is a good period of time to start with pattern configuration. It usually includes a complete work cycle of users, including logons, logoffs, etc. It allows to drill into the data within the “Forensic Lab”. The Forensic Lab is used to analyse log data from the past. It also allows the creation of patterns and charts.


ETD-Dashboard-Forensiclab.png


 

 

We created several charts in the context of the project in the Forensic Lab (see the picture below) .


ETD-ForensicLab.png


Here is a little overview with general charts.


  • Emails
    • Emails incoming vs outgoing
    • Emails per user
    • Emails per gateway
    • Attachment kind
    • Attachment count
    • Incoming threat emails
    • Outgoing threat emails
    • Threat emails per user
  • Anti-Virus-Scanner
    • Virus found
    • Virus per user
    • Heuristic
    • Heuristic per user
    • Updates errors
    • Update errors per system
  • Windows Events
    • Logon successful
    • Logon fail
    • New object created
    • Object deleted
    • Object modified
    • Events per domain controller

 

All these charts and some more are presented on monitor pages. Monitor pages are configurable in terms of scale and refresh interval. For example below you can see the picture that provides an overview of the email gateway.

 

ETD-Monitoring-Mail-Example.png

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.

Actions

Filter Blog

By author:
By date:
By tag: