CERT/CC Blog

CNAME flux

2012-01-05T21:15:00Z

Hello this is Jonathan Spring. Recently, Leigh Metcalf and I uncovered some interesting results in our continuing work on properties of the Domain Name System (DNS). Our work involves an unconventional use of CNAME (canonical name) records. Besides an IP address, CNAME records are the only other location a domain may have in the DNS. Instead of an IP address, a CNAME record is a redirection or alias service that points to another name.

]]> CNAMEs should behave similarly to IP addresses in the DNS – relatively statically. IP addresses have shown departures from the expected consistency in the past. Several years ago, content distribution networks (CDNs) popularized a DNS usage that is known as IP flux. The IP address of resources is changed quickly in the DNS for geographic nearness, load balancing, and redirection in the case of failure. Malicious actors soon caught on, and implemented their own networks using IP flux.

Leigh and I have found that CNAME flux is also in practice to some degree. By using a source of passive public DNS resolutions we have found domains that change their CNAME destination multiple times a day. We consider a domain to be exhibiting flux if it changes destination 8 or more times in one day. For example, the following records of a domain exhibiting CNAME flux were observed on October 2, 2011.

rname	class	type	TTL	rdata
corn.best.stanford.edu	IN	CNAME	10	corn26.stanford.edu
corn.best.stanford.edu	IN	CNAME	10	corn02.stanford.edu
corn.best.stanford.edu	IN	CNAME	10	corn15.stanford.edu
corn.best.stanford.edu	IN	CNAME	10	corn10.stanford.edu
corn.best.stanford.edu	IN	CNAME	10	corn12.stanford.edu
corn.best.stanford.edu	IN	CNAME	10	corn19.stanford.edu
corn.best.stanford.edu	IN	CNAME	10	corn24.stanford.edu
corn.best.stanford.edu	IN	CNAME	10	corn23.stanford.edu

The CNAME here seems to be balancing the load on a particular service by redirecting users to the more available servers, given the naming scheme and short time to live (TTL) of 10 seconds. However, like CDNs, if benign actors gain benefit from a tactic then malicious actors are likely to be able to use the same tactic to their ends.

So far, the domains using CNAME flux amount to a small percentage of the CNAME records observed. There are around 16M domains in our data source that use CNAME records each day, and only 15-200 of those domains exhibit CNAME flux. We measured the incidence of CNAME flux between October 1 and November 30, 2011. The results are presented in this chart.

We can’t say whether or not the practice will become more widespread. But CNAME flux is yet another creative use of one of the few ubiquitous Internet protocols, and creative protocol use tends to cause headaches for security folks.

Challenges in Network Monitoring above the Enterprise

2011-09-23T14:06:00Z

Recently George Jones, Jonathan Spring, and I attended USENIX Security '11. We hosted an evening Birds of a Feather (BoF) session where we asked a question of some significance to our CERT^® Network Situational Awareness (NetSA) group:

Is Large-Scale Network Security Monitoring Still Worth Effort?

]]> One of the foundational principles behind most organizations' network security practices is still "defense in depth," which is implemented using a variety of security controls and monitoring at different locations in an organization's networks and systems. As part of a defense-in-depth strategy, it has become commonplace for organizations to build enterprise security operations centers (SOCs) that rely in part on monitoring the extremely large volumes of network traffic at the perimeter of their networks. There has been a recent trend toward increased investment in (and reliance on) network monitoring "above the enterprise" in order to simplify sensor deployments, decrease cost, and more easily centralize operations. At the same time, the idea of a well-defined defensible perimeter is being challenged by cloud computing, the insider threat, the so-called advanced persistent threat problem, and the prevalence of socially-engineered application-level attacks over network-based attacks. For an opinion piece about how things have changed, read Rik Farrow's article in the USENIX magazine ;login:.

The purpose of the BoF was to revisit some of the assumptions behind approaches to large-scale network monitoring at this level. We also wanted to lead a discussion about the challenges we face in monitoring, especially in light of these changes. We considered the following questions.

What problems do we confront when monitoring at the supra-enterprise level?

We discussed a number of challenges, many of which are the result of networks not being architected with "monitorability" as a priority. We also discussed the following factors:

Bandwidth
Encryption
Everything in HTTP[S]
NAT, proxies, tunneling
Carrier-grade NAT/IPv4 islands
Lack of knowledge of policy and assets
Legal restrictions

What data can we expect to remain unencrypted?

We can expect that as more and more traffic is encrypted, we'll still be able to see the following data that must remain unencrypted in order for an IP network to function properly:

IP headers (traffic summaries) - Packets have to be routed by the public infrastructure, which means that IP headers will remain unencrypted for the foreseeable future. This will enable various traffic analysis techniques. However, it's worth noting that tunnels (including IPv6) and anonymizing networks like Tor will affect what we see.
DNS queries and responses - While DNSSEC deployment will mean that DNS responses will be digitally signed, we can expect that the content will remain unencrypted. This will enable analysis that will support the identification of new malicious domains and the detection of the use of DNS by malware.
BGP and related routing protocols - Just as we can expect IP headers to remain unencrypted, we can expect BGP to remain in the clear.

In addition, there is other "global metadata" that can be combined with monitoring data and used for analysis. This metadata includes registration data (i.e., "whois" data), gTLD zone files, public certificates for certificate authorities, website reputation data, and RBL lists.

What can you still analyze at the supra-enterprise level?

Using traffic analysis techniques, we can see phenomena that appear as changes in traffic patterns. We identify these variations by developing indicators for the following:

Worms, DDoS, floods, large-scale scans
Trends
The scale and scope of global attacks (e.g., all banks, etc.)
Detection based on locality (e.g., identifying traffic from a particular country)

A literature search on intrusion detection using traffic analysis will identify a variety of papers. For example, there are a number of papers in RAID proceedings. Some examples can also be found in the FloCon^® proceedings, available at the CERT FloCon site.

Using a combination of traffic analysis, DNS, and (selective) content capture, we can develop heuristics that can function as indicators for the following:

Spear phishing, spammers and botnets
Malicious domains with DNS analysis (We have published a blog entry about this topic, and the USENIX Security proceedings also include a related paper.)

In general, analysis based on a broad view of network traffic remains invaluable as part of incident analysis. It provides a way to understand the traffic associated with a particular incident and to identify activity occurring elsewhere in the network that matches a particular pattern.

A broad view of DNS and our network's traffic also enables a whole class of analysis we might call "indicator expansion"-various ways in which we can take a single indicator of malicious activity, like a single IP on a watch list, and find additional IPs also associated with the malicious activity of interest. This expansion can be based on a behavioral detection algorithm; for example, heuristics for enumerating the IPs of all the bots in a botnet. We can also often expand our watch list by leveraging DNS or other global metadata to associate an IP with a DNS name or a real-world entity, and to then map that entity back to additional IP addresses that we can add to our watch list.

