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.