Security – Page 4 – Technological Musings

Detecting DNS cache poisoning

I spoke with a good friend of mine last week about his recent trip to NANOG. While he was there, he listened to a talk about detecting DNS cache poisoning. However, this was detection at the authoritative server, not at the cache itself. This is a bit different than detection at a cache because most cache poisoning will happen outside of your domain.

I initially wrote about the Kaminsky DNS bug a while back, and this builds somewhat on that discussion. When a cache poisoning attack is underway, the attacker must spoof the source IP of the DNS response. From what I can tell, this is because the resolver is told by the root servers who the authoritative server is for the domain. Thus, if a response comes back from a non-authoritative IP, it won’t be accepted.

So let’s look at the attack briefly. The attacker starts requesting a large number of addresses, something to the tune of a.example.com, b.example.com, etc. While those packets are being sent, the attacker sends out the responses with the spoofed headers. Since we are now guessing both the QID *and* the port, we miss a lot because the port is incorrect.

When the server receives a packet on a port that is not expecting data, it responds with an ICMP message, “Destination Port Unreachable.” That ICMP message is sent to the source IP of the packet, which is the spoofed authoritative IP. This is known as ICMP backscatter.

Administrators of authoritative name servers can monitor for ICMP backscatter and identify possible cache poisoning attacks. In most cases, there is nothing that can be done directly to mitigate these attacks, but it is possible to identify the cache being attacked and notify the admin. Cooperation between administrators can lead to a complete mitigation of the attack and protection of clients who may be harmed.

This is an excellent example of the type of data you can identify simple through passive monitoring on your local network.

They’re Watching You… (Book Review: Little Brother)

My good friend Wil Wheaton (yeah, we’ve never met.. or talked…) mentioned a captivating book he read a few months ago. What really caught my attention was that he handed the book off to his son because he thought it was a book he could share with him. Having children myself, I decided to take a look at the book to see what all the fuss was about. That book is called Little Brother .

Little Brother is a book about a teenager caught up in global events that forever change his life. After a terrorist attack in his neighborhood, the Department of Homeland Security swoops in to save the day. What follows is a terrifying look into the future of our own country as privacy erodes and Big Brother takes over.

Cory Doctorow weaves a tale that is not only believable, but may be an eery foreshadowing of real events. It is a glaring reminder that we, as citizens, must ensure that the government continues to serve rather than control us.

I heartily recommend checking this book out. Cory has released Little Brother under the Creative Commons License and has it available as a free download on his website. I strongly encourage you to support Cory and buy a copy if you like the book. And if you like Cory’s work, his website has free downloads of other stories he has written.

Steal the Net’s Identity

Imagine this. You wake up in the morning, go about your daily chores, and finally sit down to surf the web, read some news, check your mail, etc. A some point, you decide to log in to your bank to check your accounts. You get there, login, and you’re greeted with a page explaining that the site is down for maintenance. Oh well, you’ll come back later. In the meantime, someone drains your account using the username and password that you just graciously handed them, not realizing that the site you went to was not where you intended to go.

Sound familiar? Yeah, I guess it sounds a bit like a phishing attack, though a tad more sophisticated. I mean, you did type in the address for the bank yourself, didn’t you? It’s not like you clicked on a link in a email or something. But in the end, you arrived at the wrong site, cleverly designed, and gave them your information.

So how the hell did this happen? How could you end up at the wrong site when you personally put in the address, your computer has all the latest in virus scanning, firewalling, etc? You spelled it right, too! It’s almost as if someone took over the bank’s computer!

Well, they did. Sort of. But they did it without touching the bank’s computers at all. They used the DNS system to inject a false address for the bank website, effectively re-directing you to their site. How is this possible? Well, it’s a flaw in the DNS protocol itself that allows this. The Matasano Security blog posted about this on Monday, though the post was quickly removed. You may still be able to see the copy that Google has cached.

Let me start from the beginning. On July 8th, Dan Kaminsky announced that he had discovered a flaw in the DNS protocol and had been working, in secret, with vendors to release patches to fix this problem. This was a huge effort, one of the very first the world has ever seen. In the end, patches were released for Bind, Microsoft DNS, and others.

