nCircle VERT Blog: September 2011 Archives

Just a quickie here.

I was playing around with my wireless settings yesterday (see my previous post) and discovered an interesting difference between Windows 7 and OS X 10.6. A difference that increased the respect I have for some of the security changes Microsoft is making. As a side note, I had the same result with my iPad and iPhone that I had with OS X but I'll stick with just laptops for now.

So I changed from WPA2+AES to WPA+TKIP to test my ISPs theory that my router couldn't handle the encryption load. Both Windows 7 laptops in the house refused to connect, stating that the settings had changed and I was required to remove the wireless network and add it again. OS X, however, was happy to simply reconnect to a network with changed security settings without giving it a second thought.

So kudos to Microsoft for the little bit of forethought that went into that implementation.

As part of my pursuit of a diploma in Computer Systems Technology, I am required to carry out several internships in between semesters of Classroom study. I have been lucky enough to secure an internship with nCircle's Vulnerability and Exposure Research Team (VERT), which is based in Toronto, Canada.

Lucky because doing an internship at nCircle brings my understanding of the computer world in general to an entirely new level, let alone the security aspect of it. Although the majority of in-class lessons that I have sat through mainly focused on networking protocols and Cisco hardware, it is really just a basic foundation on which to build an understanding of the things that really matter in the InfoSec world. Having the base knowledge of these protocols only gives me a glimpse into how everything works together. Different Operating Systems and Applications utilize these protocols in their own ways to communicate with each other in the modern network. This is where my experience at nCircle comes into play.

In no way do I want to discredit the education that I am currently receiving from my post-secondary institution, however there are definitely things that could be added to the curriculum. As an example, I will note some of the different Operating Systems in use today. There are variations of Unix based systems, Apple's systems, and of course the different products offered by Microsoft to mention a few. Most of these Operating Systems won't be touched in the majority (if not all) of computer courses being offered by post-secondary institutions.

I fully credit nCircle as the reason that my eyes are beginning to open to the world of InfoSec and the many different things it has to offer. It's like being in a never ending chase... you may edge closer and fall further behind, but you will never catch up. The wonderful part of working at nCircle is the continuous learning experience as one task might include Oracle databases on Solaris machines, followed by one which involves MAC OS X with some random applications thrown in between the major tasks. Network security isn't specific to one brand or product line. It involves everything and anything, not to mention the constant influx of new technology that guarantees the need for regular improvement of one's knowledge and skill set.

Although my experience thus far with VERT is relatively short, it is long enough to understand that Network Security goes beyond a 9 to 5 job and becomes a way of life.

Recently I had a chance to work on an issue related to an older TLS Renegotiation issue , and realized that I didn't understand that issue as well as I thought I had in past.

I used to use following command to test whether a target is vulnerable for this issue:

#openssl s_client -connect 192.168.2.111:443

After the SSL channel is established, simply type 'R' to renegotiate. If the channel is still on, a conclusion of 'target is vulnerable' will be made. Apparently, this method isn't that correct without deeper inspection.

The reason is that this vulnerability is a protocol bug rather than an implementation problem. So, when this bug was discovered and discussed, the only solution vendors had was to disable renegotiation in TLS, like OpenSSL 0.9.8l does. However, Sometime after the release date RFC 5746 was developed to polish TLS renegotiation protocol.

http://tools.ietf.org/html/rfc5746

In this modification, secure renegotiation protocol is implemented. The major reason for the previous design is the fact that the old handshake (before renegotiation) and new handshake
(after renegotiation) are distinct. So when the client initiates a handshake to the server, it doesn't have method to determine if this is a new handshake or a fake renegotiation from an attacker, which allows the attacker to MITM the connection and inject traffic.

With the secured renegotiation protocol, RenegotiationInfo is created. This structure may include client_verify_data or server_verify_data to bind the two handshakes. Here is how it works:

When a new connect is established, the server will include an empty RenegotiationInfo to client, to tell that this is a new handshake. If it is not empty, it is implied that this is renegotiation handshake. Also, the client verify the RenegotiationInfo content. If the client_verify_data or server_verify_data wasn't its own, it will sent alert and drop the channel.

For more details, the above RFC link is a pretty good resource. Let's go back the old method I used for this issue. It will still works well if you do more inspection in the process. Still use same command:

#openssl s_client -connect 192.168.2.111:443

You may notice that right after the CIPHER info line there is a line that indicates whether the target has secure renegotiation or not:

CIPHER is DHE-RSA-AES256-SHA
Secure Renegotiation IS supported

This line indicates that the server already implements the protocol in RFC 5746, and is not vulnerable to this bug, even typing 'R' will not cause it shutdown.

Microsoft’s MS11-074 advisory has been out for a couple weeks now and I just wanted to post some thoughts on it. First off it was a particularly large advisory featuring many applications:

• Microsoft Office 2007 Groove
• Microsoft SharePoint Workspace 2010
• Microsoft SharePoint Foundation 2010
• Microsoft SharePoint Services 2.0
• Microsoft SharePoint Services 3.0
• Microsoft SharePoint Server 2007
• Microsoft SharePoint Server 2010
• Microsoft Groove Server 2007
• Microsoft Groove Server 2010
• Microsoft Office Forms Server 2007
• Microsoft Office 2010 WebApps

For administrators this is quite a list of patches to apply if running these applications on their network. In addition to the larger than usual application list for a single advisory, Microsoft has covered SharePoint Server 2007/2010 in an unusual way this time.

Overall there are a total of six vulnerabilities addressed by MS11-074; five of which affect SharePoint Server at various versions. The unusual thing about this advisory was that Microsoft patched SharePoint by individual server component instead of one patch to address the vulnerabilities. Regardless of the reason for this I see it presenting an issue to administrators who have to prioritize the patches they apply especially if they are required to apply those that are critical first. In this case they were all rated important so it may not have been such an issue however I disagree with Microsoft failing to provide a mapping in in MS11-074 for which patch corrects which vulnerability.

To illustrate the details:

Microsoft Application	# of Vulnerabilities	# of Patches
Microsoft SharePoint Server 2007 (x86)	2	4
Microsoft SharePoint Server 2007 (x64)	2	4
Microsoft SharePoint Server 2010	5	7

As it stands, an administrator would have to apply all of these vulnerabilities in order to ensure a patched state not knowing if any subset of patches will correct a particular vulnerability. Now I just want to say I am not at all trying to advocate minimum patching practices here as I can already hear a rebuttal to this post in my head “Who cares which patch fixes which vulnerability just apply them all”; While I can understand that line of thinking I wanted to point out that on large networks prioritizing the distribution of patches is a reality and the presentation of MS11-074 makes it difficult for administrators to do this.

When Technical Support Dweebs Attack

I have quite the large collection of devices on my home network, as I'm sure most tech geeks do. This includes: Computers (5), Kobo eReaders (2), iPads (2), AppleTV, PS3, XBox360, Wii, Apple TV, iPhone, Blackberry and a Partridge in a Pear Tree. Well, maybe not a patridge in a pear tree, but you get the point... a number of these devices are enabled at any given time.

So that's the background on my network, now for the story.

I recently experienced an internet outage at home. This wasn't a single occurance but occured 10-15 times in the course of a day. I'd spoken to my ISP a couple of days prior about a single instance but that issue seemed to have gone away. Today's call resulted in the identification of the problem, there are line issues in my area and a technician will be coming by to investigate further.

This verdict was reached after only three phone calls which involved speaking with four "technicians". I hesitate to use the word "technician", so we'll stick with dweeb. In particular, I want to discuss Dweeb #1, the first Dweeb I spoke with.

This guy actually started reading to me from his script, not the portions that he was supposed to ask me, but the entire script, "OK, now it says that I should get you to test your browser." and "It says here that you are required to reboot your router before we proceed, should we try that now?"

