Posts Tagged spoofing

Short-Term Memory

Sometimes I get the feeling that too many Internet users (especially the younger generation) view 1995, or the beginning of commercialized Internet as the start of time itself. More specifically, I notice how people tend to have a short-term memory when it comes to security issues. A recent example of this was all the creative network exploitation scenarios that arose from the great DNS cache poisoning scare of 2008: intercepting e-mails destined for the MX of users who didn’t really click on “Forgot Password,” pushing out phony updates, innovative twists on spear phishing, etc. The fact of the matter is that man-in-the-middle attacks were always a problem; cache poisoning makes them easier but their feasibility has always been within reason. My point is that vendors should address such weaknesses before the proverbial fertilizer hits the windmill.

Too often, short-term memory is the catalyst for reoccurring breaches of information. Sometimes I wonder what (if anything) goes through the mind of one of those celebrities that just got their cell phone hacked for the third time. Maybe it’s something like, “Oh.. those silly hackers! They’ve probably gotten bored by now and they’ll just go away.” Then I wonder how often similar thoughts enter corporate security (in)decision–which is likely to be why cellular carriers neglect to shield their clientele’s voicemail from caller ID spoofing and other shenanigans. Nonetheless, the amusing charade that 2600 pulled on the Obama campaign for April Fool’s Day was simply a case of people believing everything they read on the Internet.

Don’t get me wrong. I’ve seen some major improvements in how larger software vendors are dealing with vulnerabilities, but an overwhelming majority of their security processes are still not up to par. Short-term memory is one of those cases where wetware is the weakest link in the system.

The idea of the digital security industry using long-term memory to become more like insurance companies and less like firefighters is quite intriguing. Putting protective forethought into the equation dramatically changes the playing field. Imagine an SDLC where programmers don’t have to know how to write secure code, or even patch vulnerable code for that matter. I can say for sure that such a proposition will become reality in the not too distant future. Stay tuned…

Advertisements

Leave a Comment

Updating the Updater

Professor John Frink Updates

Attacks against security components have been fairly common on server operating systems for decades; on PC’s this wasn’t always necessary because of security models that resembled swiss cheese. Since the beginning of the 21st century, Microsoft has been working diligently to close obvious holes (for the most part.) As a result, researchers have shifted their focus to the attack surface of security-centric code on PC’s. Case in point; in the past several years we’ve seen loads of advisories released for vulnerabilities in anti-virus software. Read the Yankee Group’s “Fear and Loathing in Las Vegas: The Hackers Turn Pro” for a more in-depth analysis of this trend. One area in particular where I feel PC protection is lacking is automated software security update mechanisms; there is a lot of room for improvement.

According to Hewlett-Packard, Digital Equipment Corporation was the first in the industry to perform patch delivery in 1983. Prior to this, updates were commonly delivered on tape by private courier. At one of 2600’s HOPE conferences, Kevin Mitnick spoke about an analog attack he had used to compromise this process during the social engineering panel. The gist of it was that he wore a UPS uniform (procured from a costume store) and delivered the “update” tape to his mark with a login trojan on it. Later, Mitnick became known for using SYN floods and TCP hijacking against Tsutomo Shimomura. Some sources even refer to this sort of digital man-in-the-middle as “The Mitnick Attack.”

Many software update components don’t use public key infrastructure to cryptographically verify the validity of the update server (i.e. SSL) or the updated package (i.e. digital signature.) This is a problem. Impersonating the software update server is usually trivial. Wi-Fi access point impersonation, DNS cache poisoning, ARP spoofing, session hijacking, and compromising the legitimate update server are all possibilities.

Some applications–I’m not going to name any names–rely on HTTP (note that I didn’t say HTTPS) for downloading packages after checking for updates instead of using a separate file transfer manager program or internal update component. This is much easier to reverse engineer than a custom update solution. Sometimes the attacker can allow the real update server to carry out most of the process and simply shoehorn their malcode into the update session(s) after initial preconditions are met.

SSL won’t save the day either unless it’s implemented properly. I’ve seen plaintext updaters with digital signatures that are safer than some HTTPS updaters. Gentoo’s Portage Tree (emerge and ebuild) is a good example of an effective plaintext digital signature approach. See SECOBJADV-2008-01 (CVE-2008-3249) for a description of a software updater with an erroneous SSL implementation.

The issue is further complicated because software updaters themselves need to be updated in order to resolve such vulnerabilities. Typically this requires a major architectural modification. What’s worse is that breaking the updater would force users to manually update. Hoyvin-Glayvin!

Comments (2)

%d bloggers like this: