Remote management

The Safest Way To Do Remote Desktop Support

In a recent Q & A episode of the Security Now! podcast with Steve Gibson and Leo Laporte, a reader was concerned that doing remote desktop support on infected PCs from his computer could make him vulnerable to infection. As I always do, I immediately began thinking about how I would answer the question (my wife thinks I’m nuts because I’m always talking to myself while I listen to the podcast).  In my experience with remote support programs, I’ve never had a problem with malware, so never considered the issue. However, I have to agree that Steve’s answer amounts to the safest way to do remote desktop support on infected PCs. Here’s an (edited) excerpt from Security Now!Episode 146:

STEVE: …In a perfect world, [remote desktop support] would be completely safe because…

LEO:  You’re not really running anything on your system.  It’s a window into their system; right?

STEVE:  Exactly.  Essentially you’re seeing their video, and you are taking over their mouse and keyboard.  So it’s purely a remote I/O sort of deal.  But we know it’s not a perfect world… So if…there were a vulnerability in whatever remote communications software you were using, and malware knew about that, it would be…possible for the malware to detect that you had connected using VNC, GoToMyPC, Remote Desktop…and exploit a known problem in order to cause a buffer overrun at your end of the connection.

LEO: So anytime you’re having a conversation with another computer, there’s always that potential no matter what protocols you’re using.

STEVE: Yes. So what I would do if I were a person who was going to be sort of habitually connecting to probably infected remote machines…you’d want to do that in a VM [virtual machine] at your end.

I’ve often recommended using virtual machines for surfing the web. My post, “Two Ways to Operate Securely on the Web,” is a good example. Extend that security maxim to remote connections of all kinds and you’ll be even safer.

This Router Configuration Option Can Be Dangerous

In my February 20th post, “Omit This Setup Step and Your Router Can Be Easily Compromised,” I stressed the importance of changing the default router password. I forgot to mention in that article another configuration option that can be dangerous, even if you’ve changed the default password: Remote management. While I’ve never seen this feature enabled by default, it’s better to err on the side of paranoia and make certain it isn’t enabled on your router.

Obviously, this would be a serious problem if you haven’t changed the default password; it’s less of a concern if you have, but passwords can be cracked and if someone decides to target you, it’s not a good idea to have your router’s login visible to them. If you absolutely must have remote management available to you (why?), then it’s imperative that when you change the default login password, you use an unguessable and virtually uncrackable one.

HP’s iLO is not Vulnerable to Phlashing Attack

My May 29th post, “Phlashing Attack Can Damage Systems Beyond Repair,” generated some attention from Hewlett-Packard’s PR department. Depending on how you read it, my article could be interpreted to imply that their Integrated Lights Out (iLO) embedded remote management interface may be vulnerable to the PhlashDance attack. It wasn’t my intention to imply this and I am convinced that iLO is secure.

After having had a cordial conversation with Doug Hascall, Manager, iLO firmware, Industry Standard Servers, Hewlett-Packard, I agreed to post details about iLO’s security. Here is Doug’s email responding to my article:

Ken,

I enjoyed our conversation yesterday regarding the security of iLO and the phlash attack referenced by my colleague Richard Smith. As I mentioned on the phone, we take the security of iLO and our HP servers very seriously. This note is to share some of the information we discussed regarding iLO’s flash security.

iLO firmware employs the following flash protections:

* iLO firmware images are digitally signed with a 1024-bit RSA public/private key.
* The digital signature is checked before allowing a firmware update process to continue.
* The digital signature is checked by the iLO boot block every time iLO comes out of reset.
* The iLO boot block can only be flashed by physically changing a switch setting inside the server.
* Flashing the iLO firmware remotely requires login authentication and authorization, including optional two-factor authentication.
* The iLO firmware image to be flashed is completely uploaded into RAM before reprogramming of the flash device.

All ProLiant iLO firmware releases, from the original version that shipped with the ProLiant DL360 G2 in March 2001, have employed these protections.

I conferred with Rich Smith via e-mail to explain the iLO security architecture and to investigate the possibility of iLO being vulnerable to a Phlashing attack. Rich’s assessment was that iLO firmware and its upgradeability appear to have been designed with security in mind and he does not believe that iLO would be susceptible to a phlash attack or the methods used in the phlashdance fuzzer.

Security is a vitally important topic. I appreciate the attention that the security community brings to this topic and the associated opportunity we have to improve our products.

Respectfully,

Doug Hascall
Manager, iLO Firmware
Industry Standard Servers
Hewlett-Packard

This is security done right. Are you listening, Microsoft?