How are attacks changing?

One thing we can say for sure is that attacks are moving up the application stack. In addition to targeting ports, servers, and hosts, they now target applications like web browsers and PDF viewers, as well as users themselves. The goal is to be able to monitor the users and the assets they control. It's not entirely clear what we can rely on being visible at this level in the future.

There are several big questions that need to be answered in order to formulate a strategy for supra-enterprise monitoring:

What kind of selective content capture should we doing?
At what point do we need a different monitoring approach (on hosts, systems, etc.)?
How does the picture change at lower levels, (e.g. enterprise and below)?

What are some monitoring techniques that can still work?

During the BoF session, we discussed the following techniques:

Re-routing suspicious traffic to a place it can be monitored. This could include selective full-packet capture.
Leveraging routers and switches to generate traffic summaries (NetFlow/CFlowD, SFLow, etc.)
Intelligent sampling

What about "the cloud?"

We discussed how "the cloud" is a problem because we can no longer rely on being able to distinguish individual virtual host endpoints within a cloud infrastructure. This could be solved by ensuring that NAT does not happen before the monitoring point. One thought: assign IPv6 addresses to everything, no more NAT.
Will Google, Amazon, and other vendors invest in the infrastructure required to do monitoring? Should this come standard with hosting services?
Will cloud providers provide flow or monitoring data? Should this be standard practice? What about other monitoring options for your servers?
Monitoring requirements could be incorporated into providers' terms of services agreements.
What about cloud-to-cloud attacks? Could attackers provision E2C machines to attack users on that platform?

See part one and part two of the article "Monitoring Cloud Computing by Layer," written by one of our CERT NetSA colleagues, for a list what's needed to monitor "the cloud."

What about mobile?

We finished the session up with a brief discussion of mobile. We have the same endpoint issue as the cloud in a world of 3G devices. In the case of 4G, we can expect that it will be common to assign IPv6 addresses to the mobile device endpoints.

Final Thought

At the end of the session, one of the participants suggested ironically that as data moves to "the cloud" and users move to mobile devices using third-party networks, a larger percentage of the traffic that remains on corporate networks might actually be illegitimate, malicious, and otherwise unrelated to business purposes.

Continuing the discussion...

We hope to continue this discussion about exploring the ways that supra-enterprise network monitoring is changing, what techniques can be effective, and where new approaches are needed.

Please join us in January for FloCon 2012 Austin, Texas. We will be moderating a panel discussion. In the meantime, we'd like to continue the discussion on the FloCommunity mailing list.

Signed Java and Cisco AnyConnect

2011-06-09T17:35:13Z

A few years ago, I published a blog entry called Signed Java Applet Security: Worse than ActiveX? In that entry, I explained the problems that arise when a vulnerability is discovered in a signed Java applet. Let's see how the Cisco AnyConnect vulnerability is affected.

]]> US-CERT Vulnerability Note VU#490097 describes a vulnerability in the Cisco AnyConnect ActiveX and Java clients that allows an attacker to download and execute arbitrary code. The vulnerability note indicates that Cisco has addressed this vulnerability, but what does that actually mean?

To exploit the ActiveX version of AnyConnect, an attacker could create a web page that hosts and uses the vulnerable version of the ActiveX control. Internet Explorer ActiveX users can "immunize" themselves against the exploit by obtaining and installing the fixed version of the AnyConnect ActiveX. Once an updated version of an ActiveX control has been installed, Internet Explorer is designed to prevent the control from being downgraded.

While Internet Explorer uses the ActiveX version of AnyConnect, other browsers use the Java version. To exploit the Java version of AnyConnect, an attacker could create a web page that hosts and uses the vulnerable version of the signed Java archive. Java will use whichever Java applet is provided by the web server. Even if a user has installed the fixed version of the Java applet, that does not prevent exploitation of the vulnerable one. In other words, simply fixing the Java applet does nothing to protect end users from being exploited.

For the most part, this situation is due to a limitation of the Java runtime and how it handles signed Java applets. However, there has been one significant change since my original blog post on signed Java applet security. As of JRE 6u14, Java supports a blacklist feature. This feature can be used to disable known-vulnerable signed Java applets based on their Manifest hash. The Java blacklist feature is a step toward the protection that ActiveX kill bits give us. One problem with Java blacklists is that Oracle does not currently provide blacklist entries for third-party Java applets. Basically, Oracle is not providing an updated JRE version that disables the vulnerable Cisco AnyConnect Java applet versions.

For additional information about how to protect against the Cisco AnyConnect vulnerability, including setting Java blacklist entries for the vulnerable versions, see US-CERT Vulnerability Note VU#490097.

Effectiveness of Microsoft Office File Validation

2011-05-19T18:26:00Z

Microsoft recently released a component for Office called Office File Validation that is supposed to help protect against attacks using malformed files. Because I recently performed file fuzzing tests on Microsoft Office, I decided to test the effectiveness of Office File Validation.

]]> Background

Before a file is opened, Office File Validation analyzes the file's structure to determine if it is well-formed. Office will warn the user if a file has failed validation before the file can be opened. To increase protection, Office File Validation can be configured to automatically block malformed files from being opened rather than giving the user a choice. Until recently, this feature was only available with Microsoft Office 2010. Office File Validation is now available as an optional add-on for Microsoft Office 2003 and 2007.

Microsoft states, "Office File Validation helps detect and prevent a kind of exploit known as a file format attack or file fuzzing attack." I was able to test the accuracy of this claim by using the crashing test cases from the brief Office fuzzing campaign that I performed.

The Test

To test Office File Validation, I used a set of 100 DOC files that cause Microsoft Word 2003 to crash in unique ways. The test environment is fully patched as of May 19, 2011. Rather than using the raw fuzzed files from our fuzzing framework, I used the minimized test cases. After determining that a file causes an application to crash, the framework will attempt to generate a file that is minimally different from the original seed file but that still causes the same crash. In other words, the files are as well-formed as possible, yet they still cause Word to crash.

The Results

When a crash is encountered, !exploitable assigns a crash Major and Minor value to help determine uniqueness. By using both the Major and Minor hash values, the original set of 100 crashes is reduced to 55. In this particular set of test cases, this corresponds to a 45% reduction in attack surface. If you consider just the crash Major values, the number of cases that cause unique crashes goes from 38 to 18, or a 53% reduction in attack surface.

Conclusion

The Microsoft Office File Validation add-on does help prevent file fuzzing attacks. Although the protection it provides is far from comprehensive, the protection is significant enough to warrant its use. I recommend that Office 2003 and Office 2007 users install Office File Validation to help minimize the attack surface of the Microsoft Office products. It is important to realize, however, that because Microsoft Office File Validation does not block all malformed files, additional runtime exploit mitigations should be used to help keep you safe. The blog entry about fuzzing Microsoft Office outlines these mitigations. Incidentally, Microsoft has released an updated version of EMET, which provides additional exploit mitigation techniques and improves support for enterprise deployments. I strongly encourage users and administrators to evaluate its use.

