Vulnerability Analysis Blog

Ping sweeping in IPv6

2008-09-12T19:06:00Z

Hello, its Ryan. We've noticed a misconception about IPv6 that is popular on the internet: that IPv6 addresses are hard to ping sweep because there are so many possible addresses. Ping sweeping can lead to port scanning, so this misconception is viewed as a security feature. In this post, I'll prove that, while it won't work across the internet, ping sweeping on the local network is easier in IPv6 than in IPv4.

]]> Before we go further, if you don't know what IPv6 is, read this Wikipedia entry. Essentially, IPv6 is a new protocol that is a lot like the currently deployed IPv4, but it has many more addresses (about 2^128 total). It is so much like IPv4 that a lot of network gear supports IPv6 without any modifications. Most newer operating systems have native IPv6 support, and many prefer IPv6 connections over IPv4 ones.

On our IPv6 test network, we are running a few Linux machines and an OS X laptop. On one of the Linux machines, we run the following command:

ping6 -I eth0 ff02::1

And, on this machine, the neighbor cache fills up with all the link local addresses of the other computers connected to the node. Linux systems with iproute2 can use command

ip neighbor

to show the neighor cache. Folks on Windows Vista and Server 2008 can use the netsh command

netsh interface ipv6 show neighbors

What just happened?

Well, we sent an ICMPv6 echo request (type 128) message to the all-nodes multicast address. All the nodes that were listening sent back the ICMPv6 echo reply (type 129) message. When we received these messages, their link-local (and MAC) addresses were added to our neighbor cache. eth0 is the interface connected to the network (the -I flag is needed when pinging the multicast address).

Ok, so that was fun--we just created a list of all the link layer addresses on our Ethernet segment. The next exercise is even more fun. Run this command:

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

Now check the neighbor cache. It will show the global IPv6 (the equivalent of a public IPv4) address. We just discovered the global IPv6 addresses of the hosts on our network.

These commands won't work across the internet because, in general, multicast isn't supported across the web. They also won't work with hosts that filter ICMPv6 types 128 and 129 (which is not compliant with RFC 4980 section 4.4.1). However, it is not possible to block all ICMPv6 types, and an analysis of restrictive host-based firewalls will likely show that some multicast ICMPv6 traffic is allowed.

So what can you do about this problem? Not that much, and the truth is, it isn't really a problem. Things are working exactly as they should, and security effort is usually better spent making sure hosts are secure, not obscure.

Many network managers think their networks don't support IPv6 because it hasn't been officially deployed. Most networking gear we tested that works at layer 2 seems to pass IPv6 packets with no problem. Flat networks will probably support IPv6 just fine. Almost all popular operating systems support and prefer IPv6.

So, what's to prevent an attacker from starting a stateless auto-config server (a way to send router advertisements), passing out IPv6 addresses, and possibly conducting ping sweeps on your network? Probably nothing. If you purchased network security equipment that protects you from IPv4-based attacks, this doesn't need mean that it's broken. IPv6 is a new protocol, and you'll probably need to deploy new equipment, upgrade old equipment, and/or notify users of the risks of running IPv6 on your network. An applicable analogy is that its like purchasing a Blu-Ray disc for a movie that you already own on DVD.

If you'd like more information about how this works, email us at cert@cert.org with INFO#498112 in the subject line. We have some other blog posts about IPv6 coming soon, and we'd like to know answers to these questions:

Do you deploy commercial or open source network switches or IDS systems that provide robust IPv6 support?
If you ran these ping6 commands on your network, how effective were they?
Are your hosts blocking ICMPv6? Do you plan to keep them with that configuration?

Carpet Bombing and Directory Poisoning

2008-09-04T19:50:08Z

Hey, it's Will. Earlier this year, details about "carpet bombing" attacks were released. Apple addressed the issue by prompting users before downloading files, but recent news indicates that Google Chrome, which is based on Apple's WebKit code, is also vulnerable to the same type of attack. However, some people seem to be missing an aspect of the attack that affects all web browsers.

]]> When loading a DLL, Microsoft Windows looks for the DLL in a certain sequence of directories. The first match for the file name wins. In most cases, Windows will first look for a DLL in the same location as the executable. This behavior is what allows the Apple Safari "carpet bombing" vulnerability to work. If an attacker can place code in a directory that gets searched before Windows finds the "real" DLL, the attacker's code will be executed.

