HQL Injection on Web Application Running Oracle Database

Hi,

Recent pentest encountered me with an application that it seems at first glance to vulnerable to SQL Injection as the common test usually I tested shows some firm behavior.

https://site.yappare/index.jsp?id=1' error

https://site.yappare/index.jsp?id=1'' no error / normal page

I believe this should be an Oracle SQL Injection after few tests. However, no result! SQLMap shows that this can be exploited via Time-Based but also no success at the end. During the fuzzing, an error message triggered as shown:

 Googling the error message pointing me to result as shown:

So, my initial understanding is slightly wrong. I should focus on Hibernate. Did some reading and looking for any good references for Hibernate Injection. These links really help me.

http://blog.h3xstream.com/2014/02/hql-for-pentesters.html

http://paulsec.github.io/blog/2014/05/05/blind-hql-injection-in-rest-api-using-h2-dbms/

After understand a little bit on how to do the injection. Did it via Blind technique as described by Paulsec, and voila! able to dump the current Hibernate version.

https://site.yappare/index.jsp?id=1') and substr(org.hibernate.cfg.Environment.VERSION,0,1)=’n' and ('1'='1

where n is actually numbers/characters that we are querying for.

Hibernate version 3.0.2

This is not enough to demonstrate the impact. Tried to read about hibernate/orm structure it seems they are using prepared statement query. I'm not able to get any clue how to query the database information. It'll be harder to me. Luckily Mikhail Egorov and Sergey Soldatov recent presentation helps me!

http://2015.zeronights.ru/assets/files/36-Egorov-Soldatov.pdf

It is possible to query a standard injection via DBMS_XMLGEN.getxml(‘SQL’) for Oracle dbms.

and Voilaa!! 

https://site.yappare/index.jsp?id=1') and NVL(TO_CHAR(DBMS_XMLGEN.getxml('Boolean Blind SQL Injection') and ('1'='1

Thanks!

Reference(s)

• http://blog.h3xstream.com/2014/02/hql-for-pentesters.html
• http://paulsec.github.io/blog/2014/05/05/blind-hql-injection-in-rest-api-using-h2-dbms/
• http://howtodoinjava.com/2014/10/27/complete-hibernate-query-language-hql-tutorial/#select_operation
• http://hsqldb.org/doc/guide/builtinfunctions-chapt.html
• http://kitkatsatonthemat.blogspot.my/2011/09/oracle-order-by-sql-injection.html
• http://2015.zeronights.ru/assets/files/36-Egorov-Soldatov.pdf

Referrer Leakage from HTTPS to HTTPS

From my recent bounty program participation, I failed to find any awesome bug for the whole bounty period. Requiring me to have an iOS9 to perform the full application test also one of the disadvantage as I don't own any Apple product :(

Then, I tried to look for any low hanging fruits on the application. Gotcha! HTTP Referrer Leakage!
When the password reset token provided to the user - after they reset - usually it'll come in a Hyperlink format where there are two ways for the user to use it. Either directly click on it or safely copy and pasted it in the browser.

I choose the second option in order to demonstrate the reset token is leaked to another external URL. And as can see in the figure below, the reset token actually being sent to the newrelic.com website.

Submitted this issue to the program's owner and the analyst responded that this is an issue that in 'Won't Fix' category. The first reason I obtained was it is because the referrer leaked from HTTPS to another HTTPS.
This is what actually hit something on my mind. I never thought about this before. Is the HTTP Referrer will not be logged by the external URL if both are using HTTPS?
With a help from my friend, we tried to simulate the situation. There are two cases. One from HTTPS to HTTP, the second one from HTTPS to HTTPS.


Doing some research  and found that, it is NOT!

Test Cases

HTTPS to HTTP will not leak the referrer

HTTPS to HTTPS will leak the referrer

By summary:

• HTTP Referrer will not be leaked to another URL if it is transmitted from HTTPS to HTTP. 
• HTTP Referrer will  be leaked to another URL if it is transmitted from HTTPS to HTTPS. 

So I get back to the bounty program to ask for review the submission again. Another staff replied with a better explanation why they consider this as a 'Won't Fix' issue. The reason are any of these:

(1) the impact is too low to qualify for a reward 

(2) a prerequisite to exploit the issue is heavy social engineering 

(3) a prerequisite to exploit the issue is being a man-in-the-middle or having theoretical access to a separate restricted resource

 So I believe the 1st reason is the suitable for this situation as the reset token in this case only one-time usable. The situation for an account to get reset via this issue is really rare by looking on the likelihood of it to happen. Furthermore, MiTM attack would not help in this case as the request is transmitted over SSL.

Nevertheless, no harm to submit the issue as they're are certain program that accepting this issue as a minor flaw and got rewarded.

• https://hackerone.com/reports/738
• https://hackerone.com/reports/13557
• https://hackerone.com/reports/5691
• https://hackerone.com/reports/47140

Reference(s)

1. https://isc.sans.edu/diary/When+does+your+browser+send+a+%22Referer%22+header+(or+not)%3F/16433
2. http://smerity.com/articles/2013/where_did_all_the_http_referrers_go.html
3. http://stackoverflow.com/questions/323200/is-an-https-query-string-secure
4. https://www.ietf.org/rfc/rfc2616.txt