Terrorism Survival Bundle for Windows Mobile
Seems not to be a joke.
Entries Tagged "Windows"
Page 6 of 10
Bypassing Microsoft Vista's Memory Protection
This is huge:
Two security researchers have developed a new technique that essentially bypasses all of the memory protection safeguards in the Windows Vista operating system, an advance that many in the security community say will have far-reaching implications not only for Microsoft, but also on how the entire technology industry thinks about attacks.
In a presentation at the Black Hat briefings, Mark Dowd of IBM Internet Security Systems (ISS) and Alexander Sotirov, of VMware Inc. will discuss the new methods they’ve found to get around Vista protections such as Address Space Layout Randomization(ASLR), Data Execution Prevention (DEP) and others by using Java, ActiveX controls and .NET objects to load arbitrary content into Web browsers.
By taking advantage of the way that browsers, specifically Internet Explorer, handle active scripting and .NET objects, the pair have been able to load essentially whatever content they want into a location of their choice on a user’s machine.
Paper here.
EDITED TO ADD (8/11): Here’s commentary that says this isn’t such a big deal after all. I’m not convinced; I think this will turn out to be a bigger problem than that.
Physically Hacking Windows Computers via FireWire
This is impressive:
With Winlockpwn, the attacker connects a Linux machine to the Firewire port on the victim’s machine. The attacker then gets full read-and-write memory access and the tool deactivates Windows’s password protection that resides in local memory. Then he or she has carte blanche to steal passwords or drop rootkits and keyloggers onto the machine.
Full disk encryption seems like the only defense here.
Dual_EC_DRBG Added to Windows Vista
Microsoft has added the random-number generator Dual_EC-DRBG to Windows Vista, as part of SP1. Yes, this is the same RNG that could have an NSA backdoor.
It’s not enabled by default, and my advice is to never enable it. Ever.
EDITED TO ADD (12/18): I should make this clear that the algorithm is available as a program call. It is not something that the user can enable or disable.
SANS Top 20
Every year SANS publishes a list of the 20 most important vulnerabilities. It’s always a great list, and this year is no different:
The threat landscape is very dynamic, which in turn makes it necessary to adopt newer security measures. Just over the last year, the kinds of vulnerabilities that are being exploited are very different from the ones being exploited in the past. Here are some observations:
- Operating systems have fewer vulnerabilities that can lead to massive Internet worms. For instance, during 2002-2005, Microsoft Windows worms like Blaster, Nachi, Sasser and Zotob infected a large number of systems on the Internet. There have not been any new large-scale worms targeting Windows services since 2005. On the other hand, vulnerabilities found anti-virus, backup or other application software, can result in worms. Most notable was the worm exploiting the Symantec anti-virus buffer overflow flaw last year.
- We have seen significant growth in the number of client-side vulnerabilities, including vulnerabilities in browsers, in office software, in media players and in other desktop applications. These vulnerabilities are being discovered on multiple operating systems and are being massively exploited in the wild, often to drive recruitment for botnets.
- Users who are allowed by their employers to browse the Internet have become a source of major security risk for their organizations. A few years back securing servers and services was seen as the primary task for securing an organization. Today it is equally important, perhaps even more important, to prevent users having their computers compromised via malicious web pages or other client-targeting attacks.
- Web application vulnerabilities in open-source as well as custom-built applications account for almost half the total number of vulnerabilities being discovered in the past year. These vulnerabilities are being exploited widely to convert trusted web sites into malicious servers serving client-side exploits and phishing scams.
- The default configurations for many operating systems and services continue to be weak and continue to include default passwords. As a result, many systems have been compromised via dictionary and brute-force password guessing attacks in 2007!
- Attackers are finding more creative ways to obtain sensitive data from organizations. Therefore, it is now critical to check the nature of any data leaving an organization’s boundary.
Much, much more information at the link.
The Strange Story of Dual_EC_DRBG
Random numbers are critical for cryptography: for encryption keys, random authentication challenges, initialization vectors, nonces, key-agreement schemes, generating prime numbers and so on. Break the random-number generator, and most of the time you break the entire security system. Which is why you should worry about a new random-number standard that includes an algorithm that is slow, badly designed and just might contain a backdoor for the National Security Agency.
Generating random numbers isn’t easy, and researchers have discovered lots of problems and attacks over the years. A recent paper found a flaw in the Windows 2000 random-number generator. Another paper found flaws in the Linux random-number generator. Back in 1996, an early version of SSL was broken because of flaws in its random-number generator. With John Kelsey and Niels Ferguson in 1999, I co-authored Yarrow, a random-number generator based on our own cryptanalysis work. I improved this design four years later—and renamed it Fortuna—in the book Practical Cryptography, which I co-authored with Ferguson.
The U.S. government released a new official standard for random-number generators this year, and it will likely be followed by software and hardware developers around the world. Called NIST Special Publication 800-90 (.pdf), the 130-page document contains four different approved techniques, called DRBGs, or “Deterministic Random Bit Generators.” All four are based on existing cryptographic primitives. One is based on hash functions, one on HMAC, one on block ciphers and one on elliptic curves. It’s smart cryptographic design to use only a few well-trusted cryptographic primitives, so building a random-number generator out of existing parts is a good thing.
But one of those generators—the one based on elliptic curves—is not like the others. Called Dual_EC_DRBG, not only is it a mouthful to say, it’s also three orders of magnitude slower than its peers. It’s in the standard only because it’s been championed by the NSA, which first proposed it years ago in a related standardization project at the American National Standards Institute.
The NSA has always been intimately involved in U.S. cryptography standards—it is, after all, expert in making and breaking secret codes. So the agency’s participation in the NIST (the U.S. Commerce Department’s National Institute of Standards and Technology) standard is not sinister in itself. It’s only when you look under the hood at the NSA’s contribution that questions arise.
Problems with Dual_EC_DRBG were first described in early 2006. The math is complicated, but the general point is that the random numbers it produces have a small bias. The problem isn’t large enough to make the algorithm unusable—and Appendix E of the NIST standard describes an optional work-around to avoid the issue—but it’s cause for concern. Cryptographers are a conservative bunch: We don’t like to use algorithms that have even a whiff of a problem.
But today there’s an even bigger stink brewing around Dual_EC_DRBG. In an informal presentation (.pdf) at the CRYPTO 2007 conference in August, Dan Shumow and Niels Ferguson showed that the algorithm contains a weakness that can only be described as a backdoor.
This is how it works: There are a bunch of constants—fixed numbers—in the standard used to define the algorithm’s elliptic curve. These constants are listed in Appendix A of the NIST publication, but nowhere is it explained where they came from.
What Shumow and Ferguson showed is that these numbers have a relationship with a second, secret set of numbers that can act as a kind of skeleton key. If you know the secret numbers, you can predict the output of the random-number generator after collecting just 32 bytes of its output. To put that in real terms, you only need to monitor one TLS internet encryption connection in order to crack the security of that protocol. If you know the secret numbers, you can completely break any instantiation of Dual_EC_DRBG.
The researchers don’t know what the secret numbers are. But because of the way the algorithm works, the person who produced the constants might know; he had the mathematical opportunity to produce the constants and the secret numbers in tandem.
Of course, we have no way of knowing whether the NSA knows the secret numbers that break Dual_EC-DRBG. We have no way of knowing whether an NSA employee working on his own came up with the constants—and has the secret numbers. We don’t know if someone from NIST, or someone in the ANSI working group, has them. Maybe nobody does.
We don’t know where the constants came from in the first place. We only know that whoever came up with them could have the key to this backdoor. And we know there’s no way for NIST—or anyone else—to prove otherwise.
This is scary stuff indeed.
Even if no one knows the secret numbers, the fact that the backdoor is present makes Dual_EC_DRBG very fragile. If someone were to solve just one instance of the algorithm’s elliptic-curve problem, he would effectively have the keys to the kingdom. He could then use it for whatever nefarious purpose he wanted. Or he could publish his result, and render every implementation of the random-number generator completely insecure.
It’s possible to implement Dual_EC_DRBG in such a way as to protect it against this backdoor, by generating new constants with another secure random-number generator and then publishing the seed. This method is even in the NIST document, in Appendix A. But the procedure is optional, and my guess is that most implementations of the Dual_EC_DRBG won’t bother.
If this story leaves you confused, join the club. I don’t understand why the NSA was so insistent about including Dual_EC_DRBG in the standard. It makes no sense as a trap door: It’s public, and rather obvious. It makes no sense from an engineering perspective: It’s too slow for anyone to willingly use it. And it makes no sense from a backwards-compatibility perspective: Swapping one random-number generator for another is easy.
My recommendation, if you’re in need of a random-number generator, is not to use Dual_EC_DRBG under any circumstances. If you have to use something in SP 800-90, use CTR_DRBG or Hash_DRBG.
In the meantime, both NIST and the NSA have some explaining to do.
This essay originally appeared on Wired.com.
The Storm Worm
The Storm worm first appeared at the beginning of the year, hiding in e-mail attachments with the subject line: “230 dead as storm batters Europe.” Those who opened the attachment became infected, their computers joining an ever-growing botnet.
Although it’s most commonly called a worm, Storm is really more: a worm, a Trojan horse and a bot all rolled into one. It’s also the most successful example we have of a new breed of worm, and I’ve seen estimates that between 1 million and 50 million computers have been infected worldwide.
Old style worms—Sasser, Slammer, Nimda—were written by hackers looking for fame. They spread as quickly as possible (Slammer infected 75,000 computers in 10 minutes) and garnered a lot of notice in the process. The onslaught made it easier for security experts to detect the attack, but required a quick response by antivirus companies, sysadmins and users hoping to contain it. Think of this type of worm as an infectious disease that shows immediate symptoms.
Worms like Storm are written by hackers looking for profit, and they’re different. These worms spread more subtly, without making noise. Symptoms don’t appear immediately, and an infected computer can sit dormant for a long time. If it were a disease, it would be more like syphilis, whose symptoms may be mild or disappear altogether, but which will eventually come back years later and eat your brain.
Storm represents the future of malware. Let’s look at its behavior:
- Storm is patient. A worm that attacks all the time is much easier to detect; a worm that attacks and then shuts off for a while hides much more easily.
- Storm is designed like an ant colony, with separation of duties. Only a small fraction of infected hosts spread the worm. A much smaller fraction are C2: command-and-control servers. The rest stand by to receive orders. By only allowing a small number of hosts to propagate the virus and act as command-and-control servers, Storm is resilient against attack. Even if those hosts shut down, the network remains largely intact, and other hosts can take over those duties.
- Storm doesn’t cause any damage, or noticeable performance impact, to the hosts. Like a parasite, it needs its host to be intact and healthy for its own survival. This makes it harder to detect, because users and network administrators won’t notice any abnormal behavior most of the time.
- Rather than having all hosts communicate to a central server or set of servers, Storm uses a peer-to-peer network for C2. This makes the Storm botnet much harder to disable. The most common way to disable a botnet is to shut down the centralized control point. Storm doesn’t have a centralized control point, and thus can’t be shut down that way.
This technique has other advantages, too. Companies that monitor net activity can detect traffic anomalies with a centralized C2 point, but distributed C2 doesn’t show up as a spike. Communications are much harder to detect.
One standard method of tracking root C2 servers is to put an infected host through a memory debugger and figure out where its orders are coming from. This won’t work with Storm: An infected host may only know about a small fraction of infected hosts—25-30 at a time—and those hosts are an unknown number of hops away from the primary C2 servers.
And even if a C2 node is taken down, the system doesn’t suffer. Like a hydra with many heads, Storm’s C2 structure is distributed.
- Not only are the C2 servers distributed, but they also hide behind a constantly changing DNS technique called “fast flux.” So even if a compromised host is isolated and debugged, and a C2 server identified through the cloud, by that time it may no longer be active.
- Storm’s payload—the code it uses to spread—morphs every 30 minutes or so, making typical AV (antivirus) and IDS techniques less effective.
- Storm’s delivery mechanism also changes regularly. Storm started out as PDF spam, then its programmers started using e-cards and YouTube invites—anything to entice users to click on a phony link. Storm also started posting blog-comment spam, again trying to trick viewers into clicking infected links. While these sorts of things are pretty standard worm tactics, it does highlight how Storm is constantly shifting at all levels.
- The Storm e-mail also changes all the time, leveraging social engineering techniques. There are always new subject lines and new enticing text: “A killer at 11, he’s free at 21 and …,” “football tracking program” on NFL opening weekend, and major storm and hurricane warnings. Storm’s programmers are very good at preying on human nature.
- Last month, Storm began attacking anti-spam sites focused on identifying it—spamhaus.org, 419eater and so on—and the personal website of Joe Stewart, who published an analysis of Storm. I am reminded of a basic theory of war: Take out your enemy’s reconnaissance. Or a basic theory of urban gangs and some governments: Make sure others know not to mess with you.
Not that we really have any idea how to mess with Storm. Storm has been around for almost a year, and the antivirus companies are pretty much powerless to do anything about it. Inoculating infected machines individually is simply not going to work, and I can’t imagine forcing ISPs to quarantine infected hosts. A quarantine wouldn’t work in any case: Storm’s creators could easily design another worm—and we know that users can’t keep themselves from clicking on enticing attachments and links.
Redesigning the Microsoft Windows operating system would work, but that’s ridiculous to even suggest. Creating a counterworm would make a great piece of fiction, but it’s a really bad idea in real life. We simply don’t know how to stop Storm, except to find the people controlling it and arrest them.
Unfortunately we have no idea who controls Storm, although there’s some speculation that they’re Russian. The programmers are obviously very skilled, and they’re continuing to work on their creation.
Oddly enough, Storm isn’t doing much, so far, except gathering strength. Aside from continuing to infect other Windows machines and attacking particular sites that are attacking it, Storm has only been implicated in some pump-and-dump stock scams. There are rumors that Storm is leased out to other criminal groups. Other than that, nothing.
Personally, I’m worried about what Storm’s creators are planning for Phase II.
This essay originally appeared on Wired.com.
EDITED TO ADD (10/17): Storm is being partitioned, presumably so parts can be sold off. If that’s true, we should expect more malicious activitity out of Storm in the future; anyone buying a botnet will want to use it.
Slashdot thread on Storm.
EDITEDT TO ADD (10/22): Here’s research that suggests Storm is shinking.
EDITED T OADD (10/24): Another article about Storm striking back at security researchers.
Microsoft Updates Both XP and Vista Without User Permission or Notification
The details are still fuzzy, but if this is true, it’s a huge deal.
Not that Microsoft can do this; that’s just stupid company stuff. But what’s to stop anyone else from using Microsoft’s stealth remote install capability to put anything onto anyone’s computer? How long before some smart hacker exploits this, and then writes a program that will allow all the dumb hackers to do it?
When you build a capability like this into your system, you decrease your overall security.
Sidebar photo of Bruce Schneier by Joe MacInnis.