Description
The Simple LAN Scanner is a very simple LAN scanner written in Python. It scans the local network and tries to give you the MAC and IP addresses of the discovered running systems. Furthermore it creates a small log file at the end of the scan.

Usage
sudo ./simple_lan_scan.py –network=<your network>

Usage example
sudo ./simple_lan_scan.py –network=192.168.1.0/24

Installation
Make sure you install the package python-scapy before you run the Simple LAN Scanner.

Feature list
- Tries to give you the MACs and IPs of discovered running systems.
- Creates a small log file.

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.
- Power to teh c0ws!

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

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.

packetstormsecurity.org is now equipped with a modern look (new design + layout), pages for authors and profiles (registering is possible). Furthermore the start page and files organisation got over-worked.

For me, this is a very good sign. packetstormsecurity.org is one of the oldest and well known security websites in the world, and during the last years it seemed to have just existed, but certainly did not attract any new visitors with innovations or exciting new stuff (besides the exploits and tools). Good job @staff.

Edit: Whoops, it seems that they are still working on the site. The website is often not reachable and mailing (e.g. when registering) does not work yet.  I am curious when they have completed their work, I can’t wait to see what’s new!

[Link to the GHDB]

The Exploit-DB team now accepts new submissions and has the honorable task to revive what once was almost forgotten. Epic!

It is a database for exploit and papers, very similar to Exploit DB or milw0rm. They used to only accept new submissions from Israeli security researchers. Recently, they changed their policies and now accept submissions from everybody (actually I received an email from them and was asked to submit my stuff there).

Most of the authors, exploits, shellcodes, papers etc. seemed already to be cloned from other databases, but still some submissions are missing.

I think it is great that another database came up. We now have more ways to receive our security stuff

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

So mobile phones should be very secure, right? If someone would be able to take over control of such devices, it would be possible to track down many areas of our live. So the vendors should be making sure that every mobile phone is highly secure.

Insecure connections
Many mobile phones with Bluetooth abilities accept new incoming connections by default. This means that accessing data on these mobile phones is very easy (I have seen various live hacking demonstrations where the speaker simply hacked the smartphones of the audience without them knowing it).

Keyboard lock? Ehm yeah.
In most cases the keyboard lock of a cellular gets turned on when you don’t use it for a certain amount of time. Sadly this lock is of no use when you connect the mobile device to a computer and start a synchronisation tool. You still can access all the data without even having to enter a PIN or some sort of lock code. Furthermore some devices have a special way of unlocking the keyboard, e.g. by moving a bar from the left to the right. Very secure. If you left your phone let’s say at a restaurant, someone simply has to move the bar and then has access to the device.

Unencrypted data and connections
The files on mobile devices and storage cards are not encrypted in most cases. So are the connections to other phones.

Those are only three points concerning security issues, but at the same time this is already enough to state that the devices which we use daily are not secure enough.

Description
The Simple Log File Analyzer helps you to detect possible hack attempts within the log files of your webserver.

Features
- Error handling
- Scan a log file for four different attack types
- Display a short scan report
- Write scan results to a new log file
- Easy to use (everything is simple and automated)

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

Usage example
scan_log.py -file vhost_access.log

Disclaimer
I am not responsible if this script or you cause any damage# to your system. The memory consumption can become quite large and the generated reports very huge. So be sure you know what you are doing. I highly recommend you download your log files on a separate machine and analyze these files there.

Known issue
XSS attempt discovery feature can be a little bit buggy.

Screenshot

Simple Log File Analyzer