The Deliverator – Wannabee

So open minded, my thoughts fell out…

Archive for August, 2008

The Kaminsky DNS Attack – No End in Sight

Posted by Deliverator on 29th August 2008

Almost a month ago, I posted about a major new attack which Dan Kaminsky had found that would allow a attacker to poison a DNS server’s cache allowing the attacker to redirect traffic for an arbitrary domain. When Kaminsky first discovered the attack, a target server could be compromised in as little as 10 seconds. Patches to every major DNS server package have been released, but essentially all they do is increase the number of packets (and hence time) needed to compromise a server. A physicist named Evgeniy Polyakov in Moscow decided to find out just how much time the new patches bought. He connected two computers to a fully patched DNS server running the *nix standard BIND DNS server software over gigabit ethernet and let her rip. The answer, which serves as a sort of worst case scenario for a successful attack, was a mere 10 hours. While most attackers don’t exactly have a gigabit ethernet interface to an ISP’s dns server, it is possible that an attacker could plant a trojan within an ISP where it would be able to attack the dns server at LAN speeds. The combined bandwidth of a modern botnet is not to be underestimated as well. In short, even a fully patched system is potentially vulnerable.

While Polyakov explored a worst case scenario against a properly patched BIND system, not all the patches for major DNS server software provide even 10 hours of protection. Notably, Microsoft’s patch doesn’t do nearly as good job as others. One of the chief protections that the patch should provide is to randomize the UDP port used by the DNS server to request information from top level servers. From what I’ve read, Microsoft’s patched DNS server only makes requests from a range of 2500 some odd UDP ports, vs 64k+ possible ports for a patched BIND server. This makes it far easier for an attacker to compromise a Microsoft DNS server than a *nix one. Lets take a step back and explain why, by doing a simplified rough outline of how the attack works.

For an attack to succeed an attacker has to cause the DNS server to issue a request for information pertaining to whatever domain the attacker wishes to poison. The attacker induces the DNS server to make such a request by requesting information regarding a non-existent subdomain of the domain to be poisoned. The subdomain doesn’t exist, so the DNS server couldn’t possibly already have information stored in its cache about it. So, the attacker issues a request for somerandomfoo.google.com, for example. The attacker, knowing that the DNS server has just passed the request on, switches roles and pretends to be the responder and floods the DNS server with response packets. The forged response packets contain revised DNS servers for the domain that the attacker wishes to hijack. The packets would presumably set a very high TTL (time to live) on the bogus information, so that the ISP’s DNS server keeps it in its cache for a VERY long time. In my admittedly brief research, it seems like the maximum time as per RFC is 68 years, although it is unlikely that information would be cached for that length of time in any real world scenario. At the rate that basic underlying services like DNS are showing their cracks, I would be very impressed if the current DNS system lasts the next 6.8 years, much less 68. Still, being able to cause all of a major ISP’s subscribers to visit fake google when they type google.com in their browsers, would be extremely valuable to a malicious hacker, even if the cache poisoning only lasted for a few hours.

In order for a forged response packet to be accepted by the ISP’s DNS server, it has to have the correct transaction id. The transaction id is a pseudo-random 16 bit number that is generated by the DNS server when it makes a request. The server only accepts the response as genuine if the response packet contains the same transaction id# it used when it issued the request. It used to be that these transaction id #’s were issued in a decidedly non-random fashion…1, 2, 3, 4, etc. Which made it decided easy to guess what transaction id # the server would want next. DNS hijacking is far from new. Eventually, DNS server software wised up to the fact that it might be a good idea to randomize the transaction id to make it harder to guess. Still, there are only 2^16 possible values it can take on and you can flood a server with a LOT of packets. Another factor was needed to make DNS harder to hijack, WITHOUT fundamentally breaking the way DNS works. One way to add a factor is to issue each request from a unique UDP port#. Then an attacker not only needs to hit upon the right transaction id, but he has to deliver it to the right port. Up until recently, many DNS servers issued their requests from a static, unchanging port, or issued requests in sequence or in some other way which would allow an attacker to guess what port was going to be used to issue the next request. The primary thing the recent batch of patches to DNS software was designed to do is to increase the number of possible ports from which a DNS server might issue a request and increase the randomness by which a DNS server decides which port to use. Microsoft’s failure when compared to BIND’s implementation is that they only add 2500 ports worth of randomness while BIND adds some 64 thousand.

