admin, Author at Layer Seven Security

Netweaver Single Sign-On: Is it Worth the Risk?

admin on February 23, 2012

SAP’s acquisition of SECUDE in 2011 is finally bearing fruit. Recently, SAP announced the launch of Netweaver Single Sign-On 1.0 which can be downloaded from the Service Marketplace. This is the latest addition to SAP’s identity and access management portfolio and is based on SECUDE’s Secure Login and Enterprise SSO solutions. It uses protocols such as Kerberos, X.509 and SAML to enable mutual authentication between not only SAP applications but between SAP and legacy systems. It also supports cross-company authentication between different domains. This is achieved through federated identity systems based on a choice of IDP or STS, which is used to issue and verify security tokens.

SSO aligns well with SAP’s ambition to ‘help companies run better’. It does so by seamlessly integrating people, processes and technology without the inconvenience of multiple logons. It also lowers the Total Cost of Ownership (TCO) by reducing the burden on Helpdesks that spend an inordinate amount of time helping locked-out users reset their passwords. According to research performed by the META Group (now owned by Gartner) 20-50% of all support calls are caused by forgotten or expired passwords. The cost to manually reset passwords ranges from $15-30 per call, and on average, users call help desks with a password problem 4 times a yearâ€. Forrester Research estimates the average cost is closer to $70. This should give SAP a leg up over the competition, not that it needs it, judging by the latest results.

For security folks, the case for SSO is less clear cut. While it enables companies to standardize and enforce stricter password policies to legacy systems, simplify administration and reduce the risk that users will write down credentials needed to logon to different systems, SSO has some serious drawbacks.

Firstly, implementing SSO is no picnic. Retrofitting legacy systems can be a nightmare. Secondly, since SSO only deals with authentication and not authorization, the administrative gains are minimal: somebody still has to setup privileges for every new user. Privileges are rarely synchronized between systems.

Thirdly, it creates a single point of attack. This is by far the most serious concern with SSO which delegates authentication to a single, central Identity and Access Management (IAM) system. IAMs are attractive targets for attackers, especially when they provide direct access to information-rich SAP systems. Attack vectors used to compromise SSO logins and passwords range from cross-site scripting, phishing to social engineering and have been successfully deployed against SSO schemes used by tech giants such as Google, Facebook and Twitter. A special mention should be given to Denial of Service (DoS) attacks. Note that SSO intensifies the damage caused by DoS against an IAM since it impacts every system relying upon the IAM for authentication.

Clearly, SSO is a double-edged sword. To realize the benefits, you have to manage the risks. This should include multi-factor authentication and hardening of all systems in the SSO environment. The latter should include regular patching, client-side security such as SNC encryption for SAP GUI traffic and host-level vulnerability assessments. You can learn more about SAP vulnerability management here.

SAP patches a session hijacking vulnerability in the Netweaver Portal

admin on February 14, 2012

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.

A Guide to Rootkits and Trojans in ABAP Programs

admin on February 5, 2012

If you missed Ertunga Arsal’s presentation on SAP Rootkits and Trojans at the 27th Chaos Communication Congress, you can now watch the entire hour-long session below. Ertunga is an accomplished SAP security expert and an entertaining speaker if you appreciate dry, German humour. In this video, Ertunga demonstrates how attackers can use several paths to compromise weak SAP systems (usually development or test environments), infect clients that connect to the compromised systems and then eventually work their way up to production and even partner systems. These so-called˜Triple Penetration’ attacks can compromise entire SAP landscapes.

Ertunga also demonstrates how attackers can crack hashed SAP passwords and discusses problems with SSO. He makes a great comment about how SSO is really a convenience feature and does nothing to improve security and shows how attackers can create their own SSO certificates to logon to SAP using the IDs of users in the target system.

