Injection attacks can be very easy to discover and exploit, but they can also be extremely obscure. The consequences can also run the entire range of severity, from trivial to complete system compromise or destruction. In any case, the use of external calls is quite widespread, so the likelihood of a web application having a command injection flaw should be considered high.

Shell Commands

Many web applications use operating system features and external programs to perform their functions. Sendmail is probably the most frequently invoked external program, but many other programs are used as well. When a web application passes information from an HTTP request through to the command line, it must be carefully scrubbed. This also applies when opening files in the file system. Otherwise, the attacker can inject special (meta) characters, malicious commands, or command modifiers into the information and the web application will blindly pass these on to the external system for execution.

SQL

SQL injection is a particularly widespread and dangerous form of attack. To exploit a SQL injection flaw, the attacker must find a parameter that the web application passes through to a database. By carefully embedding malicious SQL commands into the content of the parameter, the attacker can trick the web application into forwarding a malicious query to the database. These attacks are not difficult to attempt and more tools are emerging that scan for these flaws. The consequences are particularly damaging, as an attacker can obtain, corrupt, or destroy database contents.

Environments Affected

Every web application environment allows the execution of external commands such as system calls, shell commands, and SQL requests. The susceptibility of an external call to command injection depends on how the call is made and the specific component that is being called, but almost all external calls can be attacked if the web application is not properly coded.

Some environment specific considerations:

• MySQL – older mysql libraries only processes one statement at a time when you pass it a query. Newer mysql libraries (e.g., mysql in PHP) will process multiple SQL commands in one query
• Oracle – most Oracle client libraries support variable binding. This is the best way to avoid SQL injection.
• Perl – check for shell injection when you open a file if the filename is derived from user input

Examples:

• A malicious parameter could modify the actions taken by a system call that normally retrieves the current user’s file to access another user’s file (e.g., by including path traversal “../” characters as part of a filename request).

• Additional commands could be tacked on to the end of a parameter that is passed to a shell script to execute an additional shell command (e.g., “; rm -r *”) along with the intended command.

• SQL queries could be modified by adding additional ‘constraints’ to a where clause (e.g., “OR 1=1″) to gain access to or modify unauthorized data.

Example:

DELETE FROM CRITICALTABLE WHERE USER=’$VAR’

where the user enters

HACKER’ OR ’1′=’1

Notice the mismatched quotes! Inserting this into the SQL statement, we’d get:

DELETE FROM CRITICALTABLE WHERE USER=’BADGUY’ OR ’1′=’1′

This would delete all the information in the critical table.

How to Determine If You Are Vulnerable

The best way to determine if you are vulnerable to command line or SQL injection attacks is to search the source code for all calls to external resources (e.g., system, exec, fork, Runtime.exec, SQL queries, or whatever the syntax is for making requests to interpreters in your environment). Note that many languages have multiple ways to run external commands. Developers should review their code and search for all places where input from an HTTP request could possibly make its way into any of these calls. You should carefully examine each of these calls to be sure that the protection steps outlined below are followed.

How to Protect Yourself

The simplest way to protect against injection is to avoid accessing external interpreters wherever possible. For many shell commands and some system calls, there are language specific libraries that perform the same functions. Using such libraries does not involve the operating system shell interpreter, and therefore avoids a large number of problems with shell commands.

• Use bind variables where ever possible. If not, escape all user variables which be used in a SQL statement or on the command line.
• In Coldfusion, use variable binding by using the CFQueryParam Tag within your CFQuery tags.
• In Perl, prepare your statements using variable binding and then pass the parameters when executing the query:
  $cursor = $db->prepare(“DELETE FROM CRITICALTABLE WHERE USER=?”);
  $cursor->execute($user);
• Use pattern matching to verify user input is an expected value. If input is not what is expected, throw an error. Error messages should be generic.  
• Turn off/control debug messages to avoid giving an attacker potentially useful information.
• Database level: Limit access to the web account that is accessing the database.  Write procedures to insert records and update data rather than give the application direct access to the tables;  Limit application to READ-only access where possible – at user level as well as database level.
• Reuse previously tested code wherever possible.

