CAPTCHA (“Completely Automated Public Turing test to tell Computers and Humans Apart”) is a type of challenge-response test used by many web applications to ensure that the response is not generated by a computer. CAPTCHA implementations are often vulnerable to various kinds of attacks even if the generated CAPTCHA is unbreakable.

I’ve had a few questions on testing CAPTCHAs as of late and decided to do a quick write-up on how I test the strength of a CAPTCHA or in some cases write a CAPTCHA breaker. I will start below with a quick test that I use to gauge the initial strength of a CAPTCHA implementation (Microsoft Onenote has excellent handwriting detection and is very easy to use for this purpose):

1. Copy the image contents to my clipboard
2. Open up onenote (or your favorite OCR tool)
3. Paste the image onto a one note page.
4. Choose copy text from picture
5. Now you will have the contents on your clipboard. Paste that into notepad and compare the results.
6. If there is noise in the middle of the text, such as a curved line, make the image very large and stretch the image vertically. Then pass this through a handwriting detection library. The stretching appears to make the noise in the middle less prominent. Note: This is based on my own personal tests and not concrete science.

Figure 1 – Using Onenote’s OCR functionality for a quick test

A few other things I will also try before attempting to solve the image. Remember if you can’t script the transformation then you have defeated the purpose of the test.

• Convert the image to black and white (this, for whatever reason, filters out a ton of background noise).
• Many CAPTCHAS use a static piece of noise like curved line the middle of the word. You can often get around this by doing a static crop of a region of the image.
• Cut the image up into a grid. This can easily be achieved using a Photoshop script or ImageMagick, but I have not gone through the trouble of making one in a long time. See the example in Figure 2. This can be achieved by examining each pixel in the image and identifying the leftmost black pixel as a starting point and identifying the rightmost boundaries of each letter where the black pixels are continuous. This assumes there is a clear boundary however between each letter. This may be easier to solve by treating each CAPTCHA as a series of images in favor of a single image.

Figure 2 – Removal of image noise by simply converting the image to black and white

Figure 3 – Defining character boundaries to simplify solving the CAPTCHA

There is a huge weakness in the CAPTCHA in Figure 2 (in use by many prominent online retailers) due to none of the characters actually touching. You could easily write a script that identified the first area of the image that identified the leftmost black pixel and the rightmost where all the black dots were touching. This would give you the locations of the character boundaries which could then be used to create a grid containing each letter. You may have trouble when you run into certain characters like the number one, lowercase L and the letter I; however it is for this very reason that many CAPTCHAs exclude those characters from the character set.
In many ways, automating CAPTCHA strength testing is very similar to handwriting detection and simple tools are widely available for this task including FOSS libraries.

A couple other CAPTCHA solver libraries are out there, including the somewhat dated PWNCAPTCHA that was recently open sourced. Here is a list of a few other helpful tools that you can use to make your own CAPTCHA solvers:

• Perl OCR Libraries – http://search.cpan.org/search?query=ocr&mode=all
• Ruby OCR Libraries – http://code.google.com/p/ocropus/
• Perl IMAGEMAGICK Image Manipulation Library – http://www.imagemagick.org/script/perl-magick.php

The script below is a framework for a tool performing some of the image transformations I described using ImageMagick

#!/usr/bin/perl -w

# CAPTCHA Solver v1 – A simple tool for image transformations and OCR to solve CAPTCHA

# Author: Mark Maxey – mmaxey@accuvant.com

# 1-9-2008

# Version 1.0

use strict;
use Image::Magick;

# read in the image
my $image = Image::Magick->new;
open(IMAGE, ‘/home/mmaxey/image.gif’);
$image->Read(file=>\*IMAGE);
close(IMAGE);

# turn the image to black and white
$image->Quantize(colorspace=>’gray’);

# cropping the image to eliminate static noise
$image->Crop(geometry=>’100×100+10+20′);
$image->[$x]->Frame(“100×200″);

# resize the image
my $img_width = ‘2000′;
my $ratio_main = ‘1′;
my $img_height = ‘2000′;
$image->Resize(width=>$img_width * $ratio_main, height=>$img_height * $ratio_main);

# OCR Code here
# if you can’t figure this part out you shouldn’t be doing this
# end OCR

Some key things to remember when testing a CAPTCHA:

1. Eliminate as much noise as you can, which is generally easy by just converting the image to black and white
2. Identify areas where static cropping of noise can be eliminated
3. Some OCR toolkits can limit the character set to specific characters (no special characters and all lowercase for example). Use this where applicable to improve the accuracy of the test
4. Turning the CAPTCHA into a grid will often make it very easy to solve by clearly defining word boundaries
5. If the CAPTCHA does not involve text you probably can’t solve it using the methods I described above
6. Increase the size of the image, this will help you hone in on where the boundaries are and makes a lot of the noise much easier to deal with
7. Sometimes a CAPTCHA, if there are parameters available for tampering, can be used to DoS a site or cause other problems. Quite often you will see a parameter like width=200&height=350, so what if you make this 999999999999 x 99999999999999999 etc.

Overview:
The blog post here makes statements about a vulnerability in the Linux kernel handling of SCTP data. The primary point of the post is to show how a vulnerability that was once thought to be of a relative low risk was incorrectly assessed and it can provide a 3rd party remote access to a server using SCTP. This post will attempt to verify the claims, duplicate the examples, and give a risk assessment.

Public Vulnerability Information
The following links provide information about the vulnerability:

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0065

http://www.vupen.com/english/advisories/2009/0029

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=9fcb95a105758b81ef0131cd18e2db5149f13e95

Vulnerability Details
An analysis of the patch that fixes the vulnerability show the following additions in code:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=9fcb95a105758b81ef0131cd18e2db5149f13e95;hp=aea3c5c05d2c409e93bfa80dcedc06af7da6c13b

— a/net/sctp/sm_statefuns.c
+++ b/net/sctp/sm_statefuns.c
@@ -3689,6 +3689,7 @@ sctp_disposition_t sctp_sf_eat_fwd_tsn(const struct sctp_endpoint *ep,
{
struct sctp_chunk *chunk = arg;
struct sctp_fwdtsn_hdr *fwdtsn_hdr;
+       struct sctp_fwdtsn_skip *skip;
__u16 len;
__u32 tsn;

@@ -3718,6 +3719,12 @@ sctp_disposition_t sctp_sf_eat_fwd_tsn(const struct sctp_endpoint *ep,
if (sctp_tsnmap_check(&asoc->peer.tsn_map, tsn) < 0)
goto discard_noforce;

+       /* Silently discard the chunk if stream-id is not valid */
+       sctp_walk_fwdtsn(skip, chunk) {
+               if (ntohs(skip->stream) >= asoc->c.sinit_max_instreams)
+                       goto discard_noforce;
+       }
+
sctp_add_cmd_sf(commands, SCTP_CMD_REPORT_FWDTSN, SCTP_U32(tsn));
if (len > sizeof(struct sctp_fwdtsn_hdr))
sctp_add_cmd_sf(commands, SCTP_CMD_PROCESS_FWDTSN,
@@ -3749,6 +3756,7 @@ sctp_disposition_t sctp_sf_eat_fwd_tsn_fast(
{
struct sctp_chunk *chunk = arg;
struct sctp_fwdtsn_hdr *fwdtsn_hdr;
+       struct sctp_fwdtsn_skip *skip;
__u16 len;
__u32 tsn;

@@ -3778,6 +3786,12 @@ sctp_disposition_t sctp_sf_eat_fwd_tsn_fast(
if (sctp_tsnmap_check(&asoc->peer.tsn_map, tsn) < 0)
goto gen_shutdown;

+       /* Silently discard the chunk if stream-id is not valid */
+       sctp_walk_fwdtsn(skip, chunk) {
+               if (ntohs(skip->stream) >= asoc->c.sinit_max_instreams)
+                       goto gen_shutdown;
+       }
+
sctp_add_cmd_sf(commands, SCTP_CMD_REPORT_FWDTSN, SCTP_U32(tsn));
if (len > sizeof(struct sctp_fwdtsn_hdr))
sctp_add_cmd_sf(commands, SCTP_CMD_PROCESS_FWDTSN,

This patch adds the addition of a new variable as well as two diffrent checks for an invalid stream ID. The comments about each code addition explains exactly what the code is for:

/* Silently discard the chunk if stream-id is not valid */

Both code snippets do the same thing: they convert a value from network to host order then check is the result is greater than or equal to asoc->c.sinit_max_instreams. There are two important things about this code snippet.

The first is that there is an indication that this vulnerability is remotely exploitable since the value is being converted from network to host byte order.

The second is that the simple check of greater than or equal to is a length check that is designed to prevent an overwrite of some sort.

Following the declaration and assignment of these values, reveals what the vulnerability is. Due to a logic error in the handling of certain types of packets, more specifically the FWD packets, the kernel can be tricked into writing chucks of data beyond the boundary allocated for it resulting in memory corruption. This memory corruption can be used to manipulate memory in such a way that execution of arbitrary code occurs and allows an attacker take control of the target machine.

This validates the statements made in the blog post about the nature and the risk associated with the vulnerability.

Exploitation
Exploit code for this vulnerability has been released here: http://www.milw0rm.com/exploits/8556

In order to test the code, a Linux server is needed to act as the victim and a Linux client is needed to act as the attacker. For the client, a Backtrack 4 VMware image is used. Since the default install of Backtrack does not have the SCTP development libraries, the tool aptitude is used to install them with the following command:

aptitude install libsctp-dev

After aptitude reports success, the exploit code can be downloaded from Milw0rm and compiled using the command:

gcc sctp.c -o sctp

The exploit can be tested with the command “./sctp”.

For the server, a VMWare image of Ubunti 8.10 is used. This server needs SCTP development libraries installed in the same way the Backtrack libraries were installed. The VMware image can be found here: http://www.vmware.com/appliances/directory/95733

Since the exploit requires a process using SCTP to be running an example can be found from IBM here: http://www.ibm.com/developerworks/linux/library/l-sctp/

After uncompressing and building the tool using the make command it is executed.

The exploit running:

The traffic captured in wireshark:

The exploit works as advertised and can give a remote attacker access to a server. The exploit is designed to only issue the “id” command and report the results but this could be easily modified to allow interactive access or to deliver to a botnet payload.

Analysis
This exploit works as advertised and can give remote access to a 3rd party. SCTP can be implemented by a variety of different custom applications. SCTP can also be installed on servers with network intensive applications like Voice over IP. Most application testing would miss the inclusion of SCTP since most general purpose scanning tools do not detect a server supporting it. Source code or server access is the most reliable way to verify SCTP is supported.

In closing, since a vulnerability was discovered, reported, and is now shown to be exploitable in the Linux implementation of SCTP, other operating systems that support it will be targeted as well. If your applications rely on SCTP or a server with SCTP enabled, isolating it from the rest of the network is now a must.

The difference between a mediocre application assessment and a stellar one is assimilation of information and the ability to apply it to the problem at hand. During an application assessment an individual has a limited amount of time to understand an application, its underlying architecture, the development methodology and compress that into knowledge that can be used to locate and exploit weakness in the target.

What if the scope changes? If an app tester is on site evaluating a target and new information about a weakness of flaw in the environment became available, that information should be quickly applied assimilated and applied tot he audit otherwise any deliverable could be deemed worthless becasue it is not up to date with the current threat facing the application.

A case in point is a Linux kernel vulnerability discussed on April 27th, 2009 on a blog called KernelBOF. The blog post details a problem in the Linux Kernel handling of SCTP data. The CVE information can be found here: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0065

The main point of the post is that people do not understand or appropriately rate the risk of kernel bugs such as this one. The bug was released on January 5th, 2009 and at the time documentation seemed to indicate that the perceived risk of this vulnerability was as a Denial-of-Service (DoS) only and the actual affect is unknown. The KernelBOF blog then dives into deep detail about the vulnerability and shows why it is really a threat.

A good app assessment engineer should be able to take the vulnerability information, reproduce it, and give the client insight into how it affects their environment. The following next blog post entitled “SCTP Linux Kernel Vulnerability Assessment and Reproduction” will give insight into the process and how certain judgments are made about the risk.

–app assessment team