One problem that has cropped up with this source port randomization approach is that many DNS servers are behind some form of NAT router/firewall device, in order to shield them from attack. The problem is that many NAT routers de-randomize the outbound requests and issue them from sequential port numbers instead, effectively making a patched server no more effective in combating the attack than an unpatched server. Dan Kaminsky’s site has a neat video created by Clarified Networks from his source data, which graphically shows the patching of servers over time. One of many interesting trends which can be seen in the video is that while the number of patched servers goes up markedly over time to about 65% at the end of the video on 08/03/08, the numbers of patched servers behind some form of derandomizing NAT also goes up with time, so it appears that some ISPs are taking action in applying the patch, but don’t understand exactly what it does or how their infrastructure is effectively making the patch worthless. You can check out the video at the end of this post or download a much higher quality version.

I think the upshot of all this is that the patches currently going around might buy your ISP some time, but that it is not meant as a final solution to DNS cache poisoning. At best, I think the patch helps make it clear to a network admin at the ISP that an attack is underway (suddenly receiving tens of thousands of bad response packets is kinda a dead giveaway) and hopefully gives them enough time (assuming they have planned for it in advance) to do something about it.

Near term, people far smarter than I are hard at work trying to figure out additional techniques that can be used to foil a Kaminsky style attack on a DNS server, without breaking the existing DNS standard and putting a severe lurch in the internet as we know it. Unfortunately, many of the proposed ideas that have the virtue of staying within the standard would also increase DNS traffic, particularly on the root name servers, to such an extent that you are back to that minor issue of BREAKING THE INTERNET.

