In the old days, when Web 1.0 was all the rage, a website developer or administrator published all the content for end users to read. Things were relatively safe as long as certain protection mechanisms were in place. But, life has become more complicated in recent years with the launch and subsequent popularity of Web 2.0. This new age of collaboration introduced a fun and innovative way for end users to communicate via social media sites such as FaceBook, Twitter, MySpace and many many others.  However, because social media sites pull content from multiple sites and servers, Web 2.0 has made it significantly more complicated for you to truly secure your users’ browsers.

Trust is really at the root of the problem.  Social networking sites give users an inherent sense of trust that they shouldn’t have. And, unfortunately that trust opens the door wide open for a variety of new attack vectors. If you don’t have the right policies and solutions in place, there’s a pretty good chance that sooner or later the bad guys are going to use social media to access your corporate data.

How will they do it? There are a few different strategies we’re seeing. 

1. In some instances, criminals are creating malicious websites (or infecting legit sites due to their own vulnerabilities) that have malware installed and are redirecting users in various ways to those sites. Once a user goes to the malicious site, their system becomes infected with this malware.  At this point, the attacker is purely limited by their imagination on what could happen next.  Most commonly, the malware starts harvesting information from your user’s system, such as their passwords or corporate information.  The malware then attempts to either stream this information back to a predetermined host controlled by the attacker, or utilizes a batch process to email or funnel this information out to the attacker.
2. As of late, spear phishing is the attack strategy of choice. With this method, criminals gather information about your employees from social networking sites. 

This brings up another common oversight or gap in many organizations current information security policies.  As an example, should your employees be allowed to disclose that they work for you?  How about the division of the company they work in?  How about what project or program they are working on?   All of this type of information can be used in a spear phishing attack. 

Once the attacker has gathered enough information about their intended target, they start sending personal emails to your end users to gain their trust, and then direct them to websites or applications to install, which facilitates the malware infection. Cross-domain attacks are also common. This strategy influences users to click on links they normally wouldn’t have because of their newly assumed trust level with the attacker’s bogus company or request.  Once infected, again, it’s up to the attacker’s imagination at this point on what they wish to do with their new victim.  

There are a number of things you can do to protect your company and mitigate the threats:

• Implement an IT security program with sound policies – Adopt or update your existing Acceptable Internet Usage policy to inform your employees on what types of information they are allowed to post online about your company to reduce the possibility of spear phishing.
• Implement the right technologies – At this point, you should already have anti-malware/anti-virus software installed on every corporate computer to attempt to cover your end users. In addition to this, you should consider investing in data leak prevention solutions, to help enforce your corporate policies on what is acceptable content to post online or even be allowed to leave your network.
• Continually educate your employees – a lot of cybercrime relies on an end user’s lack of knowledge. Continually update and performed user awareness training sessions or “brown bag” events to teach your users the common threats they will face, as well as update them on the latest attacks being carried out.

 Jim Broome
Director – Accuvant LABS

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

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

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.