Entries Tagged "vulnerabilities"
Page 33 of 48
Storing Cryptographic Keys with Invisible Tattoos
This idea, by Stuart Schechter at Microsoft Research, is—I think—clever:
Abstract: Implantable medical devices, such as implantable cardiac defibrillators and pacemakers, now use wireless communication protocols vulnerable to attacks that can physically harm patients. Security measures that impede emergency access by physicians could be equally devastating. We propose that access keys be written into patients’ skin using ultraviolet-ink micropigmentation (invisible tattoos).
It certainly is a new way to look at the security threat model.
Back Door in Battery Charger
The United States Computer Emergency Response Team (US-CERT) has warned that the software included in the Energizer DUO USB battery charger contains a backdoor that allows unauthorized remote system access.
That’s actually misleading. Even though the charger is an USB device, it does not contain the harmful installer described in the article—it has no storage capacity. The software has to be downloaded from the Energizer website, and the software is only used to monitor the progress of the charge. The software is not needed for the device to function properly.
Here are details.
Energizer has announced it will pull the software from its website, and also will stop selling the device.
EDITED TO ADD (3/23): Additional news here.
FIPS 140-2 Level 2 Certified USB Memory Stick Cracked
Kind of a dumb mistake:
The USB drives in question encrypt the stored data via the practically uncrackable AES 256-bit hardware encryption system. Therefore, the main point of attack for accessing the plain text data stored on the drive is the password entry mechanism. When analysing the relevant Windows program, the SySS security experts found a rather blatant flaw that has quite obviously slipped through testers’ nets. During a successful authorisation procedure the program will, irrespective of the password, always send the same character string to the drive after performing various crypto operations—and this is the case for all USB Flash drives of this type.
Cracking the drives is therefore quite simple. The SySS experts wrote a small tool for the active password entry program’s RAM which always made sure that the appropriate string was sent to the drive, irrespective of the password entered and as a result gained immediate access to all the data on the drive. The vulnerable devices include the Kingston DataTraveler BlackBox, the SanDisk Cruzer Enterprise FIPS Edition and the Verbatim Corporate Secure FIPS Edition.
Nice piece of analysis work.
The article goes on to question the value of the FIPS certification:
The real question, however, remains unanswered how could USB Flash drives that exhibit such a serious security hole be given one of the highest certificates for crypto devices? Even more importantly, perhaps what is the value of a certification that fails to detect such holes?
The problem is that no one really understands what a FIPS 140-2 certification means. Instead, they think something like: “This crypto thingy is certified, so it must be secure.” In fact, FIPS 140-2 Level 2 certification only means that certain good algorithms are used, and that there is some level of tamper resistance and tamper evidence. Marketing departments of security take advantage of this confusion—it’s not only FIPS 140, it’s all the security standards—and encourage their customers to equate conformance to the standard with security.
So when that equivalence is demonstrated to be false, people are surprised.
Reacting to Security Vulnerabilities
Last month, researchers found a security flaw in the SSL protocol, which is used to protect sensitive web data. The protocol is used for online commerce, webmail, and social networking sites. Basically, hackers could hijack an SSL session and execute commands without the knowledge of either the client or the server. The list of affected products is enormous.
If this sounds serious to you, you’re right. It is serious. Given that, what should you do now? Should you not use SSL until it’s fixed, and only pay for internet purchases over the phone? Should you download some kind of protection? Should you take some other remedial action? What?
If you read the IT press regularly, you’ll see this sort of question again and again. The answer for this particular vulnerability, as for pretty much any other vulnerability you read about, is the same: do nothing. That’s right, nothing. Don’t panic. Don’t change your behavior. Ignore the problem, and let the vendors figure it out.
There are several reasons for this. One, it’s hard to figure out which vulnerabilities are serious and which are not. Vulnerabilities such as this happen multiple times a month. They affect different software, different operating systems, and different web protocols. The press either mentions them or not, somewhat randomly; just because it’s in the news doesn’t mean it’s serious.
Two, it’s hard to figure out if there’s anything you can do. Many vulnerabilities affect operating systems or Internet protocols. The only sure fix would be to avoid using your computer. Some vulnerabilities have surprising consequences. The SSL vulnerability mentioned above could be used to hack Twitter. Did you expect that? I sure didn’t.
Three, the odds of a particular vulnerability affecting you are small. There are a lot of fish in the Internet, and you’re just one of billions.
Four, often you can’t do anything. These vulnerabilities affect clients and servers, individuals and corporations. A lot of your data isn’t under your direct control—it’s on your web-based email servers, in some corporate database, or in a cloud computing application. If a vulnerability affects the computers running Facebook, for example, your data is at risk, whether you log in to Facebook or not.
It’s much smarter to have a reasonable set of default security practices and continue doing them. This includes:
1. Install an antivirus program if you run Windows, and configure it to update daily. It doesn’t matter which one you use; they’re all about the same. For Windows, I like the free version of AVG Internet Security. Apple Mac and Linux users can ignore this, as virus writers target the operating system with the largest market share.
2. Configure your OS and network router properly. Microsoft’s operating systems come with a lot of security enabled by default; this is good. But have someone who knows what they’re doing check the configuration of your router, too.
3. Turn on automatic software updates. This is the mechanism by which your software patches itself in the background, without you having to do anything. Make sure it’s turned on for your computer, OS, security software, and any applications that have the option. Yes, you have to do it for everything, as they often have separate mechanisms.
4. Show common sense regarding the Internet. This might be the hardest thing, and the most important. Know when an email is real, and when you shouldn’t click on the link. Know when a website is suspicious. Know when something is amiss.
5. Perform regular backups. This is vital. If you’re infected with something, you may have to reinstall your operating system and applications. Good backups ensure you don’t lose your data—documents, photographs, music—if that becomes necessary.
That’s basically it. I could give a longer list of safe computing practices, but this short one is likely to keep you safe. After that, trust the vendors. They spent all last month scrambling to fix the SSL vulnerability, and they’ll spend all this month scrambling to fix whatever new vulnerabilities are discovered. Let that be their problem.
Six Years of Patch Tuesdays
Nice article summing up six years of Microsoft Patch Tuesdays:
The total number of flaws disclosed and patched by the software maker so far this year stands at around 160, more than the 155 or so that Microsoft reported for all of 2008. The number of flaws reported in Microsoft products over the last two years is more than double the number of flaws disclosed in 2004 and 2005, the first two full years of Patch Tuesdays.
The last time Microsoft did not release any patches on a Patch Tuesday was March 2007, more than 30 months ago. In the past six years, Microsoft had just four patch-free months—two of which were in 2005. In contrast, the company has issued patches for 10 or more vulnerabilities on more than 20 occasions and patches for 20 or more flaws in a single month on about 10 occasions, including yesterday.
I wrote about the “patch treadmill,” pointing out that there are simply too many patches and that it’s impossible to keep up:
Security professionals are quick to blame system administrators who don’t install every patch. “They should have updated their systems; it’s their own fault when they get hacked.” This is beginning to feel a lot like blaming the victim. “He should have known not to walk down that deserted street; it’s his own fault he was mugged.” “She should never have dressed that provocatively; it’s her own fault she was attacked.” Perhaps such precautions should have been taken, but the real blame lies elsewhere.
Those who manage computer networks are people too, and people don’t always do the smartest thing. They know they’re supposed to install all patches. But sometimes they can’t take critical systems off-line. Sometimes they don’t have the staffing available to patch every system on their network. Sometimes applying a patch breaks something else on their network. I think it’s time the industry realized that expecting the patch process to improve network security just doesn’t work.
Patching is essentially an impossible problem. A patch needs to be incredibly well-tested. It has to work, without tweaking, on every configuration of the software out there. And for security reasons, it needs to be pushed out to users within days—hours, if possible. These two requirements are mutually contradictory: you can’t have a piece of software that is both well-tested and quickly written.
Before October 2003, Microsoft’s patching was a mess. Patches weren’t well-tested. They broke systems so frequently that many sysadmins wouldn’t install them without extensive testing. There were jokes that a Microsoft patch was indistinguishable from a DoS attack.
In 2003, Microsoft went to a once-a-month patching cycle, and I think it’s been a resounding success. Microsoft’s patches are much better tested. They’re much less likely to break other things. And, as a result, many more people have turned on automatic update, meaning that many more people have their patches up to date. The downside is that the window of exposure—the time period between a vulnerability’s release and the availability of a patch—is longer. Patch Tuesdays might be the best we can do, but the whole patching system is fundamentally broken. This is what I wrote last year:
The real lesson is that the patch treadmill doesn’t work, and it hasn’t for years. This cycle of finding security holes and rushing to patch them before the bad guys exploit those vulnerabilities is expensive, inefficient and incomplete. We need to design security into our systems right from the beginning. We need assurance. We need security engineers involved in system design. This process won’t prevent every vulnerability, but it’s much more secure—and cheaper—than the patch treadmill we’re all on now.
Who Should be in Charge of U.S. Cybersecurity?
U.S. government cybersecurity is an insecure mess, and fixing it is going to take considerable attention and resources. Trying to make sense of this, President Barack Obama ordered a 60-day review of government cybersecurity initiatives. Meanwhile, the U.S. House Subcommittee on Emerging Threats, Cybersecurity, Science and Technology is holding hearings on the same topic.
One of the areas of contention is who should be in charge. The FBI, DHS and DoD—specifically, the NSA—all have interests here. Earlier this month, Rod Beckström resigned from his position as director of the DHS’s National Cybersecurity Center, warning of a power grab by the NSA.
Putting national cybersecurity in the hands of the NSA is an incredibly bad idea. An entire parade of people, ranging from former FBI director Louis Freeh to Microsoft’s Trusted Computing Group Vice President and former Justice Department computer crime chief Scott Charney, have told Congress the same thing at this month’s hearings.
Cybersecurity isn’t a military problem, or even a government problem—it’s a universal problem. All networks, military, government, civilian and commercial, use the same computers, the same networking hardware, the same Internet protocols and the same software packages. We all are the targets of the same attack tools and tactics. It’s not even that government targets are somehow more important; these days, most of our nation’s critical IT infrastructure is in commercial hands. Government-sponsored Chinese hackers go after both military and civilian targets.
Some have said that the NSA should be in charge because it has specialized knowledge. Earlier this month, Director of National Intelligence Admiral Dennis Blair made this point, saying “There are some wizards out there at Ft. Meade who can do stuff.” That’s probably not true, but if it is, we’d better get them out of Ft. Meade as soon as possible—they’re doing the nation little good where they are now.
Not that government cybersecurity failings require any specialized wizardry to fix. GAO reports indicate that government problems include insufficient access controls, a lack of encryption where necessary, poor network management, failure to install patches, inadequate audit procedures, and incomplete or ineffective information security programs. These aren’t super-secret NSA-level security issues; these are the same managerial problems that every corporate CIO wrestles with.
We’ve all got the same problems, so solutions must be shared. If the government has any clever ideas to solve its cybersecurity problems, certainly a lot of us could benefit from those solutions. If it has an idea for improving network security, it should tell everyone. The best thing the government can do for cybersecurity world-wide is to use its buying power to improve the security of the IT products everyone uses. If it imposes significant security requirements on its IT vendors, those vendors will modify their products to meet those requirements. And those same products, now with improved security, will become available to all of us as the new standard.
Moreover, the NSA’s dual mission of providing security and conducting surveillance means it has an inherent conflict of interest in cybersecurity. Inside the NSA, this is called the “equities issue.” During the Cold War, it was easy; the NSA used its expertise to protect American military information and communications, and eavesdropped on Soviet information and communications. But what happens when both the good guys the NSA wants to protect, and the bad guys the NSA wants to eavesdrop on, use the same systems? They all use Microsoft Windows, Oracle databases, Internet email, and Skype. When the NSA finds a vulnerability in one of those systems, does it alert the manufacturer and fix it—making both the good guys and the bad guys more secure? Or does it keep quiet about the vulnerability and not tell anyone—making it easier to spy on the bad guys but also keeping the good guys insecure? Programs like the NSA’s warrantless wiretapping program have created additional vulnerabilities in our domestic telephone networks.
Testifying before Congress earlier this month, former DHS National Cyber Security division head Amit Yoran said “the intelligence community has always and will always prioritize its own collection efforts over the defensive and protection mission of our government’s and nation’s digital systems.”
Maybe the NSA could convince us that it’s putting cybersecurity first, but its culture of secrecy will mean that any decisions it makes will be suspect. Under current law, extended by the Bush administration’s extravagant invocation of the “state secrets” privilege when charged with statutory and constitutional violations, the NSA’s activities are not subject to any meaningful public oversight. And the NSA’s tradition of military secrecy makes it harder for it to coordinate with other government IT departments, most of which don’t have clearances, let alone coordinate with local law enforcement or the commercial sector.
We need transparent and accountable government processes, using commercial security products. We need government cybersecurity programs that improve security for everyone. The NSA certainly has an advisory and a coordination role in national cybersecurity, and perhaps a more supervisory role in DoD cybersecurity—both offensive and defensive—but it should not be in charge.
A version of this essay appeared on The Wall Street Journal website.
Security Fears Drive Iran to Linux
According to The Age in Australia:
“We would have to pay a lot of money,” said Sephery-Rad, noting that most of the government’s estimated one million PCs and the country’s total of six to eight million computers were being run almost exclusively on the Windows platform.
“Secondly, Microsoft software has a lot of backdoors and security weaknesses that are always being patched, so it is not secure. We are also under US sanctions. All this makes us think we need an alternative operating system.”
[…]
“Microsoft is a national security concern. Security in an operating system is an important issue, and when it is on a computer in the government it is of even greater importance,” said the official.
Computer Virus Epidemiology
“WiFi networks and malware epidemiology,” by Hao Hu, Steven Myers, Vittoria Colizza, and Alessandro Vespignani.
Abstract
In densely populated urban areas WiFi routers form a tightly interconnected proximity network that can be exploited as a substrate for the spreading of malware able to launch massive fraudulent attacks. In this article, we consider several scenarios for the deployment of malware that spreads over the wireless channel of major urban areas in the US. We develop an epidemiological model that takes into consideration prevalent security flaws on these routers. The spread of such a contagion is simulated on real-world data for georeferenced wireless routers. We uncover a major weakness of WiFi networks in that most of the simulated scenarios show tens of thousands of routers infected in as little as 2 weeks, with the majority of the infections occurring in the first 24–48 h. We indicate possible containment and prevention measures and provide computational estimates for the rate of encrypted routers that would stop the spreading of the epidemics by placing the system below the percolation threshold.
Honestly, I’m not sure I understood most of the article. And I don’t think that their model is all that great. But I like to see these sorts of methods applied to malware and infection rates.
EDITED TO ADD (3/13): Earlier—but free—version of the paper.
Sidebar photo of Bruce Schneier by Joe MacInnis.