For those calls that you must still employ, such as calls to backend databases, you must carefully validate the data provided to ensure that it does not contain any malicious content. You can also structure many requests in a manner that ensures that all supplied parameters are treated as data, rather than potentially executable content. The use of stored procedures or prepared statements will provide significant protection, ensuring that supplied input is treated as data. These measures will reduce, but not completely eliminate the risk involved in these external calls. You still must always validate such input to make sure it meets the expectations of the application in question.

Another strong protection against command injection is to ensure that the web application runs with only the privileges it absolutely needs to perform its function. So you should not run the webserver as root or access a database as DBADMIN, otherwise an attacker can abuse these administrative privileges granted to the web application. Some of the J2EE environments allow the use of the Java sandbox, which can prevent the execution of system commands.

If an external command must be used, any user information that is being inserted into the command should be rigorously checked. Mechanisms should be put in place to handle any possible errors, timeouts, or blockages during the call.

All output, return codes and error codes from the call should be checked to ensure that the expected processing actually occurred. At a minimum, this will allow you to determine that something has gone wrong. Otherwise, the attack may occur and never be detected.

The OWASP Filters project is producing reusable components in several languages to help prevent many forms of injection. OWASP has also released CodeSeeker, an application level firewall.

While the adoption of web applications for conducting online business has enabled companies to connect seamlessly with their customers, it has also exposed a number of security concerns stemming from improper coding. Vulnerabilities in web applications allow hackers to gain direct and public access to sensitive information (e.g. personal data, login credentials).

Web applications allow visitors to submit and retrieve data to/from a database over the Internet. Databases are the heart of most web applications. They hold data needed for web applications to deliver specific content to visitors and provide information to customers, suppliers etc.

SQL Injection is perhaps the most common web-application hacking technique which attempts to pass SQL commands through a web application for execution by the back-end database. The vulnerability is presented when user input is incorrectly sanitized and thereby executed.

Checking for SQL Injection vulnerabilities involves auditing your web applications and the best way to do it is by using automated SQL Injection Scanners. We’ve compiled a list of free SQL Injection Scanners we believe will be of a value to both web application developers and professional security auditors.

SQLIer – SQLIer takes a vulnerable URL and attempts to determine all the necessary information to exploit the SQL Injection vulnerability by itself, requiring no user interaction at all. Get SQLIer.

SQLbftools – SQLbftools is a collection of tools to retrieve MySQL information available using a blind SQL Injection attack. Get SQLbftools.

SQL Injection Brute-forcer – SQLibf is a tool for automatizing the work of detecting and exploiting SQL Injection vulnerabilities. SQLibf can work in Visible and Blind SQL Injection. It works by doing simple logic SQL operations to determine the exposure level of the vulnerable application. Get SQLLibf.

SQLBrute – SQLBrute is a tool for brute forcing data out of databases using blind SQL injection vulnerabilities. It supports time based and error based exploit types on Microsoft SQL Server, and error based exploit on Oracle. It is written in Python, uses multi-threading, and doesn’t require non-standard libraries. Get SQLBrute.

BobCat – BobCat is a tool to aid an auditor in taking full advantage of SQL injection vulnerabilities. It is based on AppSecInc research. It can list the linked severs, database schema, and allow the retrieval of data from any table that the current application user has access to. Get BobCat.

SQLMap – SQLMap is an automatic blind SQL injection tool, developed in python, capable to perform an active database management system fingerprint, enumerate entire remote databases and much more. The aim of SQLMap is to implement a fully functional database management system tool which takes advantages of web application programming security flaws which lead to SQL injection vulnerabilities. Get SQLMap.

Absinthe – Absinthe is a GUI-based tool that automates the process of downloading the schema and contents of a database that is vulnerable to Blind SQL Injection. Get Absinthe.

SQL Injection Pen-testing Tool – The SQL Injection Tool is a GUI-based utility designed to examine database through vulnerabilities in web-applications. Get SQL Injection Pen-testing tool.

SQID – SQL Injection digger (SQLID) is a command line program that looks for SQL injections and common errors in websites. It can perform the follwing operations: look for SQL injection in a web pages and test submit forms for possible SQL injection vulnerabilities. Get SQID.