A Security Comparison: Microsoft Office vs. Oracle Openoffice

2011-04-13T18:52:00Z

Recently, Dan Kaminsky published a blog entry that compared the fuzzing resiliency of Microsoft Office and Oracle OpenOffice. This blog entry contains the results from a similar test that I performed in November 2010. Also included are some other aspects of the Office suites that can affect the software's security.

]]> Background

Fuzz testing is a dynamic software testing technique that can be used to find bugs that result in the crashing of an application. Every bug that results in a crash has the potential of being a vulnerability. Depending on the specific circumstances of a crash, these bugs may also result in vulnerabilities that allow an attacker to execute arbitrary code. Fuzz testing can be used as one measure of the number of vulnerabilities that an application may contain.

The Test

I used a Python-based mutational fuzzing framework for Microsoft Windows. The fuzzer takes a starting, or "seed," file, mutates it, and opens it using the target application while monitoring that application for a crash. Microsoft's !exploitable Crash Analyzer debugger extension analyzes any crashes and assigns them each a hash identifier. The fuzzing framework uses the hash that was generated to determine if a crash is unique. Note that !exploitable may assign different hashes to the same underlying software defect. I configured the fuzzing framework to use a set of 19 different DOC files. The fuzzer used a random byte mutation strategy, which set the value of a range of bytes to a random value. The range used for this test was to mutate 0.001% to 1% of the seed file for each iteration. Each seed file was mutated in 10,000 different ways, resulting in a 190,000-iteration fuzzing campaign for each target application. I used the same set of 190,000 mutated files to test each Office suite.

The Targets

I tested currently supported Microsoft Office products:

Microsoft Office XP Professional (released March 5, 2001)
Microsoft Office 2003 Professional (released November 17, 2003)
Microsoft Office 2007 Professional (released January 30, 2007)
Microsoft Office 2010 Professional (File validation disabled)
Microsoft Office 2010 Professional (released June 15, 2010)

All Microsoft Office products were fully patched with updates as of November 2010.

I tested Microsoft Office 2010 with file validation both enabled and disabled. The default configuration for Office 2010 has a feature called "Gatekeeper," which performs some preliminary validation of input files before opening them. If a file fails the validation, the user receives a warning but can continue to open the file. The standard fuzz testing run for Office 2010 indicates files that would crash the application without any additional user interaction. The "Office 2010 with File Validation disabled" fuzz testing run indicates files that would crash the application if the user proceeds to open the file despite the warning.

I also tested the following versions Oracle OpenOffice:

OpenOffice 3.2.1 (released June 4, 2010)
OpenOffice 3.3.0 RC7 (released November 26, 2010)

Because the fuzzing campaign focused on DOC file parsing, I used Microsoft Word in the Microsoft Office suite and OpenOffice Writer in the Oracle OpenOffice suite.

The Results

This graph shows the results from all of the products. As indicated by the first five columns, there is a clear decrease in the number of unique crashes with the Microsoft Office products. Office XP has the most unique crashes of any of the Office suites. However, there is not a one-to-one mapping of unique crash hashes to software bugs. More specifically, the !exploitable extension produces a Major hash and a Minor hash. Unique Major hashes are more likely to be unique bugs, while unique Minor hashes may be variations of the same bug.

Here is the same data, but only focusing on the crash Major value:

By looking only at the crash Major value, the Office XP bar is less of an outlier. An investigation of the crash hashes revealed that a large number of the unique crashes for Office XP contained the same Major value but a different Minor. Those results suggest that there is a good chance that they are all the same underlying bug. To narrow the scope of the data even further, let's look at only crashes that are reported to be either EXPLOITABLE or PROBABLY_EXPLOITABLE by the Microsoft !exploitable extension:

With this particular fuzzing campaign, Oracle OpenOffice produced more unique crash Major values that are tagged as EXPLOITABLE or PROBABLY_EXPLOITABLE.

While you can determine some trends with these graphs, it's important to realize that every Office suite contains bugs that can easily be discovered with simple fuzzing techniques. Because software vendors will never eliminate 100% of the bugs in their software, it is important to consider the features that can help prevent an attacker from exploiting the bugs.

Mitigations

Eliminating software defects should be a priority for software vendors, but software can never be 100% defect-free. Therefore, it is also important that software vendors take advantage of runtime exploit mitigations available in the operating system. Runtime exploit mitigations make it more difficult for an attacker to execute code when exploiting a vulnerability. For example, if runtime exploit mitigations are in place when a user opens a malicious Office document, they may cause the application to crash instead of allowing malicious code to be executed. The following are some runtime exploit mitigations:

ASLR (address space layout randomization) - This feature prevents libraries from loading at predictable locations in order to mitigate exploits that rely on return-to-library or "return-oriented programming" techniques.
DEP (data execution prevention) - This feature prevents execution of code that resides in memory pages that aren't marked as executable. To be truly effective, DEP must be combined with ASLR because there are several strategies for bypassing DEP that leverage predictable locations of libraries.
Preliminary File Validation - This feature checks that a file conforms to an application's expectations. Software bugs are often triggered by malformed data. If a malformed file fails validation, then the target application may not open the file.

Further information about DEP and ASLR can be found in the Microsoft Security Research & Defense Blog.

We tested which mitigations the Office suites use. In the table below, if there is a "Y" in the Permanent DEP column, the application uses SetProcessDEPPolicy to enable DEP for the life of the process. The ASLR column indicates the percentage of libraries in the application's directory that are linked with the /DYNAMICBASE flag, which indicates compatibility with ASLR. Any library that is not linked with /DYNAMICBASE can potentially be used to bypass DEP. There are two caveats for this column:

Although a library exists in the application's install directory, the application does not necessarily use the library.
An application may install and load a library from a location outside of the application's install directory.

The percentages reported for ASLR can be used as a rough approximation of the level of ASLR compliance. Finally, the Preliminary File Validation column indicates whether the application performs validation of files before opening them for full processing.

In the table, the colors represent how well the product incorporates the mitigations. Green indicates the ideal, yellow indicates some conformance, and red indicates little or no conformance.

Mitigations	Permanent DEP	ASLR	Preliminary File Validation
Office XP	N	0%	N
Office 2003	N	73%	N
Office 2007	N	94%	N
Office 2010 (File Validation Disabled)	Y	95%	N
Office 2010	Y	95%	Y
OpenOffice 3.2.1	N	1%	N
OpenOffice 3.3.0 RC7	Y	84%	N

Mandatory Mitigations