The flaw itself is interesting, to say the least. When a user requests an address for a domain, it usually goes to a local DNS cache for resolution. If the cache doesn’t know the answer, it follows a set of rules that eventually allow it to ask a server that is authoritative for that domain. When the cache asks the authoritative server, the packet contains a Query ID (QID). Since caches usually have multiple requests pending at any given time, the QID helps distinguish which response matches which request. Years ago, there was a way to spoof DNS by guessing the QID. This was pretty simple to do because the QID was sequential. So, the attacker could guess the QID and, if they could get their response back to the server faster than the authoritative server could, they would effectively hijack the domain.

So, vendors patched this flaw by randomizing the QID. Of course, if you have enough computing power, it’s still possible to guess the QID by cracking the random number generator. Difficult, but possible. However, the computing power to do this in a timely manner wasn’t readily available back then. So, 16-bit random QIDs were considered secure enough.

Fast forward to 2008. We have the power, and almost everyone with a computer has it. It is now possible to crack something like this in just a few seconds. So, this little flaw rears its ugly head once again. But there’s a saving grace here. When you request resolution for a domain name, you also receive additional data such as a TTL. The TTL, or Time To Live, defines how long an answer should be kept in the cache before asking for resolution again. This mechanism greatly reduces the amount of DNS traffic on the network because, in many cases, domain names tend to use the same IP address for weeks, months, and, in many cases, years. So, if the attacker is unsuccessful in his initial attack, he has to wait for the TTL to expire until he can try again.

There was another attack, back in the day, that allowed an attacker to overwrite entries in the cache, regardless of the TTL. As I mentioned before, when a DNS server responds, it can contain additional information. Some of this information is in the form of “glue” records. These are additional responses, included in the original response, that helps out the requester.

Let’s say, for instance, that you’re looking for the address for google.com. You ask your local cache, which doesn’t currently know the answer. It forwards that request on to the root servers responsible for .com domains using a process known as recursion. When the root server responds, the response will be the nameserver responsible for google.com, such as ns1.google.com. The cache now needs to contact ns1.google.com, but it does not know the address for that server, so it would have to make additional requests to the root servers to determine this. However, the root server already includes a glue record that gives the cache this information, without the cache asking for it. In a perfect world, this is wonderful because it makes the resolution process faster and reduces the amount of DNS traffic required. Unfortunately, this isn’t a perfect world. Attackers could exploit this by including glue records for domains that they were not authoritative for, effectively injecting records into the cache.

Again, vendors to the rescue! The concept of a bailiwick was introduced. In short, if a cache was looking for the address of google.com, and the response included the address for yahoo.com, it would ignore the yahoo.com information. This was known as a bailiwick check.

Ok, we’re safe now, right? Yeah, no. If we were safe, there wouldn’t be much for me to write about. No, times have changed… We now have the power to predict 16-bit random numbers, overcoming the QID problem. But TTL’s save us, right? Well, yes, sort of. But what happens if we combine these two attacks? Well, interesting things happen, actually.

What happens if we look up a nonexistent domain? Well, you get a response of NXDOMAIN, of course. Well yeah, but what happens in the background? Well, the cache goes through the exact same procedure it would normally go through for a valid domain. Remember, the cache has no idea that the domain doesn’t exist until it asks. Once it receives that NXDOMAIN, though, it will cache that response for a period of time, usually defined by the owner of the root domain itself. However, since it does go through the same process of resolving, there exists an attack vector that can be exploited.

So let’s combine the attacks. We know that we can guess the QID given enough guessing. And, we know that we can inject glue records for domains, provided they are within the same domain the response is for. So, if we can guess the QID, respond to a non-existent domain, and include glue records for a real domain, we can poison the cache and hijack the domain.

So now what? We already patched these two problems! Well, the short-term answer is another patch. The new patch adds additional randomness to the equation in the form of the source port. So, when a DNS server makes a request, it randomizes the QID and the source port. Now the attacker needs to guess both in order to be successful. This basically makes it a 32-bit number that needs to be guessed, rather than a 16-bit number. So, it takes a lot more effort on the part of the attacker. This helps, but, and this is important, it is still possible to perform this attack given enough time. This is NOT a permanent fix.

That’s the new attack in a nutshell. There may be additional details I’m not aware of, and Dan will be presenting them at the Blackhat conference in August. In the meantime, the message is to patch your server! Not every server is vulnerable to this, some, such as DJBDNS, have been randomizing source ports for a long time, but others are. If in doubt, check with your vendor.

This is pretty big news, and it’s pretty important. Seriously, this is not a joke. Check your servers and patch. Proof of concept code is in the wild already.

Hide that data…

Data security is a pretty hot topic these days, especially when it comes to portable data. In fact, recent reports put airport laptop theft in the tens of thousands a week. Most, if not all, of these laptops have sensitive data on them, whether it be sensitive to the user, or sensitive to the user’s employer. And to make matters worse, most of these laptops lack anything beyond basic security such as a Windows logon password.

But is security that much of an issue? Is it that difficult to effectively secure the data on a laptop, or any other computer for that matter? Well, it depends on the type of security weâ€™re talking about. There are significant differences between securing data on a machine that is not powered as opposed to a machine that is powered and processing that data. In the latter case, firewalls, anti-virus software, and good programming practices will help to shield that data from nosy intruders.

If your machine is not powered, and the attacker can gain physical access, is there any way to protect the data? The answer is actually quite simple. There exists a product that can encrypt the data on your machine, either in chunks, or as a whole. In fact, with the latest version, you can even choose to have it deploy a decoy operating system, just in case youâ€™re being tortured for your password.. What is this wondrous software, and how much is it going to cost you? It’s called TrueCrypt, and it’s FREE.

TrueCrypt is a data encryption tool that runs on Windows, Mac OS X, and Linux. In fact, if you’re a decent programmer, you can probably get it to work on most any operating system as the source is freely available. The TrueCrypt website highlights the following as main features:

Creates a virtual encrypted disk within a file and mounts it as a real disk.
Encrypts an entire partition or storage device such as USB flash drive or hard drive.
Encrypts a partition or drive where Windows is installed (pre-boot authentication).
Encryption is automatic, real-time (on-the-fly) and transparent.
Provides two levels of plausible deniability, in case an adversary forces you to reveal the password:
1) Hidden volume (steganography) and hidden operating system.
2) No TrueCrypt volume can be identified (volumes cannot be distinguished from random data).
Encryption algorithms: AES-256, Serpent, and Twofish. Mode of operation: XTS.

There is a small amount of overhead when using encryption, but for most business applications, that’s an acceptable sacrifice for the security gained. Even without the use of hidden volumes or decoy operating systems, TrueCrypt offers a safe, secure manner by which you can protect your data. And, if you so choose, you can mode TrueCrypt volumes between computers and even operating systems, such as on a USB flash drive, while maintaining compatibility. In fact, I use this feature on a daily basis. I have a small 1 Gig USB flash drive with a TrueCrypt partition on it where I store some personal information such as a copy of portable Thunderbird. Included on the USB drive, in an unencrypted area, is a copy of TrueCrypt for Windows, Mac, and Linux. Thus, if I ever need to mount the drive on an operating system without a copy of TrueCrypt, I’ve brought my own.

TrueCrypt 6.0 was released over the July 4th holiday. This latest release adds some great new features. Parallel encryption and decryption, meaning it will use all of the processors (or cores) on a multi-processor system, was added. This allows TrueCrypt to run substantially faster on multi-processor systems. Also added was the ability to create and run hidden, or decoy, operating systems. Hopefully I’ll never find myself in a situation where such a decoy is needed, but perhaps James Bond will find this new feature useful. A number of minor enhancements were made as well, including a number of bug fixes. The current version history can be found here, and you can download the latest version here.

TrueCrypt is a wonderful tool, even for personal data protection. I recommend looking into it, and even integrating it into your everyday life. It’s a small change, barely noticeable for most, but the security benefits are staggering. Just don’t forget your password, ok?

Instant Kernel-ification

Server downtime is the scourge of all administrators, sometimes to the extent of bypassing necessary security upgrades, all in the name of keeping machines online. Thanks to an MIT graduate student, Jeffery Brian Arnold, keeping a machine online, and up to date with security patches, may be easier than ever.

Ksplice, as the project is called, is a small executable that allows an administrator the ability to patch security holes in the Linux kernel, without rebooting the system. According to the Ksplice website :

“Ksplice allows system administrators to apply security patches to the Linux kernel without having to reboot. Ksplice takes as input a source code change in unified diff format and the kernel source code to be patched, and it applies the patch to the corresponding running kernel. The running kernel does not need to have been prepared in advance in any way.”

Of course, Ksplice is not a perfect silver bullet, some patches cannot be applied using Ksplice. Specifically, any patch that require “semantic changes to data structures” cannot be applied to the running kernel. A semantic change is a change “that would require existing instances of kernel data structures to be transformed.”

But that doesn’t mean that Ksplice isn’t useful. Jeffery looked at 32 months of kernel security patches and found that 84% of them could be applied using Ksplice. That’s sure to increase the uptime.

I have to wonder, though, what is so important that you need that much uptime. Sure, it’s nice to have the system run all the time, but if you have something that is absolutely mission critical, that must run 24×7, regardless, won’t you have a backup or two? Besides which, you generally want to test patches before applying them to such sensitive systems.

There are, of course, other uses for this technology. As noted on the Ksplice website, you can also use Ksplice to “add debugging code to the kernel or to make any other code changes that do not modify data structure semantics.” Jeffery has posted a paper detailing how the technology works.

Pretty neat technology. I wonder if this will lead to zero downtime kernel updates direct from Linux vendors. As it is now, you’ll need to locate and manually apply kernel patches using this tool.

Pink Floyd – Goodbye Blue Sky

Getting screwed again by DRM

I’m definitely no fan of Digital Rights Management (DRM) in it’s current form. It’s intrusive, prevents me form taking advantage of something I purchased, and is generally an all around nuisance.

Take, for instance, DRM “enhanced” music. Most DRM licenses only allow you to listen to the music on authorized devices, and limits the number of devices you can put the music on. Some even go as far as to limit the number of times you can listen to a specific track. For some users this is ok, but what about those of us who change music players on a regular basis? Now we have to be concerned about the type of DRM being used and whether or not it’s compatible with our new player. It’s truly a nightmare.

There are even more issues with DRM, though. Let’s take a look at modern games. For consoles, DRM isn’t much of an issue yet. Every console is the same, so there are no compatibility problems if you have to get a new console, or if you want to take your game to a friend’s house to play. Downloaded content is a little trickier as it is often tied to the console it was downloaded on. Unfortunately, in many situations, if the console fails and you get a replacement, you must re-purchase the downloaded content. This isn’t always the case, but it does happen.

For PCs, however, the landscape is a little different. DRM is used to prevent piracy of games. Unfortunately, with the wide number of PC configurations, this can cause incompatibility problems. But even beyond the compatibility issues, there are sometimes worse problems.

Take, for instance, SafeDisc DRM by Macrovision. SafeDisc has been around for years and is often the cause of incompatibility problems with games. SafeDisc requires a special driver to be loaded into Windows that allows the operating system to validate the authenticity of games that use the SafeDisc DRM scheme. Apparently, Microsoft thought it would be useful to bundle a copy of the SafeDisc driver with Windows and has done so since Windows XP shipped about 6 years ago.

Recently, Elia Florio, from Symantec, discovered a vulnerability in the SafeDisc driver. This vulnerability allows an attacker to escalate their privileges, ultimately allowing them full control of the operating system. Thanks to Microsoft bundling this driver with Windows, even non-gamers are susceptible to this attack.

This highlights a major problem with DRM. Ensuring security is a pretty tough, complex job. The more complex the programming is, the harder it is to keep secure. DRM is intentionally complex, intending to prevent theft. As a result, it becomes very difficult to ensure that the code is secure. This is a perfect example of that problem. Unfortunately, it seems that this will only grow to be a larger problem as time goes on, unless we stamp out DRM.

Macromedia apparently has a fix for this problem on their website, and Microsoft is working on a solution as well. Microsoft has refused to commit to a delivery date, though. I would encourage you to update this driver as soon as possible, or, if you are a non-gamer, remove it completely.

Busted…

Imagine this. You turn on your computer and, unbeknownst to you, someone starts changing your files. Ok, so maybe it’s not so tough to imagine these days with all of the viruses, trojans, and hackers out there. But what if the files were being changed by someone you trusted? Well, maybe not someone you trust, but someone that should know better.

On August 24th, this exact scenario played out. All across the globe, files in Windows XP and Vista installations were modified with no notice, and no permission. But, this can easily be explained by the Windows Automatic Update mechanism, right? Wrong. The problem here, is that these updates were installed, regardless of the Automatic Update setting. Yep, you heard that right. These files were updated, even if you did not have automatic updates set to download or install updates.

