2009/07/17
TheRegister: Webcams, printers, gizmos - the untold net threats
by Dan Goodin
Forget mis-configured Apache servers and vulnerability-laden Adobe applications. The biggest security threats to business and home networks may be the avalanche of webcams, printers, and other devices that ship with embedded web interfaces that can easily be turned against their masters.
The web interfaces are designed to make it easy to manage the devices by allowing people to use a readily familiar medium to change settings such as file names and IP addresses. But there's a catch: The low-cost gadgets were never designed to withstand attacks, even though they interact with some of the most sensitive parts of a computer network, says a team of researchers at Stanford University that tested 21 devices made by 16 different manufacturers.
"We didn't find a single secure device," said Hristo Bojinov, a PhD candidate at Stanford's Computer Security Lab, who plans to present the findings later this month at the Black Hat security conference in Las Vegas. "It tells us that it's a long tail that's completely overlooked right now."
The device that posed the highest number of threats was NAS, or network-attached storage, units, which were susceptible to all five attack classes considered in the study.
For instance, attackers can sabotage NAS units made by one vendor (The Register agreed not to name any specific manufacturers or models in this article) by doing nothing more than entering javascript commands when trying to log in to the device. From then on, the device will execute XSS, or cross-site scripting, attacks against network admins each time they view a device log that stores the wayward login attempts.
Similarly, attackers can manipulate SMB, or server message block, commands, to rename files on a NAS device so they contain malicious javascript. The Stanford team has dubbed such exploits cross-channel scripting attacks because they use a non-web-based channel such as the file transfer protocol to store arbitrary scripts that, when viewed in a web browser, can expose the admin to serious threats. Four of the five NAS manufacturers studied in the report were vulnerable to them.
Other devices that are vulnerable to cross-channel attacks include network switches, routers, photo frames, voice over internet protocol phones, and so-called LOM, or lights out management, systems for remotely managing servers and other network equipment. Other attack classes detailed in the study included CSRF, or cross-site request forgeries, and unauthorized access of files or device resources.
"What we're talking about here is a fairly global problem," said Bojinov. "Pretty much all vendors we have looked at are affected by this."
The researchers have also modeled web-based exploits that invoke CSRF attacks to plant an ever-present "ghost" in certain models of photo frames that allow people to use the internet to remotely change the images being displayed. From then on, the device is under the spell of the demon, which can be programmed to send a copy of each picture stored, the times the device is accessed and other potentially sensitive data.
The findings are significant for a couple reasons. First, once infiltrated, the devices will continue to attack because the malicious scripts reside in configuration pages, device logs, and other pages. Even if an attacked PC is later disinfected, the device may continue to clobber new victims. What's more, these devices are generally invisible to anti-virus and other security programs.
Second, the number of electronic devices being shipped with web interfaces has snowballed and is only getting bigger. In the next few years, the number of such gizmos attached to the net will outnumber servers, the researchers say.
And yet few if any device manufacturers supply defenses against such attacks.
"At a high level, usually the problems can be fixed by being very careful about escaping the state that device stores, and presents," Bojinov says. "However, given the fact that it is so hard to keep track of all input and output, it is too much to ask each vendor to fix to the problem directly."
As a result, the research team - which also includes Dan Boneh, head of the Applied Cryptography Group in Stanford's Computer Science Department, and Elie Bursztein, a post-doctoral researcher at the Stanford Computer Security Lab - are considering whether it makes sense to build a set of lightweight tools that vendors could include in their wares.
One approach is the creation of browser extension the team calls a "sitefirewall" that would prevent attacks from using the browser to leak data outside an intranet. The team plans to release a proof-of-concept tool later this year. A second approach is a framework for developing embedded web interfaces that fixes the most common implementation problems.
InfoWorld: Google Chrome OS can't be perfectly secure
by Roger Grimes
Google's plan to release a Chrome-based OS next year has garnered the expected fanfare that comes with anything the company announces. I've also seen articles in which people at Google are quoted as saying the OS will be free from malware and immune to malicious hackers. My gut feeling is that these folks were misquoted. I don't think anyone with serious experience in this field would make that sort of claim - but I could be wrong.
Whether or not they said it, the question remains: Is it truly possible for the search giant to accomplish what no other company has and release a perfectly secure OS? The answer: Probably not. (For the sake of full disclosure, I'm a security architect at Microsoft.)
For starters, the best indicator of future behavior is past behavior. Every software vendor who has promised perfect security has failed to deliver. Who can forget Oracle CEO Larry Ellison's pledge of "unbreakable software" ? That was hundreds, if not thousands, of patched bugs ago. Unlike Oracle's offerings, Chrome OS will be available to and used by the general public, making it a huge target for malicious hackers and purveyors of malware. That alone renders the prospect of flawless security all but impossible.
Second, I don't know of a Google product to date that has not had its share of bugs. Even Google Chrome, the "most secure browser ever," has had at least eight discovered vulnerabilities in its very short life - and with the browser's very small market share. If Google Chrome were to gain market share, more vulnerabilities would naturally emerge. No software has ever escaped that fact.
Secure software is static software
But let's say that Google achieves the near-impossible, what no one else has done, and makes a perfectly secure OS. One of the key challenges for any software title is that as it becomes more popular, it must become more functional. Security alone does not make a product popular. Otherwise, software such as OpenBSD or anything written by Dr. D. J. Bernstein would have a much higher install base. These products are well-regarded for being extremely - though not perfectly - secure. Perhaps these products haven't gained broader acceptance because - I 'm waiting for the flame mail - they don't offer the functionality and experience that most users really want.If a company fails to add functionality and features to its wares, its competitors will grab its customers.
However, adding new functionality and new features requires new code, which in turns increases complexity and the chances for security bugs.
For example, Adobe Acrobat was relatively secure when it simply read PDF text documents. To attract more customers and remain competitive, Adobe added a bunch of new features, such as the ability to run JavaScript and participate in encryption. By no small coincidence, Adobe Acrobat now has lots of security patches. You can say the same of any popular app.
Further, even if Google somehow manages to crank out a perfectly secure OS, it will still need to rely upon other organizations' software to work. That, in turn, will almost certainly create chinks in the OS's armor. For example, almost every Internet product relies on DNS, which has proved extremely hackable. Hack that, and you hack everything that relies on it, including otherwise secure browsers and OSes.
Beyond relying on DNS, how will the Google OS and browser render documents and content such as PDFs, Macromedia Flash files, iTunes music, and all other code and content that makes up the rich Internet experience? Google developers will have a hard time delivering all that functionality themselves. They would have to perfectly code every (or at least the most popular) content-type rendering engines. More than likely, Google will allow other vendors' products to interact with their products, and that brings up dozens of security issues in a given month.
I'm even ignoring for the moment the reports that the Google OS will be a Linux variant. Linux itself has many kernel bugs a year. Google Chrome, the browser, relies upon other components (such as Web Toolkit) with have their own vulnerabilities.
There are other hard questions: How will people be able to save content between sessions or send each other files? How will Google be able to perfectly distinguish between malicious and legitimate file attachments when no other company has been able to do it?
Allow users to save content on the local machine and you've opened up a potential security hole. Only allow objects to be saved in the cloud, and the cloud becomes the target. Heck, most of the cloud vendors are still trying to come to grips with what securing the cloud even means, much less having a perfectly secure cloud.
Google can only accomplish a perfectly secure OS by coding with zero bugs (which has never been done and will never be done), by interacting with perfectly secure third-party products (which don't exist), and/or by providing less functionality and customization to its customers. That's a tall order and a prescription for strong competition, because no matter what we believe, customers really don't want perfectly secure software - at least not at the expense of rich features.
To its credit, Google does have a better-than-average chance of making a relatively more secure OS. Google developers don't have the incredible backward-compatibility issues that Windows, Linux, and BSD product teams must deal with. Google has a chance to strike out on its own and support what it wants want to support. The company did something similar with the Chrome browser. But again, Google's previous security track record indicates that perfect security – even with less functionality – will be difficult.
A Google Chrome OS could be successful for a lot of other reasons, and I applaud Google for its initiative and innovation. (By the way, congrats for Gmail coming out of beta! ) I'm always a believer in more competition. It improves everyone's product and usually benefits the customer. But after spending 23 years in the computer industry and hearing the repeated false promises of "perfect security," please excuse me if I'm skeptical.
Processor.com: Storage Encryption Strategies
by George Crump
When it comes to storage encryption, the primary concern is protecting data as it leaves the trusted environment of your data center. There are three primary cases when this occurs; users taking data out of the environment on USB memory sticks, external hard drives, and laptops; data being moved offsite for long-term storage or protection from disaster; and when storage systems are decommissioned. There is also the case of storage being encrypted as an extra level of security within the trusted environment. In all cases, encryption needs to be applied in a way that is effective yet unobtrusive to business operations.
User Storage
Today's workforce is becoming more and more mobile, with employees working from home or on the road via laptops and USB drives. Given the risk of the devices being lost or stolen, there must be safeguards put in place to make sure that the data can't be read.
"At the device level, companies and government agencies are requiring that users utilize portable storage devices that utilize encryption," says Gary Streuter, vice president of marketing at CMS Products (www.cmsproducts.com). "These devices basically work by setting a password for the device so that when it is plugged in to a USB port, the user is prompted for the password, [and] after so many—typically five—failed attempts, access to the device is denied, and in some cases it will erase itself."
For laptops, there is the typical security of logging in to the system, but Streuter advises that may not be enough. "Often users will either have their systems set for auto-login or create very simple passwords that are easy to defeat," he says. For laptops, shared computers at home, and even shared drives on a corporate file server, Streuter recommends the use of a software application that can encrypt the data on laptop drives or in folders on shared systems to provide a second challenge for access.
These systems can also be set for a time-out value that will require reauthentication after a period of inactivity, putting the system to sleep or shutting it down. Such software protects highly sensitive data from an internal breach as well as a user walking away from a machine and forgetting to log out.
Data Center Storage
The primary focus for encrypting data center storage should be as it leaves the trusted environment either for long-term storage or when it is decommissioned. Encryption often is not effective against internal threats such as those from internal IT staff or external maintenance providers because they have been authorized and placed in the trusted environment.
Jose Carreon, product marketing manager for security technologies at Brocade (www.brocade.com), suggests that primary storage should be the critical focal point for storage managers. "Primary storage is always the most important to encrypt [because] it is the storage layer where most of the dynamic sensitive data resides," he says. "For example, assume credit card information that gets accessed and processed every second of the IT working day . . . has to be protected while in transit and at rest."
According to Kevin Bocek, director of product marketing for Thales Information Systems Security (iss.thalesgroup.com), there are four primary ways that users can encrypt data center storage in transit or at rest: application-based encryption, which encrypts data as the application writes it to storage; host bus adapter-based encryption via a storage card, which encrypts data as it leaves the host on its way to storage; SAN-based encryption, which encrypts data as it enters the storage fabric; and encryption at the array or drive level.
"Each of these methods has its advantages," says Bocek. "Encrypting at the application level makes sure that data is encrypted as it is written to the storage system, but applications need to be rewritten to take advantage of that; additionally, it is sometimes difficult to determine what data should and should not be encrypted. In similar fashion, HBA-based encryption is ideal if just a few applications on a few servers need encryption, but in today's environment, with server virtualization, it may be hard to isolate the application. Additionally, the cost of replacing cards could be expensive if many servers need encryption. Encrypting in the storage fabric provides [broader] encryption without having to change the application or the HBA cards. Finally, storage again can encrypt everything broadly, but it requires replacing the current tape or storage solution."
Bocek believes that for many customers, encrypting at the fabric through either a specific appliance or switch provides the right balance of broad encryption without disruption or replacement of key components in the environment.
Brocade's Carreon agrees that fabric-based encryption may be the most suitable location for most customers. "Encryption technologies typically have a serious impact on systems when deployed in software. When encryption is implemented in hardware, the scenario is very different in that you deploy dedicated and highly optimized encryption devices that can deliver from 48 up to 96Gbps of encryption processing, enabling customers to choose to encrypt all data if they desire to do so."
Archive Storage
Another key area for encryption strategy is archiving data that needs to be maintained for adherence to specific industry regulations or for disaster recovery purposes. According to Jered Floyd, CTO of Permabit Technologies (www.permabit.com), this creates an unusual dichotomy. "On one hand, the data has to be retained for years and be readily accessible. On the other, it is often data that needs to be encrypted in case of loss." Floyd suggests that the encryption in this case needs to be handled exclusively by the device because it potentially will outlive any primary storage encryption strategy put in place.
Decommissioning of older storage is another situation where data leaves the building, which can be of concern if the data is replicated to a untrusted environment. "Most disk archive customers will replicate their archive storage to another facility, [but] some of those customers may put that into a hosting facility that is outside of the organization's trusted environment."
In either case, Floyd suggests the strategy of having the encryption intelligence stay with the archive. A storage shelf pulled from the archive is no longer able to see the encryption keys, and as a result, data cannot be read. In the situation where replication is to an untrusted remote site, there should be the option to not replicate the keys, and as a result, data cannot be read by the hosting company's staff.
What To Encrypt?
Beyond protecting data that is leaving the environment, the key decision that most customers need to make is what data to encrypt. According to Brocade's Carreon, "The simplest approach may be to encrypt all the data. Otherwise, any company with requirements for compliance to federal and industry mandates needs an assessment of their data that is typically accomplished through a data classification exercise."
He continues, "Once you identify sensitive data, where it lives, and who owns it, you have to then define the relevant policies for enforcing the encryption and data center security requirements. Products that enable customers to have the flexibility and choice to encrypt all data without any impact to the day-to-day operational environment may be a safer and a simpler approach."
