Vulnerability description:
SAP's NetWeaver platform is vulnerable to a (web based) session fixation vulnerability. An initial HTTP connection to the J2EE Engine gets assigned a standard Java cookie, named JSESSIONID, that contains the user session ID pre-authentication. Once the user successfully authenticates through any SAP web application or module, hence using the SAP NetWeaver platform and the SAP J2EE Engine, the session ID is not renewed post-authentication, therefore, the platform is vulnerable to session fixation.

SAP NetWeaver is SAP’s integrated technology platform and technical foundation for all SAP applications and modules:

This session fixation vulnerability can be used to selectively attack targeted key business SAP users (regular or administrator), as well as any SAP user indiscriminately. As a result of the attack, the attacker will get unauthorized access to SAP by hijacking the victim user session and fully impersonating the user within the SAP environment.

Session fixation vulnerabilities can be leveraged to bypass the most advanced authentication mechanisms, including passphrases, client-based digital certificates, smart cards, and biometrics.

Considering SAP industry presence as the world’s leader in business software, and its current numbers (+100K customers in 120 countries, +140K installations, and +2,4K certified partners), the impact of this specific vulnerability is extremely high worldwide, affecting thousands of critical business environments and their daily activities.

All the vulnerability details, how it was discovered, worldwide impact, and additional protections mechanisms (apart from the ones detailed in this advisory) are available on the associated presentation and whitepaper [1], and specifically on case study #3.

Security solutions, workarounds, and countermeasures:
Companies and organizations using SAP products and solutions, therefore the SAP NetWeaver platform, must apply the recommendations detailed on the associated SAP Security Note, 1310561 [2], and ensure that the newly added "SessionIdRegenerationEnabled" Web Container Service property is enabled. Turning on this property adds a new secure (HTTPS) cookie to sessions, called JSESSIONMARKID, that gets renewed after a successful login, thus mitigating session fixation attacks.

By default, this property is disabled in previous/legacy versions (6.x), and it is enabled since version +7.11 SP06 and all SPs for 7.20 and 7.30.

Vulnerable platforms:
SAP has confirmed that multiple SAP NetWeaver versions are vulnerable, including 6.40 up to 7.20. See the associated SAP Security Note for details [2].

The vulnerability was discovered on SAP NetWeaver Portal version 6.4.200607310245.

Vendor information:
SAP confirmed the existence of this vulnerability on July 2009 and released an associated SAP Security Note, number 1310561, on December 2010 [2], acknowledging proper security researcher credit [3].

We at Taddong honestly believe this finding must be publicly known by the information security community in order to take appropriate countermeasures and mitigate the vulnerable behavior. Therefore, we have tried to coordinate the release of this security advisory together with the vendor, following responsible disclosure principles. This vulnerability is extremely relevant considering the extensive number of SAP-based business environments available in the industry and the potential impact of the associated attacks.

Vulnerability report timeline: (Summary)2009-07-02: Taddong contacts SAP to provide details about this vulnerability.2009-07-14: SAP ratifies the vulnerability and provides the temporary available countermeasures ("SessionIdRegenerationEnabled"). The disclosure plans and estimated timeframe for a fix started to get discussed.2009-07-23: The initial estimated timeframe is set in two months (end of September), being both parties aware that most probably this is a best case scenario. 2009-09-18: A few difficulties and stability issues associated to fixing the vulnerability started to arise, so a new fix estimate is set for January 2010. During the next couple of weeks different options are evaluated to reduce the newly estimated deadline, and to analyze the real impact worldwide.2009-11-24: An status update is requested by Taddong, and the January estimation is confirmed to be still valid. An initial technical solution was being tested by that time. Besides that, the disclosure plans and models of both parties continued being evaluated. SAP clarifies is in the process of evaluating its externally facing security program.2010-01-26: A solution is still not available, the issue was escalated internally, and several months were required to be able to fix the vulnerability for all the different releases affected (7 months after initial notification). During the process, responsible disclosure and impact are reevaluated.2010-03-08: A new deadline is established for September 2010 trying to cover all releases, as a few issues were found on legacy versions. In parallel, the option of providing partial fixes for specific customers is under evaluation (9 months after initial notification).2010-08-06: A meeting is scheduled for November 2010 with the goal of discussing in-depth the vulnerability details and conclusions, plus collaborating and agreeing on the final disclosure actions and release deadline (13 months after initial notification).2010-12-14: The vulnerability is privately released by SAP in the SAP Service Marketplace as Security Note 1310561 [2] to its customers and partners (18 months after initial notification).2011-03-17: The vulnerability and lessons learned are publicly released by Taddong during the Black Hat Europe 2011 conference in Barcelona [1] after an implementation time of three months (21 months after initial notification).2011-03-18: Taddong publishes this security advisory.

