Gaining the ability to remotely control your HVAC might seem like an energy-responsible thing to do, but it might also pose hidden security risks.
In a recent blog titled Security implications in HVAC equipment SANS handler Swa Frantzen wrote of his concerns regarding one energy-saving program in Texas. The utility, TXU, uses what's called an iThermostat, which allows you to program your thermostat remotely over the Internet from any laptop or desktop.
In California, PG&E offers a similar program, SmartAC. PG&E also uses an Internet addressable, programmable thermostat, however, the user guide (PDF) mentions only remote access from the utility, not from the end user.
Frantzen makes it clear that's he's not intentionally picking on the iThermostat system; he's only using it for educational purposes. Nor am I necessarily saying the SmartAC program is flawed either. I do, however, think his academic questions are quite valid because they go beyond just HVAC systems.
Recently there was a security hole identified within an Internet-connected coffee maker. I think the first question here should be: do we really need to access our coffee machine remotely?
It might be argued that these systems (the HVAC and coffee machine) both terminate--they don't necessarily allow a remote attacker access to a home computer network. But that's for right now. Jump ahead a few years when these systems start talking each other, when you'll be able to create a warm and comfy home environment from your desktop at work.
Until then, what if someone remotely views your schedule of when the AC turns on and off? It could tip a potential burglar to when you're likely to be home and when not. And what if, asks Frantzen, the remote lockout on the thermostat fails and some remote hacker cranks the heat or air conditioning setting to its maximum setting while you're on vacation?
Is anyone even thinking about these issues? If not, shouldn't someone be?
On Thursday, the domains used by ICANN, the Internet Corporation for Assigned Names and Numbers, and IANA, the Internet Assigned Numbers Authority, were hijacked. A Turkish hacking group known as NetDevilz claimed =responsibility. There is no word on how the hijack was accomplished.
The group successfully redirected ICANN site visitors to a page with the following message:
"You think that you control the domains but you don't! Everybody knows wrong. We control the domains including ICANN! Don't you believe us? haha :) (Lovable Turkish hackers group)"
According to SANS, changes to the ICANN site were corrected within 20 minutes. However, the update took another 24 to 48 hours to propagate throughout all the DNS serves worldwide.
On June 19, NetDevilz evidently hijacked Photobucket's DNS records, which resulted in a denial of service against that service.
The timing of the attack on ICANN is embarrassing for the organization, to say the least. Last week, ICANN announced it was opening up the generic top-level domain name (gTLD) to include just about anything. Currently, gTLDs are limited to .com, .net, .org, and 18 others. Under the new plan, like businesses could be organized under .healthcare, for example. In his blog, Neal Krawetz looks at the pros and the cons of the change.
None of the DNS hijacks have involved serving up malicious software.
On Monday, Adobe Systems rolled out its new Web 2.0 development tool, Adobe Integrated Runtime, or AIR. Following its release were some concerns from the security community.
Adobe CEO Shantanu Narayen talks up AIR at a San Francisco event.
(Credit: Charles Cooper/CNET News.com)AIR, formerly Adobe Apollo, is a runtime environment that allows developers use HTML, Flash, AJAX, Flex, and other Web 2.0 tools to create desktop applications. One such application built using Adobe AIR comes from Nickelodeon Online.
But some security experts are concerned about local file access by AIR applications. Recently, Firefox experienced a vulnerability that could have allowed remote attackers to access a targeted file system. To mitigate this, Adobe says it implemented a sandboxing environment, however, Adobe's documentation suggests that the sandboxes are less secure than a Web browser's sandbox.
Additionally, Adobe says that AIR applications need to be digitally signed, however, these certificates can be self-signed. And many users will ignore the warnings and run untrusted applications.
Finally, there is the potential for Cross-Site Scripting (XSS), SQL injection, and local link injection. While these threats are not limited to Adobe AIR, developers could gain a false sense of security by relying only on AIR's weaker sandbox protection.
Adobe has also provided the following: an informative article titled "Introduction to AIR security" and a white paper, "AIR Security" (PDF). But Lenny Zeltser, writing on the Sans Internet Storm Center site, notes that "many developers will be unaware of Adobe AIR security best practices or will knowingly take shortcuts that expose end users to attacks."
On Tuesday, exploits for the Yahoo apps were reported circulating. There is currently no patch from the individual vendors, so the only workaround is to disable the several specific, vulnerable ActiveX controls. (ActiveX controls were developed by Microsoft for use with Internet Explorer and other browsers.)
The SANS tool, available here, eliminates the risks associated with editing the Windows system registry file. A command line version is available here.
The kill-bit tool first checks your system to see if any of the vulnerable CLSIDs exist. If so, the tool saves a copy of any values currently set, then updates the display to show that the CLSID--the unique sequence assigned to each ActiveX component that specifies which control you are using--exists. It also shows whether the kill-bit flag is set. To set the kill-bit, just check the box beside any of the affected ActiveX controls then click on the "Set" button. Unchecking any of the boxes will either reset the "Compatibility Flags" to their saved value or remove the CLSID entirely (if you didn't have the control installed in the first place).
SANS suggests setting the kill-bits for all of the affected ActiveX controls, and, even if you don't currently have one or more of these CLSIDs installed on your machine, go ahead set the kill-bit for controls that might be added to your system in the future.
- prev
- 1
- next
