1. There is truly a need for the application.  There must be an honest business need for the application. If not, organizations should seriously question the decision to use it. This must be carefully considered as every application chosen to support an enterprise-level need increases the overhead of an organization’s IT staff in terms of security and management responsibilities.  Many things are “nice to have,” but, at the end of the day, they simply decrease an organization’s security posture and tax already stressed resources.
    
2. The application can be thoroughly supported by the vendor or with available third-party resources.  Before using an application, the organization should determine how well they can support that application. It’s not wise to tie the success of an enterprise to an application that is overly difficult to manage or maintain. If the application does not have active vulnerability discovery and remediation support, requires management and support overhead that the organization cannot supply, relies on program or system support that negatively impacts the organizations business continuity management program, or contains areas of management and/or security vulnerabilities that cannot be sufficiently addressed using available native or third-party solutions, then the use of the application is likely not a good choice. Too often, we become fascinated with the shiny new car and forget to consider if we have the ability and money required to keep the car running.

Examples of applications that companies should be concerned about include social media and older legacy applications.  These show both ends of the software spectrum – the new and the old.  Both, however, have concerns that must be addressed before they are allowed into the enterprise.

Social media is a rapidly expanding area, and, in many cases, these applications can definitely have legitimate business uses.  However, organizations should consider the dangerous concerns that social networking applications present concerning unauthorized data loss, loss of worker productivity, bandwidth and system resource consumption, and possible infection vectors for compromised code and malware.

Older, well-known applications are often used in favor of newer versions of the same systems.  Companies must consider that the cost savings made in not upgrading to newer versions may be offset by inherent security risks. Widely published and well-known security vulnerabilities contained in these programs can be easily compromised using tools openly proliferated across the Internet.  Also, the software may be at the end of its support lifecycle or tied to older hardware that is no longer easily available for replacement.  Older protocols and operating systems may have a legitimate business use, but, given the wide variety of more secure, supported, and commercially viable options available, the continued use of these products are likely more of a risk than benefit.

What litmus test does your organization use to determine whether or not to deploy a specific application in your environment?

Chris Gray
Senior Risk and Compliance Management Consultant

For better or for worse, Microsoft has taught the industry to patch once a month. But, most of Microsoft’s patches released on this monthly cycle deal only with the various Microsoft Operating Systems and fail to address vulnerabilities in primary or secondary applications or services such as Exchange, SharePoint, IIS, etc. Due to this type of release cycle, and a lack of self education on the part of the administration staff, many organizations are failing to effectively patch the technologies and applications that lie on top of their Operating Systems, such as Oracle databases and desktop applications like Adobe Acrobat. Without a comprehensive patch management program, organizations continue to have significant gaps in their security based on missing patches. 

Honestly, enterprise patch management doesn’t have to be a problem.  Just recently, Microsoft released their new patch management solution, which provided better flexibility to manage patches at the desktop and secondary application level. Additionally, there have been solutions available on the market that enable organizations to effectively maintain operating system patches for not only Windows but other operating systems such as Linux and Unix, as well as primary and secondary functioning applications like SQL servers, MS Office and the various Adobe products. Some even go as far as providing better support for pushing antivirus updates. Many of these solutions also provide the capabilities companies need to maintain consistent hardware configuration settings. 

Just as enterprise patch management is a fixable issue, so is network enterprise configuration management. From a hardening procedure standpoint, organizations spend a lot of time creating their standard system build image and forget to come back and update that image on a regular basis.  A solution that was effective six to 12 months ago will not be effective today, and it will leave a network vulnerable. Standards change and the Internet is not static. Therefore, it’s important for companies to pay attention to ongoing maintenance of standards and policies and make ongoing changes as appropriate. 

As you can see, when it comes to network security the people and processes are just as important as the technology – maybe even more so. I strongly believe that the biggest potential mistake administrators and/or companies can make is not educating their users.

 The majority of recent attacks faced by Twitter and Google are directly targeting the employees and users of corporate networks. Companies that haven’t taught their users the basics of what to avoid can pretty much assume they’re going to get infected by the next big infestation/attack, especially when you couple that with legacy technologies like Internet Explorer 6 as the standard browser they are required to use. Providing ongoing user awareness training and seminars that include real world examples and scenarios is the best way to educate users on their requirements to help keep the environment as secure as possible. 

Companies also need to focus more on using the right resources for the right initiatives. A common mistake that I’ve seen over the past two years happens when an organization buys a Web Application Firewall (WAF) and leverages network operations personnel to implement and maintain the system. Unfortunately they will find out the hard way that they are using the wrong resources. A WAF requires detailed knowledge of the Web environment and application infrastructure, which many network operational professionals do not have. Based on a strong understanding of Web applications, an application level professional or developer would be a better choice for ongoing maintenance of this type of technology – at least from a policy and technology enforcement perspective.

I’d love to hear about the changes your company has made to harden network security. Let me know!

Jim Broome
Director – Accuvant LABS

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.

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.

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