Consider the following scenario: Suppose that you use a web browser to download files, and you have some directory where you put your downloaded files. As time goes on, that directory gets filled with items that you've downloaded. Occasionally, you may open one of the trusted programs that you've explicitly downloaded and run it from your browser's download manager or from Windows Explorer.

If this scenario seems plausible, you may have inadvertently executed malicious code! This risk is even greater if you use a web browser that saves files to your computer without prompting, such as Google Chrome or an older version of Apple Safari for Windows. It's important to note, though, that any web browser or other application is at risk here, too, because the DLL search order behavior is a feature of Microsoft Windows.

What can you do to protect yourself from this kind of attack? For starters, make sure that your web browser is configured to prompt you before downloading a file. For example, Google Chrome has a preference called "Ask where to save each file before downloading." Configuring your web browser to prompt you before downloading a file can help prevent a directory from being "poisoned" without your knowledge. The most effective protection, however, is to move a file to a trusted (i.e., empty) directory before executing it. Before running a program in Microsoft Windows, it is not enough to verify that you trust the program itself. You must also trust the directory from which the application is launched. A cluttered download directory is not trustworthy.

Windows Vista does not appear to be vulnerable to directory poisoning. In my testing, Vista seems to give DLL search order priority to the system directory rather than to the executable's current directory.

Safely Using Package Managers

2008-07-10T13:48:04Z

Hi, it's Ryan. Package managers partially automate the process of installing and removing software packages. Most package managers use cryptographic signatures to verify the integrity of packages. In the article Attacks on Package Managers, the authors describe how an attacker can abuse package managers that use digital signatures.

]]> Most operating systems have package managers, but UNIX-like systems use them extensively to manage packages on an installed system. Some examples of system-wide package managers (we're purposely avoiding application-specific package managers in this post) are APT, Portage, and YUM. There are a lot more, though—Wikipedia has a partial list of others.

Many of these package managers use cryptographic signatures to verify the integrity of packages. The Debian Wiki describes how APT uses GPG to check packages, and other package managers behave in a similar way.

What problems can the attacker cause by gaining control of a mirror? Completely shutting down the mirror server would be easy for users to notice. A more subtle attack would be to distribute packages that are signed but still contain vulnerabilities. How can a package be both signed and vulnerable? Well, before CVE-2008-0166 was discovered, OpenSSL (OpenSSL versions 0.9.8c-1 to 0.9.8g-9 on Debian-based systems to be precise) did not have any publicly known vulnerabilities. After discovery, OpenSSL had well-known problems, and, until they were updated, SSH servers (OpenSSH uses OpenSSL) were vulnerable. However, the vulnerable version is still a valid signed package. Assuming that a user is obtaining security updates from a third-party mirror, that mirror could pass the user signed packages with known vulnerabilities.

Before going any further, it's worth pointing out that this problem isn't limited to open-source vendors. Any software that gets updates via the internet (just about all software) could be affected. However, exploitation is much more difficult when the software vendor directly controls the mirrors--before attacking clients, an attacker needs to locate and take control of the mirror. Many open-source projects make it simple for third parties to become mirrors.

So, we've talked about the problem and why it is somewhat of a concern for vendors that don't directly control their mirrors. As far as we can tell, no mirror site has intentionally given clients packages with known vulnerabilities and then exploited those vulnerabilities. Furthermore, there are several things mirror users and administrators can do to protect themselves:

Administrators can avoid using third-party repositories by running locally hosted mirrors, setting up caches, or getting packages from a trusted source. It is important to note that exploits can be created rapidly, so even a small delay in getting fixed software can be problematic.
When third-party repositories need to be enabled, users should select their respositories carefully. How long has the mirror been around? Is it up to date? Is it easier to get the package from another source (such as the developer's home page)? Does the operating system vendor track the repo?

Projects use mirrors to reduce bandwidth costs and provide redundancy. How can software maintainers offer secure mirrors that aren't slow and unstable? Some commercial Linux distributions offer high-speed direct downloads from trusted sources. Another potential solution to this problem is P2P technology. If widely used, programs like DebTorrent may allow official repositories to distribute metadata and tracker information while decreasing bandwidth costs.

The issues we've talked about (mirror distribution, software integrity) are a subset of the larger problem of obtaining, installing, and managing trusted software. The importance of obtaining verified, trusted packages needs to managed according to your security policy.

Thanks to Justin Cappos and Justin Samuel for providing us information about these issues. A special thanks to all the vendors who gave us feedback.

If you send us mail, we are tracking these issues as VU#230187.

ActiveX Vulnerability Discovery at the CERT/CC

2008-07-03T13:55:01Z

Hi, it's Will. Anybody who has been keeping an eye on the US-CERT Vulnerability Notes has probably noticed that I've published a lot of ActiveX vulnerabilities. So it should be no surprise to learn that we have been testing ActiveX controls and discovering vulnerabilities in the process.

]]> Vulnerability Detection in ActiveX Controls through Automated Fuzz Testing. This paper describes the various attack surfaces of ActiveX controls, the techniques used to test those attack surfaces, and also some results obtained by testing a large number of downloaded ActiveX controls. It may also give some insight into why the Securing Your Web Browser document suggests disabling ActiveX in the Internet Zone of Internet Explorer.

Signed Java Applet Security: Worse than ActiveX?

2008-06-03T18:38:12Z

Hi, it's Will again. ActiveX vulnerabilities seem to be getting a lot of attention lately. However, Java applets are also a concern. ]]> sandbox in your web browser. This model prevents a Java applet from accessing sensitive resources, such as your file system or registry. So, barring vulnerabilities in the Java Virtual Machine (JVM), Java applets should not have the ability to do anything malicious on your system. That was the case with the JDK 1.0 security model.

Starting with version 1.1, Java included support for signed applets. These applets, which can run in your web browser as the result of viewing a web page, are not limited by any sandbox and can do just about anything that native code can. In other words, a signed Java applet should be treated the same as an EXE file on Windows.

When a web page attempts to run a signed Java applet, the Java Runtime Environment (JRE) will prompt the user before executing the code. When a Java applet without a trusted certificate is started, the JRE will, by default, still allow the user to execute the code. Some versions of JRE may warn the user that the digital signature cannot be verified. For example, the following dialog is presented when the JRE encounters an applet with an untrusted signature, such as a self-signed applet:

If the Java applet is signed with a trusted certificate, the user will still be prompted. However, the option to Always trust content from this publisher is enabled by default. This means that if you run a signed Java applet from one particular vendor, you will trust all Java applets from that vendor by default, regardless of the site that is hosting them. The following dialog is presented when a Java applet with a valid signature is started. Note the default option of trusting all applets signed by that publisher.

Now let's consider the vulnerability remediation steps regarding a signed Java applet. With ActiveX, Microsoft has the ability to deploy a kill bit for a control that is vulnerable. Everybody who is set up for automatic updates from Microsoft will receive the kill bit, which prevents the control from being used in Internet Explorer. But what happens if a vulnerable signed Java applet is discovered? There is no Java analogy to the ActiveX kill bit. An attacker can host a copy of the Java applet on his or her own web site, and that applet will still have a valid digital signature. Keep in mind that just like with ActiveX, a digital signature gives no indication of the safety of running the code. It can only indicate that the code was actually written by the organization that is listed on the signature. And even then, the user has to trust that the Certification Authority (CA) did due diligence in verifying the identity of the code signer.

This lack of remediation options is why I believe that from a security perspective, signed Java is about on par with ActiveX... circa 1996. Internet Explorer started supporting the kill bit and blocking ActiveX controls with invalid signatures in version 4, which was released in 1997.

So how can you protect yourself against malicious or vulnerable signed Java applets? The easiest way is to disable Java, as explained in our Securing Your Web Browser document. If you need to use Java, there are other options that can restrict the use of signed Java applets:

The option to Allow user to grant permissions to signed content can be disabled. With this option disabled, unsigned applets will still run in the Java sandbox. But any signed applet will be denied.
The option to Allow user to grant permissions to content from an untrusted authority can be disabled. Unsigned applets will still run, as with the above option. Applets that are signed with a trusted certificate authority can also run. But applets that have an untrusted signature, such as a self-signed applet, will be blocked.
The options Check publisher certificate for revocation and Enable online certificate validation should be enabled. These options will enable further validation of Java certificates. Note that these options are not enabled by default.

The following dialog shows the relevant options. These options are available in the Java Control Panel item for Windows, in the Advanced tab, listed under Security. Other platforms may require different steps.