Blind SQL Injection Perl Tool – bsqlbf is a Perl script that lets auditors retrieve information from web sites that are vulnerable to SQL Injection. Get Blind SQL Injection Perl Tool.

SQL Power Injection Injector – SQL Power Injection helps the penetration tester to inject SQL commands on a web page. It’s main strength is its capacity to automate tedious blind SQL injection with several threads. Get SQL Power Injection.

FJ-Injector Framwork – FG-Injector is a free open source framework designed to help find SQL injection vulnerabilities in web applications. It includes a proxy feature for intercepting and modifying HTTP requests, and an interface for automating SQL injection exploitation. Get FJ-Injector Framework.

SQLNinja – SQLNinja is a tool to exploit SQL Injection vulnerabilities on a web application that uses Microsoft SQL Server as its back-end database. Get SQLNinja.

Automagic SQL Injector – The Automagic SQL Injector is an automated SQL injection tool designed to help save time on penetration testing. It is only designed to work with vanilla Microsoft SQL injection holes where errors are returned. Get Automagic SQL Injector.

NGSS SQL Injector – NGSS SQL Injector exploit vulnerabilities in SQL injection on disparate database servers to gain access to stored data. It currently supports the following databases: Access, DB2, Informix, MSSQL, MySQL, Oracle, Sysbase. Get NGSS SQL Injector.

First SEARCH the following Keywords in Google or any Search Engine:

admin\login.asp
login.asp

with these two search string you will have plenty of targets to chose from…choose one that is Vulnerable

INJECTION STRINGS: How to use it?

This is the easiest part…very simple

On the login page just enter something like

user:admin (you dont even have to put this.)
pass:’ or 1=1–

or

user:’ or 1=1–
admin:’ or 1=1–

Some sites will have just a password so

password:’ or 1=1–

In fact I have compiled a combo list with strings like this to use on my chosen targets . There are plenty of strings in the list below. There are many other strings involving for instance UNION table access via reading the error pages table structure thus an attack with this method will reveal eventually admin U\P paths.

The one I am interested in are quick access to targets

PROGRAM

i tried several programs to use with these search strings and upto now only Ares has peformed well with quite a bit of success with a combo list formatted this way. Yesteday I loaded 40 eastern targets with 18 positive hits in a few minutes how long would it take to go through 40 sites cutting and pasting each string

combo example:

admin:’ or a=a–
admin:’ or 1=1–

And so on. You don’t have to be admin and still can do anything you want. The most important part is example:’ or 1=1– this is our basic injection string

Now the only trudge part is finding targets to exploit. So I tend to search say google for login.asp or whatever

inurl:login.asp
index of:/admin/login.asp

like this: index of login.asp

result:

http://www3.google.com/search?hl=en&ie=ISO…G=Google+Search

17,000 possible targets trying various searches spews out plent more

Now using proxy set in my browser I click through interesting targets. Seeing whats what on the site pages if interesting I then cut and paste URL as a possible target. After an hour or so you have a list of sites of potential targets like so

http://www.somesite.com/login.asp
http://www.another.com/admin/login.asp

and so on. In a couple of hours you can build up quite a list because I don’t select all results or spider for log in pages. I then save the list fire up Ares and enter

1) A Proxy list
2) My Target IP list
3) My Combo list
4) Start.

Now I dont want to go into problems with users using Ares..thing is i know it works for me…

Sit back and wait. Any target vulnerable will show up in the hits box. Now when it finds a target it will spew all the strings on that site as vulnerable. You have to go through each one on the site by cutting and pasting the string till you find the right one. But the thing is you know you CAN access the site. Really I need a program that will return the hit with a click on url and ignore false outputs. I am still looking for it. This will saves quite a bit of time going to each site and each string to find its not exploitable.

There you go you should have access to your vulnerable target by now

Another thing you can use the strings in the urls were user=? edit the url to the = part and paste ‘ or 1=1– so it becomes

user=’ or 1=1– just as quick as login process

Combo List

There are lot of other variations of the Injection String which I cannot put on my blog because that is Illegal. If you are interested I can send it to you through Email. Just write in your email address in comment and I will send it to you as early as possible but you need to remain patient it may take 1 or 2 days.

