Layer Seven Security

Lessons from the Top Ten Data Breaches of 2012: Defense-in-Depth for SAP Systems

admin on February 6, 2013

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.

Top Ten Data Breaches 2012

 

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.

The Final Frontier: The Challenges in Developing Secure Custom ABAP Programs

admin on January 18, 2013

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.

SAP has responded by issuing a series of recommendations to customers to strengthen configuration settings in components of the NetWeaver AS. These can be found in the whitepaper Secure Configuration of the SAP NetWeaver Application Server Using ABAP.

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.

Security Researchers Expose a Dangerous Authentication Bypass in Oracle Databases

admin on September 27, 2012

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.

Cybersecurity Disclosures: A Three Step Strategy for Compliance with the New SEC Guidance

admin on August 23, 2012

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.

Download the Ultimate Guide to Auditing and Securing Procure-to-Pay Controls in SAP

admin on August 17, 2012

The third installment of Layer Seven Security’s SAP Audit Guide was released today and can be downloaded at http://layersevensecurity.com/SAP_audit_guides.html. The series has proven to be a popular resource for audit and security professionals with over 10,000 downloads to date. The latest Guide focuses upon expenditure-related controls in areas such as vendor master data, purchasing, invoice processing and payment processing.

Forthcoming volumes of the Guide will deal with areas related to inventory, human resource management and Basis. Although the Guide was originally intended to the cover ERP-related modules most commonly implemented by SAP clients, Layer Seven Security will develop and issue similar guides for components such as Customer Relationship Management (CRM), Supplier Relationship Management (SRM) and the Enterprise Portal (EP). Stay tuned for future releases and feel free to give us your feedback.

SOAP Opera: Securing SAP Web Services

admin on July 19, 2012

The best run businesses may run SAP but very few run it exclusively. Most SAP systems operate in a complex, heterogeneous environment with information and processes spread across multiple systems including legacy applications. For SAP, this has always been a barrier to the rapid deployment of its software. Traditional solutions such IDocs, BAPIs and other interfaces were far from ideal, requiring extensive manual effort. Creating and managing the interactions between SAP and non-SAP systems was not only difficult and time-consuming, it hindered program development. Minor change requests would lead to long-term projects that would take months and, in some cases, years to implement.

Service-Orientated Architecture (SOA) offered a salvation for SAP. By embracing the principles and techniques of SOA, SAP was able to improve interoperability (which is essentially the ability to integrate diverse systems) and reduce development time and effort. This meant breaking down SAP functions into discrete objects that could be accessed or executed by other applications using open protocols and standards. These objects are known as Web services or, when subject to SAP business logic, Enterprise Services (ES). Examples include the ability to read customer data, create a sales agreement, cancel a shipment or update bank details.

Web services are constructed using standardized rules to support flexibility and ease of integration. The rules include Simple Object Access Protocol (SOAP). The name is misleading. SOAP is neither simple nor a protocol. In fact, it’s a schema for data exchange using Extensible Markup Language (XML). It provides a standardized way to exchange information between diverse systems. SOAP messages are XML documents that consist of an envelope, header and body.

Other Web service rules include Universal Description Discovery Integration (UDDI), which is used to register and catalog Web services, and Web Services Description Language (WSDL), which is equivalent to method signatures in programming language, used to describe how web services are called, the types of data that are transferred, as well as information related to network protocols, addresses and ports. We should also mention Web Services Business Process Execution Language (WS-BPEL), which is used to construct applications by binding together different Web services.

Service orientated environments are based on loosely coupled Web services that locate one another through UDDI registries and then dynamically bind together during runtime. When combined with WSDL, this happens through automated applications without human intervention. It can also be initiated by end users interacting with SOA environments through Portals. Portals, such as the SAP Enterprise Portal (EP), act as proxy agents, enabling users to interact with Web services in a SOA. We will discuss security concerns with the EP in a later article since this review is focused exclusively on Web services.

