Layer Seven Security

White Hats, Black Hats and Skiddies: The Class System in Information Security

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.

The Top 5 Security Notes you should apply to Patch your SAP systems

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.

The Four Myths of ERP Security

There are several myths in ERP security. One of the most common is that security is largely a matter of controlling access and segregation of duties. Another is that business applications are accessible only within internal networks. Yet another is that such applications are not a target for attack. All three are based on a simplistic and misguided take on today’s ERP systems.

The reality is that contemporary ERP systems have a highly complex structure. Complexity is the enemy of security. Vulnerabilities can be found not only in the business or application layer (which is the traditional area of focus for ERP security practitioners) but the technical layer that includes database, operating system and network components. A Fort Knox approach for the application level will provide a false sense of security if architectural,  configuration and programming flaws are not addressed at the technical level.

This is compounded by the fact that most ERP instances have more than one attack surface. Almost all have direct or indirect connections to the Internet. The former includes connections to external offices, suppliers, vendors or other partners and to SAP services. The latter can include connections to user workstations with Web access. ERP resources are increasingly designed to be accessible by mobile users using Web-based protocols, ports and services. The isolated mainframes of yesteryear are a distant memory in our era of global communications.

Vectors for attack surfaces in ERP systems are generally well-known. What’s more, most can be performed with low-spec laptops and minimal technical knowledge. The idea that very few people have any motive to attack such information-rich systems is one of the most disturbing and perplexing myths in ERP security. I’m reminded of a comment that was made to me by a prominent partner in a well-known consulting firm. The partner was engaged as a security advisor by a large meat processing company during an otherwise successful SAP implementation. In his view, the client had a relatively low risk profile which justified a ‘vanilla’ security framework for its SAP systems. As a result, the company was urged to stick with SAP defaults, wherever possible.

The leads to the fourth and most damaging myth in ERP security: the notion that systems are securely configured by default and, where they are not, it’s the responsibility of the vendor to secure the system. ERP systems are designed to be flexible. They have to be capable of meeting the diverse needs of every imaginable business in all industries and sectors. As a result, there is no standard configuration that can meet the requirements of every business. Security has to be enabled. Default security settings are often highly dangerous and can leave organizations open to internal and external attacks. For this reason, SAP has issued numerous white papers, security guides and other publications to support the secure configuration of its software during and after implementation. This should be required reading for all security professionals specializing in SAP.

SAP does not take responsibility for security issues arising from architectural flaws, misconfigurations and inadequate patching. Customers are expected to design, manage and maintain their systems in a secure manner. This can prove to be a challenge in companies where there is no clear ownership over SAP resources or in cases where systems are owned by business departments that lack the technical skills to effectively manage ERP security. In these scenarios, business owners should take steps to share ownership with IT functions, especially technical resources within their organization that are more accustomed to dealing with infrastructure or platform-level security. There is often a strong relationship between the strength of SAP security in organizations and the degree of partnership between business and IT.