However, the highlight of the session is the discussion around SAP Rootkits and Trojans. Ertunga walks through several injection attacks that can be used to infect ABAP programs. Rootkits can be used to execute commands that, for example, automatically donate part of a company’s profit to charity (the so-called ‘Robin Hood’ worm) or publish salary information online. He points out that development activities should be tightly controlled and monitored, especially if you’re using third party developers with SAP_ALL rights. If your developers are internal, Ertunga warns against hiring developers from competitors since this can open the door to commercial espionage and sabotage.

The Hidden Danger of GRC

admin on February 4, 2012

Does anyone remember the world before GRC? I know it seems like decades ago but the fact is solutions such as SAP GRC are a relatively new phenomenon. Until recently, most of us were working with SU01 and SUIM. While such tools have undoubtedly made life easier for administrators and auditors alike, there’s a hidden danger associated with their use that I’ve observed over and over again when clients rely too heavily on them to secure their environments.

Before we get to that, here’s a brief survey of GRC platforms for readers looking to adopt or switch solutions:

Today’s GRC landscape is far more complex than a simple toss-up between Approva and SAP GRC (formerly Virsa). Although these platforms remain the most popular among large companies with thousands or even tens of thousands of users, the market includes a number of new upstarts that are worth considering if you’re looking to save some serious dollars without sacrificing functionality. This includes Alert Enterprise, Security Weaver, Xpandion and CSI Tools (the links are provided below). All of these vendors offer a suite of scalable applications designed to provision user access, monitor segregation of duties in real time and automate user access reviews.

The pros and cons of the different platforms depend upon what you’re looking for. However, one very important piece of advice is to define your requirements very clearly and stick to them throughout the selection process. This way, you won’t be swayed by clever marketing that offers you bells and whistles you’ll never use. I’ve lost count of the number of times I’ve seen security and audit groups buy vast GRC suites to monitor everything in sight when in fact all they really needed was a basic tool to check their authorizations once a year or, at best, every quarter. Truth be told, if this is what you’re looking for, you should consider sticking with SAP SUIM. It may be so slow and cumbersome, but it gets the job done for next to nothing.

There’s also another important benefit to persevering with standard SAP functions that’s often overlooked: working directly with SAP builds a familiarity and depth of understanding of your environment that’s hard to form when you’re dealing with SAP through GRC tools. It also requires more intellectual effort and therefore forces users to develop their investigative skills rather than rely upon canned queries and reports.

In the grand scheme of things, these are minor drawbacks. We could just as easily argue that the enormous time and effort freed up by GRC tools allows resources to be devoted to more value-added areas. True, but there is a far bigger concern that can’t be so easily dismissed.

In the minds of those that administer GRC tools, the very notion of what is and isn’t SAP security is closely associated with the scope of the software they use. In other words, these tools shape our conception of security. Time and again, we are lulled into a false sense of security because of the rosy picture painted by GRC software. Often, this turns out be a mirage when we are forced to widen our paradigm to include the security of technical components of SAP that are beyond the scope of these programs. SAP security is about more than authorizations. It’s even deeper than Basis. In fact, it reaches down into the very kernel of SAP. It includes areas that are new to the SAP landscape and others that are often simply overlooked or underestimated. Many of these areas are discussed in our whitepaper Perfect Storm: The Brave New World of SAP Security. The moral of the story is that the results of GRC tools should be taken with a pinch of salt. Locking down critical authorizations, users and configurables doesn’t mean that your SAP systems are secure or even compliant with SOX, PCI or other standards. It’s only a small part of a broader security strategy that should include managing the technical components of SAP Netweaver that can be highly vulnerable to internal and external attack.

The SAP Security Blog

admin on January 18, 2012

Welcome! This blog is designed to help you stay in touch with the latest trends and developments in SAP security. Feel free to join the discussion by leaving comments and stay updated by subscribing to the RSS feed. To subscribe by email, click the RSS icon in the top right hand corner of the page, select ‘View Feed XML’ and then choose your email application. For most of you, this will be Microsoft Office Outlook. Thanks!