Now keep in mind, before I share my favourite tidbit of technical advice, that my issue is an internet outage, something I feel I'm more than qualified to identify, that affected both wired and wireless connections. My internet service and my IPTV service were both affected at various points.

So at this point I'm half asleep, doing other things, and listening to the dweeb read off his script. I throw in the occasional 'yep' or 'ok', but otherwise I'm in la-la land. That is... until he reads the next portion of his script, "OK Sir, it sounds like it's probably the security settings, we'll need to change them."

I use WPA2+AES on my network, I have for the last year that I've had this service, and no one has ever told me that my wireless settings might be an issue on previous calls. I asked him to repeat himself and he indicated that I needed to "lower my security". Apparently I have two many devices on my network which causes "too much security to occur", so if I "switch to a lower security setting, less security will happen." I can only assume that in some instances, security means encryption but I'll never know for sure.

He suggested we start lowering my security settings, first to WPA and then lower if necessary and I couldn't help but laugh. I've never before had tech support tell me I had to make myself less secure, but that's what this guy was doing. I allowed him to test WPA+TKIP and then afterward moved myself back up to WPA2+AES but what if I wasn't a tech geek?

If this is standard practice for ISPs dealing with wireless issues, then we have a serious problem. ISP routers are finally shipping with something more secure than WEP enabled by default, but tech support could potentially reintroduce this insecure setting. That's a scary thought! Support organizations for these ISPs are reducing security instead of pushing to improve security.

I don't have an answer, but I still have to ask the question... What do we do when tech support dweebs attack?

Large enterprises have issues maintaining or patching their systems on a consistent basis. There are many reasons for this occurrence. When attempting to patch applications that the business relies on to function, the applications cannot be interrupted for any long period of time. Applications in large scale enterprises sometimes have the need to use specific versions of software, which can sometimes include legacy 16-bit applications, to interact and run. This can cause massive application conflicts. Example: Application A needs to use Java Version 1.5 but they also need to use Application B which uses Java Version 1.3. When a Java update is released then there will be multiple issues created. The system is now vulnerable because of exploitable software present on their system and the application will now crash because of reliance on that specific version of Java. When a new release of an application comes out, example: version 1.00 to 1.50, it can take months of testing and deployment to release that application on a large scale basis, this is because of application conflicts and possible disturbance to the business function. With the ability to use virtual applications we are ensuring that the host OS is kept up to date with latest security patch’s while maintaining business functionally.

This is possible by using virtual applications that use sandbox technology, by creating a virtual file system and registry for the user. The end user is now able run multiple versions of any application without conflicts. You are also able to make a small virtual application that can package 16-bit and 32-bit.This makes patching your virtual application easy. Software is being separated into component/packages that are bundled into single virtual executable, Example: Internet Explorer and Java being a separate package that you can individually update then recompile. This decreases time when you are dealing with large applications that take time to build. Large scale environments can now have a very quick turn around when an update is released. This decreases man-hours in terms of deployment: overnight delivery of patched applications to thousands of users, no additional issues created when deploying.

So the host OS can be patched immediately when released without application conflict arising and no interruption to the business function, which is the main goal to maintain. The virtual applications are locked down from the local host OS this will help system administrators update vulnerable systems faster and more efficiently. At a previous employer we used VMware ThinApp it is a clientless virtual application that met almost off our needs and were very impressed by the results. Ultimately the end goal is to remove all vulnerable software from a system but this allows for isolation of vulnerable software’s attack surface which is a cost effective mitigating factor against an ongoing battle.

Last week I discussed how to use IP360 reporting filters to exclude or include a list of IP addresses when generating a report. This week I am going to show you how to create a report consisting of only hosts with a specific operating system class. For example, let's walk through the process for creating a report filter that generates a report of only Windows hosts.

