Late last week, I read a SearchSecurity.com blog that quoted Caleb Sima as saying, “…developers shouldn’t learn anything about security. It’s not their job.” I felt compelled to write about the piece, not to support or condemn that statement, but rather to encourage people to think about the bigger picture. 

You see, there are a variety of factors that play into what a security program should contain, and every organization is completely different. Security requirements can be influenced by whether a company is public or private, its vertical markets and even its size, among other things. They can also be impacted by the organization’s level of security awareness.  As a result, some companies may have IT departments that include one security-focused resource; others may have entire departments with multiple resources, while some don’t have any security experts on staff at all. This disparity makes it almost impossible to come up with a one-size-fits-all, cookie cutter approach to information security.

So, rather than focus on the development process, which is clearly just one aspect of security, each company really needs to think about how its overall security program should look when it’s mature. The underlying goal is always to define and develop a program that protects the confidentiality, integrity and availability of information assets. This requires taking the appropriate steps to evaluate the organization’s current risk landscape as well as the risk-reducing potential of available solutions.

Using this risk-based approach, companies will be able to see where they fall short when it comes to compliance, including for regulations and standards such as HIPAA, GLBA, and PCI, and mitigate gaps. Organizations will also be better equipped to address their unique risks with measures that are logical, efficient and cost-effective. Furthermore, companies will be in a position to effectively test the integrity of their existing security program so they can see where their current measures are sufficient and where they are not, and then weigh their priorities based on need.

It is not news to anybody that threats are present in every environment and, regardless of the existence of an information security program, incidents can and do occur. However, organizations that invest time and effort into implementing coherent information security practices reduce both the likelihood (probability) and scope of the episode. This translates into an enormous business impact. Failing to entrust data can be very costly, including the direct expenses associated with detecting, halting and repairing compromised systems, as well as the tangential expenses tied to attempting to restore a ruined reputation. There also are penalties for violating state and federal privacy laws under the principles of unfair or deceptive trade practices, and the inherent loss of productivity, which can result in tens of thousands of dollars a day based on loss of email usage alone. The implications – both financial and operational – skyrocket when malware spreads to other aspects of the computing environment such as servers, workstation operating systems, and file shares.

Think about it. Can your organization really afford to focus only on one piece of the puzzle?

Doug Landoll, CISSP, CISA, MBA
Practice Director – Risk & Compliance Management

Last week, NetworkWorld published an article  under the headline “RSA 1024-bit private key encryption cracked.”  RSA encryption was one of the first widely-used asymmetric key algorithms, meaning it used two keys, one public and one private.  A message encrypted with the public key couldn’t be decrypted without the private key, the idea being that your public key would be published so that anybody could encrypt messages with your key and send them to you, and the private key is kept secret so that only you could decrypt and read those messages. 

This asymmetric encryption idea was such a huge improvement over previous shared-secret cryptosystems that it is used in everything from web browsers, where it protects sensitive transactions like online banking and shopping cart checkouts, to cryptoprocessors used in banking mainframes, embedded devices like iPhones and mp3 players, and credit-card sized smart cards like those that protect premium satellite and cable TV content.  The most common use of RSA is probably in web browsers and web servers, with an installed base of more than one billion personal computers.

Given such pervasive use of asymmetric crypto, and RSA’s algorithm in particular, news that 1024-bit private key encryption has been cracked would be alarming indeed.  Fortunately for all the online shoppers out there, this is another example of headline hyperbole.  The article outlines the findings of a paper titled “Fault-based attack of RSA authentication” that describes an attack the authors carried out on an encryption library that implements the RSA algorithm, called the OpenSSL library.  In order to perform the attack, the authors had to tamper with the power supply of the computer they were attacking, lowering the voltage just to the point where the computer would still operate, but occasionally operate incorrectly.

So, the first thing to note is that the thing that was cracked was the OpenSSL library’s version of the RSA algorithm.  The paper did not find any weaknesses in the actual RSA algorithm itself.  And the second point of interest is that the attack required physical access to the power supply of the target system.  For example, to carry out this attack on an online banking server, the attacker would need physical access to the online banking server’s power supply, which means they would need to be inside the bank’s data center.  Given the “wealth” of other targets available to an attacker standing inside of a bank’s data center, theft of the online banking web server private SSL key by a difficult and time-consuming voltage regulation attack seems rather unlikely.

