Entries Tagged "malware"

Page 45 of 50

VOIP Encryption

There are basically four ways to eavesdrop on a telephone call.

One, you can listen in on another phone extension. This is the method preferred by siblings everywhere. If you have the right access, it’s the easiest. While it doesn’t work for cell phones, cordless phones are vulnerable to a variant of this attack: A radio receiver set to the right frequency can act as another extension.

Two, you can attach some eavesdropping equipment to the wire with a pair of alligator clips. It takes some expertise, but you can do it anywhere along the phone line’s path—even outside the home. This used to be the way the police eavesdropped on your phone line. These days it’s probably most often used by criminals. This method doesn’t work for cell phones, either.

Three, you can eavesdrop at the telephone switch. Modern phone equipment includes the ability for someone to listen in this way. Currently, this is the preferred police method. It works for both land lines and cell phones. You need the right access, but if you can get it, this is probably the most comfortable way to eavesdrop on a particular person.

Four, you can tap the main trunk lines, eavesdrop on the microwave or satellite phone links, etc. It’s hard to eavesdrop on one particular person this way, but it’s easy to listen in on a large chunk of telephone calls. This is the sort of big-budget surveillance that organizations like the National Security Agency do best. They’ve even been known to use submarines to tap undersea phone cables.

That’s basically the entire threat model for traditional phone calls. And when most people think about IP telephony—voice over internet protocol, or VOIP—that’s the threat model they probably have in their heads.

Unfortunately, phone calls from your computer are fundamentally different from phone calls from your telephone. Internet telephony’s threat model is much closer to the threat model for IP-networked computers than the threat model for telephony.

And we already know the threat model for IP. Data packets can be eavesdropped on anywhere along the transmission path. Data packets can be intercepted in the corporate network, by the internet service provider and along the backbone. They can be eavesdropped on by the people or organizations that own those computers, and they can be eavesdropped on by anyone who has successfully hacked into those computers. They can be vacuumed up by nosy hackers, criminals, competitors and governments.

It’s comparable to threat No. 3 above, but with the scope vastly expanded.

My greatest worry is the criminal attacks. We already have seen how clever criminals have become over the past several years at stealing account information and personal data. I can imagine them eavesdropping on attorneys, looking for information with which to blackmail people. I can imagine them eavesdropping on bankers, looking for inside information with which to make stock purchases. I can imagine them stealing account information, hijacking telephone calls, committing identity theft. On the business side, I can see them engaging in industrial espionage and stealing trade secrets. In short, I can imagine them doing all the things they could never have done with the traditional telephone network.

This is why encryption for VOIP is so important. VOIP calls are vulnerable to a variety of threats that traditional telephone calls are not. Encryption is one of the essential security technologies for computer data, and it will go a long way toward securing VOIP.

The last time this sort of thing came up, the U.S. government tried to sell us something called “key escrow.” Basically, the government likes the idea of everyone using encryption, as long as it has a copy of the key. This is an amazingly insecure idea for a number of reasons, mostly boiling down to the fact that when you provide a means of access into a security system, you greatly weaken its security.

A recent case in Greece demonstrated that perfectly: Criminals used a cell-phone eavesdropping mechanism already in place, designed for the police to listen in on phone calls. Had the call system been designed to be secure in the first place, there never would have been a backdoor for the criminals to exploit.

Fortunately, there are many VOIP-encryption products available. Skype has built-in encryption. Phil Zimmermann is releasing Zfone, an easy-to-use open-source product. There’s even a VOIP Security Alliance.

Encryption for IP telephony is important, but it’s not a panacea. Basically, it takes care of threats No. 2 through No. 4, but not threat No. 1. Unfortunately, that’s the biggest threat: eavesdropping at the end points. No amount of IP telephony encryption can prevent a Trojan or worm on your computer—or just a hacker who managed to get access to your machine—from eavesdropping on your phone calls, just as no amount of SSL or e-mail encryption can prevent a Trojan on your computer from eavesdropping—or even modifying—your data.

So, as always, it boils down to this: We need secure computers and secure operating systems even more than we need secure transmission.

This essay originally appeared on Wired.com.

Posted on April 6, 2006 at 5:09 AMView Comments

Security Through Begging

From TechDirt:

Last summer, the surprising news came out that Japanese nuclear secrets leaked out, after a contractor was allowed to connect his personal virus-infested computer to the network at a nuclear power plant. The contractor had a file sharing app on his laptop as well, and suddenly nuclear secrets were available to plenty of kids just trying to download the latest hit single. It’s only taken about nine months for the government to come up with its suggestion on how to prevent future leaks of this nature: begging all Japanese citizens not to use file sharing systems—so that the next time this happens, there won’t be anyone on the network to download such documents.

