The Liferay JSON implementation does not check if a user calling a method on a serviceClass is disabled. Usually the default administrator user, test@liferay.com, is used to create a new administrator and disabled without a change to the default password, so it is possible to use it to execute JSON API calls. Versions 6.0.5 and 6.0.6 are vulnerable.
840d89136b0bbd34dcc7fbaa674c8f425af2c5bab7ef9bb1fac81338af82ef39
=============================================
- Release date: August 3rd, 2012
- Discovered by: Danilo Massa & Enrico Cinquini
- Severity: High
=============================================
I. VULNERABILITY
-------------------------
Liferay JSON service API authentication vulnerability
II. BACKGROUND
-------------------------
JSON service API are provided by all Liferay services that allows invoking
its methods directly through HTTP using JSON as a data serialization
mechanisms.
This API is automatically generated by Service Builder, which means that
you can also provide it for your custom services developed in the extension
environment with no extra effort.
III. INTRODUCTION
-------------------------
The Liferay JSON implementation do not check if a user that call a method
on a serviceClass is disabled. Usually the default administrator user,
test@liferay.com, is used to create a new administrator and disabled
without to change the default password, so it is possible to use it to
execute JSON API calls.
IV. DESCRIPTION
-------------------------
In order to get control of a Liferay portal is necessary to:
- create a fake openID user on a free provider (like myopenid.com)
- enumerate users calling the method getUserById of UserServiceUtil
service class (the parameter of this call is a number so it is virtually
possible to enumerate all users)
- find a user with administrative role calling the method getUserRole of
RoleServiceUtil service class using the valid userIds harvested in the
previous step
- set the previously created fake openId URL for the discovered
administrator user using a call to updateOpenId method of the
UserServiceUtil service class
At this point is possible to login to Liferay as the discovered
administrator selecting the OpenId authentication method to the portal.
V. PROOF OF CONCEPT
-------------------------
Below is a harmless test that can be executed to check if a Liferay
installation is vulnerable.
Using a browser go to the following URL:
http://<liferay_url>/tunnel-web/secure/json
and use the standard test@liferay.com user and password when the web site
require a basic authentication in order to check if they are still valid.
A vulnerable Liferay installation will show a blank web page, a secured
installation will ask the authentication credentials three times before to
show an error page.
VI. BUSINESS IMPACT
-------------------------
An attacker could exploit the vulnerability to become administrator and
retrive or publish any kind of data on Liferay.
It is also possible to inject a web comand shell on the Liferay machine.
VII. SYSTEMS AFFECTED
-------------------------
Versions 6.0.5 and 6.0.6 are vulnerable.
Versions 6.1 is vulnerable but the password for the standard administrator
user is not hardcoded in the installation but asked at installation time
(so can be different from the standard one)
VIII. SOLUTION
-------------------------
Upgrade to a patched release (when availble) or as quick workaround change
the default password for user test@liferay.com.
IX. REFERENCES
-------------------------
Liferay's JSON API usage examples:
http://www.liferay.com/web/james.falkner/blog/-/blogs/yet-another-liferay-json-service-example
http://www.liferay.com/es/web/raymond.auge/blog/-/blogs/476431
Liferay's service classes documentation:
http://docs.liferay.com/portal/6.0/javadocs/com/liferay/portal/service/package-tree.html
X. CREDITS
-------------------------
The vulnerability has been discovered by:
Danilo Massa massa(under_score)danilo(at)gmail(dot)com
Enrico Cinquini enrico(dot)cinquini(at)gmail(dot)com
XI. VULNERABILITY HISTORY
-------------------------
June 11th, 2012: Vulnerability identification
June 12th, 2012: Vendor notification
August 3rd, 2012: Vulnerability disclosure
XII. LEGAL NOTICES
-------------------------
The information contained within this advisory is supplied "as-is" with no
warranties or guarantees of fitness of use or otherwise. We accept no
responsibility for any damage caused by the use or misuse of this
information.