The SAP NetWeaver Application Server (NetWeaver AS) incorporates a Web Service Framework that includes ABAP and Java runtime environments for SOAP requests, tools that support UDDI registration and an Internet Communication Manager (ICM) to manage Web service calls usually through port 80NN (HTTP). Netweaver AS is the cornerstone of the SAP software stack. It integrates SAP and non-SAP applications and manages connections between the application layer and the underlying operating system and database.

SAP Internet Communication Manager

Creating a Web service in SAP couldn’t be any easier. In most cases, it can be performed through simple wizards in both ABAP (Object Navigator) and Java (Developer Studio). You will need authorizations associated with the role SAP_BC_WEBSERVICE_ADMIN including S_ICF_ADMIN. Transaction WSADMIN is used to manage runtimes, generate WDSL documents and publish Web services in the UDDI.

Securing Web services is a formidable challenge. SOAP was designed for simplicity and extensibility, not security. Standard SOAP messages do not perform any authentication between endpoints or intermediaries, or provide mechanisms to protect the integrity or confidentiality of data at rest and in transit. For the most part, Web services share the same underlying architecture as Web applications. Consequently, they are vulnerable to similar exploits. This includes SQL injection attacks that target databases accessed by Web services, dictionary attacks against password protected Web services, directory traversal, buffer overflows, packet sniffing, man-in-the-middle exploits, schema poisoning, denial-of-service attacks, Trojan horses containing logic bombs, trapdoors and backdoors and XML injection attacks that target Web services directly which could lead to cross-site scripting. Since UDDI directories and WSDL mechanisms rarely require authentication and authorization, Web services are also vulnerable to remote reconnaissance attacks which are used to garner information on target systems to probe for potential vulnerabilities. Specialized search engines such as Shodan simplify the task of fingerprinting Web services that are exposed to the public, making reconnaissance very easy.

Firewall rules can be configured to ensure Web services are only accessed from legitimate networks and trusted systems. This could be supported by Intrusion Prevention Systems (IPS) that monitor for attacks against Web services. However, in reality, network perimeter controls offer scant protection against such attacks. Web services travel over HTTP. This is left open by most firewalls. Furthermore, the typical IPS does not support SOAP. Next-generation firewalls that have the ability to filter HTTP content including XML messages are expensive and offer poor throughput. Therefore, they are rarely adopted by organisations.

XML gateways provide the equivalent level of protection without the degradation in performance.  Gateways are like application-level firewalls that act as intermediaries between external (untrusted) and internal Web services. Since they force SOAP messages to pass through hardened entry points that restrict access based on source, destination and other measures, gateways offer some measure of protection against Web service attacks. Enterprise level appliances such as the Cisco ACE XML Gateway can be integrated into SAP environments.

Gateways are attractive targets for attackers and, if subverted, can compromise internal Web services. Therefore, they should be regularly patched and supported by strong policies and rule-sets. Also, they should be reinforced by other components of an effective defense-in-depth strategy. This should include SSL/ TLS (HTTPS) to authenticate and encrypt SOAP messages when dealing with single endpoints (SSL doesn’t work with SOAP messages that traverse multiple destinations). It should also include adequate header extensions in SOAP messages that define security policies for message handling in accordance with the WS-Policy framework. The policies should include requirements for authentication, encryption and non-repudiation. Digital signatures should be used to protect against unauthorized modification of the policies. They should also be used to protect UDDI entries since compromised entries could lead requestors to bind to malicious Web service providers. Web services and underlying data should be replicated to improve availability and guard against denial of service attacks. Reconnaissance attacks can be blunted by disabling default error messages in the ICM and J2EE that disclose sensitive system information. They can also be thwarted by deactivating the info ICF service which can be abused by remote attackers to retrieve the same information. The presence of the info and dozens of other high-risk SAP services can be detected through vulnerability assessments performed by Layer Seven Security. The assessment leverage SAP-certified software to scan for over 400 security vulnerabilities in SAP systems. This includes services that can be accessed by attackers to perform critical functions and compromise such systems. Some of these services do not require any user authentication.