From the user awareness point of view, if you are ever presented with a dialog that is requesting permission to run a signed Java applet, keep in mind that the code may be malicious. If you do not trust both the Publisher and the From fields in the dialog, you should not run the application.

Is Your Adobe Flash Player Updated?

2008-05-29T22:42:15Z

Hey, it's Will. As you may already be aware, there is active exploitation of a vulnerability in Adobe Flash. So, it's a good idea to make sure that you have the latest version of Flash Player, which, at the time of this writing, is 9.0.124.0. Even if you think that you are up to date, can you be sure? ]]>
It is important to realize that a system may contain several instances of the Adobe Flash Player. The Adobe Flash Player plug-in installer for Windows will install only the Netscape-style plug-in for Flash, which is used by Mozilla Firefox, Opera, and other browsers that support plug-ins. The Adobe Flash Player ActiveX installer for Windows will install only the ActiveX version of Flash, which is used by Internet Explorer and other programs that use Internet Explorer components.

The situation that someone may run into is that the plug-in version of Flash may be completely up to date, but the ActiveX version is not, or vice-versa.

All Microsoft Windows systems should run the the ActiveX installer. If you have any browser other than Internet Explorer, also run the plug-in installer. Alternatively, visit the Get Flash Player page with every browser on your system to install the appropriate Flash Player versions.

Another cause for confusion is that Firefox allows plug-ins to be installed either system-wide or in a specific user's profile. As a result, a Flash plug-in that was installed in one manner may not be updated properly if the new version of Flash is installed in a different manner. Other browsers may have similar issues.

At the very least, make sure that you have attempted to upgrade to the latest version of Adobe Flash. But to make sure that you are protected, it would be wise to investigate whether your system has multiple versions of Adobe Flash Player, and update each of those accordingly.

Who has my cookies?

2008-05-15T19:21:16Z

Hi, Ryan Giobbi from the Vulnerability Analysis team making this post. The CERT/CC has been tracking cross-site scripting vulnerabilities for a long time, and the actual vulnerabilities haven't changed much over the years. However, some technology that was developed to make life easier can actually be exploited to expand the impact of a cross-site scripting attack. ]]>
Here's some background information on how some websites do authentication: many websites set cookies to identify, track, and authenticate users. Online services that use cookies for authentication are constrained by the browser's same origin policy. For example, the cookie set by http://mail.example.com cannot access the cookie set by http://www.example.com.

To support single sign-on, web applications may set one authentication cookie and structure their URLs to allow multiple sites to access the cookie. Under this architecture, a single XSS (cross-site scripting) vulnerability could affect numerous applications.

A few weeks ago, we saw a report of an XSS vulnerability in Google Spreadsheets over on Billy (BK) Rios's blog. These type of vulnerabilities are not rare, but this one was interesting because of its impact—Google uses single sign-on to manage access to many of their hosted applications.

Web application vendors can (and often do) plug XSS holes in their services to prevent exploitation of these types of vulnerabilities—but what can users do to protect themselves? The Securing Your Web Browser document has some good tips, and users should also consider how often they are logged into web applications. Certain XSS attacks (such as ones that steal authentication cookies) only work if the user is logged into the web application and has an authentication cookie on their system. To limit exposure to these types of vulnerabilities, users can uncheck "remember me on this computer" options on web-application login forms and can regularly delete cookies.

The Dangers of Windows AutoRun

2008-04-24T23:12:00Z

Hi, this is Will Dormann of the CERT/CC Vulnerability Analysis team. A few months ago, reports of infected digital picture frames hit the media. I was curious about how the malicious code was being executed, so I began investigating the Microsoft AutoRun and AutoPlay features.]]>

For certain device types, such as CD-ROM drives, Windows will automatically execute the program that is specified in the Autorun.inf file when the device is connected or when media is inserted. The security impact of this feature is that somebody with physical access to a Windows computer can run malicious code by inserting a CD-ROM into the drive. But we already know that physical access to a computer can give an attacker the ability to do just about anything, right?
When a drive icon is clicked in Windows Explorer, Windows will execute the program specified in the Autorun.inf file. In this case, user interaction is required for the code to execute. However, the AutoRun behavior can be unexpected, as it is common to believe that clicking the drive icon will display the contents of the drive, rather than executing code.

In the process of investigating AutoRun behavior, I noticed two interesting things:

With Windows Vista, the NoDriveTypeAutoRun registry value actually has the opposite behavior than what Windows has documented. In other words, if you think that you have protected yourself by restricting AutoRun with this registry value, you have actually put yourself at additional risk. We have published details about this issue as US-CERT Vulnerability Note VU#889747. The end result here is that a user may inadvertently execute code by clicking on the icon for a device, such as a USB thumb drive.
Although the documentation for NoDriveTypeAutoRun indicates that Windows will not use AutoRun features on USB mass storage devices, this does not necessarily mean that users can safely plug any USB device into their system. For example, a system will recognize Sandisk U3 USB devices as both a CD-ROM device and a USB mass-storage device. Considering that an attacker can easily modify the CD-ROM contents of a U3 device, you now have a way for an attacker to execute code of their choice on a Windows system by simply plugging in a small USB device. No other user interaction is required.

The information about malicious use of U3 drives is not particularly new. But how many systems have AutoRun disabled? One aspect that makes the problem confusing is that it is not obvious how to disable AutoRun precisely and effectively. VU#889747 originally listed several steps that appeared to be effective in my testing, but they also had the adverse effect of disabling MCN messages, which can prevent Windows from detecting when a CD-ROM or DVD is changed.

One of our readers has provided us with a workaround that disables AutoRun closest to the source, which is the Autorun.inf file itself. By importing the following registry key, the Autorun.inf file will no longer be used to determine AutoRun and AutoPlay actions:

REGEDIT4

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\IniFileMapping\Autorun.inf]

@="@SYS:DoesNotExist"

This setting appears to disable AutoRun behaviors without causing other negative side-effects. More details about this workaround are available in Nick Brown's blog entry Memory stick worms.

Vulnerability Analysis at the CERT/CC

2008-04-17T15:51:00Z

Hi, this is Art Manion, the Vulnerability Analysis team lead at the CERT Coordination Center (CERT/CC). For our first blog entry, I'd like to briefly explain our efforts to reduce software vulnerabilities.

]]> One approach is to remove known vulnerabilities from deployed software (from another angle, this means reducing the amount of time that software contains a particular vulnerability). We consider this "traditional" vulnerability analysis and coordination:

find out about a vulnerability, whether from a public source, private report, or internal discovery
analyze the vulnerability and consider threat scenarios
identify and securely contact vendors that may be affected
coordinate disclosure to private and public audiences

Summarized neatly, this all sounds easy enough. In practice, though, things aren't so simple:

There are a lot of vulnerabilities. Which ones are the most severe? What do I consider severe? What do you consider severe?
How should I expend effort to get the most out of my limited vulnerability analysis and response resources?
Which vendors produce, maintain, or distribute the vulnerable software? How do I contact those vendors and communicate securely with them?
If I find a vulnerability, how do I report it, and are there any risks associated with reporting?
Which disclosure practice do I follow? How much and what kind of information should go into an advisory?

The CERT/CC works closely with US-CERT (part of the Department of Homeland Security) on vulnerability analysis and coordination. For us, public vulnerability disclosure typically results in a US-CERT Technical Alert or Vulnerability Note.

Experience suggests that we will be dealing with vulnerabilities for years to come. Responding to vulnerability reports, as either a software producer or a consumer, should not be treated as an emergency or "one-off" event. Both software producers (vendors) and consumers (users) should develop vulnerability management capabilities that are built into normal business processes. For vendors, vulnerability management includes advertising ways to receive vulnerability reports, coordinating among internal business units and with external parties, being familiar with coordination and disclosure practices, and delivering vulnerability information and fixed software. For users, vulnerability management involves the following: awareness of new vulnerability information, inventory and patch management, risk assessment, configuration and change control, and consideration of procurement and support contract language.

Thinking about the subjective question about the severity of a given vulnerability has led us to research ways to make better decisions about how to respond to vulnerabilities. But that is a story for another entry.

What I've described above is focused on responding to vulnerabilities in already deployed software. We are also taking a more proactive approach to reduce the number of newly introduced vulnerabilities. This effort, which falls under the CERT Secure Coding Initiative, involves training developers, improving source-code analysis tools, and developing secure coding standards.

An administrative note—our blog is not going to have comments enabled, at least for now. If you'd like to provide feedback, please send us email using the link in the right sidebar. We'll consider updating entries based on feedback we receive.