In the previous article, we looked at the difference between security audit and pentest. Now let’s see how a typical pentest looks like and what distinguishes it from the perfect one.
The exploitation of 3 vulnerabilities permits an attacker to hijack an SAP administrator account without any access to an SAP system by using the black-box method. A typical pentest involves the following steps:
- Information gathering
- Vulnerability exploitation
- Privilege escalation
- Business Risk demonstration
1. Information gathering
Information gathering is the first step in every penetration testing. Some information about the system can be collected without a vulnerability, for example, by scanning a network for particular SAP services or a web server for available web applications in order to understand if there are any applications or services that have security issues.
This step also includes exploiting a specific vulnerability type called “Information disclosure”. Usually, these low-risk vulnerabilities are very common and often left unpatched since administrators have to cope with more critical issues and don’t have resources for the former. However, with help of this vulnerability, an attacker might receive information ranging from the operation system, SAP version, private IP to user list and their passwords.
Although a typical SAP installation is full of Information disclosure vulnerabilities, during our pentest the system was so securely configured that we had to search for zero-days.
Eventually, we found multiple Information disclosure vulnerabilities. For instance, using vulnerabilities ERPSCAN-16-010 and ERPSCAN-16-016 an attacker can get an SAP user’s name, surname, privileges, and logins remotely and without authentication.
An example of vulnerabilities exploitation can be seen in a screenshot below.
The exploitation of this vulnerability is easy, an attacker needs to anonymously open an available webdynpro application uniform resource identifier (URI) and press “Select” button. Nevertheless, an attacker can’t log into the SAP system using only usernames; passwords for SAP accounts are also required. Here comes the second step of our Pentesting plan – vulnerability exploitation.
2. Vulnerability exploitation
This step is straightforward. After we get to know which services and web applications are available, we can find out if these services have a vulnerability and exploit it.
If we speak about the SAP NetWeaver J2EE application server, there are multiple loopholes (from Verb Tampering vulnerability in CTC web service and Invoker servlet to P4 Authentication bypass, multiple XXE and SSRF issues in K2EE web services) identified years ago. All of them exist in almost every SAP Implementation even now, but some clients really take care of SAP Security and eliminated the so-called “low-hanging fruits” for hackers. It is the point that distinguishes a perfect pentester from a script-kiddie or a vulnerability scanner. A real pentester tries to find a new vulnerability even if there are no obvious ways. In doing so, he or she first considers what is needed. In fact, the pentester already has some information about the system – usernames. Therefore, gaining at least a password hash guarantees the win. How? Certain vulnerabilities may give access to it, they are SQL Injections.
SQL injections are common issues appearing in traditional applications but rare in SAP (see the table below). This type allows attackers to inject their own evil SQL commands. It legitimates the request and paves the way for accessing the critical data in a database (e.g., business data, users’ passwords, and bank account information). Using an SQL injection attackers try to get credit cards dates, users passwords, social cards information, etc.
During the same pentest, we found an anonymous SQL injection vulnerability in SAP NetWeaver (later it got an identifier ERPSCAN-16-011). The vulnerability is in SAP UDDI (Universal Description, Discovery and Integration) component, the most widespread one, and it affects SAP NetWeaver versions 7.11 – 7.50. For its exploitation, an attacker only sends an HTTP query of the following type:
POST /UDDISecurityService/UDDISecurityImplBean HTTP/1.1 Content-Type: text/xml <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <SOAP-ENV:Body> <m:deletePermissionById xmlns:m="http://sap.com/esi/uddi/ejb/security/"> <permissionId>x' AND 1=(SELECT COUNT(*) FROM BC_UDV3_EL8EM_KEY) or '1'='1</permissionId> </m:deletePermissionById> </SOAP-ENV:Body> </SOAP-ENV:Envelope>
The vulnerability is presented in permissionId that can contain any SQL command. When SAP gets this code, it will be executed. For example, SAP server will execute this SQL command and return a count of rows from the BC_UDV3_EL8EM_KEY table.
SELECT COUNT(*) FROM BC_UDV3_EL8EM_KEY
Using this vulnerability, attackers can get the hash of users’ passwords from UME_STRINGS table. After that, they need to get passwords from the hash. It can be accomplished in 2 ways:
- Use bruteforce attack
- Find another vulnerability in password crypto algorithm
3. Privilege escalation
The latest attack step before Business Risk demonstration is privilege escalation.
After exploitation we may have access to the system but this access is restricted to certain actions, and we need to escalate privileges using a chain of vulnerabilities. The first part of the pentest gave us some knowledge but it’s not enough in this case. In this example, we have usernames and password hashes. Still, we don’t have passwords. After spending time to complete this project, we were so close to the goal and found a vulnerability in password encryption functionality in SAP NetWeaver (ERPSCAN-16-003).
When any user with a password is created in an SAP system, passwords are secured with encryption. The function that makes it possible is HashWithIterations stored in PasswordHash.class.
SAP SE made a mistake during the realization of encryption algorithm, and as a result, the password is stored in the database as base64 that is not encryption but encoding algorithm.
4. Business Risk demonstration
The great news is that now we have access to the system even though in the beginning we thought that it was impossible because all the known vulnerabilities were patched. Usually, a traditional pentest ends here, but for a perfect one, it’s not enough to show only access but essential to demonstrate business risks.
So, we got administrator account on the SAP system, for example, of the Manufacturing vertical. These companies, which use SAP products, can manage technologic process using SAP MII module. SAP MII (SAP Manufacturing Integration and Intelligence) is an SAP application for synchronizing manufacturing operations with back-office business processes and standardize data.
Between SAP MII and technologic controllers there is SAP PCo. When SAP PCo receives all control data from SAP MII it changes the data and sends them to controllers. As we have SAP NetWeaver administrator user, then we can get access to SAP MII and manage controllers, which are responsible for oil production.
Our research team identified several vulnerabilities in SAP xMII. These can be used as part of a multistage attack, starting from one of the numerous business applications exposed to the internet with the ultimate aim of getting control over the shop floor. Industry control systems were designed without basic security measures: Once a perpetrator breaches a network, they gain unfettered access to all the controllers and their configurations. Here, fallouts depend on perpetrators’ goals and are limited by their skills and imagination. For example, an attacker can change the melting temperature so that products will be more fragile. Another attack vector is a slight modification of the instruction of the welding seam. Both actions could lead to dire consequences if they are performed during car production or high-tech equipment manufacturing.
The full attack vector looks like that:
- A pentester using information disclosure gets SAP users’ logins
- With help of an SQL injection and SAP user logins, a pentester gets users’ passwords hashes
- Exploiting a vulnerability in crypto algorithm, a pentester can get users’ and administrators’ passwords, and using a valid username and password log into the system
- By having this access, pentester demonstrates the business risk
In a next article, we will see why the vulnerabilities occurred and how SAP SE fixed them.
The post Perfect SAP Penetration testing. Part 2. Attack Scenario appeared first on ERPScan.
This is a Security Bloggers Network syndicated blog post authored by Vaagn Vardanyan. Read the original post at: Blog – ERPScan