A web developer’s diary

February 13, 2017

GemFire OQL – Information Leakage

Filed under: PHP — Celia @ 5:52 am

Gemfire is an in-memory data grid.It pools memory across multiple processes to manage application objects and behavior. Its written in Java and has a key-value structure storage. This data is stored in something called as a ‘region’ which can be queried using Object query language much like how one would have SQL for RDBMS.

I came to know about this some time back and since the opportunity of abusing an OQL is rare, I googled a bit about it. The only journal which references gemfire OQL and a remote command injection is below.

http://blog.emaze.net/2014/11/gemfire-from-oqli-to-rce-through.html

While doing penetration testing, I tried following the examples cited in this blog. The application I was testing was doing for black list filtering and hence all attack vectors weren’t going through properly but the first attack vector that was successful was something like below.

  1. select * from /region1 limit 10.

Comments: My query returned exactly 10 rows and I knew then that I would be able to pass any data in the parameter and  it is getting appended to code also.

2. select p.getclass.forName(‘java.lang.Runtime’).getDeclaredMethods()[7].getName() from /region1 p.

This query is similar to what is explained in the emaze blog and using the above construct, you would be able to list out all the methods of the run time. Getting to this stage was a little tough as I needed to tweak and find out which parameter was getting accepted and which wasn’t. For some reason, the invoke method wasn’t working at all. Before calling it a day, I had passed on this query to my colleague Prashanth working in a different timezone who cracked the shell.

3.select p.getclass.forName(‘java.lang.System’).getDeclaredMethods()[5].invoke(null, ‘os.version’.split(‘asd’)) from /region1 p

This gave out the version number and like wise, one can get all the System properties from similar queries. So, in your testing even if you don’t get a RCE, try an information leakage like above.

 

 

 

 

 

 

RSA Cleartrust Account Lockout Policy

Filed under: PHP — Celia @ 4:59 am

By default, RSA Cleartrust provides options to lock accounts after five consecutive failed authentication attempts within one day. Likewise, the system can unlock users after a specified amount of time or provides an option to have the administrator of the system unlock the users.

The above configuration setting seems to be a foolproof one and one wouldn’t see anything wrong here. This was until I stumbled upon a specific configuration setting in one application. There, the development team had done the below configuration for account lock out.

“Lock accounts after 3 consecutive failed attempts within 2 minutes”. => This I didn’t even know was possible. At a glance it looks even more promising that this setting can catch a robot early. But wait, if I am a malicious insider or a person known to victim, I can use this feature to abuse the system every 3 minutes and finally capture the password. I don’t have to be a robot to get this out.

I told the AD team my thoughts and they removed this interval option from their setting. What are your thoughts?

 

 

 

Create a free website or blog at WordPress.com.