First, navigate to 'Analyze -> Reporting Filters' and click 'New' to create a new reporting filter. Give your filter a name such as "Windows Hosts Only" and proceed to the 'OS Groups' tab. Next, select the 'Include' action and double-click 'nCircle: Windows' from the available list. The selection will move over into the selected box. You can now click 'Add', and the filtering rule will appear below. Now that you have completed the filter, click 'Submit' to save.



Now that your filter is complete, you can apply it to any report you are generating to restrict the hosts in the report to Windows boxes only.

If you wish to create your own OS Group, or modify existing ones, you can navigate to 'Analyze -> OS Groups' and either click on 'New' or select an existing filter to view it. In existing filters such as 'nCircle: Windows' you see the operating system tree for Windows is a different colour than the other operating systems in the list, as these are the ones currently selected. Selecting a parent will create a group that includes all of that parent's children.

Recently many web owners are concerned with the new published Apache DoS issue(CVE-2011-3192), which can be triggered when the vulnerable code handles HTTP requests with malicious 'Range' headers. Today I would like to talk a little bit of it as well as the detection of your installation.

This bug exists in a function called ap_byterange_filter in byterange_filter.c. When an HTTP request with Range header is sent to an Apache server, the function ap_byterange_filter will decide how many range values the request has by detecting character ',' in the value field:

...
if (!ap_strchr_c(range, ',')) {
/* a single range */
num_ranges = 1;
}
else {
/* a multiple range */
num_ranges = 2;
}
...

Later, if the number of range values is bigger than 1, the function will create bucket pool for the request:

...
if (ctx->num_ranges == 1) {
...
}
else {
char *ts;

e = apr_bucket_pool_create(ctx->bound_head, strlen(ctx->bound_head), r->pool, c->bucket_alloc);
...

It has been proved that if a lot of HTTP requests with multiple values set in Range header will consume huge amount of CPU and memory of the target.

If you have an affected version of Apache installed you may wonder whether it is vulnerable or not based on your configuration. To tell that, there is a very simple method which is actually from the published exploit for this bug. In its code, it simple sends following request to the target server:

GET / HTTP/1.1
Host: Localhost
Range: bytes=0-
Connection: Close

If the target responses with 'HTTP/1.1 206 Partial Content', then it is vulnerable to this bug. After walking through all the source code of Apache HTTPD server, I found that the vulnerable function, ap_byterange_filter , is the only one which uses 'HTTP_PARTIAL_CONTENT' response. That means this detection of method is pretty accurate to tell whether an affected version of installation is vulnerable or not.

Note: all the source code pieces are copied from the last vulnerable version of Apache, 2.2.19.

Today I will be talking a bit about a specific subset of the report filtering
functionality of IP360. If you are like me, you often need to create a report
containing, or excluding a specific list of IP addresses. This is where the
'Fine Tune' tab in the report filter section of IP360 comes in handy. I will
walk through the process for creating and using a report filter to serve this
purpose.

Begin by navigating to 'Analyze -> Reporting Filters' in the IP360 interface
and clicking on 'New'. Give a logical name to your filter such as
"Excluding/Including IP List" and then continue to the 'Fine Tune' tab. You
will be presented with several drop-down boxes. From the 'Attribute' box,
select 'IP/IP Range' and change the 'Action' to 'Include' or 'Exclude' based
on the desired result. Next, enter your IP Address or range in the text box
and click 'Add'.

Below is a screenshot of a reporting filter I have set up to exclude a list of
hosts from my report.



After saving your reporting filter, begin generating a report of your choosing.
When configuring options for report generation, the second step, 'Select a
Reporting Filter', will allow you to apply the reporting filter you just created.
Double-click your filter to move it into the 'Selected' section as illustrated below.
Click the 'View' button to generate your report with the selected filter applied.



Now that you've seen how reporting filters can save you time and simplify reporting,
it's time to really make use of them. Next week, we'll take a more in-depth look at
some of the additional functionality offered by reporting filters.