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

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

During the last weeks I spent much time thinking about the security of websites in general. While many webmasters are unaware of many security threads and simply don’t possess much knowledge in this area, a lot of them welcome popular CMS (such as Joomla, WordPress, Drupal etc.) and use addons to enhance their sites.

What some of them forget is to check if the used software is vulnerable in any way. The result is that thousands of new insecure websites are created every day and can be abused easily in many ways. I find it very shocking that even large companies rely on the script vendors and store sensitive company/customer data in the website. One heavy case I was able to witness is a component supplier for the German car industry.

While the corporation itself seems to be very large, their website was made by a freelancer. He uses a well known CMS with a few modifications and commercial themes/layouts. While browsing the website it was obvious that there might be several SQL injection vulnerabilities which allow attackers to access the whole database and obtain information which can be used for industrial spying.

But it is so easy to check if the own website is vulnerable to the most common attacks (SQL injection, local/remote file inclusion, XSS, CSRF, information disclosure, weak passwords, false software configuration). A good beginning would be to simply browse vulnerability databases. Or googling for “software product name vulnerability”. Or asking someone with security knowledge to check the own website. Or learning about the most popular web vulnerabilities and checking the website yourself.

I find it rather sad to see that so many website owners fail to do so. More said is probably the fact that you can’t even make them responsible for not knowing much about IT security since not everyone is aware of such issues or does have the necessary technology affinity for knowing such stuff.

When I have learned something during the past weeks (except the stuff for my final exams ), then it is the fact that even very experienced webmasters/users/developers may simply not be familiar with web security. While doing some vulnerability research for fun I was given the opportunity to get in contact with many security enthusiasts, security professionals and developers (e.g. for Joomla components). Sometimes it took me many mails to explain to them how their software is vulnerable and how they can fix their products. Some of them even sell their software for a lot of money. And this is in fact a bad thing.

Imagine all the plugins for popular CMS which are released daily – and how many might be vulnerable to simple attacks.

How can normal webmasters be expected to keep up with the daily amount of information and recently published vulnerabilities?

So when building a new website, many of them simply download the CMS (e.g. Joomla), some required components (let’s say a gallery and guestbook component) and a cool theme. The new website can be completed within hours and the results are still awesome. But maybe also “awesome” insecure.

Especially when someone sells a website to a customer who has no IT knowledge at all this can be a very huge problem. They most probably never update their scripts and you can imagine what problems may occur in such cases.

So, what is the solution? How to fight the problem that there are so many plugins/extensions for popular CMS and so many of them might be vulnerable?

One idea might be to found a new project which contains a list of checked extensions. As soon as a new plugin is released the members of this project check it for vulnerabilities and rate it as secure when all tests are passed.

The result would be a list of extensions which were checked by people who are familiar with web security. We then would have a “trusted list of secure software extensions” and everyone can rely on it. Of course new software versions of existing plugins also have to be tested and the perfection would be that software vendors let their software be checked first before they release it.

While this might be a good idea this would take many volunteers who are a) competent enough to perform such tests and b) who are active on regular basis. Furthermore such a project should be supported by both the software and security industries.

Maybe there will be such a project one day and maybe I will even start it one day by myself.

Simply the idea of having a list of secure plugins – no matter for which CMS –  is awesome enough, isn’t it?

View the changelog here.

Download it here.

According to the changelog not many things were changed.

This little tutorial will show Debian/Ubuntu users how to install it and perform the first test.

I. Introduction

Tools like Nessus and Nmap are indispensable when it comes down to security assessment and penetration testing. Many researchers have to rely on those tools in order to find weaknesses in websites/web apps.

But like it is often the case, every application got it’s disadvantages.Especially in the area of vulnerability detection it is very hard to determine which tool is the best one.

On the 18th March 2010 Google entered the “market” and tries to deliver a very fast but comprehensive vulnerability scanner. “Skipfish” is free, coded in C, very fast, doesn’t need many resources, achieves more than 2000 requests per second, opens up to 100 simultaneous TCP connections, creates decent reports and even reveals vulnerabilities in popular web apps which haven’t been found yet.

Link: http://code.google.com/p/skipfish/

For me this sounds great, so I decided to give it a try.

II. Downloading and installing

I assume that you got a Debian/Ubuntu box and some time. Some of the commands may require “sudo”, but you are already familiar with your OS and know what to do

Let’s install some required packages first:

apt-get install libidn11-dev make gcc libssl-dev

Now we download the app:

wget http://skipfish.googlecode.com/files/skipfish-1.33b.tgz

tar xfvz skipfish-1.33b.tgz

make

Skipfish is now ready to be launched, but let’s provide the tool with a dictionary first:

cp dictionaries/default.wl skipfish.wl

III. Running Skipfish

Ok, time to start!
./skipfish -o /home/your-target http://www.your-target.tld

As you can see here, one of my small machines is heavy occupied because of the test:

In the test I did for this little tutorial, I had thousands of request sent after a few minutes.. after 5 minutes, only like 3,3 % percent of the whole scan was completed. Jesus!  

Furthermore my little VPS was in the same state like it was being DoSed.

=> Skipfish really can small down a Linux box if the machine is small and not very well optimized.

Well, let’s cancel the test after a few minutes and have a look at the report:

In my eyes, this is a very well generated report.

IV. Some additional words

Well, the best would be if you play around a little bit and have a look at all the options:

./skipfish -h

According to many comments (which you are able to find through Google) Skipfish doesn’t find all obvious vulnerabilities, like SQL injection or XSS.  In my tests, quite the contrary was the case. Google’s Skipfish even found some vulnerabilities in some well known web apps which haven’t been discovered or published yet.

I will definitely use this tool for future penetration tests and my vulnerability research, and of course I highly recommend that you do the same

V. Sources

http://www.redspin.com/blog/2010/03/19/installing-google-skipfish-on-ubuntudebian/

http://questions.securitytube.net/questions/546/is-skipfish-really-so-different-from-nessus-appscan-and-others