These restrictions make the attack sound like something that is purely theoretical, and not useful in real life.  While it is true that online shopping and banking probably aren’t under much threat from this kind of attack, RSA and related algorithms are used in many other applications.  This kind of attack is most likely to be carried out against systems that are designed to operate in a public environment: smart grid electric meters for example, or consumer electronics devices like iPhones and game consoles – any device with a private key embedded in the hardware that could, if extracted, be used to impersonate the device or card. 

While this kind of attack is most useful against embedded devices, the paper’s author’s claim that one of their contributions with this research is demonstrating that voltage-manipulation fault injection attacks can be applied to larger devices like the microprocessors found in desktop PCs and servers.  The really strange thing about this paper is that while the researchers claim to have implemented the attack on a full-size SPARC/Linux/OpenSSL workstation, the actual hardware was a Xilinx Virtex2Pro FPGA, which was emulating a SPARC CPU, and which the researchers claim is representative of an off-the-shelf commercial embedded device. It seems as if they are trying to have it both ways – i.e. it is an attack against a full-size workstation, and by the way it also is an attack against something you might see in a typical embedded system. (What kind of embedded system would be running Linux on an emulated SPARC on an FPGA?  Maybe an embedded cryptoprocessor or something).

The attack seems to be based on causing short-lived faults in the CPU during one of the RSA signature algorithms used by OpenSSL.  Since this kind of attack has been around for a while, the OpenSSL library actually contains some code to counter it.  According to the paper, the signature is first generated with the private key rather quickly using Chinese Remainder Theorem style multiplication.  Then the signature is checked, using the public key.  If the signature is invalid, the system assumes it was attacked and goes to a slower, but supposedly more attack-resistant signature mechanism, i.e. left-to-right squaring.

According to the paper, the results of the fallback left-to-right squaring RSA signature are not checked before the signature is sent to the other party.  That is probably the bug in OpenSSL.  Because the result isn’t checked, an invalid signature is sent.  The recipient can use these invalid signatures to infer information about the private key and with enough invalid signatures and processing time, the entire private key can be broken.

While the NetworkWorld headline is an exaggeration, the paper itself could probably be summarized in the following three sentences:

1. It is possible to perform fault-based crypto attacks against microprocessor systems, at least when they are implemented in an FPGA.
2. The OpenSSL RSA signature algorithm’s fallback algorithm, left-to-right squaring, is also vulnerable to fault-injection style attacks, even though it was supposedly chosen as the fallback algorithm because of its increased resistance to such attacks.
3. The OpenSSL RSA signature algorithm apparently doesn’t check the result of the fallback algorithm prior to sending signed messages.

The paper does present an attack that might be used to jailbreak the next iPhone or Xbox, or clone satellite TV or cable cards, at least if any of those systems use a vulnerable version of OpenSSL.  However, a more accurate headline might have been “Obscure bug in OpenSSL library poses little risk to consumers.”

Phil Brass
Managing Principal Consultant – Accuvant LABS

A recent article published on the Wall Street Journal online declares a “Broad New Hacking Attack” involving the ‘new’ malware threat, Zeus or zbot.  This threat is far from new, however, neither the malware nor the phenomenon.  In April of 2008, RSA issued an advisory about the threat.  It is simply another dashboard exploiting a different set of vulnerabilities. 

The reality of the situation is that the current security controls in place for many companies are not going to adequately protect against this kind of threat. At a macro level, until industry standards demand rapid patch releases from vendors and corporate policies enforce more timely updates for their users, these botnet armies will continue to grow virtually unchecked. 

Even with corporate patch management programs that enforce strong update policies, it is fundamentally a losing battle to try and stay ahead of the people crafting this malware by patching once a month.   Whether it’s Microsoft’s ‘patch Tuesday’ or Firefox’s semi-monthly security updates, the window of time in between patches leaves attackers too much room to craft new exploits to update the malware with.  Companies are limited by the patches released by vendors and the vendors in turn are limited by the vulnerabilities they are aware of.

In order to further facilitate the production of these patches, stronger incentives should exist for responsible vulnerability disclosure.  Rather than simply relying on community reports or vulnerability leaks, vulnerability disclosure should be rewarded monetarily.  If Microsoft is willing to offer a quarter of a million dollar reward for the arrest of the people that made Conficker, isn’t it reasonable to offer rewards for the responsible disclosure of these vulnerabilities before they reach the massively exploited botnet-army stage?  These patches are only useful, however, if corporate policies enforce regular updates.  It‘s the circle of life. 

There are, obviously, steps that can be taken to mitigate the risk presented by these threats but those are covered in Jim’s post.

Matthew Parcell

Senior Security Consultant – Accuvant LABS

Tags: botnet, Conficker, patches, responsible disclosure

Yesterday, the Wall Street Journal published an article by Siobhan Gorman about hackers in Europe and China who successfully broke into computers at 2,500 companies and agencies over the last 18 months. The hackers used various techniques to infiltrate the corporate networks, including malware, phishing, email attachments, false virus patches and botnets.

A client of ours asked us: “what do you propose we do as an organization?” The answer to this question really revolves around at what point of the infestation/attack they are at.

Not Infested/Attacked Yet – Answer:

Training, Training, Training! The best non-technical way to prevent getting infected is user awareness training and testing/retesting. The majority of the attacks faced by Twitter, Google – and with this round of attacks – are directly targeting the employees and users of your network.   If you haven’t taught your users the basics of what to avoid, you can pretty much assume you are going to get infected by the next big infestation/attack that is going to come around. Providing ongoing user awareness training and seminars that include real world examples and scenarios is the best way to educate your users on their requirements to help you keep your environment as security as possible.

Additionally, if you’re one of the organizations with dynamic content filtering, proxies, IPS, DLP, HIDS, and an enterprise patch management solution, some luck may be on your side. A lot of the ‘ware can be delivered in email, through web applications and most popularly, through PDF, so more than one area of your strategy may need attention if you don’t have the above.   

Darn it , We got it! – Now What Answer:

 So, you’ve gotten infected and need some help cleaning up or figuring out what’s going on.  Here’s where Accuvant can help and the types of services we offer:

1- Emergency Response Level Services:

Time is of the essence. Emergency response services can assist customers with responding, containing and isolating infected systems to start fixing the issue.  These services are designed to get in there fast and start helping the client monitor for points of infestation and possibly kill spreading attacks.  

2- Malware Analysis:

The LABS team has performed these for clients that want detailed analysis of a unique infestation or deliberate events.  In these cases, we do a forensic image of the system and review the binary to try and determine origin and function.  We have performed these services for financial companies, and those that need to know if they are being targeted by industrial espionage or organized crime.

3 – Solutions Optimization

After an event, several clients have asked us to come in and evaluate their current solutions to determine if they have configuration issues or coverage gaps in current technologies.  Essentially, we do a security gap analysis to see what solutions/technologies they are missing, as well and how we can optimize their existing installed solutions. Once the gaps are identified, we can start helping the client find solutions to fill the voids.

After The Dust Settles:

By now, we should have things at least contained and most of the issues have been resolved.  At this point, Accuvant highly recommends going back to step one, user security awareness training,  updating your existing program to include these latest examples and refreshing your users on their responsibilities to helping you keep your environment secure.

Unfortunately, the events that were discussed in the WSJ are ongoing. There is no silver bullet to stop stuff like this from happening, so the best solution is mitigation, prevention and awareness training. Companies need to understand their risk landscape and take steps to appropriately address those risks before they get compromised.

Jim Broome
Director – Accuvant LABS

Tags: awarness training, botnets, information security, malware, risk mitigation

The latest Oracle vulnerability announcement at the Black Hat DC 2010 conference by security researcher, David Litchfield of NGS Software, could possibly prove troublesome for Oracle 11g users.

The potential impact of this set of vulnerabilities could be devastating to an enterprise that has sensitive data contained in databases, and allows low level privileged users access through a local or networked database session. To effectively exploit the vulnerabilities, the attackers will require some degree of SQL knowledge, but this knowledge should be relatively trivial to gain considering the Black Hat presentation currently available in the public domain.

The crux of the issues stem from the fact that Oracle seems to be in the business of enabling hackers instead of enabling business. Oracle provides the locked and loaded gun to would-be attackers in the form of the Oracle Data Pump maintenance and the Java virtual machine environment called Aurora.

To help their users with an upgrade, Oracle provides a suite of tools called the Oracle Data Pump which is installed by default. Contained within this tool is a package called DBMS_JVM_EXP_PERMS, which enables administrators to export permissions and to import them using a database procedure in that tool called IMPORT_JVM_PERMS. The procedure IMPORT_JVM_PERMS within the DBMS_JVM_EXP_PERMS package enables the administrator to provide it a list of permissions and update the Java policy table, where the security permissions for certain java actions are stored.