The information in the previous table indicates that none of the Office suites fully employ all of the runtime exploit mitigations available in Windows. Microsoft has provided a tool called the Enhanced Mitigation Experience Toolkit (EMET), which can be used to force an application to use various runtime exploit mitigations. An example of how to use EMET to mitigate an Adobe Reader vulnerability was provided in the Microsoft SRD Blog. A similar method can protect the various components of the software suites identified in this document. The full user guide for EMET is available in PDF form.

EMET can be used to enable DEP and ASLR on a system-wide or per-application basis. Note that Microsoft Windows Vista or later is required to support ASLR.

Software Updates

The final aspect of the Office suites that I investigated was how the applications received updates. Unlike robustness to fuzzing, the method for receiving updates is not a direct indicator of code quality. However, the mechanism through which an application uses to receive updates can affect the security of the system that runs the application.

In the following table, green indicates the ideal answers.

Feature	Microsoft Office	Oracle OpenOffice
Update Check	SSL	HTTP
Signed Download?	Y	N
Admin Privileges Required?	N	Y
User Interaction Required?	N	Y

Two important aspects of checking for software updates:

Does the check occur over SSL or another secured channel?
Does the software validate the signature of the downloaded software?

If the software fails to perform those two aspects, then it may be a security risk. Oracle OpenOffice does not use a secured channel to check for updates, and the software that is downloaded is not digitally signed. Therefore, OpenOffice is vulnerable to the EvilGrade attack. In fact, this vulnerability has been known since 2008.

Conclusion

All of the Office suites that I tested were vulnerable to a number of crashes due to malformed input. The fuzzing campaign focused solely on DOC file parsing. However, each Office suite supports many types of data. For example, Microsoft Office supports more than 100 different file types. The numbers shown in the graphs are a small subset of the total number of unique crashes that can easily be discovered through random mutation fuzzing.

Of the Microsoft Office suites, Office XP has the most unique crashes. It is important to note that the extended support end date for Office XP is July 12, 2011. After this point, Microsoft will not provide security updates for the product. Office 2010 has the fewest number of unique crashes, uses permanent DEP, and has the highest number of libraries that are compatible with ASLR. Office 2010 file validation, which is enabled by default, provides additional protection against malformed input.

Of the Oracle OpenOffice products, the RC7 prerelease for OpenOffice 3.3.0 shows a small decrease in unique crashes when compared with the release version 3.2.1.

We are currently coordinating the results of the fuzz tests and other security analysis with the affected vendors.

Announcing the CERT Basic Fuzzing Framework 2.0

2011-02-28T20:53:00Z

Version 2.0 of the CERT Basic Fuzzing Framework (BFF) made its debut on Valentine's Day at the 2011 CERT Vendor Meeting in San Francisco. This new edition has a lot of cool features that we'll be describing in more detail in future posts, but we wanted to let you know that it's available so that you can download and try it.

]]> Since we released BFF 1.1 in September last year, we've made a number of improvements to our Linux-based fuzzing environment. We are releasing the updates as BFF 2.0. Our main goal is to make it simpler for the creators of software to get started fuzzing. Along the way, we're trying to discover and refine techniques to increase the efficiency of finding vulnerabilities through fuzzing.

Here's a summary of what we've done:

BFF has been completely rewritten in Python. After refactoring BFF 1.0 into BFF 1.1 (both written in Perl) to improve performance, we observed that modularizing the component parts of BFF would make it easier to add new features. We were also seeing more and more Python appear in the security community, so we decided to port the BFF code from Perl to Python and break it into modules. The algorithmic improvements made to BFF 1.1 remain in BFF 2.0.
We added a 'rangefinder' feature to eliminate the need for the user to figure out how much of the input file to fuzz. The rangefinder built in to BFF will automatically adjust the degree of input fuzzing to find more crashes by focusing on the ranges that are most fruitful.
We totally rewrote the crash minimization code to leverage some combinatorics and probability analysis we have done since BFF 1.1 was released. The new version is both efficient and relentless in its attempts to minimize crashing test cases to only the bits absolutely necessary to differentiate the crashing test case from the known good seed file.
Logging in BFF uses the Python logging module for all of its logging needs.
We have also incorporated a few statistics and visualization tools to help with analyzing BFF logs. These are in the analyzers directory in the scripts.zip file.

We'll be posting more about these and possibly other features of BFF 2.0 in the future, but we wanted to share the news so you can start your own fuzzing campaigns. To get started, simply follow these steps:

Download BFF 2.0 from http://www.cert.org/download/bff
Unzip scripts.zip to c:\fuzz
Unzip DebianFuzz.zip to a directory of your choice
Open DebianFuzz.vmx with VMware
Create a snapshot in VMware
Power on the VM

You may need to verify that the shared folder (c:\fuzz -> /mnt/hgfs/fuzz) is enabled in the VM preferences. Other virtualization products may work with some additional configuration. See the README file in scripts.zip for more details.

Note: For those of you who received a copy of BFF 2.0 at our vendor meeting last week, we've made a few bug fixes to the code in scripts.zip, so you might want to download a fresh copy.

"Network Monitoring for Web-Based Threats" released

2011-02-14T18:32:00Z

The CERT Network Situational Awareness (NetSA) team, specifically our talented and hard-working intern Matthew Heckathorn under Sid Faber's guidance, has published an SEI Technical Report on monitoring web-based threats.

]]> The report draws on related work such as OWASP but comes from a different point of view. While OWASP is focused on developing web applications securely, this report focuses more on situations where you don't have that control, but you need to protect servers and clients from web-based threats. The report may help you answer the following questions:

What kinds of network monitoring do you need to do?
How do you identify the attacks?
How do you prevent them at the network level?

At more than 100 pages, the report is as comprehensive as we could make it and still get it out in a (relatively) timely manner.

Blog reorganization

2011-02-11T20:01:00Z

Hi, folks. As you can see, we've changed the name of the Vulnerability Analysis Blog to the CERT/CC Blog. With this name change, we're expanding the focus of the blog to include content from other technical teams.

]]> The current RSS and Atom feeds will continue to work, but you may want to update to the corresponding new feed location now (RSS, Atom) in order to avoid any problems in the future.

Past blog entries will continue to be available at the existing URLs.

CERT Basic Fuzzing Framework Update

2010-09-22T15:26:00Z

Hi, folks. We've recently updated the CERT^® Basic Fuzzing Framework (BFF). The new BFF 1.1 contains new functionality and improves performance.

]]> The BFF is a framework to perform file mutation fuzzing for Linux applications. Since the initial release of the BFF, we have made some improvements:

The virtual machine

We upgraded the OS to the testing version of Debian ("Squeeze"). In the process of installing applications to fuzz, I noticed that some of them required libraries newer than what are available in the stable version of Debian. The VM used by the BFF is more modern.
The virtual machine now includes a generic VESA video driver in addition to the VMware driver. This can simplify the use of the BFF with other virtualization products, like VirtualBox.