One such idea, known as debouncing, stays within the DNS specification. The idea of debouncing is to issue any query twice and if you get back two different responses (indicating that one of the responses was bogus), to keep on issuing the request (with a new transaction id and port #) until you have reached some statistical confidence level that the answer is correct. There is simply no way an attacker is going to be able to get two transaction id + source port hits in that rapid a sequence. Unfortunately, this would at minimum double the load on the internet’s root nameservers as well as increasing query latency. Apparently, there simply isn’t that degree of excess capacity in the system (which instantly makes me ask why such a critical piece of internet infrastructure runs that close to capacity).

Another idea, which has long been suggested as a way to eliminate DNS hijacking skulduggery is to switch DNS from using UDP to TCP. UDP is highly efficient for simple queries because it is a connectionless protocol. You blast out a request and the other end hopefully gets the message and blasts back a response. Total number of packets sent with UDP = 2. TCP on the other hand requires a minimum of 6 or possibly 7 packets, depending on how willing you are to trust that all parties have implemented the RFC defined version of TCP. With UDP, it is possible to forge the source IP address, as no attempt is made by the recipient to verify the sender of the packet before acting on the data. The ability to spoof arbitrary UDP packets is ultimately what makes an attack like this possible. An attacker can blast out UDP packets all day long, without the receiving server being able to easily block them, because the attacker’s true IP isn’t in a single one of those packets. With TCP, however, the client and server must do a “three way handshake” before exchanging data, so it is pretty much impossible for joe random hacker to easily pretend to be someone else. Unfortunately, this method would increase traffic on the root nameservers even more than debouncing.

The neatest near term fix is being termed the 0x20 hack. It has the virtue of staying within existing DNS specifications AND not breaking the internet. Yay! The 0x20 hack relies on the fact that while the case of character in a domain name is not deemed to be significant, it is preserved during queries and replies. I.e. www.google.com is not considered to be different than wWw.GOOgle.COM. The idea as to how this applies in our case to spoil Joe Hacker’s day is as follows.

1. Hacker makes a request to the ISP’s DNS server for somebogussubdomain.google.com
2. ISP’s cleverly patched DNS server randomly changes the case of some of the letters in the request so that it now reads something like SomEboGussuBDOMaiN.GoOgle.cOm. (bear with me here, I know it looks goofy) and passes the request on to the root server. Root server responds back the information your ISPs DNS server requested and preserves the goofy casing.
3. Your ISP examines the flood of incoming requests and only accepts the one with the goofy casing that matches what it sent out, plus port number and transaction id.

Essentially, by messing with the casing of the letters, the ISP DNS server has introduced another random factor that an attacker would have to guess. It adds one bit of randomness for each letter. Unfortunately, you don’t get any benefit for number in a domain, as there is no “case” to numbers. The effectiveness of this method goes up with each additional letter, so the longer a domain name the better it works. Unfortunately, a lot of the most likely targets for cache poisoning attacks are heavily trafficked domains, which tend to have short names. Just take a look at some of the top sites in the world:

-ebay.com
-google.com
-msn.com
-yahoo.com
-live.com
-myspace.com
-paypal.com
-baidu.com

By and large, the top trafficked sites only gain 6-9 bits of protection from this method.

The 0x20 hack is certainly not the final solution, but is one of the few proposed methods which might actually mitigate the problem without breaking much in the process. Many of the Internet standards we have now, such as DNS, BGP and TCPv4 were designed literally decades ago in an inherently more trustful time. It is a small miracle that they have remained resilient and adaptable over their lifetimes, but the cracks are definitely showing. Longer term, there are going to be some real growing pains in migrating to new, incompatible Internet standards which will have security and risk mitigation as some of their main design criteria.

Posted in General, Rants and Raves, Security, Tech Stuff | No Comments »

Thoughts on the Samsung Q1 Ultra Premium UMPC

Posted by Deliverator on 20th August 2008

I’ve received my new Samsung Q1 Ultra Premium (with XP Tablet 2005 NOT Vista) and have had a few days to let my feelings about the device gel a bit. I thought I might take some time to share some of my thoughts and recommendations.

The Good:

-The 1.3 Ghz Intel Core Solo processor in the Q1 UP is a huge improvement over any of the previous processors used in UMPC devices. This system with XP and half the ram feels snappier than my core duo wielding Lenovo with Vista and 2 GB. I can play back high resolution video with no dropped frames, something every previous UMPC I’ve tried has choked upon.

-The 1024*600 resolution screen with LED backlighting is beautiful. It provides much better screen real estate than previous UMPC devices without feeling squinty. The LED backlighting is extremely bright. It is easily brighter than either my 24″ Samsung desktop monitor or Lenovo Z61m.

-Comes with a minimum of pre-installed crapware.

-Very long battery life (5-6 hours of active use with WiFi and Bluetooth in use)

-Quick battery recharge time

-Built in SD card reader is full SDHC compliant, which means you can use 4+ GB capacity SD cards with it. This combined with the excellent screen will make this device very useful for reviewing/culling photos from my D80 without having to lug around a full laptop.

-Built in disk imaging utility which can be used for point in time snapshot backups.

-Dual microphones, stereo speakers and dual cameras all make this an excellent platform for video conferencing and VOIP use.

-There is an unused mini-PCI Express card slot inside the unit. Brave modders have already used this slot to add WWAN modules and other goodies to the Q1 UP. The ram module can also be upgraded to at least 2 GB, although the slot is much less accesible than the mini-PCI Express slot. For those of you wanting 2 GB from the get go, the Vista version features 2 GB and you know….you can always “downgrade” to XP.

-The Q1 UP has a USB port on the right side as well as on the top of the unit. This flexibility in where you plug in WWAN dongles, wireless mice and the like is really nice and an improvement over previous generations of Samsung UMPC devices.

The Bad:

-The screen has a layer of plastic (probably intended as a sort of integral screen protector) above the actual resistive touch panel. On my unit, this piece of plastic seems ill fitted and bulges outward slightly causing a small air gap between the touch panel and top surface, particularly on the left side of my unit. This has several negative, detrimental effects. Firstly, it requires one to press down harder than normal to register a tap. Secondly, it reduces the precision of the touchscreen as the stylus has a tendency to slip as this layer deforms. Thirdly, it is difficult to register a tap and hold properly. Fourthly, since the amount of pressure to register a tap isn’t uniform across the screen, one finds oneself having to be extremely deliberate about taping the screen. Fifthly, the difference in the amount of air caught in between the surface layer and the digitizer causes a sort of ripply, uneven glossy appearance which I find distasteful. I wish this issue was confined to just my unit, but I’ve seen reports of this issue on a couple other blogs, including from Kevin Tofel from the well respected mobile tech blog jkOnTheRun. I’m considering exchanging the unit with Amazon to see whether the roulette wheel coughs up a better unit.

-The 80 GB Toshiba HDD is pretty pokey performance wise. Quick benchmarks put its sequential read/write speed at around 22 MB/s. To put this in perspective, most run of the mill desktop hard drives turn in a number about 3 times faster. Random reads and writes suffer even more, probably due to the relatively low spindle speeds of 1.8″ hard drives. In actual use, I’ve mainly noticed this when launching larger executables such as Firefox. Once launched, application performance is excellent. I may consider swapping in a solid state disk at some point in the future, once they have gone down in price and up in capacity a bit. As I’ve noted in the past, in car use tends to be rather detrimental to hard disks.

-The Samsung Q1 has four touch areas at the top of the screen. These areas control volume up and down, pops up a display adjustment utility and utility which serves the sole purpose of remapping the functions provided by the fourway hat. It is trivially easy to accidentally brush against these buttons and I constantly find myself zeroing my volume or popping up a utility by complete accident. I’ve attempted to simply disable these buttons entirely, without much luck. I’ve managed to disable to on screen displays from popping up, but not the functions of the buttons themselves.

-All the input options included border on being mediocre:

The chicklet split qwerty keyboard is inferior to those implemented on blackberries and similar devices for the better part of the last half decade. It is not backlit or frontlit in any way, which makes it of limited usefulness for couch surfing and home theater use. The enter key is not on the keyboard itself, but is found as a round button in the center of a four way hat switch on the right side of the screen. This requires constant hand movements off the keyboard while typing. In addition, numbers are only available as second functions of the alphabetic keys, even though there is ample room on the device casing for a dedicated row of number keys. There is no delete key, even as a second function of another key, from what I can tell, or provision for f1-f12.

The thumb mouse found to the left of the screen is not only sloppy, but it is extremely difficult to make the cursor move accurately over shot distances. While an improvement over previous Q1 pointing devices, it falls frustratingly short of the excellent thumb driven pointers of the Toshiba Libretto series of over a decade ago or the track sticks that are standard issue on Thinkpads. The left and right mouse buttons, found to the right of the screen are small and are completely flush with the casing and are of the same material and texture as the surrounding casing. This makes it difficult to position ones fingers on them by tactile sensation alone. I may epoxy some grit to their surface to make them easier to use.

Inking is sub-par due to the lack of proper human interface device profile drivers for the touchscreen as well as the aforementioned issues with the poorly fitted integral “screen protector.”

Recommendations:

-There is an excellent free on screen keyboard called Zero Weight Keyboard. It is extremely well designed and customizable, and was designed with UMPC devices specifically in mind. The only minor downsides to it imo are that it uses the .Net Framework, which I would otherwise remove, and it takes up a lot of ram.

-The included hand strap and felt-like carry pouch are pretty well useless for their intended purposes. Otterbox makes a robust hard shell case for the Q1 UP which adds a great deal of shock/drop protection without adding greatly to the device’s size or blocking any ports/functions. The case has a hand strap for one handed use and there is a shoulder strap available at additional cost. It looks like any halfway decent camera bag strap would attach equally well and at lower cost than the Otterbox one.

-Ram Mounts has a number of vehicle mounting options for the Q1 UP and is the first to market (to my knowledge) with a device specific mount for the Q1 UP.

Posted in General | 1 Comment »

The Next Carputer Project

Posted by Deliverator on 14th August 2008

My car was broken into in the middle of the night a couple weeks ago. It was parked right in front of my house at the time. The thief broke in through the rear passenger side window and proceeded to remove most of my car computer system through brute force. The irony is that very little of the equipment removed is likely to be operable/sellable as a great number of cables had to be clipped in order to facilitate a hasty removal. I was planning to replace my carputer this year anyways, so I am not too put off about the actual theft, save for having my none too great faith in human goodness lowered a notch. My comprehensive insurance policy took care of the cost of the damage to the car, minus a $100 deductable, but it has taken the better part of the last two weeks, and a lot of leg and phone work, to get the car itself put back in order. Oh, and of course the equipment wasn’t covered without an additional policy rider, which I wasn’t told I would need. Safeco was less than proactive in working with me to get my life back to order and I will probably be redirecting my hard earned $ elsewhere in the near future as a result.

On the positive side of things, I get to build out a new car computer. My inclination, this time around, is not to go with discrete components, requiring a great deal of wiring, but instead to base the system around a UMPC (Ultra Mobile PC). I wasn’t too impressed with the first generation of UMPC devices. They were, by and large, poor performing with a lot of ill thought out hardware design and layout issues. A lot of the first generation of devices used the anemic Intel A110 processor. Couple this with 1 GB of ram, the bloated mess that is Vista and a much higher than projected price point made them non starters in the marketplace. I think this seriously delayed the production of a second, better generation of UMPC devices, mainly in favor of Netbooks like the all popular eePC. Unlike UMPC devices, Netbooks actually managed to meet their price points and were largely based around lighter weight OSes like XP and Linux. Unfortunately, a Netbook doesn’t meet my in car needs by a longshot. Thankfully, newer, more refined UMPC devices have recently entered the marketplace.

I was particularly attracted to the Samsung Q1 Ultra Premium. It has a lot of features that seem to make it ideal for the particular challenges of in vehicle computing. It has a LED backlit 1024×600 resolution 7″ display, which should both be brighter and higher in resolution than the pricey Xenarc 7″ previous mounted on my dash. While some people prefer the active, Wacom style digitizers found on a lot of Tablet PCs and some UMPCs, the Samsung’s resistive touchpanel is more suited to my use. With an active digitizer, you are forced to use a stylus, but with a resistive touch panel, you can substitute a fingertip in a pinch. While Samsung has done little to bring the price down to anything resembling Microsoft’s original vision for UMPC devices, they have greatly improved on the original concept. The latest Samsung models have split key qwerty keyboards (the original was just a slate), improved wireless and connectivity options, a faster processor and a choice of a tablet enhanced version of XP or Vista. I figured the Q1 UP was a close enough match to my needs that I ordered one via Amazon. Not much point asking which OS I chose…

Part of my reason for choosing a UMPC over discreet components was to have something which I can remove from the car and take with me. If there isn’t something in the car, its not bloody likely going to be broken into. I’m hoping the UMPC proves versatile enough to replace my laptop while on the run. Since I started carrying around my Nikon D80 (and lenses) around all the time, my backpack has gotten a wee bit on the heavy side of comfortable.

I plan on mounting the Q1UP using a bracket from Ram Mounts. Ram Mounts is a local, Seattle company which makes all sorts of clever vehicle mounting solutions for everything from cell phones to laptops. I’ve not used them in the past, but I’ve heard good things. Their product is also specifically designed for the Q1UP, unlike a lot of generic mounting brackets which have a tendency to block access to ports.

Once mounted, the chief issue becomes how to simply and easily interface the Q1UP to peripherals. One of my chief disappointments the last time I was revamping my car computer was that basically nobody made a reasonably priced car stereo with an audio input jack. I had to use the less than ideal solution of an in-line FM modulator to get my computer audio into my car’s stereo system. Now in these scary modern times where everything has to be able to plug into an ipod, virtually all car stereos have auxiliary input jacks on their front panel. I wasn’t sure I wanted to clutter up my dash with an audio cable, as well as potentially damage the audio connector on the Q1UP from overuse, so I began looking for other solutions. Turns out that some reasonably priced car stereos now can take auxiliary audio input via Bluetooth A2DP profile, as well as Bluetooth headset profile. The Q1UP supports Bluetooth 2.0, so I’ll probably get a new car stereo, even though the thief didn’t steal my current one.

I’ll probably use my Holux M1000 Bluetooth GPS unit rather than a USB GPS, to avoid cabling. For internet connectivity, I will be using a Cradlepoint PHS300 Wifi to Cellular router, with uplink via a Sprint EVDO expresscard. I’ve been using this battery powered wifi router / cellular card combo with my laptop (and Nokia N810) for several months now and have really enjoyed being able to go anywhere and have connectivity without needing to have an obtrusive dongle coupled to my laptop as a disaster waiting to happen. When all is said and done, the only thing I should need to plug in is power. If I start needing to plug in more peripherals, I may consider a wireless USB hub.

Well, the parts are on order. I’ll try and produce some followup to let anyone who is interested know how well (or not) everything comes together in practice.

Posted in CarPuter, Portable Computing/Gadgets, Rants and Raves, Tech Stuff | 2 Comments »

Major Security in Vulnerability in DNS

Posted by Deliverator on 2nd August 2008

Dan Kaminsky is a well known and respected security researcher. In recent months, he has alluded to a widespread vulnerability in DNS servers and clients, but has publicly kept fairly tight lipped as to the exact nature of the vulnerability in order to give ISPs, OS and device manufacturers a chance to release updates to fix address the issue. Many major ISPs and OS vendors have done a coordinated fix, in order to minimize the window for potential exploitation. Unfortunately, not everyone seems to have gotten the memo and this will have very unfortunate consequences for users of such devices/services. Dan will spill the beans officially at the upcoming Blackhat computer conference, but enough details have leaked out from Dan and sources close to him that the nature of the vulnerability alluded to by Dan is now believed to be known and is being actively exploited “in the wild.” I highly recommend visiting Dan’s site, DoxPara Research and click on “Check My DNS” to see if your ISP’s DNS is vulnerable. If your ISP’s DNS is vulnerable, I suggest contacting them to inquire as to what their lazy admins are up to and then switch your computers to use OpenDNS or other more responsible DNS server until your ISP gets its house in order.

The vulnerability appears to allow an attacker to poison the cache of affected DNS servers, allowing them to inject bogus nameservers into your ISP’s cache for a given domain and set a very high time to live on the cached information such that it only expires after a very long period. This in effect allows attackers to redirect queries for any arbitrary website.

For instance, they could redirect traffic for google.com to a look alike page which installs viruses or other malware on your computer. Or, they could direct traffic for yourbank.com to a lookalike page and steal your online banking information. They could redirect traffic for common antivirus packages such that your copy of Norton never updates itself or Windows Update fails to run. The possibilities are almost endless. Unlike phishing attacks which rely on a credulous user to click on a link in an email, this attack corrupts your service provider in such a way that all users of an ISP, even those with a modicum of common sense, will be affected simultaneously. More advanced users who are in the habit of checking SSL certificates and the like are less likely to get bit, but the potential for creative larceny on this one is soo high that I’m certain that all the potential ramifications of this attack have yet to be worked out.

Even assuming that ISPs get their act together quickly, you tend to find DNS servers shoehorned into all manner of commodity hardware and these are less likely to be patch promptly, either from lack of action on the part of device manufacturer or lack of awareness by the device owner/administrator. I fully expect to see more localized versions of this attack for years to come. Batten down the hatches folks, this storm is going to be a bad one.

Posted in General, Operating Systems, Security, Tech Stuff | No Comments »