As a result of a lot of requests for the list of SQL Injection String and due to lack of time on our behalf to respond to your Comments we have now decided to give the download link for the list of SQL Injection Strings. Now you just need to Subscribe to our RSS Feed via Email and get the Download link at the bottom of the Confirmation Email. Please don’t Forget to click on the Confirmation Link given in that Email.

Here is the form to Subscribe to our RSS feed via Email:

Happy Hunting

I m considering writing a series of guides which for now I m calling “Hungry Hackers Guide”. i do have my malicious streaks (mainly on my own stuff though, I enjoy breaking my own machines), but I am mostly white hat. I guess these guide will basically aim to give white hat hackers a security lecture from a black hat perspective. i dunno. *shrugs*

Basic access control in apache

At it’s most basic level, access control in apache is specified in the httpd.conf (or equivalent file. these were previously three files, now merged into one for simplicity’s sake). the most basic directives are allow from and deny from. the default permissions for any given directory is allow from all (which will allow any client to get pages from that directory).

the format for these directives is as follows:

<Directory /> Order Deny,Allow Deny from All </Directory>

This will disallow any client from retrieving any file on your server, unless you explicitly allow files further up the tree. However, since sometimes normal users will want to control their own web directories, and it’s impractical (at least, at most, unsafe) to allow webmasters to modify the httpd.conf, we can specify to allow users to override certain directives using the allowoverride directive.

Allow override

Allowoverride (as stated above) allows non-root users to override access controls on a directory. you simply specify which directives you want the user to be able to override (the default is everything), and then apache looks in each directory for a .htaccess file (or other, specified with the AccessFilename directive) and applies the contents of that to it’s access control.

Part of the access control, the part which we will be covering (given the scope of this document) is the authconfig directives. below we’ll view a typical .htaccess file for most sites with moderate to poor security (most porn sites simply use these, porn sites can actually be great practice to crack passwords).

/* a typical .htaccess file */ AuthName "Marvin Martian's Porn Emporium" AuthType Basic AuthUserFile /home/marvin/public_html/members/.htpasswd require valid-user

As you can see above, there aren’t many directives required to provide password protection to a directory. as you can see, in this case, the webmaster has been pretty lazy and stuck the .htpasswd file inside the same directory. the format of the .htpasswd file is simple: <user>:<encryptedpassword>

[eminimall]

A Bad case

On a poorly secured server, there are no access restrictions on the .htpasswd file. since the .htpasswd file is in a web-accessible directory, and user which is able to authenticate to the directory is able to obtain the password list.

Simply enter the url /members/.htpasswd, and you should receive a full userlist as well as all the encrypted passwords. very silly indeed. if the file doesn’t exist, on a poorly configured server one merely has to read the .htaccess file to obtain the location. if it is below the “web-root”, then it would require a cgi-exploit of some sort to obtain the file. but on any other directory, simply use the browser to obtain the file:

webmaster:TTn.VQRliM8c2 hornyguy:ZpgNeARi106aM fatmike69:drXj18zVxxBVc

Unfortunately, these passwords aren’t of much use in their current form. they require cracking.

Cracking Passwords

Most unix passwords are encrypted using a “one way hash” or “trapdoor hash” – which entails actually losing data from the password in such a way that the original password simply cannot be obtained by reversing the algorithm.

The only way to crack such passwords is using brute force guessing attacks. a simple perl script can be used to achieve this:

#! /usr/bin/perl # crack.pl by fwaggle <root@fwaggle.net> open (PASSFILE, ".htpasswd"); my @passfile = <PASSFILE>; close PASSFILE; open (DICTFILE, "dictionary.txt"); my @dictfile = <DICTFILE>; close DICTFILE; foreach $line (@passfile) { my ($username, $encpass) = split(/:/, $line); foreach $attempt (@dictfile) { if ($encpass eq crypt($attempt, $encpass)) { print("Cracked: ${username}:${attempt}\n"); } } }

The above perl script is a simple brute force password cracker. it may or may not work, i didn’t actually test it before writing this article – but it closely resembles one i released to alt.hacking quite a while ago. whether it works or not, you should hopefully be able to see the process which password cracking requires (even for perl, the syntax is almost plain english).

