Serious bug in widely used Java app library patched

Fahmida Y. Rashid

A serious cross-site request forgery vulnerability in a widely used Java application library was patched last week. Developers who use Java Spring Social core library in their projects are strongly urged to update as soon as possible.

Attackers are able to take over a user's account by exploiting a CSRF-style flaw against the Spring Social authentication feature, according to the technical analysis posted on SourceClear's site. The Java Spring Social core library provides Java bindings to service provider APIs from sites such as GitHub, Facebook, LinkedIn, and Twitter. The library lets developers add a social login feature ("Login with GitHub," for example) to their applications and handles the connections with OAuth2 providers. Attackers who successfully exploit the flaw can use victims' social credentials to log in to their accounts on the vulnerable site.

The issue was first discovered by Kris Bosch of Include Security, but Paul Ambrosini, SourceClear's co-founder, identified the failed CSRF check in the Spring Social code. SourceClear privately disclosed the vulnerability (CVE-2015-5258) to Pivotal Software, the developer behind the Spring Social core library, and Pivotal last week released the fix on Maven Central as part of version 1.1.3.

Since the flaw affects all current versions, including version 1.1.2, developers should upgrade to the new version in order to prevent this issue in their projects.

"Given that Spring Social is widely used in Java applications for authentication with different service providers, this vulnerability has a large potential impact," Ambrosini wrote.

The attack mechanism is straightforward. First, the attacker clicks on the social login button on the targeted site using the vulnerable version of Spring Social. This causes the site to generate a unique URL associated with a social media account under the attacker's control. At this point, the attacker needs to trick the victim into clicking on the link, by embedding it into a phishing email, posting the link on social media, hiding the URL as an image source, or by obfuscating the link, to name a few potential scenarios. Once the victim clicks on the link, the victim's account is tied to the attacker's social credentials, giving the attacker full access.

Security flaws in libraries are particularly challenging because they can pop up in many different places. Very few developers nowadays write applications from scratch; most are built by putting together different libraries and frameworks, Lego-style. Even if developers don't introduce any bugs into their code, their applications become vulnerable if the relevant libraries are not updated to the latest versions. Updating is frequently not straightforward, since developers need to first test their applications to ensure the new library or framework doesn't break something else.

In this case, the vulnerability goes beyond those projects that explicitly use the Spring Social library. Many frameworks include the library's social authentication feature, and any project using those frameworks will also be at risk. An example is BroadleafCommerce, an open-source e-commerce framework that uses Spring Social for authentication. All websites that use BroadleafCommerce may be affected by this bug.

This situation is similar to last week's collective hand-wringing when researchers disclosed a vulnerability in Apache Commons and other third-party libraries that handle serialized Java objects for input. The issue impacted widely used commercial software such as JBoss, WebSphere, and WebLogic.

SourceClear's Ambrosini found the root cause of the vulnerability as a failed check of the state parameter during the OAuth2 connection flow. The flow refers to when a user is redirected from the website to the authentication provider, then back to the original site. The state parameter is used as a CSRF-token to protect against cross-site request forgery as it ensures values sent back from the provider actually belong to the user requesting access to the site. In the Spring Social code, the check doesn't throw an exception with an invalid flow.

All OAuth2 providers are most likely affected, Ambrosini said, emphasizing that the vulnerable code was in Spring Social and not with the providers.

SourceClear recommends creating a custom connect controller for projects which, for whatever reason, would not be able to update to the new version of Spring Social. Sample code is available on SourceClear's site. Details about the code changes are available on GitHub.

Considering the seriousness of the flaw and how easily attackers would be able to abuse the issue, developers should update to the new 1.1.3 version as soon as possible.