Are you Vulnerable to Shell or SQL Injection?

Injection flaws allow attackers to relay malicious code through a web application to another system. These attacks include calls to the operating system via system calls, the use of external programs via shell commands, as well as calls to backend databases via SQL (i.e., SQL injection). Whole scripts written in perl, python, and other languages can be injected into poorly designed web applications and executed. Any time a web application uses an interpreter of any type there is a danger of an injection attack.

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.

Popularity: 1% [?]

You might be interested in the following Articles

Read more »

List of all the SQL Injection Strings

One of the major problems with SQL is its poor security issues surrounding is the login and url strings. This tutorial is not going to go into detail on why these string work as all these details have been given in my previous article Top 10 Tricks to exploit SQL Server Systems .

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.

Read more »

Cracking .htaccess/.htpasswd for Passwords

This article is intended to be an almost complete guide to cracking and protecting websites which utilize the .htaccess/.htpasswd method for controlling access to data. it’s not intended to be a how-to guide for hacking websites. if you’re looking for a simple howto and not interested in reading in-depth information, then this isn’t the text for you.

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.

Read more »

2007′s Biggest Problem – The Trusted Insider

This has not been a banner year for insider hacks, and insider data loss across the board. In many ways we can most likely call this the year of the insider. 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.

Adding to that is a recent insider hack from Florida, where a senior database administrator stolen and then sold through a 3rd party, consumer information that should have been better secured, or at least, someone should have been watching.

Working for a subsidiary called Certegy Check Services, Sullivan used his access to Fidelity’s database to pilfer records that included individuals’ names, addresses and financial account information, according to court documents. To cover his tracks, he incorporated a business called S&S Computer Services, which sold the data to an un-indicted accomplice. According to authorities, this unidentified person resold the information to direct marketers, including one called Strategia Marketing, which also went by the name Suntasia. Source: Channel Register
While the TJX settlement was not that much in terms of money out to consumers, the loss of data, and the selling of data is not just for hackers anymore. The underground economy in data, should include insiders as a source, either by purpose, or because they got spear phished as they did at Los Alamos this week.
Security Risk Management needs to take a lot of this into consideration, and controls must be in place to make sure that these kinds of events do not happen with the same kind of frequency that they have happened this year.
One thing that security risk managers can do is familiarize them with the insider threat research conducted by CERT. This is one of the best repositories for data about insider threats, that will help a company scenario plan, and come up with contingencies as well as monitoring strategies.
Another good source of Links is Practical and well worth visiting.
In the mean time, while we wind down for the holidays, it might be time to revisit your security practices, and work on mitigations for insider threats. There have been far too many this year.

Read more »