Layer Seven Security
Missing authorization checks in the Archiving Workbench, default pass phrases on the J2EE secure store and SQL injection vulnerabilities in Java applications. Read the guide to July’s SAP Security Notes at http://layersevensecurity.com/SAP_security_advisories.html
There are few terms more widely misunderstood in the world of information security than the word ‘hacking’. Although it’s used in a variety of contexts, it’s most commonly used to refer to all types of cyber crime including everything from fraud and industrial espionage to identity theft and spamming. If you take this view, cyber crimes are the deeds of ‘hackers’.
In reality, hackers do far more good than harm. Many are researchers that practice a form of ethical hacking driven by a desire to improve the state of information security. Ethical hackers are the ‘white hats’ of security. They use everything from port scanning to breaking and entering to simulate an attack against networks and systems, usually with the consent of their targets. Software companies such as SAP owe a huge debt to white hats. Many of the vulnerabilities patched by SAP Security Notes are discovered not by SAP, but independent researchers that are far more adept at finding vulnerabilities than SAP itself.
In the past, white hats would publish details about vulnerabilities as soon as they were discovered. Today, most follow SAP’s Disclosure Guidelines. As a result, very few vulnerabilities are publicized until they are patched by SAP. Whether or not this is in the interest of SAP customers is open to debate. It could be argued that this reduces the incentive for SAP to properly patch its software, A case in point is a session hijacking vulnerability in the Enterprise Portal which wasn’t patched until 18 months after it was reported to SAP.
White hats rule the roost of information security. One step below are the black hats who most closely resemble the stereotypical image of hackers portrayed in pop culture. Black hats use the same tactics as white hats but differ in their motives which are generally malicious. Most are driven by the need for notoriety or personal gain, although some are motivated by more noble goals such as social justice. The latter are often referred to as ‘hacktivits’. Its difficult to stall an attack by talented and determined black hats. The only approach that provides any glimmer of hope is the tried and tested defense-in-depth strategy which may buy enough time to detect a breach before any real damage is done or encourage attackers to direct their efforts towards other less well defended targets outside your network.
White hats look down upon black hats but the two groups have much in common. Firstly, they are both skilled in the art of finding and exploiting vulnerabilities. Secondly, they’re partial to challenges and venerate well-constructed code like a thing of beauty. Thirdly, both white hats and black hats frown upon script kiddies, or skiddies for short.
Skiddies are the hillbillies of the information security world. They don’t look down upon anyone since they’re at the rock bottom of the totem pole. Skiddies are considered social pariahs since they have no appreciation of the concepts and tools of information security. Their sole purpose is to exploit vulnerabilities discovered by black hats. Black hats take pride in their work. Targets are carefully selected and attacks are meticulously planned. They go to great lengths to cover up their tracks. Skiddies, on the other hand, blindly execute scripts developed by black hats hoping to catch victims that happen to be susceptible to whatever vulnerability they’re targeting at a moment in time. Despite this, skiddies should not be underestimated. They far out-number black hats. They also have an uncanny ability to learn about new exploits long before they’re patched. This is fuelled by IRC (Internet Relay Chat) and online trading for zero-day exploits.
The proliferation of easy to use security tools with point and click interfaces has dumbed down hacking and turned the tide in favor of skiddies. Many programming or configuration flaws in systems such as SAP don’t require any technical skill to exploit. Therefore, relying upon security through obscurity no longer works, especially when systems are public-facing.
Intense, focused attacks led by black hats are destructive but far less likely than a random strike performed by a skiddie. However, the latter will quickly reveal vulnerabilities in a poorly patched SAP environment.
April was another bumper month for SAP Security Notes. In all, SAP issued 33 patches, of which 5 were considered critical. Top of the list were Notes 1647225 and 1675432 which address missing authorization checks in components of Business Objects Data Services (EIM-DS) and the SAP Classification System (CA-CL).
EIM-DS is SAP’s flagship solution for data integration and quality. It’s used to consolidate, cleanse and migrate data from both SAP and external systems. CA-CL is used to manage classification properties and classes for various types of objects. An example could be an object such as a Ford F-350. This would fall into a Vehicle class and have properties such as length, weight, color, power, capacity, etc. assigned within the system. Both EIM-DS and CA-CL suffer from vulnerabilities that could enable users to escalate their privileges and perform administrative functions.
SAP also issued three other critical Security Notes. Two of these deal with programming errors in the SAP User Management Engine (BC-JAS-SEC) and other components of the NetWeaver Web AS Java. This manages Web-based access to SAP applications such as the Enterprise Portal. Note 1651004 is designed to protect the UME from cross-frame scripting (XFS) attacks that could be used to the steal the logon credentials of SAP users. You can learn more about XFS here. Note 1641208 deals with signature wrapping attacks that target XML messages transmitted through certain SAP Web services. This attack can be used to intercept and manipulate a message without breaking the digital signature designed to protect the integrity of the message and its content. It could enable attackers to modify the data within XML messages without detection.
The last vital patch released by SAP in April was Note 1652803 which fixes a Denial of Service (DoS) vulnerability in certain versions of Apache Tomcat bundled with Business Objects Enterprise. Tomcat is an open source web server that provides a runtime environment for Java code. Business Objects Enterprise is the platform that supports SAP reporting tools such as Crystal Reports, Web Intelligence and the Dashboard Builder.
SAP uses the Common Vulnerability Scoring System (CVSS) system to rate Security Notes. Three of the five critical vulnerabilities patched in April have a base score of 7.5. The highest possible score is 10.0. SAP did not provide CVSS information for the other two. This is fairly common. SAP doesn’t consistently provide CVSS scores for all Notes.
The Advisory below includes a complete listing of all of the Security Notes issued by SAP last month. Particular attention should be paid to 1657200, which is designed to patch a flaw in an SAP component responsible for managing payment cards, and the injection vulnerability patched by 1638596.
On January 16, SAP issued a revamped version of the whitepaper Secure Configuration of SAP Netweaver Application Server using ABAP, which is rapidly becoming the de-facto standard for securing the technical components of SAP. According to SAP, the guidance provided in the whitepaper is intended to help customers protect ABAP systems against unauthorized access within the corporate network. In fact, many of the recommendations can also be used to protect SAP systems against remote attacks originating outside such a network. These attacks are targeted at the technical components of SAP Netweaver that are responsible for managing user authentication, authorization, encryption, passwords and system interfaces, as well as underlying databases and operating systems. Breaches in these components can enable attackers to take complete control of an SAP environment.
The following is a quick guide to help you comply with SAP’s recommendations.
1. Disable unnecessary network ports and services. In most cases, this means blocking all connections between end user networks and ABAP systems other than those required by the Dispatcher (port 32NN), Gateway (33NN), Message Server (36NN) and HTTPS (443NN). NN is a placeholder for your SAP instance number. Administrative access should only be allowed through secure protocols such as SSH and restricted to dedicated subnets or workstations through properly configured firewall rules.
2. Install the latest version of SAP GUI. This should be 7.10 or 7.20 with activated security rules configured with the ‘Customized’ setting and the ‘Ask’ default action.
3. Implement strong password policies, restrict access to password hashes in tables and activate the latest hashing algorithms. SAP does not specify the exact settings for password policy parameters but you should use frameworks such as the PCI DSS as a proxy. Refer to section 8.5 of the standard. Default passwords should be changed for standard users and the password hashing mechanism should be upgraded to the latest version available for your system. Wherever possible, downward-compatible hashes should be removed from the database.
4. Enable SNC and SSL. SAP client and server communication traffic is not cryptographically authenticated or encrypted. Therefore, data transmitted within SAP networks can be intercepted and modified through Man-In-The-Middle attacks. Secure Network Communication (SNC) should be used for mutual authentication and strong encryption. This can be performed natively if both servers and clients run on Windows. You will need to use a third party product to secure connections between heterogeneous environments such as AIX to Windows.
SNC will secure network communication using the SAP DIAG and RFC protocols. For Web-based communication, you should switch to HTTPS/ SSL and restrict access to the relevant cryptographic keys.
5. Restrict ICF services. Many of the services enabled by default in the Internet Communication Framework (ICF) are open to abuse and could enable unauthorized and malicious access to SAP systems and resources. At a very minimum, you should deactivate the dozen or so services mentioned by SAP in the white paper. This can be performed through transaction SICF.
6. Secure Remote Function Calls (RFC). Wherever possible, remove trust relationships between systems with differing security classifications and hardcoded user credentials in RFC destinations. The belief that RFC connections using SAP_ALL privileges is fine as long as the user type is not set to dialog is a myth. This represents a serious risk to the integrity of information in SAP systems.
7. Secure the SAP Gateway. The Gateway is used to manage RFC communications which support SAP interfaces such as BAPI, ALE and IDoc. Access Control Lists (ACL) should be created to prevent the registration of rogue or malicious RFC servers which can lead to the interruption of SAP services and compromise data during transit. You should also enable Gateway logging and disable remote access.
8. Secure the SAP Message Server. The Message Server is primarily a load balancer for SAP network communications. Similar to the Gateway, it has no default ACL which means it is open to the same type of attacks. You should filter access to the Message Server port using a firewall and create an ACL for all required interfaces.
9. Regularly patch SAP systems. Implement missing SAP Security Notes and patch systems at least once a month. Security Notes can be downloaded from the SAP Service Market Place.
10. Regularly monitor the SAP security configuration. Standard SAP services such as EarlyWatch (EWA) and the Computing Center Management System (CCMS) can be used to monitor some security-relevant configurations. However, they do not provide the same coverage as professional-grade security tools such as those used by Layer Seven Security. You can learn more about SAP security monitoring through vulnerability assessment here. To discover why vulnerability assessments should be an integral component of your SAP security framework, click here.
Imagine a system that provides a single, unified interface to all your SAP applications for not only everyone in your company but customers and suppliers. Imagine also that this system is web-based and uses single-sign-on. Congratulations, you’ve just envisioned the Netweaver Portal, the cornerstone of SAP’s strategy to integrate business information and processes and the fountain of much of the company’s recent success. Given its importance, you would think that any security vulnerability in the Portal would be quickly dealt with by SAP’s security engineers. Yet, if this is the case, why did it take SAP one and a half years to patch a vulnerability that left the Portal open to session hijacking?
Session hijacking is also known as session fixation or broken authentication and ranks consistently high in the OWASP Top Ten web application security risks. In fact, in the most recent survey, its rated as the third most prevalent and dangerous vulnerability in web applications. Hijacking occurs when attackers exploit weak functions in the application layer to assume the identities of legitimate users. Attackers usually target passwords, keys, session tokens and other authentication factors. Its not that difficult to find flaws in most applications since developing secure authentication and session management schemes for custom applications is no walk in the park. SAP applications are no different.
In July 2009, SAP was notified about a session fixation flaw in the J2EE engine that affected versions 6.4-7.2 of the Netweaver platform, which is essentially the technical layer of SAP systems. In the words of SAP itself, this flaw could be exploited to gain access to authenticated user sessions (SAP Note 1310561) through attack vectors such as MITM that provide hackers with access to the session IDs of SAP users which can then be used to logon to target SAP systems. The impact can be very high, especially when you consider that the Portal provides Web-based access to HR, financial, customer relationship management, product lifecycle management, and other critical applications (SAP Solution Brief).
The session hijacking vulnerability was eventually patched by SAP through the introduction of JSESSIONMARKID, a secure (HTTPS) cookie that automatically renews after successful logons. However, the shocker was that it took SAP 18 months to develop and release a patch for the vulnerability. That’s twice the length it took the company to rollout its new database, HANA, from “idea to completion” (Vishal Sikka, SAP AG Board member). Its possible that the existence of this vulnerability was well known within hacking communities long before the much anticipated fix was released by SAP. Disclosure guidelines issued by SAP urge security researchers not to publicize information about vulnerabilities until they are patched. Most researchers, rightfully so, choose to follow SAP’s request. However, given the severity of these and other vulnerabilities, customers shouldn’t accept such a long window for patch management. After all, if SAP can develop and release an entirely new database in a mere 9 months, surely it can fix a critical security flaw in its Portal just as quickly.