Even if their begging works, it solves the wrong problem. Sad.

EDITED TO ADD (3/22): Another article.

Posted on March 20, 2006 at 2:01 PMView Comments

RFID Chips and Viruses

Of course RFID chips can carry viruses. They’re just little computers.

More info here. The coverage is more than a tad sensationalist, though.

EDITED TO ADD (3/16): I thought the attack vector was interesting: a Trojan RFID attacks the central database, rather than attacking other RFID chips directly. Metaphorically, it’s a lot closer to biological viruses, because it actually requires the more powerful host being subverted, and there’s no way an infected tag could propagate directly to another tag.

Posted on March 16, 2006 at 6:55 AMView Comments

"Lessons from the Sony CD DRM Episode"

“Lessons from the Sony CD DRM Episode” is an interesting paper by J. Alex Halderman and Edward W. Felten.

Abstract: In the fall of 2005, problems discovered in two Sony-BMG compact disc copy protection systems, XCP and MediaMax, triggered a public uproar that ultimately led to class-action litigation and the recall of millions of discs. We present an in-depth analysis of these technologies, including their design, implementation, and deployment. The systems are surprisingly complex and suffer from a diverse array of flaws that weaken their content protection and expose users to serious security and privacy risks. Their complexity, and their failure, makes them an interesting case study of digital rights management that carries valuable lessons for content companies, DRM vendors, policymakers, end users, and the security community.

Posted on February 17, 2006 at 2:11 PMView Comments

Security in the Cloud

One of the basic philosophies of security is defense in depth: overlapping systems designed to provide security even if one of them fails. An example is a firewall coupled with an intrusion-detection system (IDS). Defense in depth provides security, because there’s no single point of failure and no assumed single vector for attacks.

It is for this reason that a choice between implementing network security in the middle of the network—in the cloud—or at the endpoints is a false dichotomy. No single security system is a panacea, and it’s far better to do both.

This kind of layered security is precisely what we’re seeing develop. Traditionally, security was implemented at the endpoints, because that’s what the user controlled. An organization had no choice but to put its firewalls, IDSs, and anti-virus software inside its network. Today, with the rise of managed security services and other outsourced network services, additional security can be provided inside the cloud.

I’m all in favor of security in the cloud. If we could build a new Internet today from scratch, we would embed a lot of security functionality in the cloud. But even that wouldn’t substitute for security at the endpoints. Defense in depth beats a single point of failure, and security in the cloud is only part of a layered approach.

For example, consider the various network-based e-mail filtering services available. They do a great job of filtering out spam and viruses, but it would be folly to consider them a substitute for anti-virus security on the desktop. Many e-mails are internal only, never entering the cloud at all. Worse, an attacker might open up a message gateway inside the enterprise’s infrastructure. Smart organizations build defense in depth: e-mail filtering inside the cloud plus anti-virus on the desktop.

The same reasoning applies to network-based firewalls and intrusion-prevention systems (IPS). Security would be vastly improved if the major carriers implemented cloud-based solutions, but they’re no substitute for traditional firewalls, IDSs, and IPSs.

This should not be an either/or decision. At Counterpane, for example, we offer cloud services and more traditional network and desktop services. The real trick is making everything work together.

Security is about technology, people, and processes. Regardless of where your security systems are, they’re not going to work unless human experts are paying attention. Real-time monitoring and response is what’s most important; where the equipment goes is secondary.

Security is always a trade-off. Budgets are limited and economic considerations regularly trump security concerns. Traditional security products and services are centered on the internal network, because that’s the target of attack. Compliance focuses on that for the same reason. Security in the cloud is a good addition, but it’s not a replacement for more traditional network and desktop security.

This was published as a “Face-Off” in Network World.

The opposing view is here.

Posted on February 15, 2006 at 8:18 AMView Comments

The New Internet Explorer

I’m just starting to read about the new security features in Internet Explorer 7. So far, I like what I am reading.

IE 7 requires that all browser windows display an address bar. This helps foil attackers that operate by popping up new windows masquerading as pages on a legitimate site, when in fact the site is fraudulent. By requiring an address bar, users will immediately see the true URL of the displayed page, making these types of attacks more obvious. If you think you’re looking at www.microsoft.com, but the browser address bar says www.illhackyou.net, you ought to be suspicious.

I use Opera, and have long used the address bar to “check” on URLs. This is an excellent idea. So is this:

In early November, a bunch of Web browser developers got together and started fleshing out standards for address bar coloring, which can cue users to secured connections. Under the proposal laid out by IE 7 team member Rob Franco, even sites that use a standard SSL certificate will display a standard white address bar. Sites that use a stronger, as yet undetermined level of protection will use a green bar.