This story was first broken by Windows Secrets on September 13th. The update seems to center around the Automatic Update feature itself. Nate Clinton, Program Manager for Microsoft’s Windows Update group wrote a blog entry about how and why Windows Update updates itself. Basically, the claim is that these updates are installed automatically because without them, Automatic Updates would cease to work, leaving the user with a false sense of security. He goes on to say that this type of stealth updating has been occurring since Automatic Updates was introduced. Finally, he mentions that these files are not updated if Automatic Updates are disabled.

This type of stealth updating is very disconcerting as it means that Microsoft is willing to update files without notifying the user. And while they state that Windows Update is the only thing being updated in this fashion, how can we believe them? What’s to prevent them from updating other files? Are we going to find in the future that our computers are automatically updated with new forms of DRM?

While I applaud Microsoft for wanting to keep our computers safe, and trying to ensure that the user doesn’t have a false sense of security, I disagree strongly with the way they are going about it. This is a very slippery slope, and can lead quickly into questionably legal territory. Should Microsoft have the right to change files on my computer without permission? Have they received permission already because I am using the update software? Unfortunately, there are no clear cut answers to these questions.

It’ll be interesting to see what happens from here as this has become somewhat of a public issue. Will Microsoft become more forthcoming with these updates, or will they proceed with stealth installations? Regardless, I don’t expect to see much of a reprisal because of this issue. It’s unfortunate, but for the most part, I don’t think most users actually care about issues such as this. In fact, most of them probably aren’t aware. Thankfully for those of us that do care, there are people out there keeping an eye out for issues like this.

Common PHP Regular Expression Security Issue

Stefan Esser (PHP Security Blog, Suhosin) recently posted an entry on his blog titled “Holes in most preg_match() filters” about a possible security issue that apparently escapes a lot of notice.

Let me explain the situation. PHP uses Perl Compatible Regular Expressions, PCRE, for pattern matching. In PCRE the carat metacharacter (^) is used to match the very beginning of the string, and the dollar-sign metacharacter ($) is used to match the end of the string. This is extremely useful to ensure that the expression you’ve written has matched the entire string.

However, PCRE_DOLLAR_ENDONLY is not used by default. This means that the dollar-sign metacharacter still matches to the end of the string, but it also matches is a newline character is at the end of the string. In other words, a newline character may, or may not be present at the end of the string and you won’t know either way by default.

So, how do we fix this then? Well, there are two ways. First, you can add a D modifier to the end of the regular expression like this :

preg_match(‘/^[a-z]+$/D’, $string);

Or, you can use the \z modifier like this :

preg_match(‘/^[a-z]+\z/’, $string);

Either method works, although from the comments at Stefan’s site, it looks like \z is more portable since Perl doesn’t support the D modifier.

Here is short script to “prove” this, as it were :

$badstring = urldecode(“test%0a”);
if (preg_match(‘/^[0-9a-zA-Z]+$/’, $badstring)) {
print “Test 1 MATCHES\n”
}
if (preg_match(‘/^[0-9a-zA-Z]+$/D’, $badstring)) {
print “Test 2 MATCHES\n”
}
if (preg_match(‘/^[0-9a-zA-Z]+\z/’, $badstring)) {
print “Test 3 MATCHES\n”
}

I’m posting this info for two reasons. First, it’s something programmers need to know. It’s important since security holes are a bad thing. Second, I’m guilty of this myself. phpTodo used the dollar-sign metacharacter without the D modifier, making my code somewhat insecure.

The good news is that I have corrected the problem and posted a new version. This is a precautionary measure, I don’t believe this adversely affected the security of the application, but better safe than sorry. Head over and grab the new version just to be on the safe side.

Windows .ANI Vulnerability – The plot thickens

The Internet Storm Center is reporting that the newly released Microsoft patch is causing some problems. There one known problem and a bunch of reports about other problems.

The first problem is with the Realtek HD Audio Control Panel. Apparently, the control panel won’t start after the patch is installed, complaining about a DLL being illegally relocated. Microsoft has released another patch to resolve this.

The other problems are currently undefined. Microsoft is asking that users experiencing problems contact their support line so they can investigate the issues.

Because of these problems, it may be worth it to take a second look at the ZERT patch. If you’re experiencing problems with the Microsoft patch, try uninstalling it and install the ZERT patch instead. It’s possible that you’ll experience similar problems with the ZERT patch, but it’s worth giving it a shot.

Good luck!