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.

So the week before last Neel Mehta of Google, Alex Wheeler of TippingPoint, Dave Bonvillain of Accuvant, and myself made our way to Amsterdam to speak at Blackhat Europe. The topic of our talk was ‘Cutting thru the Hype: An Analysis of Application Security Testing Methodologies’ (Dave’s name)… we were going to speak about all the different types of testing methodologies, their strengths and weaknesses, and build a matrix to help people decide what methodology to use. So Alex, Dave, and yours truly were sitting around a couple weekends before the talk trying to figure out what factors need to be ranked in order to properly define a risk of an application, and establish the most appropriate testing methodology… well after 2 or 3 hours, we had 20 some-odd criteria, not really the easiest thing to build a matrix around. So that didn’t look like it would be ready in time for the conf, so we agreed that we would be an online web-form after Blackhat where people could go, fill out the prompted questions and get a response… that’s still coming, I wouldn’t hold my breath though it’s going to take us a while to figure out how to make that work. So we needed some ‘zazz’ for the talk, as I hope many of you know both Neel and Alex are some of the best researchers in the world of infosec, so easy enough, we can drop a huge 0day, easy enough. I talked with Jeff Moss and let him know what we were planning on doing; he was excited Neel has a bug that has a pretty large impact footprint, so we were going to drop that. The only problem… disclosure… patches… time… not on our side… Here it is 2 weeks after the conference and the bug still hasn’t cleared disclosure, hopefully it will soon, and when it does you can read about it here. Other than that the trip was great…

-Jon Miller

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