I like easy visual indications about what’s going on. And I really like that SSL is generic white, because it really doesn’t prove that you’re communicating with the site you think you’re communicating with. This feature helps with that, though:

Franco also said that when navigating to an SSL-protected site, the IE 7 address bar will display the business name and certification authority’s name in the address bar.

Some of the security measures in IE7 weaken the integration between the browser and the operating system:

People using Windows Vista beta 2 will find a new feature called Protected Mode, which renders IE 7 unable to modify system files and settings. This essentially breaks down part of the integration between IE and Windows itself.

Think of it is as a wall between IE and the rest of the operating system. No, the code won’t be perfect, and yes, there’ll be ways found to circumvent this security, but this is an important and long-overdue feature.

The majority of IE’s notorious security flaws stem from its pervasive integration with Windows. That is a feature no other Web browser offers—and an ability that Vista’s Protected Mode intends to mitigate. IE 7 obviously won’t remove all of that tight integration. Lacking deep architectural changes, the effort has focused instead on hardening or eliminating potential vulnerabilities. Unfortunately, this approach requires Microsoft to anticipate everything that could go wrong and block it in advance—hardly a surefire way to secure a browser.

That last sentence is about the general Internet attitude to allow everything that is not explicitly denied, rather than deny everything that is not explicitly allowed.

Also, you’ll have to wait until Vista to use it:

…this capability will not be available in Windows XP because it’s woven directly into Windows Vista itself.

There are also some good changes under the hood:

IE 7 does eliminate a great deal of legacy code that dates back to the IE 4 days, which is a welcome development.

And:

Microsoft has rewritten a good bit of IE 7’s core code to help combat attacks that rely on malformed URLs (that typically cause a buffer overflow). It now funnels all URL processing through a single function (thus reducing the amount of code that “looks” at URLs).

All good stuff, but I agree with this conclusion:

IE 7 offers several new security features, but it’s hardly a given that the situation will improve. There has already been a set of security updates for IE 7 beta 1 released for both Windows Vista and Windows XP computers. Security vulnerabilities in a beta product shouldn’t be alarming (IE 7 is hardly what you’d consider “finished” at this point), but it may be a sign that the product’s architecture and design still have fundamental security issues.

I’m not switching from Opera yet, and my second choice is still Firefox. But the masses still use IE, and our security depends in part on those masses keeping their computers worm-free and bot-free.

NOTE: Here’s some info on how to get your own copy of Internet Explorer 7 beta 2.

Posted on February 9, 2006 at 3:37 PMView Comments

Phone Tapping in Greece

Unknowns tapped the mobile phones of about 100 Greek politicians and offices, including the U.S. embassy in Athens and the Greek prime minister.

Details are sketchy, but it seems that a piece of malicious code was discovered by Ericsson technicians in Vodafone’s mobile phone software. The code tapped into the conference call system. It “conference called” phone calls to 14 prepaid mobile phones where the calls were recorded.

Some details are here. See also this news article, and—if you can read Greek—this one.

Posted on February 3, 2006 at 11:27 AMView Comments

For-Profit Botnet

Interesting article about someone convicted for running a for-profit botnet:

November’s 52-page indictment, along with papers filed last week, offer an unusually detailed glimpse into a shadowy world where hackers, often not old enough to vote, brag in online chat groups about their prowess in taking over vast numbers of computers and herding them into large armies of junk mail robots and arsenals for so-called denial of service attacks on Web sites.

Ancheta one-upped his hacking peers by advertising his network of “bots,” short for robots, on Internet chat channels.

A Web site Ancheta maintained included a schedule of prices he charged people who wanted to rent out the machines, along with guidelines on how many bots were required to bring down a particular type of Web site.

In July 2004, he told one chat partner he had more than 40,000 machines available, “more than I can handle,” according to the indictment. A month later, Ancheta told another person he controlled at least 100,000 bots, and that his network had added another 10,000 machines in a week and a half.

In a three-month span starting in June 2004, Ancheta rented out or sold bots to at least 10 “different nefarious computer users,” according to the plea agreement. He pocketed $3,000 in the process by accepting payments through the online PayPal service, prosecutors said.

Starting in August 2004, Ancheta turned to a new, more lucrative method to profit from his botnets, prosecutors said. Working with a juvenile in Boca Raton, Fla., whom prosecutors identified by his Internet nickname “SoBe,” Ancheta infected more than 400,000 computers.

Ancheta and SoBe signed up as affiliates in programs maintained by online advertising companies that pay people each time they get a computer user to install software that displays ads and collects information about the sites a user visits.

Posted on February 2, 2006 at 6:06 AMView Comments

1 43 44 45 46 47 50

Sidebar photo of Bruce Schneier by Joe MacInnis.