With great pleasure I hereby announce the availability of the new “The Joomla Hacking Compendium”. It contains almost 1000 lines of pure knowledge and shows you the way to hack and protect Joomla.

It contains the following chapters:

0x01 - Purpose of this document
0x02 - Introduction
0x03 - The Basics of Joomla
0x04 - The Joomla core
0x05 - Joomla extensions
0x06 - Hacking Joomla
0x07 - SEO, our strongest enemy
0x08 - Examples for Joomla SQL injections
0x09 - Examples for Joomla local file inclusions
0x10 - Examples for Joomla remote file inclusions
0x11 - Examples for Joomla XSSs/CSRFs
0x12 - How to protect your Joomla
0x13 - Conclusion and a look at Joomla's feature
0x14 - How to stay informed (or: the latest vulnerabilities)
0x15 - Useful tools
0x16 - Greetings and THX

Please find an excerpt below:

::
:: 0x04 - The Joomla core
::

Before inspecting the Joomla component attack vendors we first have a
look at the core.

Download Joomla somewhere and extract all files. Open the file
libraries/phpinputfilter/inputfilter.php
and look at the code:
----------------------------------------
var $tagsArray; // default = empty array
var $attrArray; // default = empty array

var $tagsMethod; // default = 0
var $attrMethod; // default = 0

