Security Watch
RSS Feeds That Leave You Open?
Maybe not, but trust only what you know. Also: beware the danger inside virtual machines.
Based on an incredibly feeble premise, a
security firm is asserting that criminals are using RSS and Atom feeds to deliver malware. Authentium claimed that it examined the URLs embedded in 60,000 pieces of malware and discovered that more than 1,000 contained the word “blog.” From this, the firm concluded that RSS and Atom feeds were being used to distribute malware.
The more obvious conclusion is that sites that are set up to offer blogging services are simply less secure, with more vulnerabilities that allow criminals to take them over and use them to distribute their malware. Criminals are not likely placing their malware in the feeds, but simply on the sites that host the feeds -- there’s a big difference. Blogging software is still in its infancy, and much of it is a kludge to make the service work (think “shopping carts” from several years ago).
The article goes to great lengths to get several individuals to agree that malware submitted to RSS feeds would be a great way to increase delivery of that malware. While there’s no doubt that this is true, there’s equally no evidence that it's happening. Consider the difference between a site offering a Web page, and it offering the same content via RSS. Either way, the victim has to want to accept the content from that site. If the site’s RSS feed could be compromised to include malware, then it’s likely its Web site could also be compromised -- there’s little difference between them.
Finally, there’s the question of how the RSS feeds are being read. Typically, an RSS reader uses existing browsers, or browser components, to render the content in its feed. This usually means that whatever protections are available for the browser would be equally available to protect the user from criminal RSS content.
In the end, it boils down to a very simple reminder: You should only accept RSS feeds from sites you trust.
Another Week, Another Cisco Hole
Three vulnerabilities exist in Cisco’s IP phone devices. The first is in its Unified IP Conference Station devices, which contain a critical error in the authentication mechanism used by the HTTP Administrative Interface. They completely ignore authentication after an administrator has logged in. Before they can look for authentication to grant administrative privileges again, the system has to be cold-booted -- simply reloading will not reset the authenticated state. Patches are available.
The next involves Cisco's IP phones. These devices have been shipped with a default userID and password embedded in the system, which can allow anyone to remotely connect to the device as an authenticated user.
The last also involves the IP phones. This vulnerability allows any authenticated user the ability to elevate their privilege to that of administrator, and make any changes to the system such privileges provide.
One really has to wonder how devices can be released with such obvious security flaws. Buffer overflows are typically the most common security errors, and are at least somewhat understandable. The obvious lack of security testing of these devices by Cisco prior to release, however, makes one wonder whether the company had even thought of security with the devices. Of course, these devices should not be exposed to untrusted networks, so any attack will likely come from your own users.
Despite these glaring vulnerabilities, VoIP hacking is still more the stuff of legend than reality.
VMs Create Potential Risks
This is an interesting, albeit meat-free, article on the potential risks of using virtual machines. It suggests different risks that may be possible, and ideas that are being tossed around over how VM attacks might come about. It also suggests there will be a headlong rush into VM adoption, which is more a marketing wish than reality, at this point.
Like any application, Hypervisors, or the VM controller software that allows different VMs to reside on the same machine, can be securely or insecurely deployed. Furthermore, the VMs they spawn can either be deployed securely or not -- it depends on the installer.
| Want
More Security? |
This
column was originally published in our weekly Security
Watch newsletter. To subscribe, click here. |
|
|
Perhaps the only thing that rings true in the article is the fact that some will likely believe that their VM environments are as secure as the host environment. This will not likely be true by default; VMs will require careful consideration for security, each on their own. Equally true is the fact that keeping VMs up-to-date will be a complicated task. For example, ensuring that the host environment receives its appropriate Windows Update patches will be far easier than ensuring the same is true for the various VMs that are running.
Finally, if VMs are used to run out-of-date OSes to support applications with no forward migration path, an otherwise secure machine may be left with a gaping vulnerability via the application/OS running in a VM on the same box.
About the Author
Russ Cooper is a senior information security analyst with Verizon Business, Inc.
He's also founder and editor of NTBugtraq, www.ntbugtraq.com,
one of the industry's most influential mailing lists dedicated to Microsoft security.
One of the world's most-recognized security experts, he's often quoted by major
media outlets on security issues.