In order to allow Java code to read, write or execute files on the underlying server operating system, this Java policy table must have an entry.

Experienced security practitioners can already see the hand-writing form on the wall.

Oracle, as it should, does not give local users privileges to do read, write or execute files on the OS. However, there’s always a “however” in security, Oracle does allow by default ‘public’ role users to execute the DBMS_JVM_EXP_PERMS package.

What does this mean? This tool, provided by Oracle and installed by default with local user execute privileges, gives potential malicious users the ability to also perform the package procedure of IMPORT_JVM_PERMS and provide their own permissions to update the java policy table.

Mr. Litchfield continued to demonstrate how, by exploiting another Oracle provided Java class contained within Aurora, an attacker could eventually own the underlying OS to the extent of even creating his own user and granting them Administrator status on the server using the Oracle tool DBMS_JAVA.SET_OUTPUT_TO_JAVA.

DBMS_JAVA.SET_OUTPUT_TO_JAVA will redirect Java output to another java session. Per the specification for the SET_OUTPUT_TO_JAVA function, allows it to execute SQL when it receives the output. But Oracle, by default, has set DBMS_JAVA.SET_OUTPUT_TO_JAVA to execute with SYS user privileges, because the SYS user owns this package.

From this point it is just a matter of crafting a proper SQL query gives the package something to execute when the output is directed to another java session. The attacker then creates a query that causes Java to be output, which will in turn execute the SQL code that escalates the user to any role they wish, such as the ‘dba’ role.

It is recommended that all enterprises using Oracle 11g immediately remove the Data Pump tool packages mentioned, or change the permissions of the packages.

Additionally, this continues to underscore that an enterprise should consider an out of band DB monitoring solution, as once an attacker gains access to a database as the ‘dba’ role, you can no longer trust any logs that are output, or stored by the database server. Proper oversight will require an out of band solution that has complete visibility to view all database user network sessions.

–Steve Richards, Accuvant

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.

Today, during the 2009 BlackHat conference in Las Vegas, Accuvant officially announced the addition of a research and development division to its security assessment practice, which is now called Accuvant Labs. This is significant for several reasons. First, security research experts Alex Wheeler and Ryan Smith, who most recently were recently credited with discovering Microsoft’s ActiveX bug – CVE-2008-0015 and MS09-032, as well as a multitude of other vulnerabilities over the years, have joined the team.  Wheeler has worked for TippingPoint and ISS’ X-Force, and has twice served as a security researcher on the client side. Smith has worked for iDefense, ISS’ X-Force and Neohapsis, and has worked on the client side as a vulnerability assessment engineer for Allstate. These guys are among the best in the industry and we’re very excited to have them on board. In fact, both Wheeler and Smith won “Pwnie” awards for “Best Server Side Bug” in 2008 for their Windows IGMP kernel vuln (CVE-2007-0069) and are nominated again in 2009. We’ll find out around 7 pm on July 29^th at the BlackHat reception if these two dudes have done it again!  I also plan to check out Smith’s presentation on Wednesday the 29^th. He’s dropping a talk with Dave Dewey and Mark Dowd that I have had some early preview of and relates to some of the ActiveX stuff that has been getting some recent publicity. In fact, I had to do a bit of research to fully comprehend one of the demo’s I watched, so I learned something new already. J If I know those guys, it should be a solid session.

As we all know, research and development is critical to being able to proactively address security threats within the organization.  While we have been providing some of the best assessments in the industry for many years now, the addition of the researchers to the team augments our capabilities in a variety of ways, including being able to leverage 0-day attacks during our engagements, developing unique and useful tools, providing more depth with regards to binary analysis and software security testing, keeping our customers abreast of the latest threats (possibly even before their IDS and AV vendors catch up) and advancing research within the security community.

This evolution of the team is a somewhat unique situation for a group like ours. While our customers are paying for great consulting and documentation, that process has to be backed up by deep technical capabilities – and not just from the perspective of proficiency with security testing tools, enumeration and exploitation procedures – but capabilities that demonstrate industry leading expertise, such as identifying vulnerabilities that nobody else has yet found. Interestingly enough, the majority of clients out there aren’t paying for us to go in and identify 0-day type issues. However, it is this credibility that frequently brings a team like our Labs division to the table and enables us to establish differentiators for our assessment team.

