Description
The Simple Local File Inclusion Vulnerability Scanner helps you to find LFI vulnerabilities.

Usage
./lfi_scanner.py –url=

Usage example
./lfi_scanner.py –url=”http://www.example.com/page.php?file=main”

Usage notes
- Always use http://….
- This tool does not work with SEO URLs, such as http://www.example.com/news-about-the-internet/.
- If you only have a SEO URL, try to find out the real URL which contents parameters.

Feature list
- Provides a random user agent for the connection.
- Checks if a connection to the target can be established.
- Tries to catch most errors with error handling.
- Contains a LFI vulnerability scanner.
- Finds out how a possible LFI vulnerability can be exploited (e.g. directory depth).
- Supports nullbytes!
- Supports common *nix targets, but no Windows systems.

Known issues
- This tool is only able to handle “simple” LFI vulnerabilities, but not complex ones.
- Like most other LFI scanners, this tool here also has trouble with handling certain server responses.

Some notes
- Tested with Python 2.6.5.
- Modify, distribute, share and copy the code in any way you like!
- Please note that this tool was created for educational purposes only.
- Do not use this tool in an illegal way. Know and respect your local laws.
- Only use this tool for legal purposes, such as pentesting your own website
- I am not responsible if you cause any damage or break the law.
- Power to teh c0ws!

Screenshot

Simple Local File Inclusion Vulnerability Scanner screenshot

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:
[...]

Just visit the “My Tools” section for the download link.

Description
The Simple Local File Inclusion Exploiter helps you to exploit LFI vulnerabilities. After you found one, simply pass the URL of the affected website and the vulnerable parameter to this tool. You can also use this tool to scan a parameter of an ULR for a LFI vulnerability.

Usage
./lfi_sploiter.py –exploit-url= –vulnerable-parameter=

Usage example
./lfi_sploiter.py –exploit-url=http://www.example.com/page.php?file=main –vulnerable-parameter=file

Usage notes
- Always use http://….
- When you pass a vulnerable parameter, this tool assumes that it is really vulnerable.
- If you do not know if a parameter is vulnerable, simply pass it to this script and let the scanner have a look.
- Only use one vulnerable parameter at once.
- This tool does not work with SEO URLs, such as http://www.example.com/news-about-the-internet/.
- If you only have a SEO URL, try to find out the real URL which contents parameters.

Feature list
- Provides a random user agent for the connection.
- Checks if a connection to the target can be established.
- Tries catch most errors with error handling.
- Contains a LFI scanner (only scans one parameter at once).
- Finds out how a LFI vulnerability can be exploited (e.g. directory depth).
- Supports nullbytes!
- Exploit features: Dumps a list of interesting files to your hard disk.
- Supports common *nix targets, but no Windows systems.

Known issues
- I know there is more about LFI than it is covered in this tool. But this is the first release,
and more features will be implemented in future versions.
- This tool is only able to handle “simple” LFI vulnerabilities, but not complex ones. For example: Some LFI vulnerabilities consist of two URL parameters or require to find a way around filters. In those cases, this tool unfortunately does not work.
- Like most other LFI exploiter / scanner, this tool here also has problems with handling certain server responses. So this tool does not work with every website.

Some notes
- Tested with Python 2.6.5.
- Modify, distribute, share and copy the code in any way you like!
- Please note that this tool was created for educational purposes only.
- Do not use this tool in an illegal way. Know and respect your local laws.
- Only use this tool for legal purposes, such as pentesting your own website
- I am not responsible if you cause any damage or break the law.
- Power to teh c0ws!

Screenshot

Simple Local File Inclusion Exploiter screenshot

Currently, the tool is still beta (version 0.8). I guess that it will be released during the next 48 hours.

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

It contains all the features from the first released version 0.3 and now contains – in addition – a column fuzzer. Simply start a scan by using python sqli_scanner.py -u “target” and then start fuzzing by using the parameter -fuzz “exploit url”. The exploit url will be provided by the scanner (when a vulnerability was found).

Description
The Simple SQL Injection Vulnerability Scanner helps you to find SQL injection vulnerabilities within your website. Simply provide an URL and let the tool do all the work.

Features
- Scan a single URL
- Detect SQL injection vulnerabilities
- User agent for web requests
- User friendly (easy to use, everything is automated)
- Error handling for http requests
- Display a short scan report
- Check if the provided URL is reachable

Additional information
Written in Python (less than 400 lines).

Usage
python sqli_scanner.py -u “http://target/index.php?var1=x&var2=y″

Disclaimer
This tool was written for educational and penetration testing purposes. Only check websites you are allowed to test, e.g. your own or one of your customers/friends. I am not responsible for any damage you or my script could cause. Please know and respect your local laws.

Known issue
Sometimes the target webserver throws back specific errors (403, 500 etc.). The Simple SQL Injection Vulnerability Scanner then fails to find SQL injection vulnerabilities.

Screenshot

Simple SQL Injection Vulnerability Scanner - sample output