A critical vulnerability was discovered (and fixed) in Atlassian's Crowd SSO (single sign-on) tool. My organization is stuck on a vulnerable version. How can we manage the threat posed by this vulnerability until we can upgrade, and, more importantly, is there any way we can track an attacker that utilized this vulnerability to see what else may have been accessed?
Ask the Expert!
Brad Casey is ready to answer your network security questions. Submit them now via email!
If your company is using any version of Atlassian Software Systems' Crowd offering preceding version 2.5.4, it is vulnerable to this latest exploit, which allows malicious users to craft specially formulated URLs that trick the server into returning all files that reside on it, including configuration files and other files that contain user credentials. This is a huge vulnerability to say the least. What is particularly disturbing, is the fact that this vulnerability resides within a SSO service.
To successfully manage this vulnerability until an upgrade is performed, an organization has two options: encrypt every single file that resides on the server running the Crowd service, or turn off the service altogether.
Encrypting every file, or at least those files that contain sign-on credentials, is a viable option if an organization is willing to accept the risk of exposing all of its files to the Internet. This must be determined on a case-by-case basis. If it is decided that employees absolutely must have remote access to corporate applications and services, encrypting the files may be the best route. However, before this is decided, every user's SSO password must be changed because of the unfortunate reality that the organization may have already been compromised.
If alternative solutions for accessing company resources are available, turning off the SSO service may be deemed more palatable. For all intents and purposes, this allows for a total mitigation of the problem.
Whether you can track those who successfully exploited the vulnerability is really tough to answer. If an examination of the logs is conducted and it is found that files containing credentials have been copied from the server to another location, one may be able to ascertain who the culprit is by looking at the source and destination IP addresses. However, if the attacker took any measures toward obfuscation, then such analysis likely won't be possible.
This was first published in December 2013