The scripts

In some cases, the gdb process would hang during a fuzzing run, which can result in resource exhaustion. The gdb process is now properly killed when its timeout expires.
BFF 1.0 discarded crashes caused by the SIGABRT signal. The reason for this was to ignore, by default, crashes that were the result of a failed assertion. However, this feature was also discarding heap corruption crashes that were caught by glibc. BFF 1.1 now investigates SIGABRT crashes to determine if they are the result of a failed assertion. Only failed assertion crashes are discarded by default.
The zzuf.pl script has been refactored for improved performance, sanity, and modularity. (Thanks Allen!)
The BFF now performs automatic crashing testcase minimization via fuzzdiff. (Thanks Dan!)

Download BFF 1.1

Study of Malicious Domain Names: TLD Distribution

2010-08-31T18:28:00Z

Hello, folks. This post comes to you courtesy of Aaron Shelmire from the Network Situational Awareness team. Aaron writes:

Recently the Network Situational Awareness team at CERT has been researching the characteristics of malicious network touchpoints. The findings of this initial research are very telling as to the true state of security on the internet.

]]> The Domain Name System (DNS) can be thought of as a multi-level addressing scheme that overlays the numerical IP addresses. This allows content on a numerical address to be called by an easily remembered name such as cert.org. It also expands the possible naming space to a nearly unlimited number of options, like hcjakaudbre.net or ajkcausdih.biz. While the options are not necessarily easily pronounceable, the possibilities for addresses are endless.

The DNS is laid out in a series of labels referred to as levels. The first, or top, level is the last part of the domain name. As an example, www.google.com is a three-level domain name with a top-level domain (TLD) of com, a second-level domain of google, and a third-level domain of www. So, when your computer needs to look for www.google.com, it asks the DNS root servers responsible for the .com TLD who the authoritative DNS server for google is based on the .com zone file. The google domain server would then supply the answer of the numerical address of www.google.com. Addresses on other domains use the same backward resolution.

Looking at this construction from a security perspective, we can identify the level responsible for a malicious domain. For example, let's consider the invented address somebadhost.hoster.com. Because somebadhost is a subset of hoster.com, hoster.com would be responsible cleaning up any malicious content on somebadhost. However, if the malicious touchpoint was something like badguy.com, the responsibility for removing the malicious content lies with the registrar that allowed Mr. Bad Guy to register the domain badguy.com as well as with the root server operators.

In our research, we established a control case of randomly chosen domains to compare against a population of malicious domains. This allows us to see how the behaviors and characteristics of malicious domains involved in criminal and espionage operations contrast to those behaviors of the general population of domains.

As shown, a random sample of domains is mostly distributed over the .com top-level domain, with some distributed over the .org and .net TLDs. For the purpose of comparison, note that the China top-level domain (.cn) is only seen 1.7% of the time.

Using the data of malicious domains, we see a very different distribution.

Most of the malicious domains are still using the .com, .org, and .net TLDs, but these TLDs are less popular than they are in the control sample. In the malicious sample, the .info TLD becomes very prominent (as opposed to only .9% of the control case), and the .biz TLD appears as a more popular TLD (compared to .2% in the control case). The China TLD nearly doubles its presence to 3.0% of the malicious domains.

These results may imply that the TLDs that have smaller proportions in the malicious sample than in the control sample have applied policies and practices that enable them to prevent the use of their resources for malicious activity.

CERT Basic Fuzzing Framework

2010-05-26T18:00:00Z

Hi folks. I've been involved in a fuzzing effort at CERT. One of the ways that I've been able to discover vulnerabilities is through "dumb" or mutational fuzzing. We have developed a framework for performing automated dumb fuzzing. Today we are releasing a simplified version of automated dumb fuzzing, called the Basic Fuzzing Framework (BFF).

]]> Dranzer was one of our first fuzz testing projects. By performing automated smart fuzz testing of ActiveX controls, I was able to discover thousands of vulnerabilities. Luckily, Microsoft has made some improvements to Internet Explorer to help minimize the impact of ActiveX vulnerabilities.

Another technique that I've used for discovering vulnerabilities is dumb fuzzing. Don't let the name fool you. Dumb fuzzing has the advantage of being more universal than smart fuzzing. Dranzer is limited in that it tests only ActiveX controls; with dumb fuzzing, you can switch targets easily after your dumb fuzzing environment is complete.

The Basic Fuzzing Framework (BFF) consists of two main parts:

a Linux virtual machine that has been optimized for fuzzing
a set of scripts and a configuration file that orchestrate the fuzzing run

The virtual machine is a stripped-down Debian installation with the following modifications:

The Fluxbox window manager is used instead of the heavy Gnome or KDE desktop environments.
Fluxbox is configured to not raise or focus new windows. This can help in situations where you may need to interact with the guest OS while a GUI application is being fuzzed.
Memory randomization is disabled.
VMware Tools is installed, which allows the guest OS to share a directory with the host.
The OS is configured to automatically log in and start X.
sudo is configured to not prompt for a password.
strip is symlinked to /bin/true, which prevents symbols from being removed when an application is built.

The fuzzer used by the BFF is Sam Hocevar's excellent zzuf application. zzuf was chosen for its deterministic behavior, number of features, and lightweight size. By invoking zzuf from a script (zzuf.pl), we are able to automate additional aspects of a fuzzing run:

Collect program stderr output, valgrind memcheck, and gdb backtrace. This information can help a developer determine the cause of a crash.
De-duplication of crashing testcases. Using gdb backtrace output, zzuf.pl will determine if a crash has been encountered before. By default, duplicate crashes are discarded.

The zzuf.pl reads the configuration options from the zzuf.cfg file. This file contains all of the parameters relevant to the current fuzz run, such as the target program and syntax, the seed file to be mutated, and how long the target application should be allowed to run per execution. The configuration file is copied to the guest OS when a fuzzing run has started. The zzuf script will periodically save its current progress within a fuzzing run as well. These two features work together to allow the fuzzing VM to be rebooted at any point, allowing the VM to resume fuzzing at the last stop point. The fuzzing script also periodically touches the /tmp/fuzzing file. A linux software watchdog will check for the age of this file; and, if it is older than the specified amount of time, the VM will automatically be rebooted. Because some strange things can happen during a fuzzing run, this robustness is necessary for full automation.

