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..)

During my tests, Google Skipfish discovered some vulnerabilities within websites (CMS, blogs etc.) and did a very good job revealing especially XSS vectors. But as the title of this blog post already states, I am no longer excited about Skipfish.

Too noisy about unimportant stuff
Skipfish is very fast in comparison to other tools, but for a reason I fail to understand the application also scans for charset declerations and numeric names (which can be enumerated). This means that the scan takes longer than necessary and that the log files are spammed with false positives. Yes, you can switch some of that stuff off, but still you get results which can’t be used for security purposes.

Log files get generated _after_ the scan
When you start Skipfish and know that the scan takes while, you are normally curious about first results while the scan is still in process. Right? Yes, me too. Sadly the log files only get generated when the scan is completed (or aborted) and sometimes even this log file generation failes when there is not enough disk space. It would be awesome if the log file would be created when the scan starts and then be extended during the scan.

Obvious vulnerabilities are not found
Skipfish constantly failes to find LFI or SQLi vulnerabilities within prepared websites I crafted. Where manual testing succeeds, this application fails to discover most of the stuff.

Too many false positives
For an unappearent reason, Skipfish declares secure websites as vulnerable to e.g. SQL injection attacks. An example is Joomla: While scanning my test installation, Skipfish triggered “high impact vulnerabilities” by calling the URL /joomla/index.php/index.php. While proceeding in the scan, Skipfish also thought that /joomla/index.php’ is vulnerable (which is wrong). Another example would be that Skipfish sometimes declares websites as vulnerable to XSS attacks when the search term “skipfish” appears somewhere in the source code. Skipfish fills out all forms in the test website and then sometimes discovers itself in the source code.. although the filters are effective in protecting from XSS attacks.

Skipfish loves to enumerate own log directories
Don’t make the mistake and run Skipfish on the same machine where your test object is located at Skipfish loves to crawl its own log directories and tries to enumerate file names (e.g. /var/www/skipfish/log_dir_1/admin.tar.gz). In fact this is not really wrong since Skipfish should find log files on _other_ web servers but still this is very annoying. Scanning the log file folders takes very long and does not have many advantages.

Please don’t get me wrong – I like skipfish. It does a good job in many ways, it is fast and easy to use. I think it just needs some improvements and maybe in 1 or 2 years, it is the leading application on the free vulnerability scanner market.

Update 2010-09-20: I have received an email from Michal Zalewski, the or at least one guy behind Google Skipfish. He comments my blog post and I feel obligated to share his opinion with you. This is only fair, right?

Hey,

Some comments

1) “Skipfish is very fast in comparison to other tools, but for a
reason I fail to understand the application also scans for charset
declerations” – actually, there are very good, security-related
reasons for this – see item #12 here:

http://code.google.com/p/skipfish/wiki/KnownIssues

You can limit the verbosity of these checks by using the -J option, though.

Brute force of file names and directories can be trivially disabled,
too – but it’s done for a very specific purpose – to discover things
such as index.php.old, secret /admin/ directories, etc.

2) “Obvious vulnerabilities are not found”

Have you reported these to me?:-) The only way I can improve the
scanner is when I get feedback from users, and it’s actually extremely
frustrating that people are so hesitant to do so.

3) “Another example would be that Skipfish sometimes declares websites
as vulnerable to XSS attacks when the search term “skipfish” appears
somewhere in the source code.” – that’s hopefully not true. Skipfish
consider pages to be vulnerable to XSS only when it successfully
managed to inject a special, unique HTML tag, or its own HTML
parameter, on the page. Again, if you see any examples to the
contrary, please let me know.

“Skipfish fills out all forms in the test website and then sometimes
discovers itself in the source code.. although the filters are
effective in protecting from XSS attacks.” – again, this is unlikely.
The XSS checks are actually one of the strongest suits of the tool,
and usually alert you to valid XSS vectors, even though some of them
may be very subtle.

4) “Skipfish declares secure websites as vulnerable to e.g. SQL
injection attacks. An example is Joomla: While scanning my test
installation, Skipfish triggered “high impact vulnerabilities” by
calling the URL /joomla/index.php/index.php.” – please report false
positives if you see any. See problem #10 for one possible
explanation, though:

http://code.google.com/p/skipfish/wiki/KnownIssues

Cheers,
/mz

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.