[eminimall]

Better Cracking Performance

Perl isn’t the quickest of languages, and using the standard crypt() calls aren’t exactly optimized for high speed cracking. a far better solution is to download a purpose-built, c coded password cracker such as john the ripper. john the ripper is optimized to crack passwords extra fast, as well as it includes an “incremental mode” in case your dictionary should fail to crack a password. ie, in the above example, if the user’s password doesn’t happen to be in the dictionary, then you won’t be able to crack it.

Using an incremental password cracker, every character combination is tried, in an intelligent order (in a vain attempt to save time in something that is wholely unpredictable), so that absolutely any password will be cracked, eventually.

The one problem with john the ripper is that it’s picky about the files that it gets inputted. in order to crack the .htpasswd files, you must edit them to make them appear like regular unix /etc/passwd files. this means adding extra fields, like this:

<username>:<password>:1:1:user:/bin/sh:/root

for example, the entries above could look like this:

webmaster:TTn.VQRliM8c2:1:1:webmaster:/bin/sh:/root hornyguy:ZpgNeARi106aM:3:3:hornyguy:/bin/sh:/root fatmike69:drXj18zVxxBVc:3:3:hornyguy:/bin/sh:/root

The windows version doesn’t seem to require this for some reason, so you can just feed it a regular .htpasswd file. note that the windows version may have markedly poor performance when compared to the unix versions.

Finding vulnerable servers

Now that we’ve discussed how to break these passwords, it’s almost time to talk about securing them. if you’re only interested in hax0ring passwords from sites, chances are you’re probably well equipped to crack any password files you might stumble accross. if you’re just looking to hack anything, try searching in google or altavista for a phrase like .htpass, and wade through the results and see if you find a file that says “Index of /something” that contains a .htpasswd file.

if you have permission to read the file, you’ve basically hacked it already. this is admittedly a lame hack, but if you’re bored – do the net in general a favour. crack the passwords, and email them to the admin. that’s all i ever used to do, and you get the same sense of achievement and hacker cred, without the legal problems of defacements.

on a side note, the same results can be achieved by searching for service.pwd. this is the password file for fp-apache, the frontpage server extensions for apache. some really lame admins don’t check permissions on this file, and you can easily gain access to these kinds of systems (and if you’re feeling particularly malicious, just connect with a frontpage client and upload a defacement).

Putting an end to this Nonsense

if you’re running your own site, then here’s the section you’ll really be interested in – stopping someone from doing this to you. the first thing you need to do is prevent users from reading your .ht* files. the easiest way to hinder this is to put the .htpasswd file someplace that’s not web-accessible (such as your home dir, out of ~/public_html).

the next step, as an admin of a server, is to prevent apache from serving these pages from the web. there is no (i repeat NO) reason that a web client should ever need to see these pages, they are for server side configuration only.

so, we can easily accomplish this using the <Files> directive, and a niftylittle regular expression:

<Files ~ "^\.ht"> Order allow,deny Deny from all </Files>

this particular example (taken from apache’s httpd.conf, now thankfully included in default distributions to keep lame admins from unknowingly putting themselves at risk) prevents the server from serving any files that begin with .ht. thus, .htaccess and .htpasswd are both protected.

the final step from here is to ensure that the files are protected on the server – meaning file permissions. the ideal situation is to have suEXEC for apache running, and to have the files accessible only by the httpd (but still owned by you). that way, you can chmod the files when you need to edit them, but cgi exploits will not allow users to read the files.

Wrapping it up

well, this concludes my little rant about .htpasswd and .htaccess files. hopefully you learnt something from this. comments are always welcome, just email me. also, if you’re looking for a unix/unix-like irc channel to lurk on, come on my irc network (irc.mooircd.org) and join #hackerzlair – it’s lag free, packet kiddie free, and quite nice.

That about does it I think. Maybe I’ll write some more of these files if I think about it.

Either through actual hacking, or through actual not compliance with company policy and taking work home, or loosing disks with millions of consumer records, the trusted insider is 2007′s biggest problem.