What has made Accuvant’s assessments successful over the past seven years is outstanding consulting, bottom line. The addition of an R&D division to Accuvant Labs results in the apex of service.  For example, we have always had capable resources, but never spent a ton of time working on vuln research, tool development, etc. like many similar organizations pursue because we were solely focused on consulting. And, while these resources that may be outstanding consultants, they aren’t necessarily the same folks you want to plop down and have RE some random binary. Conversely, we have learned through experience that individuals who are extremely technically proficient at finding bugs or writing exploits may not be the best at nurturing customer relationships, i.e. being responsive, communicative, meeting deadlines or writing good documentation. As such, the addition of the R&D group within the Labs services practice allows us to stand alone as a consulting group that can bridge the gap between elite research and premium consulting. We are pursuing a model where our resources work on what they do best – researchers focusing on research, consultants focusing on consulting – with both groups working collaboratively within the same team so that their specific strengths can complement the other. I believe this model not only meets the needs of the CIO/CISO but confirms our continually building expertise and credibility to appeal to the engineers and administrators in the enterprise.

Needless to say, we are looking forward to the contributions from Wheeler and Smith and to continuing to provide best-in-class assessment services to our clients. If you are out here at BlackHat, we got a grip of the Labs consultants and Accuvant sales folks out here, so please swing by our booth and say hi and if we have any left – grab an invite for our party at Pure for Thursday night.

Over my 10 plus years of security consulting I’ve seen hundreds of different security programs in place, at a variety of different companies, in various industries. Some appear to be very successful, while others…well lets just say at least people are employed – especially in the recession that we are in right now. One thing that I do know though is that a solid security program encompasses three fundamental aspects – upper management support, solid security policies, and user buy in. If one or more of these are missing then the security program is ad hoc at best. So how do you achieve all three and create a solid security program? Let me try to break it down.

1. Security Education / User Awareness – First you have to create awareness and the need for security within the organization. One of the best ways to open the eyes of the company employees is through a risk assessment and/or business impact analysis. Get everyone thinking the “what if” scenario and what it could mean for the company if a breach were to occur. What assets are of value in the company? What information is of value to the company? Get everyone on-board with you and create that need within the organization.
2. Upper Management Support – now that you’ve got the attention of everyone and focused on the need for security, it’s time to get upper management to buy off on the need for security within the organization. If step one was done successfully, this shouldn’t be a problem. In fact, upper management might be coming to you to ask what needs to be done to prevent such events. With the full support from upper management on your side it’s time to move on to the next step.
3. Solid Policies, Procedures, Guidelines and User Buy-In – This is the area that I most often see as the fault in an organizations security program. Typically, upper management supports the project and then the security group forms a bunch of security policies and guidelines and then pushes them out to the company to follow. While the policies and guidelines may be very well written and follow best practices, one key element was left out – the actual users involvement in creating the policies and guidelines. No one like rules and restrictions pushed upon them, and if they are, they tend to not follow them or resent them. Getting the users involved in the process of creating policies, procedures and guidelines will go a long way in implementing a successful security program.

This brings me to a good point, a successful security program is not run like a dictatorship but rather like a partnership. A single team, all fighting for a common cause. All too often I see it run the other way around and the security department ends up being looked at as the enemy within the organization. Now part of this centers around user awareness and education, but a majority of it is due to the way the security department presents itself within the organization. Boy do I have some good stories to tell around this, but those will have to wait for anther time! My point is, going back to the beginning of this post, in order to have a successful security program within an organization everyone has to be involved and support it. Remember, if you’re missing just one of the 3 main parts mentioned above, then the security program will be ad-hoc at best.

Now on to the more technical needs:

1. Patch Management Program/Process – While this can be done manually, I found that using an automated solution works best and is the most successful at seeing that systems and applications stay current on patching. I recommend looking for a solution(s) that can do the following:
   1. Can inventory all applications on a system be it a Windows or a UNIX variant. Choose something that supports all systems running within your environment.
   2. Has the ability to notify you of not only new patches that need to be install but also on the success and failure of patch installation.
   3. Can produce reports on not only patching success and failure but also on virus DAT file status, services and patch levels they are running at, and systems that are out of compliance.

   Systems out of compliance – One really cool features that I’ve seen in some of the patch management solutions out on the market today is the ability to also handle configuration management. This is an awesome value add and something that I’d highly recommend looking into.

   Finally, for those applications that aren’t supported by the automated solution, a manual process needs to be put into place to keep tabs on 3rd party applications running within the environment to make sure they are kept current on patching.

