This paper attempts to fill this gap by proposing an open source tool that automates the process of detecting and exploiting command injection flaws in web applications, named as commix, (a short for command injection exploiter).

This tool supports a plethora of functionalities, in order to cover several exploitation scenarios. Moreover, Commix is capable of detecting, with high success rate, whether a web application is vulnerable to command injection attacks. Finally, during the evaluation of the tool we have detected several 0-day vulnerabilities in web applications.

Download the presentation which has been presented during Blackhat Europe 2015.

XSS attacks have become very common nowadays, due to bad-written PHP web applications. In order to provide users with rudimentary protection against XSS attacks most web browser vendors have developed built-in protection mechanisms, called XSS filters. In this paper, we analyze two attacks that take advantage of poorly written PHP code to bypass the XSS filter of WebKit engine named XSS Auditor and perform XSS attacks. In particular, the first attack is called PHP Array Injection, while the second attack is a variant of the first one and it is named as PHP Array-like Injection. Both attacks take advantage of improper management of variables and arrays in PHP code to bypass the XSS Auditor. We elaborate on these attacks by presenting concrete examples of poorly written PHP code and constructing attack vectors to bypass the XSS Auditor. To defend against the identified attacks, we provide proper code writing rules for developers, in order to build secure web applications. Additionally, we have managed to patch the XSS Auditor, so that it can detect our identified XSS attacks. (Download the paper)

Goal of this research, was to create and introduce an open-source security tools called Jaidam that would take as input a list of domain names, scan them, determine if WordPress or Joomla platform was used and finally check them automatically, for web vulnerabilities using two well‐known open source tools WPScan (in case of WordPress) and Joomscan (in case of Joomla).

WPScan is a black box WordPress Security Scanner (written in Ruby) which attempts to find known security weaknesses within WordPress installations. Its intended use it o be for security professionals or WordPress administrators to asses the security posture of their WordPress installations. Features include:

• Username enumeration (from author querystring and location header)
• Weak password cracking (multithreaded)
• Version enumeration (from generator meta tag)
• Vulnerability enumeration (based on version)
• Plugin enumeration (2220 most popular by default)
• Plugin vulnerability enumeration (based on version)
• Plugin enumeration list generation
• Other misc WordPress checks (theme name, dir listing, …)

Joomscan is a tool (written in Perl) that tests a Joomla installation for known vulnerable plugins and core security configuration mistakes. Detection of these vulnerabilities will allow a web site owner to get the plugins update or fixed before they get attacked. Joomla is a popular content management system; that is very extensible. This popularity and wide range of extensions makes it a popular target for hackers. The Joomscan tool has the following features:

• Exact version Detection – the scanner can pinpoint versions with a greater accuracy than just the meta generator tag.
• Joomla! based web application firewall plugin detection.
• Probes for known vulnerable Joomla Core security issues as well as extensions / plugins.

Prerequisites

Jaidam has been written and tested in debian‐like distros. The main distro that it was tested on is the new generation of the industry‐leading BackTrack Linux penetration testing and security auditing distribution, Kali Linux. In order for the program to run in a kali linux distro it is necessary for the distro to be fully updated, upgraded.

apt-get update && apt-get upgrade
apt-get dist-upgrade

After being download and extracted, the program runs in standalone mode.In case of other debian‐like distros the prerequisites are:

Ruby >= 1.9.2 – Recommended: 1.9.3
Curl >= 7.21 – Recommended: latest – FYI the 7.29 has a segfault
RubyGems – Recommended: latest
Pyhon = 2.7
Git
WPScan
JoomScan

Jaidam Security Tool

The innovative part of Jaidam security tool is that it combines the modules of Joomscan and WPScan in one package providing more functionality to the user saving up much time.

Jaidam has a simple environment and can be used, from web developers that want to test their sites, from pentesters that have multiple/single site to check, either from a researcher that want to have statistics for the situation of specific websites.

Jaidam will not attempt to penetrate any of this site or to find any 0day. This tool will only warn you if there is a possible vulnerability in the site. More information about the vulnerability are presented but in no way this tool will exploit that vulnerability.

Moreover it can handle a list of sites taken as an input so as the user has the ability to run a distributed web vulnerability scan. After completing the scan procedure, all the results are stored in a sqlite3 database within the file “jaidamSQLite.db”

Jaidam is written in Python programming language and its structure is shown below :


.
|-- core
|   |-- colors.py
|   |-- config.py
|   |-- __init__.py
|   |-- menu.py
|   `-- update.py
|-- modules
|   |-- grscan.py
|   |-- __init__.py
|   |-- modmenu.py
|   `-- otenet.py
|-- jaidam.py
|-- README
|-- scan
|   |-- __init__.py
|   |-- jms.py
|   |-- lst.py
|   `-- wps.py
|-- sites
`-- VERSION

4 directories, 16 files

With the executable jaidam.py we run the program and the user has a number of options:

  L / l: Create List
  C / c: Create list of custom TXT file
  S / s: Scan a single site

  W / w: Use WPScan for scanning WordPress sites
  J / j: Use Joomscan for scanning joomla sites
  M / m: Use Jaidam Extra Modules(*)
  D / d: Automatic creation of list using built in function 
  G / g: Automatic creation of list using built in function (aproximatly 14000 gr sites)

  U / u: Update Jaidam to the latest version
  Q / q: Quit

By pressing “L” the user has three options:

  C / c: to create lists from text file.
  S / s: to scan a single site.
  Q / q: Quit