The BFF is preconfigured to automatically begin fuzzing a very old version of ImageMagick. A debug build of ImageMagic 5.2.0 is installed on the system, zzuf.cfg is set up with the fuzzing parameters, and a simple Netpbm seed file is included. When the machine is powered on, it will automatically log in and zzuf.pl will invoke the zzuf fuzzer. ImageMagick's convert program will repeatedly execute, attempting to convert the seed file into a bitmap file. The way that zzuf works is that each time the application is launched, the seed file will be mangled in a certain way. The goal of fuzzing is to determine malformed input that causes the target application to crash. The zzuf.pl script takes this one step further by collecting additional information about the crashes. Cases that are determined to be unique are saved.

To begin fuzzing on your own, simply follow these steps:

Unzip scripts.zip to c:\fuzz
Unzip DebianFuzz.zip to a directory of your choice.
Open DebianFuzz.vmx with VMware.
Create a snapshot in VMware
Power on the VM

You may need to verify that the shared folder is enabled in the VM preferences. Other virtualization products may work with some additional configuration. See the README.txt file in scripts.zip for more details.

Get your own BFF here.

P.S. If you are interested in this sort of stuff, check out our job opportunities.

Top-10 Top Level and Second Level Domains found in Malicious Software

2010-03-05T19:10:32Z

Hello folks. This post comes to you courtesy of Ed Stoner and Aaron Shelmire from the Network Situational Awareness group at CERT. They write:

Recently there have been some statistics published on botnet Command & Control (C2) channels. These statistics claim that 94.58% of botnet C2 channels are under the .com top level domain (TLD). While it's impossible to accurately comment on those statistics without knowing the methodology used to arrive at them, we at CERT have been doing research concerning malicious domain names that arrives at a different result.

]]> Over a period of the 6-months from July 2009 until February 2010, our malicious software collection expanded by over 250,000 samples. Those samples reference nearly 120,000 domain names. The top 10 domain names were

Count	TLD	Percentage of total domains
28191	.net	~23.9%
25040	.com	~21.0%
23674	.info	~19.9%
19889	.org	~16.7%
8020	.biz	~6.7%
3561	.cn	~3.0%
1894	.br	~1.6%
1046	.cc	~.9%
902	.ru	~.8%
594	.de	~.5%

Our collection shows a much more even distribution of domain names over top level domains.

As for second-level domains we have the following top 10.

Count	TLD	Percentage of Total Domains
7200	.no-ip.biz	~6%
5810	.3322.org	~4.9%
1980	.no-ip.info	~1.6%
1897	.no-ip.org	~1.6%
1488	.dyndns.org	~1.3%
1420	.yi.org	~1.2%
628	.vicp.net	~.5%
495	.gicp.net	~.4%
311	.zapto.org	~.3%
269	.mooo.com	~.2%

The "no-ip" domains account for approximately 10% of malicious domain names when aggregated.

There are a couple of caveats regarding this data.

First, these are only the domain names as they appear in the malicious code. This doesn’t mean that 23.9% of malicious traffic is routed to domain names underneath the .net top level domain, nor that 23.9% of malicious activity occurs because of the .net TLD.

This also doesn't mean that 3.0% of malicious domain names are physically located in China. It simply means that the .cn-Registrar has allowed those names to be registered.

They could be serving an exploit payload, serving as a drop point for data exfiltration, or serving as a point to grab the RAT software.

Lastly, these samples have been sorted and made unique. This means that if a domain name appeared 100 times, we only counted that domain name once. If we kept all occurrences of domain names, we would have nearly 500,000 instances of domain names being used within that 6-month period.

Plain Text Email in Outlook Express

2009-11-13T14:23:00Z

Reading email messages in plain text seems like a reasonable thing to do to improve the security of your email client. Plain text takes less processing than HTML, which should help minimize your attack surface, right? As it turns out, Outlook Express (and its derivatives) is doing more than you think when it is configured with the "Read all messages in plain text" option enabled.

]]> Outlook Express is an email client that is provided with various versions of Microsoft Windows, starting with Windows 98. In Windows Vista, the client was renamed Windows Mail. Windows 7 does not come with an email client, but a newer version of Windows Mail called Windows Live Mail is available for download. Despite the different names, all three products are essentially different versions of the same software. In this blog entry, the term "Outlook Express" refers to all three versions.

Security-conscious people tend to disable unnecessary features to improve the security of software that we use. For example, most web browsers can be made more secure by disabling features like Java, ActiveX, or even JavaScript by default. Sure, it's a trade-off with functionality, but when you're constantly processing untrusted data by viewing web pages, it makes sense to minimize your attack surface. The same techniques can be applied to your email client. For example, most popular email clients include an option to display messages as plain text. In Improving Internet Safety and Security Settings, Microsoft recommends setting the option "Read all messages in plain text."

It is reasonable to guess that the "Read all messages in plain text" option means that Outlook Express displays only the plain text MIME part of an email message. Or perhaps it just strips out the HTML tags from the message. However, both these guesses are wrong. Outlook Express is doing much more than this.

When Outlook Express receives an HTML email message, it determines the handler for the "text/html" MIME type. Outlook Express then uses the Internet Explorer rendering engine (MSHTML) to process the message. If the "Read all messages in plain text" option is specified, then the content is reduced to a plain text form. The important concept here is that the Internet Explorer rendering engine is used to process HTML email messages, regardless of the plain text setting.

In fact, ironically, setting the option to read messages in plain text can put the system at increased risk! While investigating attack vectors for the Windows animated cursor stack buffer overflow vulnerability (VU#191609), I noticed that when the "Read all messages in plain text" option was enabled, Outlook Express could be compromised just by displaying an email message in the preview pane. The default configuration of displaying messages in HTML format was not vulnerable via the preview pane. The HTML email referenced an ANI file on a remote server, and even though it was configured to display messages in plain text, Outlook Express retrieved the remote ANI file and processed it. Microsoft was notified of this behavior, and they updated their security bulletin with the text: "Note Reading e-mail in plain text on Outlook Express does not mitigate attempts to exploit this vulnerability." The behavior of Outlook Express does not appear to have changed since then.

Consider the recent Windows 7 / Server 2008 R2 denial-of-service vulnerability. This vulnerability can cause a Windows 7 or Server 2008 R2 system to hang upon attempting to create an SMB connection to a malicious server. Similar to the ANI bug, if Windows Live Mail is configured to display messages in plain text, the vulnerability can be triggered by simply receiving a malicious email and displaying it in the preview pane. The default configuration of displaying messages in HTML format is not as vulnerable because it appears to require additional user interaction, such as clicking the "Show images" link or forwarding or replying to the message.

If you are using an email client based on Outlook Express (including Windows Mail and Windows Live Mail), avoid using the "Read all messages in plain text" option. While it is possible that the setting could protect against some vulnerabilities, I have investigated several scenarios where it puts the user at increased risk. Note that Microsoft Outlook does not appear to be affected by this problem. In Outlook, the option to read messages in plain text does appear to offer increased protection against vulnerabilities.

Managing IPv6 - Part 2

2009-10-06T19:44:00Z

Past entries have addressed both securing and disabling IPv6. This entry describes ways that administrators can secure their networks and generate test cases to test those settings.

]]> Administrators and developers who work with IPv4 will notice that IPv6 has made some changes beyond offering many more addresses than IPv4. The following are some of the changes that have security impacts:

Many hosts that currently have private IPv4 addresses will have global, publicly reachable addresses.
ICMPv6 contains much of the functionality of DHCP in IPv4 and cannot easily be entirely filtered.
IPv6 addresses can be predictable or partially random. Modern operating systems allow both, and there is a tradeoff between system management ease of use and user privacy.

These changes can cause problems. For example, a host that accepts any ICMPv6 type can be fingerprinted easily from remote systems. That might not be a problem for some networks, but it could be critical for others.

There are ways for administrators to handle these challenges. The examples below aren't universally applicable, so use them as a general guide.

Managing networks using global IPv6 addresses

Globally reachable addresses are not "hidden" in the same way as NAT addresses. To filter traffic destined to these clients, administrators can use application-layer proxy servers, stateful network filtering, or host-based firewalls.

Below is an example of filtering traffic to a globally reachable IPv6 address. For the purpose of these rules, 2001:1::/64 is the local network, eth0 is the LAN interface on a firewall, eth1 is the WAN interface on the firewall, and 2001:3::1 is an IPv6 address on the internet.

ip6tables -A FORWARD -p tcp -i eth0 -s 2001:1::/64 -p tcp -j ACCEPT ip6tables -A FORWARD -p tcp -m state --state ESTABLISHED,RELATED -j ACCEPT
ip6tables -A FORWARD -p tcp -i eth1 --dport 3389 -s 2001:3::1 -j ACCEPT
ip6tables -A FORWARD -p tcp -i eth1 -m state --state NEW,INVALID -j DROP

The following is an explanation of what's happening in these rules, based on the behavior of a typical router doing NAT.

ip6tables -A FORWARD -p tcp -i eth0 -s 2001:1::/64 -p tcp -j ACCEPT
Pass any traffic that has entered on our LAN's ethernet interface (-i eth0) and that has a source address in the range our LAN is using (2001:1::/64).

ip6tables -A FORWARD -p tcp -m state --state ESTABLISHED,RELATED -j ACCEPTPass any traffic that is part of an existing connection.

ip6tables -A FORWARD -p tcp -i eth1 --dport 3389 -s 2001:3::1 -j ACCEPT
Allow any traffic coming into our WAN interface (-i eth1) to pass through to our LAN if it matches the TCP port used for RDP (--dport 3389).

ip6tables -A FORWARD -p tcp -i eth1 -m state --state NEW,INVALID -j DROPDrop all other traffic.

After configuring the firewall, administrators should test the ruleset to confirm it is working as expected. Two commonly used tools that can test IPv6 TCP and UDP policies are nmap and netcat6.

Building on the example above, let's imagine that a user logs into a host with IP address 2001:1::2/64 and starts a netcat listener on port 3389:

$ netcat6 -l -p 3389

A scan of that IP from any host on the internet other than 2001:3::1 should fail. This result can be verified with an nmap comand:

$ nmap -PN -sT 2001:1::2/64 -p 3389
Starting Nmap 4.76 ( http://nmap.org ) at 2009-09-02 14:32 EDT Interesting ports on2001:1::2:
PORT STATE SERVICE

Filtering selected ICMPv6 types

The ICMPv6 protocol includes some great functionality. IANA maintains a list of ICMPv6 types and codes.

It is hard to make general statements about which ICMPv6 types should be allowed or denied. The following chart provides some guidance about reasonable firewall policies applied to ICMPv6 types. The types are listed based on whether or not the ICMPv6 type can typically be allowed or denied.

ICMPv6 types typically safe to allow	Purpose/Comments
1, Destination Unreachable	general connectivity testing
2, Packet Too Big	sent by routers to notify a node that it should fragment the packets
3, Time Exceeded	protects against routing loops
4, Parameter Problem	error messages and handling
128, Echo Request	ping
129, Echo Reply	ping reply
133, Router Solicitation	sent by clients to the all-nodes multicast address to request an IP address assignment
134, Router Advertisement	sent by routers to the all-nodes multicast address; clients can use the information in this message to generate an address
135, Neighbor Solicitation	queries nodes for IP and connectivity information
136, Neigbor Advertisement	sends IP and connectivity information to other nodes

ICMPv6 types that can typically be denied	Purpose/Comments
137, Redirect	alerts clients to send traffic to another router, presumably one with a more direct route to the destination; like other ICMPv6 types listed, these messages are unauthenticated and could be malicious
138, Router Renumbering	automatic reconfiguration of routers
139, Node Information Query	allows a host to be fingerprinted
140, Node Information Response	allows a host to be fingerprinted
151-154	deny by default
others	not yet used, deny by default

We've talked about filtering ICMPv6 types before, so there's no reason to discuss it again. Instead, let's focus on some test case generation options.

There don't seem to be many tools that can generate arbitrary ICMPv6 packets. One of the more commonly used tools is ping6 or ping -6. The ping command sends an echo request message to an individual IPv6 address. Creating arbitrary ICMPv6 types requires a different tool.

Newer versions of the scapy packet crafting tool can be used to generate most ICMPv6 types. Here's an example of typical scapy usage:

# scapy Welcome to Scapy (2.0.1-dev) >>> a=IPv6(dst="2001:1::2")/ICMPv6ND_Redirect() >>> send(a)

To list the available ICMPv6 types (layers), use the ls() command:

>>> ls() ARP : ARP ASN1_Packet : None BOOTP : BOOTP CookedLinux : cooked linux ... ICMPerror : ICMP in ICMP ICMPv6DestUnreach : ICMPv6 Destination Unreachable ICMPv6EchoReply : ICMPv6 Echo Reply ICMPv6EchoRequest : ICMPv6 Echo Request ICMPv6HAADReply : ICMPv6 Home Agent Address Discovery Reply ICMPv6HAADRequest : ICMPv6 Home Agent Address Discovery Request ICMPv6MLDone : MLD - Multicast Listener Done ICMPv6MLQuery : MLD - Multicast Listener Query ICMPv6MLReport : MLD - Multicast Listener Report ...

To view what parameters a layer will take, use the ls() command again:

>>> ls(ICMPv6ND_Redirect()) type : ByteEnumField = 137 (137) code : ByteField = 0 (0) cksum : XShortField = None (None) res : XIntField = 0 (0) tgt : IP6Field = '::' ('::') dst : IP6Field = '::' ('::')

This information can be used when creating packets to allow greater control over specific packets:

a=IPv6(dst="2001:1::2")/ICMPv6ND_Redirect(tgt="2001:1::3")

Disabling/enabling privacy extensions

Currently, IPv6 addresses are typically assigned via stateless autoconfiguration, DHCPv6 or static assignment.

With stateless autoconfiguration, an operating system is expected to generate part (usually the lower 64-bits) of its address. If privacy extensions are enabled, the generated address will be pseudo-random. This is good for privacy but makes remote management difficult.

On Windows Server 2008, privacy extensions can be controlled with a netsh command:

C:\> netsh interface ipv6 privacy enabled|disabled

Linux users should check /proc/sys/net/ip6/conf (the exact location varies between distributions and kernel versions).

Testing the address status of other systems on the same Ethernet segment is possible, assuming that echo requests and replies are accepted on those machines. If the following commands run on a Linux system produce predictable addresses, privacy extensions are disabled:

$ ping6 -B -I eth0 -I [global IPv6 address attached to eth0] ff02::1 $ ip neighbor

Windows users can use these commands:

C:\> ping -S [global IPv6 address] -6 ff02::2 C:\> netsh interface ipv6 show neighbors

Managing IPv6 - Part 1

2009-08-19T14:07:00Z

This entry is the first in a series about securely configuring the IPv6 protocol on selected operating systems. Although this entry focuses on how to disable IPv6, we are not recommending that everyone immediately disable IPv6. However, if critical parts of your infrastructure (firewall, IDS, etc.) do not yet fully support the IPv6 protocol, consider disabling IPv6 until those components can be upgraded.

]]> The following are some of the reasons why an administrator would want to disable IPv6:

Many networks have IPv6 connectivity running on their LAN but do not have IPv6 WAN connectivity. Programs may see the connectivity on the LAN and unsuccessfully attempt to use IPv6 to connect to remote IPv6-enabled servers.
Local IPv6 traffic might be able to bypass IDS systems or other low-layer network defenses.
Operating systems may obtain global (publicly reachable) IPv6 addresses by creating tunnels.
Running an additional protocol increases a system's attack surface.
Global addressing restores end-to-end connectivity.

There are also more than a couple of reasons why an administrator wouldn't want to disable IPv6 connectivity:

The network has full IPv6 connectivity, and software on the network actively uses some of the features (usually the large pool of global addresses) found only in IPv6.
Network services running on the LAN are actively using IPv6.
The network is designed to be a "dump pipe," and the administrator is expected to not interfere with passing traffic.
Global addressing restores end-to-end connectivity.

Below are instructions for disabling IPv6 on some popular operating systems. At the bottom of the entry are links to scripts that you can run from the command line.

Disabling IPv6 via firewalls or access control lists

To disable IPv6 at a router or firewall, block protocols 41, 43, 44, 58, 59, and 60 as well as UDP ports 3544 and 3545. This firewall policy will likely miss some tunneled and non-routed IPv6 traffic (such as Teredo-compatible tunnels on non-standard ports) running on the local network.

There is too much variation in firewall syntax for us to list rules for every vendor; instead, we've written a few rules in Cisco's ACL syntax and included an ip6tables script linked at the bottom of this page.

access-list ipv6 deny 41 any any
access-list ipv6 deny 43 any any
access-list ipv6 deny 44 any any
access-list ipv6 deny 58 any any
access-list ipv6 deny 59 any any
access-list ipv6 deny 60 any any
access-list ipv6 deny udp any any eq 3544
access-list ipv6 deny udp any any eq 3545

Disabling IPv6 on Windows XP and Server 2003

The easiest way to disable IPv6 on Windows XP and Server 2003 is to run this command from a prompt with administrator privileges and reboot:

netsh.exe interface ipv6 uninstall

Disabling IPv6 on Windows Vista and Server 2008

The IPv6 protocol cannot be uninstalled from Windows Vista. The most effective way of disabling it is to edit the registry:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters\DisabledComponents] "Compatibility Flags"=dword:0xFFFFFFFF

If you don't want to edit the registry, the following netsh commands will effectively block IPv6. Note to administrators: using the "domain profile" feature of the Windows firewall will allow you to create rules that block IPv6 connectivity based on whether the user is authenticated to your domain.

netsh advfirewall firewall add rule name "IPv6" protocol=icmpv6 dir=out action=block netsh advfirewall firewall add rule name "IPv6" protocol=icmpv6 dir=in action=block netsh advfirewall firewall add rule name "IPv6" action=block protocol=41 dir=out netsh advfirewall firewall add rule name="IPv6 protocol 43" protocol=43 action=block dir=out netsh advfirewall firewall add rule name="IPv6 protocol 44" protocol=44 action=block dir=out netsh advfirewall firewall add rule name="IPv6 protocol 58" protocol=58 action=block dir=out netsh advfirewall firewall add rule name="IPv6 protocol 59" protocol=59 action=block dir=out netsh advfirewall firewall add rule name="IPv6 protocol 60" protocol=60 action=block dir=out

Disabling IPv6 on Red Hat Enterprise Linux 5

Edit /etc/sysctl.conf
Append "net.ipv6.conf.all.disables_ipv6 = 1"
Execute "sysctl -p" as root

You can modify "net.ipv6.conf.all.disables_ipv6 = 1" for a specific interface (e.g., "net.ipv6.conf.eth1.disables_ipv6 = 1") to selectively disable IPv6 on that interface.

The following steps will disable IPv6 connectivity on all interfaces:

Edit /etc/modprobe.conf
Append "alias net-pf-10 off"
Execute the command "modprobe -a" as root

For those of you who really want to disable IPv6, add these lines to your iptables scripts:

ip6tables -P INPUT DROP ip6tables -P OUTPUT DROP ip6tables -P FORWARD DROP
ip6tables -I INPUT -p all -j DROP ip6tables -I OUTPUT -p all -j DROP

Disabling IPv6 on Ubuntu Linux (version 9.04)

Edit /etc/sysctl.conf
Append "net.ipv6.conf.all.disable_ipv6 = 1"
Execute "sysctl -p" as root

You can modify "net.ipv6.conf.all.disable_ipv6 = 1" for a specific interface (e.g., "net.ipv6.conf.eth1.disable_ipv6 = 1") to selectively disable IPv6 on that interface.

The following steps will disable IPv6 connectivity on all interfaces:

Edit /etc/modprobe.d/blacklist
Append "blacklist ipv6"
Execute the command "modprobe -a" as root

Ubuntu users who run UFW can check /etc/default/ufw. If IPV6=no, you can block IPv6 connectivity with this command:

sudo ufw disable && sudo ufw enable

Scripts

Here are files you can use to disable IPv6. As with all scripts, make sure you understand the implications before running these on your system.

ip6tables router/firewall shell script
batch file to disable on Windows XP and Server 2003
reg file to disable IPv6 on Windows Vista and Server 2008 (Microsoft has published instructions on how to import. Also see the instructions in the solution section of TA09-020A.)