var $xssAuto; // default = 1
var $tagBlacklist = array ('applet', 'body', 'bgsound' [...]
var $attrBlacklist = array ('action', 'background'     [...]
----------------------------------------

As you can see, some filter methods of Joomla are based on blacklisting.
This knowledge can be used later to exploit potential vulnerabilities in
a better way. I find this method not very effective, btw.

While HTML tags containing "body" or "bgsound" will be filtered out
at input fields or URL parameters, they can be written in many ways,
e.g. like "bOdY" or "b o DY" etc. You are only limited by your
creativity and will find ways for tricking the blacklist of the
Joomla framework.

Another interesting part is this one (same file):
----------------------------------------
/*
* Is there a tag? If so it will certainly start with a '<'
*/
$tagOpen_start  = strpos($source, '<');
while ($tagOpen_start !== false)
{
/*
* Get some information about the tag we are processing
*/
$preTag            .= substr($postTag, 0, $tagOpen_start);
$postTag                = substr($postTag, $tagOpen_start);
----------------------------------------

As you can see they assume that an HTML tag being used in XSS attacks
starts with a "<". In fact, I never use this character and many
XSS cheatsheets suggest this, too. With this information in mind,
you can most likely avoid being detected by the filters. You can start
your XSS string with "><tag... for example.

If you want to you can continue looking. You will find other filter
methods and, at the end of the file, there are also built in
mechanics which should help to prevent SQL injection vulnerabilities:
[...]

The South Korean Community/Website/Content Management System UTW suffers from various vulnerabilities.

Local File Inclusion
Script: utw_lib/get_file.php
Parameters: file, rfile
Example: utw_lib/get_file.php?rfile=<local path>&file=<local file name>

The script get_file.php is vulnerable to local file inclusion attacks. Arbitrary
files can be viewed by combining the values for the rfile and file parameters.

Source Code Disclosure
With the help of the LFI vulnerability the source code of every local script can be
viewed.
Example: utw_lib/get_file.php?rfile=get_file.php
(Yes, using the rfile variable is correct here, although its purpose is to
store a path.)

This knowledge can also be used to view local configuration files.
Example: utw_lib/get_file.php?rfile=dbinfo.inc.php
The file dbinfo.inc.php contents the MySQL data, such as the host, database,
user and password in plain text.
With the help of this information it is possible to access the MySQL server.

Cross-Site Request Forgery
Every input field I saw did not filter out HTML or JavaScript code.
I did not check if there are also XSS flaws, but there is a high chance
that you are able to permanently inject code, e.g. in the message board threads.

Low Security Levels
Since the user data is stored in plain text (including email addresses and
passwords), the identities of the registered userscan be stolen easily by
accessing the MySQL database.

Another aspect of this low security level is that many users use similar
passwords for different services, e.g. often only one password for communities
and email service logins is used.
In this case all the user passwords and their email addresses can be dumped
from the database and be used for trying to login to their email accounts.

The admin panel can be accessed by adding /utw_admin to the URL.

The product contains also a feature which makes it possible to download
files, their download locations are stored in the database. An attack scenario
would be to change the file downloads, so the users of the affected
website download malicious content.

External Website Rendering
(Un)Fortunately this product is not affected by a RFI vulnerability, or at
least I was not able to detect one. But rendering external websites in the
context of the thrusted website is possible.
Example: tw_lib/get_file.php?rfile=http://www,google.com

This is not a real vulnerability, but can be used to abuse the thrust of the
visitors in the affected website.

I submitted an exploit which contains XSS code. Surprisingly this code gets parted when you view the submitted content. XSS is possible

Will e-mail them, let’s see their reaction.

The Joomla component com_jsupport suffers from a critical XSS vulnerability:

The component allows you to create and submit tickets. The tickets can be viewed
on the website and in the admin panel.

It is possible to inject arbitrary HTML and JS/VBS code into the title field of the
ticket. If someone else views the ticket list, the code gets executed in the
visitor's browser.

This vulnerability is considered as critical since the tickets are also displayed
in the administrator backend of Joomla. As soon as a user with extended priviledges
views the ticket list in the backend, the code gets executed and damage can be caused.

Example code for the ticket title field:
"><IMG """><SCRIPT>alert("XSS")</SCRIPT>

Multiple vulnerabilities within the Zeeways Adserver were found.

>> SQL Injection
Multiple scripts with multiple parameters are affected from this vulnerability.

Example #1:
index.php?section=redir&affid=0&kid=0&zid=[SQL Injection]

Example #2:
Visit the "register" page index.php?section=user&action=register and enter your
SQLi string into the email field. Fill out the other fields with some
normal stuff (like test) and view your result.

>> Cross-Site Request Forgery
Visit the "register" page index.php?section=user&action=register and enter your
CSRF string into the email field. Fill out the other fields with some
normal stuff (like test) and view your result.

>> Local Installation Path Disclosure
Visit index.php?section=doc&action= and fill out the action parameter.

Example:
index.php?section=doc&action=test

>> Interesting error message
Visit index.php?section=doc&action=test and play around with both the section and
action parameters. You will notice that a local file inclusion is not possible
(especially when you look at the section variable), but still you will be able
to "inject" some stuff in the action parameter.
For example use
index.php?section=doc&action=#
to get no output.

This is not a real code injection vulnerability, but still some special control
characters affect the output of the website. Maybe you are able to trigger some
interesting stuff.

The Joomla component com_restaurantguide suffers from multiple vulnerabilities.

>> SQL Injection
index.php?option=com_restaurantguide&view=country&id=’&Itemid=69
(id parameter is vulnerable)

>> HTML/JS/VBS Code Injection (all input fields, also in the admin backend)
It is possible to inject HTML/JS/VBS code into the document although XSS filters are active. Simply end the current HTML tag and convert your code into decimal HTMl code without semicolons:
“><A HREF=”http://www.google.com./”>injected</A>
(which is “>injected)
The code doesn’t get parsed, so it is not possible to exploit this weakness. However, including arbitrary plain text into the current website is possible. Dangerous!

>> Interesting stuff
a) Triggering various error messages in the admin panel is possible, e.g.:
administrator/index.php?option=com_restaurantguide&controller=restaurantitems&task=edit&cid[]=[try ' or -1 or an ID which does not exist]
Sometimes the code of the component gets displayed within the browser window when you try to trigger errors with different variables.

b) Playing around with the controller variable
administrator/index.php?option=com_restaurantguide&controller=../../../../../../../../../etc/passwd%00
(NOT a LFI vulnerability since the controller classes are defined in the source code, you just get different error messages.. nothing to exploit here..)

Today I received an email from David Mavec who is one of the guys working on com_grid. According to him, all vulnerabilities within com_grid should be closed now. Short tests indicate that this is true and the built-in XSS filters are working.

Thanks for the short notice!

Update from 20.09.2010: According to David Mavec this also affects TableJX and CardViewJX.

The PaysiteReviewCMS from the vendor Mechbunny suffers from Permanent Cross-Site Scripting vulnerabilities.

Additional comment
The script image.php is used to include images with specific parameters, such asthe image width. This script might be affected by other vulnerabilities aswell.