It is worth noting that in Jaidam there is a builtin multithreaded function for faster results in determining the kind of CMS a site uses.

After the list creation (or custom list input) Jaidam tool takes every site in that list and check if it is Joomla or Worpress based .The list break down in three lists: Joomla, WordPress, Others. The criteria that this filtering is done are :

WordPress:

• If the default WordPress meta tag exist.
• If the file structure of WordPress exist (/wp‐content, /wp‐includes , /wp‐admin)

Joomla:

• If the default Joomla meta tag exist.
• If the file structure of joomla exist (/components, /administrator, /plugins, /modules, /templates)

When the scanning of domain names is completed the user is asked whether he likes to perform a WPScan or a Joomscan. By choosing for example a WPScan then it starts to scan for vulnerabilities all the sites that have recognized as WordPress sites, as it is illustrated in the following image.

And respectively for Joomscan

After completing the vulnerability scan the program stores the results in the “wp_vulne_table” for WordPress results or in the “jm_vulne_table” for Joomla results respectively and can be viewed with an SQL query as shown below :

The categories of the vulnerabilities the tool will scan for have been chosen based on the OWASP’s TOP 10 vulnerability list and are the following.

For WordPress sites:

SQL Injection
XSS
CSRF
File Upload
Denial of Service
Local / Remote file inclusion
Information disclosure
robots.txt

For Joomla sites

SQL Injection
XSS
CSRF
File Upload
Denial of Service
Local / Remote file inclusion
Information disclosure
Htaccess

Adding Extra Modules

In this section anyone can write his own python modules for this tool . Example can be another scanner or another list generator script. The only thing that you must have in mind is that you must include your script in the “/modules” folder and add your script to the menu in “/modules/modmenu.py“

Future work

Jaidam is a security tool that has shown to have much potential as fas as development concerns. There are a lot of aspects that could be improved like:

• Graphical User Interface
• Support for redhat and fedora distros.
• Features like importing address spaces to be scanned.’

License

This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU General Public License for more details.

You should have received a copy of the GNU General Public License
along with this program.  If not, see <http://www.gnu.org/licenses/>.

Check the project on GitHub and feel free to fork it.

As it has already been mentioned in a previous post, one of the most widely used instances in JavaScript is the Location Object which is used to determine the current URL.

In this example, we will focus on search property of location object which, sets or returns the query string part of a URL.

In this article we have tried to bypass XSSAuditor using location.search property. The XSSAuditor in Google Chrome (Version 37.0.2062.94 – Linux / Version 37.0.2062.103 m – Windows) and in Google Chromium (Version 35.0.1916.153 Built – Linux) was found vulnerable to a DOM-based XSS attack, when the user’s input (the attack vector) went through the location.search property and then was written to the page’s DOM by using the document.write method.

The problem

The problem we faced here was that of the location.search property.  More specifically, the location.search property printed back an encoded representation of the query string part of a URL causing the attack to fail.

That’s why we used the decodeURI() function to enclose the location.search property. The decodeURI() function replaces each escape sequence (in the encoded URI) with the character that it represents.

The weakness

Thus, to prove this weakness we make use of the following simple example “location_search_XSS.html”.

<html>
  <body>
    <script>
      document.write(decodeURI(window.location.search));
    </script>
  </body>
</html>

The Attack

In order to exploit the above weakness, we could use the same attack vector as in previous post (without svg closing tag)

?<svg/onload=alert(1)

During the execution of the following on the browser’s URL, the page takes the attack vector as an unescaped input from decodeURI(window.location.search) property and overwrites it to the page’s DOM by using the document.write method.

file:///home/ancst/Desktop/location_href_XSS.html?<svg/onload=alert(1)

After executing the above, this is the situation inside DOM.

<svg onload="alert(1)" <="" body="">
</svg>

Nowadays, one of the most widely used instances in JavaScript is the Location Object which is used to determine the current URL.

The location object is part of the Window Object which represents an open window in a browser and is accessed through the window.location property.

The location object has these properties:

It is worth noting that in this example, we will focus on href property which, as mentioned in the above table, sets or returns the entire URL of the current page.

Back in 2011 a report from Simone Onofri was sent to Chromium security team, concerning an XSS vulnerability, which was referring to an XSSAuditor’s filter bypass through the use of location.href. Currently, this appears to be fixed.

In this article we have tried to bypass XSSAuditor using (the same) location.href property. The XSSAuditor in Google Chrome (Version 37.0.2062.94 – Linux / Version 37.0.2062.103 m – Windows) and in Google Chromium (Version 35.0.1916.153 Built – Linux) was found vulnerable to a DOM-based XSS attack, when the user’s input (in our case, the attack vector) went through the location.href property and then was written to the page’s DOM by using the document.write method.

The weakness

In order to prove this weakness we make use of the following simple example “location_href_XSS.html”.

<html>
  <body>
    <script>
      document.write(window.location.href);
    </script>
  </body>
</html>

The Attack

In order to exploit the above weakness, we could use the following attack vector (without svg closing tag)

#<svg/onload=alert(1)

During the execution of the following link on the browser’s URL, the page takes the attack vector as an input from location.href property and writes it to the page’s DOM by using the document.write method.

file:///home/ancst/Desktop/location_href_XSS.html#<svg/onload=alert(1)

After executing the above, this is the situation inside DOM.

<svg onload="alert(1)" <="" body="">
</svg>