1. Vulnerability Management Program/Process – As I mentioned in a previous post, Most Common Internal Vulnerabilities Found, while having a general network vulnerability scanner in place is a must, it’s not the end all solution for a good vulnerability management program. Putting together a solid vulnerability management program requires the following:
   1. Application Vulnerability Scanner – You’re probably wondering why I’ve listed an application scanner first before a network scanner, simple fact, from an external perspective, the attacks now in days are at the application level and less from the network and service level. While network vulnerability scanners have come a long way over the past couple of years, they still aren’t as good as an application specific/focused scanner in my opinion. An application based scanner is a must now in days for any security program. Also the security group doesn’t have to bear all the cost for the scanner either. I you have in-house development of applications then the cost should really be taken on by that department as they should be scanning/testing their applications before deployment as part of they SDLC process.
   2. Network Vulnerability Scanner – Features to consider include: frequent and timely updates, good reporting (both per scan and trending), built in remediation tracking, ability to do authenticated scanning of all systems/devices within your organization, and scheduling features that will work within your organization.
   3. Service Specific Tools/Scripts – See the post Most Common Internal Vulnerabilities Found for more insight.
   4. Wireless Scanner – Yes, even though you may not allow wireless within your network, and you have policies against its deployment, you should still be sweeping/scanning all of your facilities on a regular basis for rogue access points and clients hunting for wireless networks to attach to. Not only is this good practice, but if you fall under PCI, it’s a requirement!
   5. 3rd Party Assessments – No this is not a pitch to sell our services but rather a part of the process. You always need a second set of eyes on things to make sure you haven’t overlooked anything.
2. Monitoring Process/Solution(s) – Monitoring is a monster in and of itself. Unfortunately, and I could be wrong, there is no one solution that can do it all for you. Areas that need to be monitored will include: systems and application logs, network and application threat traffic, anomaly traffic, network and device usage and network load to name a few. Basically, the security group needs to be aware of all activities happening within and directed to the network in order to defend against potential threats. When evaluating solutions it is also important to be aware of secure protocols that are being used within your environment (like SSL) and if the solution is able to decrypt this traffic to monitor it for suspicious activity. Equally important is to monitor for anomalous traffic. Remember, the attacker has all the time in the world on their side. They’re not going to just blast you with threat traffic but rather take their time poking around looking for that one in that will get them what they want.

Side note – At a previous company that I worked at years ago, we found ourselves paying more attention to the anomalous traffic as we could slowly see trends of potential attackers casing the network looking for that one way in. Back then we were using SANS’ Shadow application and white-listing all known good traffic to spot only the interesting anomalous traffic. Over time you’d start to see the attacker start to focus on one machine at which point we’d block the IP.

3. Security Education / User Awareness – We’ve now come full circle. Actually, security education and user awareness training should be ongoing from the start. Formal training should be given to all employees (ALL EMPLOYEES) at least once a year. New hires and contractors should also be required to take a security awareness training class before even ever connecting, or getting access to, the network and/or systems or devices. Aside from the once a year formal training class, user awareness should be an ongoing process throughout the year. Things like posters and weekly or monthly security newsletters should be an ongoing training method within the organization. Another successful awareness method is to reward the good through things like gift certificates or awards to those that are showing security awareness throughout their normal work activities. The point is to make security awareness training not only ongoing but also fun.

This has been a high-level overview of how to create a successful security program within an organization. It’s not complete by any means. There are several areas that I could spend all day (or several days) talking about but it is the basis for a good security program that I’ve seen in all of my years doing consulting. Remember, if you don’t have upper management support, solid security policies, and user buy-in, then the security program within your organization will be ad-hoc at best. All three are needed in order for the program to be successful.

-Kirk Greene

I thought that I take a quick moment to answer an ongoing comment/question that always seems to come up at the various client’s that I assess, “We have a solid vulnerability management program that includes an automated system patching process and a top rated vulnerability scanner, how in the hell are you still breaking into our boxes?” Well the answer is really easy; you can patch OSes all you want and scan your network with just about any general vulnerability scanner but you’ve left out one very important step – password policy enforcement beyond just domain accounts. Yes sometimes it’s insecure builds and 3rd party application patching that gives up the information that is helpful to exploit the box, but when I step back and think about it, it always comes back to the passwords.

Below is an overview of the top most common ways I generally find to get in:

• Blank/Weak MS SQL “sa” Account Passwords - Yep, number one way still I typically get in. What’s funny is that lately it’s either a security database that houses proximity card access rights or the companies Blackberry Enterprise Server. Believe it or not, most of your commercial and open source general vulnerability scanners only check for a couple of passwords for this account – typically only a blank password, but I’ve seen some that actually will also check for “sa” and “password” as the account password. As you all may or may not know, give me “sa” access to your MS SQL database and I own the box. Using the same administrator password on all of your servers? Well, I now own them as well! So what do I use to find this common hole, SQLLHF (thanks Matt Wagenknecht!!) with a dictionary file of about only 10 common passwords – does the trick almost every time.
• No Password Assigned on the Oracle TNS Listener Service - When I see an Oracle service running in an environment I start foaming at the mouth. Why you ask? Because 9 times out of 10, if no password is assigned to the listener service, I know I’ll find a default Oracle account. Also I know that if I can’t take over the host OS with that account I’m bound to find some really juicy data being stored in the database that makes taking over the host OS look like peanuts.

Side Note – The most common default Oracle account found is DBSNMP. Why is that? Because just changing the password for this account within the database breaks the Intelligent Agent service if you don’t also change the password in the snmp_rw.ora file. DBA’s will often change the account in the database, see that the Intelligent service stopped working, and then just change it back thinking that since the account isn’t a really privileged account so what’s the harm. Well reality is that this account has just the right amount of privileges to compromise not only the database but also sometimes the host OS itself. No account within an Oracle database is safe to leave with the default password assigned – even the SCOTT account!

• Cached Credentials – By default, Windows stores the last 10 accounts that logged into a system in cache. While cracking these passwords can take some time, it’s generally worth the extra time and effort as typically they are domain admin accounts that will give me the keys to the kingdom. So you might be saying, “OK, well in order to get cached credentials you’d have to be an admin on the box. That means a weak password for an admin account exists and we should have seen that during our scanning and addressed it.” Well, yes and no. How often are you scanning your workstations and mobile devices? It’s funny how when you give users local admin rights to their workstations, or most commonly laptops, how the local accounts (or the local Admin account) have a blank or the username same as the password. All it takes is one bad apple to bring down the entire tree:-)
• Weak/Default Password on Networked Appliances and/or Networking Devices - While this doesn’t directly lead to a compromise of the environment it can be just as damaging. I can’t tell you how many times I’ve run across things like default accounts on an HVAC control system for a datacenter or a central console device to manage networking gear (Often companies don’t put passwords on console access to networking devices because you have to physically be at the console – right?). Wrong! Nowadays administrators try to stay out of the datacenter as much as possible and do everything remotely. Who wants to sit in a freezing room for hours on end when you can remote into the device from the comforts of your office.

Well those are the top things that I typically run across that ruin the day for the client but make it a successful engagement for me:-) The one finding that I stress in just about every report, and also to the client throughout the engagement, is you have to expand your password policy to anything that requires or can be assigned a password – anything! Then you have to educate users on the need for good password usage. If you don’t, then there will always be a way to get in. You can scan all you want and patch systems until you’re blue in the face, but if you don’t use good passwords, you’re just opening the door for an attacker to walk right in.

To enhance your vulnerability management program, I recommend the following tools be added to your arsenal. Without them you could be leaving a door open for an attacker.

• Oscanner – Oracle scanner that tests for default Oracle accounts and passwords
• SQLLHF – MS SQL scanner that allows for dictionary attacks against the “sa” account

Aside from the tools listed above, I’d also recommend updating your system configuration policies and setting the following registry key to 0:

HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsNTCurrent VersionWinlogon CachedLogonsCount

Finally, investigate all web services identified by your scanners – especially those running in the 8000 range as some of these remote web management services can either be disruptive to the system/device or lead to a direct compromise of the system/device itself. Disable them, or at a bare minimum, change the default password and ensure that they are up to date (of the current release). By making these simple enhancements/changes, the next time I come in for an assessment, you’ll stop me dead in my tracks…Or at least make me work a little harder

-Kirk Greene

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.