About Taddong:
Taddong (www.taddong.com) is a company established in Spain in 2010 with the purpose of improving customer's information security, by discovering and eliminating or mitigating the real risks that threaten their networking and information technology infrastructures. To achieve this goal, Taddong's portfolio includes specialized information security services, requiring an in-depth technical knowledge and broad understanding of the information technology market, as well as training services, focused on providing customers with auto-defense skills. Taddong remains at the forefront of the security market through continuous research and education activities.

Disclaimer:
The contents of this security advisory are copyright (c) 2011 Taddong S.L., and may be distributed freely provided that no fee is charged for this distribution and proper credit is given.

Wednesday, March 9, 2011

Unexpectedly, at the end of last week I had to prepare in less than 24 hours the third (and last by now) episode of the "Browser Exploitation for Fun and Profit" trilogy, dubbed "Revolutions". With this one, the "Matrix-like" series is over ;)

I have had most of the ideas I wanted to highlight on the third episode on my mind for a few weeks/months, but had to put them all together on a slide deck for a last minute presentation slot on the awesome Rooted CON 2011 Spanish security and hacking conference. It was the perfect scenario to finish the trilogy:

Each episode content somehow builds on the topics and knowledge covered on the previous episodes, trying to minimize the overlap, except for the most important messages and goals I wanted to address with this initiative:

XSS vulnerabilities and attacks are undervalued, and both their risk and real impact must be seriously considered by any organization interested on protecting their web applications, and collaterally, their web users and clients.

XSS (Cross-Site Scripting) should be renamed WCI (Web Content Injection) in order to reflect the real scope of the attack, as well as what can be really done with it.

One of the main goals was to provide web application pen-testers with an open-source XSS exploitation platform, based on Samurai WTF, BeEF (the old PHP-based and the new Ruby-based versions) and Metasploit, to push XSS vulnerabilities to the limit and be able to really demonstrate the impact of XSS.

This third episode emphasizes all these main principles, focusing on the current XSS state-of-the-art and using (again) a practical and live demo, plus including two related topics I had a pending publication for:

A “new” kind of XSS I have dubbed "Global (or URL-based) non-persistent XSS": I've called it "new" not stating I'm the one that has discovered it, but emphasizing how most organization put all their attention on enforcing input validation and output encoding to mitigate XSS vulnerabilities mainly on HTTP parameters (GET and POST) and HTTP headers, forgetting about the URL itself.
There are specific scenarios, such as web applications with multi-language support, where this vulnerability is specially relevant, and in particular, due to its global nature, as it affects all the resources within the web application.

Multi-technology WCI (or XSS) on mobile devices: XSS, or better said WCI, not only affects the traditional web applications and web browsers but other "web clients" (or web-based user interfaces) associated to wireless technologies, such as the SMS or Bluetooth notification systems in mobile devices, like Windows Mobile (WM) 6.1, WM 6.5 (HTC), or Palm WebOS. My bet is that other inputs, such as barcodes, QR-codes, or audio, will affect mobile devices in the near future too!

I added a new final step to the live demo to demonstrate the BeEF frame redirect plug-in capabilities (by Yori Kvitchko), where the victim user can remain hooked to the BeEF framework through the vulnerable web application, while the vulnerable web page is hidden under a 100% iframe showing a different page, such as Google. Although this technique still has a few drawbacks on the pen-tester side due to the original URL and favicon not being replaced by the new attacker's iframe, this can be easily bypassed on some (web clients of) mobile devices (e.g. iPhone and Android) using URL or address bar hiding techniques (see the references at the end of the presentation).

I hope everybody attending any of the related presentations run during the last four moths, or that have simply read the material, enjoyed the whole trilogy. Now it is your turn to put that knowledge and skills into practice and help organizations to mitigate the impact and reduce the prevalence of XSS (or WCI) on web applications.