One of the most memorable events at last year’s BruCON in Belgium was Martin Gallo’s expose of the SAP DIAG protocol. The session can be viewed in its entirety below. DIAG (Dynamic Information and Action Gateway) is a proprietary protocol supporting client-server communication and links the presentation (SAP GUI) and application (NetWeaver) layer in SAP systems. During the conference, Gallo presented the findings of his ground-breaking research that led directly to the identification of several denial-of-service and code injection vulnerabilities arising from security flaws in the DIAG protocol, patched by SAP in 2012.
Most researchers have focused on identifying weaknesses in the compression algorithm that scrambles payloads and other data transmitted through DIAG. The most notable research in this area was performed by Secaron in 2009. Secaron demonstrated that it is possible to intercept and decompress DIAG client-server requests including usernames and passwords. Subsequent research performed by SensePost revealed that the LZC and LZH compression methods used by SAP for DIAG are variants of the Lempel-Ziv algorithm. Furthermore, since both methods are also used in the open-source SAP MaxDB, the compression and decompression code-base is publically available. SensePost created a custom protocol analysis tool in Java using MaxDB code capable of compressing and decompressing DIAG messages. The tool could be used to intercept, read and modify client-server traffic in SAP.
Gallo’s research provides an unprecedented insight into the inner workings of the DIAG protocol. The vulnerabilities revealed by the research can be exploited through both client and server-side attacks. Deep inspection of DIAG packets can be performed through the SAP Dissection plug-in developed by Gallo for Wireshark, a popular network protocol analyzer. The research underscores the importance of strong countermeasures in SAP systems. This includes restricting access to the Dispatcher service responsible for managing user requests, SNC encryption for client-server communication, disabling SAP GUI shortcuts used by attackers to execute commands in target systems, effective patch management, and periodic vulnerability assessment and penetration testing.
One of the highlights of the Sapphire conference earlier this month was the insightful session on SAP security delivered by Gordon Muehl, Senior Vice President of Product Security at SAP. A recording of the session can be viewed below. The session highlighted the threat presented to Internet-enabled SAP systems by external agents and stressed the importance of protecting systems against Web-based attacks such as verb tampering. According to SAP, such measures should include secure software development procedures and training for developers, as well as independent code reviews performed by specialized security resources to validate programs before release. SAP also recommends a proactive patch management strategy that includes regular monitoring of SAP Security Notes and the rapid application of high priority patches.
Layer Seven Security leverage leading SAP-certified solutions to secure SAP systems against external threats, identify code-level vulnerabilities and detect critical missing Security Notes. To learn more, contact a representative now.
The breadth and depth of the 2013 Verizon Data Breach Investigations Report (DBIR) is unprecedented. Released this Monday, the reports brings together the investigations performed by nineteen law enforcement agencies, research institutions and private security firms that combat data breaches including the European Cybercrime Centre (EC3), U.S Secret Service and the Department of Homeland Security. The global study represents the most comprehensive assessment of the drivers of information leakages. The findings and recommendations in the study are based on the analysis of 47,000 security incidents and over 600 confirmed breaches. They provide an unparalleled insight into attackers and their methods, enabling organizations to establish more effective countermeasures against such threats.
Threat Actors
The study categorizes threat actors into three key groups: Organized Crime, State-Affiliated and Activists. These groups tend to originate from distinct regions, target different types of assets and data, and employ distinctive attack methods. Organized crime actors, for example, generally stem from Eastern Europe and North America and target financial information in companies within the finance, retail and food industries using methods such as hacking and malware.
Activists comprise the largest group and are generally opportunistic. Organized criminals are more targeted but not as targeted and relentless as state-sponsored spies that use the most sophisticated methods to steal intellectual property, financial data or insider information from organisations. The graph below demonstrates that state-sponsored actors target a variety of sectors including education, finance and utilities. Nearly three-quarters of espionage attacks were targeted not at the public sector but at companies within manufacturing, professional services and transportation industries.
Threat Actions
All threat actors employ hacking and malware methods to varying extents. This includes brute force attacks, spyware, backdoors, SQL injection, and the use of stolen credentials. Hacking involves attempts to access information systems usually through bypassing logical security measures, whereas malware is the use of malicious software, scripts or code, designed to alter the performance of systems. Both methods are increasingly scalable, automated and anonymous due to the greater accessibility of systems through the Internet and interconnectedness between systems and organizations.
Recommendations
According to the DBIR, “All kinds of organizations, from government agencies to iconic consumer brands, internet startups to trusted financial institutions have reported major data breaches in the last year. Nobody’ immune, no target is too small, or too large. The methods used by hackers to gain access to data are numerous, wide-reaching and ever-growing. This isn’t a threat you can afford to ignore”. Although attacks may be inevitable, there are clear, concrete measures that organisations should undertake to prevent such attacks from leading to data breaches. Breaches not only have the potential to cause financial and reputational harm, they increasingly require public disclosure: the European Union is expected to introduce mandatory reporting requirements this year. Forty-six states of the U.S have already done so. Furthermore, SEC reporting requirements mandate public companies to disclose the nature and extent of cybersecurity incidents to shareholders through corporate filings.
Organisations should implement common security measures to minimize the risk of a data breach, as well as detect and contain successful attacks. The specific recommendations made by the study include the implementation of the 20 Critical Security Controls (CSC) advocated by the Consortium for Cybersecurity Action (CCA). The controls are listed in the table below.
The following table maps the CSC to the most common threat actions identified by the DBIR and demonstrates that effective data breach prevention strategies require a combination of measures in the areas of people, process and technology.
The majority of the 20 Common Security Controls are directly applicable to SAP systems. The improper configuration of SAP applications, platforms, programs and clients can expose such systems to many of the threats identified by the DBIR and the risk of a data breach. The consequences can be disastrous when poorly configured systems are combined with inadequate boundary and malware defenses, insecure network and landscape architectures, ineffective access controls, and the absence of regular vulnerability assessment and penetration testing. Layer Seven Security has developed a comprehensive white paper to guide SAP customers on measures required to secure SAP systems against data breaches. The paper advocates a strategy based on the concept of defense in depth. You can download the paper here.
According to the results of a survey released by HBGary during the recent 2013 RSA Conference in San Francisco, more than 70 percent of American investors are interested in reviewing the cybersecurity practices of public companies and nearly 80 percent would not invest in companies with a history of cyberattacks. The survey of 405 U.S. investors also found that more than 66 percent of investors are likely to research whether a company has been fined or sanctioned for data breaches before making an investment decision. The survey underscores the fact that today’s investors are acutely aware of the impact of a successful breach on brand reputation and financial performance. This includes the breach of both customer data and intellectual property (IP).
Although the former tends to attract more public attention, the latter has a more pervasive effect on corporate competiveness and performance. A 2012 FBI report entitled Economic Espionage: A Foreign Intelligence Threat to American Jobs and Homeland Security revealed that the cost of IP theft to U.S companies resulting from commercial espionage was over $13 Billion in the last fiscal year. IP-intensive industries account for almost 35 percent of U.S. gross domestic product (GDP) and over 60 percent of merchandise exports. Furthermore, they support 40 million jobs in the United States.
Legal protections such as copyrights, patents and trademarks do not effectively protect intellectual property that is susceptible to theft to regions in which such protections are ineffectively enforced. The importance of IP to the national economy and the difficultly of enforcing rights outside the U.S has led the Department of Homeland Security to brand IP theft as one of the most dangerous threats to national security. In the words of the Assistant Director of the FBI’s Counterintelligence Division, “with each year, foreign intelligence services and their collectors become more creative and more sophisticated in their methods to undermine American business and erode the one thing that most provides American business its leading edge; our ability to innovate.” In a statement to a subcommittee of the House of Representatives last year, the Assistant Director cited the efforts of a foreign corporation to extract information related to the production of titanium dioxide from the DuPont Corporation in 2011. DuPont is an industry leader in the market for titanium dioxide, estimated to be worth $12 Billion.
Although IP theft is far from new, it is amplified by globalization, the increasing interconnectedness of business partners and the accessibility of electronically-stored intellectual property.
In response, the U.S Government Accountability Office (GAO) recommends a variety of technical controls designed to manage access to information, ensure system integrity and encrypt sensitive data. This includes measures to safeguard network boundaries, enforce authentication and authorization, protect against malware, secure communication paths, and analyze, detect and patch vulnerabilities.
The protection of intellectual property within SAP environments requires a combination of countermeasures covering the triad of people, process and technology. The importance of the first and second of these areas should not be understated. Data breaches often result not from the absence of effective technical controls but employee actions or inactions caused by a lack of awareness and training. Therefore, data protection policies and procedures, including incident response plans, are an important component of strategies to safeguard intellectual property. Process-level measures should include risk assessments to isolate and classify IP, and to identify relevant threats.
Technical countermeasures should include secure landscape architectures. Firewalls and proxy servers should be used to filter access to SAP systems with properly configured ingress and egress rules. Furthermore, network traffic should be monitored and controlled through in-line intrusion prevention systems and Security Information and Event Management (SIEM) systems capable of detecting and responding to certain types of attacks. Data Leak Prevention (DLP) technologies can also be deployed to block the exfiltration of confidential data. Unfortunately, network-level controls are often side-stepped by targeted and sophisticated attacks. DLP, for example, can be by-passed by encoding, encrypting and transmitting data out of corporate networks using protocols such as VOIP rather than methods such as SMTP and FTP, commonly monitored by DLP systems.
Therefore, technical countermeasures must be applied within multiple, interdependent areas to safeguard SAP assets. This includes application, platform, program and end-user areas. Layer Seven Security’s new white paper, Defense in Depth: An Integrated Strategy for SAP Security, outlines a layered approach to protecting data in SAP systems. The paper discusses methods to secure SAP applications, programs, servers, databases, and other components against attacks that attempt to exploit common weaknesses in such environments and extract proprietary, sensitive and valuable forms of intellectual property from organizations.
According to NSA Director General Keith Alexander, cyber-espionage has led to “the greatest transfer of wealth in history.†This is supported by not only a recent report by Symantec, which places the cost of intellectual property theft in the United States at $250 billion a year, but a prominent report on cyber-espionage released by Mandiant Corporation in February this year.
The report is based on security breaches investigated by Mandiant at nearly 150 organizations between 2006 – 2013. It focuses upon the cyber-espionage activities of one of the more than twenty prolific Advanced Persistent Threat (APT) groups in the world. The group labeled as APT1 is believed to be state-sponsored and operating from the Pudong area of Shanghai. It is considered to be a branch of Unit 61398 of the People’s Liberation Army of China. The official mandate of the unit is vaguely defined as ‘computer network operations’ but there is considerable evidence to suggest that the actual mission is the collection of political, economic, and military intelligence. APT1 is estimated to control a large physical infrastructure comprised of thousands of Command and Control servers. Given the size of the infrastructure, the group is believed to be staffed with several hundred resources that are required to be proficient in network and information security and the English language.
According to the report, APT1 compromised at least 141 companies in 20 major industries since 2006. Almost nine out of ten victims were headquartered in countries where English is the native language. The industries targeted by the group “match industries that China has identified as strategic to their growth, including four of the seven strategic emerging industries that China identified in its 12th Five Year Plan” (Mandiant, 2013). Graph 1.1 below demonstrates that the targets span a wide range of industries including Information Technology, Aerospace, Public Administration and Energy, but also, less expectedly, Manufacturing, Media, Advertising & Entertainment, Financial Services and Healthcare. Graph 1.2 displays the geographical distribution of companies compromised by APT1.
1.1 Industries Compromised by APT1 Attacks (Source: Mandiant Corp, 2013)
1.2 Geographic Location of APT1 Victims (Source: Mandiant Corp, 2013)
The compromises led directly to the theft of several forms of intellectual property including technology blueprints, manufacturing processes, business plans, policy and procedure documents, partnership agreements, pricing information, parts lists, test results, meeting agendas and minutes, emails and contact lists. They also led to the theft of information related to network architectures and resources and user credentials for business systems. One of the most notable breaches involved the loss of 6.5 terabytes of data over a ten month period from a single organisation.
APT1 employ a signature attack methodology that begins with a spear phishing campaign to penetrate an organization’s network. Emails are targeted at specific employees or groups of employees and appear to be from names that are familiar to recipients. Furthermore, the subject lines and contents of emails usually contain information that is directly relevant to the target. They are delivered with malicious attachments or hyperlinks to malicious files. Files names are personalized and are carefully constructed to appear harmless. Examples include Employee-Benefit-and-Overhead-Adjustment-Keys.zip, Updated_Office_Contact_v1.zip and Oil-Field-Services-Analysis-And-Outlook.zip.
The opening of a malicious file releases an executable that installs a backdoor in the recipient’s system. This enables APT1 to send commands to the compromised system remotely. “APT intruders employ this tactic because while network firewalls are generally adept at keeping malware outside the network from initiating communication with systems inside the network, they are less reliable at keeping malware that is already inside the network from communicating to systems outside” (page 30).
Initial backdoors are beachheads designed to establish a foothold in the network, perform reconnaissance, retrieve files and pave the way for the installation of standard, more powerful backdoors that communicate over HTTP or custom protocols. APT1 deploy standard backdoors to create, modify, delete and execute programs, upload and download files, create and remove directories, start and stop processes, capture screenshots, keystrokes and mouse movements, discover systems and users, and extract passwords. Backdoors are usually installed on multiple systems to maintain a presence in the network. Communication between backdoors and Command and Control servers is difficult to distinguish from regular traffic and is often hidden in encrypted SSL tunnels.
The installation of standard backdoors is followed by privilege escalation usually through the breaking of password hashes for target systems in order to obtain legitimate user credentials. Stolen credentials are used to logon directly to systems, VPNs and portals. Compromised data and objects are packaged in archive files and transferred out of networks through backdoors or protocols such as FTP.
In the words of the report, ATP1’s “ability to adapt to their environment and spread across systems makes them effective in enterprise environments with trust relationships” (page 27). SAP environments are archetypal models of such environments. Systems in these environments and landscapes are configured with numerous trusted connections, often using the most privileged user profiles. Trust relationships in SAP systems have well-known security concerns and should only be used for connections between systems with identical security classifications and established with minimal authorisations. You can read more about securing SAP trust relationships in our white papers. The papers also include guidance on measures to protect SAP servers and clients against unauthorized remote access, password attacks and other malicious actions by groups such as APT1.
According to the Privacy Rights Clearinghouse (PRC), there were 680 reported data breaches in 2012 covering all forms of commercial, governmental, educational, medical and non-profit organizations. The breaches are estimated to have compromised over 27M data records.
The most significant breach occurred at VeriSign. Although the extent of the breach has never been disclosed nor, for that matter, the cause, the breach could potentially have an enormous impact on the ability of companies to establish secure connections to intended servers and verify the identity of those servers. This is because VeriSign is one of the principal issuers of SSL certificates used for encryption and mutual authentication. VeriSign also manages 2 of the world’s 13 root DNS servers, which control the complete database of Internet domain names and corresponding IP addresses. Although the breaches occurred during 2010, they were not disclosed by VeriSign until late 2011 when the company reported the incidents in public filings to the SEC. Guidelines issued by the SEC in 2011 now require registrants to “disclose the risk of cyber incidents if these issues are among the most significant factors that make an investment in the company speculative or risky“. A similar breach at the Dutch certificate authority Diginotar led the authority to file for bankruptcy in September 2011.
The second most significant data breach in 2012 was experienced by Global Payments, a large credit and debit card payments processor. The breach appeared to have stemmed from the compromise of servers in the company’s North American network but quickly spread to other areas of the network. According to initial estimates, approximately 1.5M records including Track 2 credit card data (card expiration date and credit card number) were directly exposed by the breach. This was later revised to 7M. Details on the cause of the breach have never been released by Global Payments. However, the company has disclosed that it has invested almost $85M on measures to improve security following the incident.
In the third major breach of 2012, a targeted phishing attack against employees at the South Carolina Department of Revenue led to the theft of usernames and passwords which were used by foreign attackers to access internal systems and other resources through remote services. Shortly thereafter, the attackers extracted over 8GB of data from the company through compressed database backup files. The files contained an estimated 5M social security numbers, 3M bank accounts and almost 400,000 credit card numbers. The attack may have been prevented through two factor authentication on remote access points. Furthermore, the damage would have been far lower had all the targeted data been encrypted.
Personal and financial records were also breached at the University of Nebraska, the fourth incident in the list. Banking information, social security numbers, addresses, grades and transcripts belonging to current and former students may have been compromised during a targeted attack against some of the organization’s databases.
The fifth and sixth incidents in the list did not involve the breach of financial data. However, they did involve the loss of hundred of thousands of customer records including social security numbers, drivers license numbers, dates of birth and employer information. Both breaches were caused by improperly configured servers. In the case of the Utah Department of Health, a default password had not been changed on one of the compromised servers. In both cases, the effected data had not been encrypted.
In the seventh most important data breach of 2012, an undisclosed vulnerability is suspected to have enabled unauthorized read-level access to a subscriber database at Intel. The database stored sensitive customer-related information including passwords, social security and credit card numbers in plain-text. However, there is reason to believe that the vulnerability was relatively short-lived and did not lead to the leakage of mass amounts of data, explaining the relatively low ranking of the incident. The group suspected to be responsible for the breach is also linked to similar breaches at NASA and US Bank in the same year.
The remaining incidents in the list involved the breach of large volumes of customer-specific data including names, addresses, phone numbers and email addresses from well-known e-commerce companies. In some cases, credit card data and passwords were also effected but the difference between these incidents and those placed higher on the list lies in the fact that sensitive data was encrypted. LinkedIn, for example, used SHA-1 to encrypt passwords. The exception is Yahoo!: over 400,000 were extracted from the company’s servers in plain-text through a SQL injection attack. All three organizations, Zappos, LinkedIn and Yahoo!, are subject to lawsuits for allegedly failing to properly safeguard user data.
Defense-in-Depth for SAP Systems
The incidents reviewed in this article cover a broad spectrum of organizations and industries. Clearly, the risk of data breach is no longer the sole preserve of e-commerce companies running custom-developed programs accessible to the general public through Web application servers. In fact, the most significant breaches effected enterprise systems designed principally for internal use. This should come as no surprise. Most system landscapes are highly integrated with multiple access points. This presents a large attack surface and provides opportunities to vault from compromised systems to connected systems by exploiting trust relationships and communication pathways required to successfully integrate applications in such landscapes.
SAP landscapes are a prime example of highly integrated environments supporting a variety of services through ports and protocols that include HTTP (80), HTTPS (443) and SMTP (25), commonly used by Web application servers. Therefore, SAP systems must be protected against the identical attack vectors that led to many of the data breaches discussed above. This includes methods such as SQL injection, exploitation of default passwords and configurations, and insecure system interfaces.
Protection should be applied at four distinct levels. The first is the authorization level. SAP systems contain thousands of authorizations that control access to various functions and resources. The improper assignment of authorizations can lead to the accumulation of access rights that may provide users with privileges beyond role requirements. Such privileges may be abused to compromise the confidentiality and integrity of information in SAP systems. Therefore, the proper assignment of authorizations and the maintenance of an adequate segregation of duties is the first pillar of SAP security.
The second area is the platform level which is comprised of two components. Â The first component is the secure configuration of the SAP NetWeaver Application Server. This includes network filters that restrict access to SAP services accessible from end-user networks, configuring ACL files for SAP Gateways and Message Servers, enabling SNC and SSL to encrypt network communications, robust password policies, the use of the latest password hashing algorithms, disabling and/or changing passwords for default users, disabling dangerous Web services, securing RFC connections, and regularly patching SAP systems.
The second component of platform level security is the configuration of underlying databases and operating systems in accordance with vendor-specific recommendations or generally-accepted security benchmarks. For example, Oracle databases supporting SAP systems should be secured in accordance with the comprehensive security guides issued by Oracle for each database version. In some cases, vendor-specific recommendations may conflict with SAP requirements. Therefore, recommendations must be applied carefully and selectively, wherever appropriate.
The third area is the program level. SAP programs should be protected against unauthorized changes. Furthermore, custom programs should be developed, tested and deployed in a secure manner to ensure they are not susceptible to code-level vulnerabilities. This includes missing or broken authorization checks, backdoors and rootkits, injection flaws, cross-site scripting, buffer overflows and directory traversals. An effective software development process including requirements for code reviews by appropriately trained resources could meet part of this requirement. However, SAP programs are more effectively controlled through tools that act as a firewall to prevent the deployment of vulnerable code and tools that detect and auto-correct suspicious statements in ABAP code. Currently, the only solution capable of performing both functions is CodeProfiler, developed by Virtual Forge.
The final area of a complete SAP security framework is client-level protection. For SAP GUI, this should include disabling scripting and recording, enabling SNC encryption, and appropriate security module settings. For browser-based access, SAP applications should be located in a trusted zone with less restrictive security settings. This will enable active scripting of Java applets required for certain SAP components without lowering the general security profile of browsers for untrusted connections. Client-level security should also include malware protection, Web filtering and restrictions on the administrative privileges of end-users.
The appropriate management of risks at all four levels in contemporary SAP environments (authorization, platform, program and client) will provide the defense-in-depth required to withstand sophisticated and determined attacks against SAP systems and minimize the risk of a data breach.
In November, SAP released an unusually high number of Security Notes to patch various forms of injection vulnerabilities in it’s software. The trend continued in December with the release of several patches for code injection flaws in the Computer Center Management System (BC-CCM), Project System (PS-IS), Transport Organizer (BC-CTS-ORG) and work processes in Application Servers responsible for executing ABAP programs (BC-CST). Given this alarming trend, this article is focused on discussing the challenges of developing secure ABAP programs for SAP systems, free of common vulnerabilities including not only injection flaws, but cross-site scripting errors, buffer overflows, directory traversals and backdoors and rootkits.
There are three attack surfaces in SAP systems. The first is through improperly defined and controlled application-level access. This attack surface is the most commonly known and understood by SAP customers. Today, most SAP clients deploy any one of a variety of access management tools to control access to sensitive functions and maintain a strict segregation of duties in their ERP systems. This manages the risk of unauthorized access through inadequate authorization structures that grant excessive or conflicting privileges to users and administrators.
The second attack surface lies at the platform level. This generally refers to components of the NetWeaver Application Server, also referred to as the Basis area of SAP systems. The NetWeaver AS is the technical foundation of the entire SAP software stack. It provides the runtime environment for SAP applications and includes work processes for ABAP and Java programs, gateways and modules for managing RFC, Web-based and other forms of communication protocols, tools to manage user roles, profiles and authorizations, and utilities that control certain database and operating system functions. The secure configuration and management of the NetWeaver AS is a vital component of a comprehensive SAP security strategy. However, the results of our security assessments repeatedly reveal common vulnerabilities in basis settings in most SAP environments. This provides a lush attack surface to internal and external attackers looking for an avenue to manipulate or appropriate business data or deliberately disrupt the availability of SAP systems.
The third and final attack surface in SAP provides an even greater array of opportunities for attackers. This surface exists at the program level. ERP systems such as SAP are designed to perform thousands of distinct functions ranging from, for example, adding a vendor to a list of approved suppliers, performing a transport to implement a change in a specific system, or encrypting/ decrypting traffic between servers or clients. These functions are performed by programs stored in the database table known as REPOSRC that are called when requested by work processes in the NetWeaver AS.
SAP programs are developed using two distinct programming languages: Advanced Business Application Programming (ABAP) and Java. Both are vulnerable to coding errors that could expose SAP programs to exploits such as code, OS and SQL injection, cross-site scripting, cross-site request forgery, buffer overflow, directory traversal and denial of service. SAP programs are also susceptible to missing or broken authority-checks that could lead to unauthorized execution of programs. Finally, SAP programs can contain backdoors through hardcoded credentials that bypass regular authentication and authorization controls, as well as malware known as rootkits that provide attackers with remote, privileged access to system functions and resources.
SAP performs a rigorous code review for all standard or delivered programs prior to release. However, some of the vulnerabilities present in the code base are not detected and patched until after release. Security Notes are therefore an important mechanism used by SAP to patch vulnerabilities arising from programming errors.
Custom programs are rarely subject to the same level of scrutiny applied by SAP to standard programs. Programs developed by in-house or off-shore developers to meet the needs of customers not met by standard SAP functionality are often laden with vulnerabilities that, when exploited, undermine the integrity of entire SAP landscapes. Such landscapes are only as strong as their weakest point. A robust application layer fortified with GRC tools has led attackers to shift their focus to the platform and code level. Given the relative openness of most SAP systems at the technical level, the strategy is proving to be profitable.
However, understandably SAP is less vocal on development procedures for custom programs since this is generally the responsibility of each SAP customer. The challenge should not be underestimated. Although manual code reviews to detect common vulnerabilities are theoretically possible, the skill-set to effectively review custom code is not only rare but expensive. Furthermore, it often leads to an increase in development time. Customers should consider investing in code scanning tools that are tuned to detect suspicious statements in ABAP code and integrate directly into the SAP Transport Management System (TMS). Such tools should also be capable of auto-correcting ABAP statements to minimize resource requirements and the impact on existing development times. Presently, the only tool capable of detecting and auto-correcting vulnerabilities in custom ABAP programs, with direct integration with SAP TMS, is Virtual Forge CodeProfiler. To arrange a security scan of custom programs in your SAP environment using CodeProfiler, please contact a representative at Layer Seven Security.
More than two-thirds of mid to large SAP customers in every industry run their SAP applications with Oracle databases. Oracle’s success is driven by compatibility and performance. Oracle 11.2 is certified for use with Unix, Linux and Windows-based SAP environments and provides features such as self-tuning, sophisticated partitioning and advanced data compression that give Oracle an edge over the competition including, in some cases, SAP’s own databases.
Oracle’s achilles heel is security. Earlier this year, the company released 78 patches to address vulnerabilities across its product range including MySQL and Oracle RDMBS. One in five of the vulnerabilities were classified as critical since they could be exploited remotely against firewalled, internal networks. Last month, Oracle issued a warning related to a major SQL injection vulnerability affecting some versions of its database servers. The CVE-2012-3132 exploit could enable attackers to gain administrative privileges in servers and therefore disclose, modify or remove data managed by such servers.
Oracle suffered another blow last week when researcher Esteban Fayo of AppSec Inc. successfully demonstrated a proof-of-concept attack against an Oracle database at the Ekoparty security conference using a stealth password cracking exploit. The exploit targets the Oracle login system through a cryptographic flaw in the hash used to encrypt passwords that are leaked in session keys generated by the database. The keys are sent to users during every logon attempt. Remote attackers can use an Oracle desktop client to establish a network connection with a database server. Once connected, they can attempt to authenticate against the server using a valid username. The server will return a session key to the attacker before the authentication process is complete. At this point, the attacker will close the connection and attempt to decrypt the hash using brute-force password cracking software. Short, non-complex passwords can be decrypted relatively quickly using a standard CPU. Since the hashes contain a random salt, attackers can’t use rainbow tables. However, they can use methods such as dictionary hybrid attacks for faster decryption. Also, since failed logon attempts are not recorded by the server, attackers can bypass controls that lock accounts after a certain number of failed access attempts.
A strong firewall policy that blocks remote access to databases may provide some defense against external attacks. However, it will not guard against internal threats including remote attackers with access to network resources inside corporate networks through malware or other methods. The vulnerability effects releases 1 and 2 of the Oracle database version 11g. Oracle has released a new authentication protocol for version 11.2. However, the company hasn’t patched the vulnerability in 11.1 nor released any plans to do so. Since older versions are not vulnerable to the exploit, SAP customers working with Oracle 11.1 should consider switching to authentication protocols used in versions such as 10g. Alternatively, they should consider removing 11g hashes. This will prompt the database to use hashes stored for earlier versions. Customers should also enforce requirements for alpha numeric passwords with a minimum of nine characters. Complex passwords are less susceptible to brute force attacks.
Missing authorization checks, hardcoded usernames and passwords, and vulnerabilities in credit card data stored in SAP Logistics. Download our latest guide to SAP Security Notes at http://layersevensecurity.com/SAP_security_advisories.html
Against a background of growing investor concern and pressure from legislators, the Securities and Exchange Commission (SEC) is leading the drive for more open and timely disclosure of cybersecurity risks and incidents from public companies. Earlier this year, it challenged Amazon’s decision not to disclose the financial impact of the theft of customer data held by its subsidiary Zappos in the company’s annual report. In the view of the SEC, Amazon failed to comply with rules incorporated in the Securities Act of 1933 and Securities Exchange Act of 1934 which require “disclosure of timely, comprehensive, and accurate information about risks and events that a reasonable investor would consider important to an investment decision” (SEC). These rules were clarified by the SEC in guidance on disclosure obligations related to cybersecurity risks and incidents, issued in October last year.
The guidance is based on a broad definition of cybersecurity which is seen as a body of technologies, processes and practices designed to protect networks, systems, computers, programs and data from attack, damage or unauthorized access. It includes attacks and breaches caused by both insiders and third parties. Therefore, incidents such as the theft of proprietary software by an employee at Goldman Sachs in 2009 would fall into scope of the disclosure requirements.
According to the guidance, incidents include not just deliberate attacks, but breaches and losses resulting from unintentional events. In addition to attacks designed to misappropriate financial assets and intellectual property or other sensitive information, it includes Denial-of-Service (DoS) attacks targeted at disrupting operations.
The guidance requires public companies to disclose the risk of cyber incidents if these issues are among the most significant factors that make an investment in the company speculative or risky. In order to comply with this requirement, registrants are expected to evaluate the likelihood and impact of a material incident arising from a breach or failure in their information systems and infrastructure. The assessment should take into account factors such as the value of information contained in applications and systems, the degree to which the fiscal health of a company is tied to the confidentiality, integrity and availability of such information and technology in general, known vulnerabilities, prior security incidents, the financial and reputational impact arising from an incident, and the strength of preventative controls. Based on such an evaluation, a company is required to disclose material cybersecurity risks in the 10-K annual report provided to the SEC which is made available to investors and the general public. Such disclosures are often buried within the section related to risk factors in the 10-K. However, registrants are obliged to discuss material risks within the Managements Discussion and Analysis (MD&A), an area more widely read by investors. The SEC provides some leeway on the extent of information registrants should disclose, recognizing that too much disclosure could be exploited by malicious groups and compromise security efforts.
An inventory of mission-critical or information-rich systems within most publically-listed organisations often reveals a suite of SAP applications supporting everything from sales and distribution, purchasing, financial reporting and human resource management, as well as more industry-specific areas. Invariably, these applications are powered by the SAP NetWeaver Application Server (AS), a platform used to develop programs, manage database, operating system and network connections, link together SAP and non-SAP applications, and a myriad of other administrative tasks. The NetWeaver AS is a complex, Web-enabled area of SAP that is vulnerable to a variety of internal and external attacks. These vulnerabilities are widely known and include various forms of injection, cross-site scripting, session hijacking, DoS, and other attacks. Therefore, when reviewing the strength of preventative controls in SAP systems to determine whether there exists a material cybersecurity risk that requires disclosure, companies should closely review the configuration of the NetWeaver AS. Misconfigurations in this area could create vulnerabilities that can be exploited by insiders and outsiders to embezzle assets, leak information including intellectual property, corrupt data or disrupt operations.
Securely configuring the NetWeaver AS should be the first step in a three pronged strategy aimed at managing cybersecurity risks in SAP systems. When combined with appropriate access controls and technical settings at the application level, companies running SAP applications will greatly reduce the likelihood of material risks in their SAP environments that may require disclosure.
SAP has issued a number of recommendations to help customers configure the Netweaver AS. These recommendations can be found in the whitepapers Secure Configuration of SAP NetWeaver Application Server using ABAP and Protecting SAP Applications Based on Java and ABAP Against Common Attacks. They include regular monitoring of the security configuration of the NetWeaver AS which can be met through vulnerability assessments performed by Layer Seven Security. The assessments leverage software certified by SAP and detect over 400 vulnerabilities in components of NetWeaver Application Servers, the foundation of SAP applications. To learn more, visit our services page or call 1-888-995-0993 to connect with one of our SAP security consultants.
