An Update On Special Needs Device Hacking

I previously posted an entry entitled Security and the Special Needs Person where I described current hacking attempts against special needs devices by security researchers. In that post, I opined that there was probably some better use of the researcher’s time. Rather than give hackers new and wonderful ways to attack the human race, why not find ways to develop secure software that would discourage attempts in the first place? Unfortunately, it seems as if the security researchers are simply determined to keep chewing on this topic until someone gets hurt or killed. I never even considered this topic in my book, “Accessibility for Everybody: Understanding the Section 508 Accessibility Requirements” because it wasn’t an issue at the time of publication, but it certainly is now.

Now there is a ComputerWorld article that talks about wearable devices used to jam the signals of hackers trying to attack those with special needs devices. What do we do next—encase people in a Faraday cage so no one can bother them? I did find the paper referenced in the article, “They Can Hear Your Heartbeats: Non-Invasive Security for Implantable Medical Devices” interesting, but must ask why such measures even necessary. If security researchers would wait until someone actually thinks of an attack before they came up with a remedy, perhaps no one would come up with the attack.

The basis of the shielding technology mentioned in the ComputerWorld article is naive. Supposedly, the shield lets the doctor gain access to the medical device without allowing the hacker access. Unfortunately, if the doctor has access, so does the hacker. Someone will find a way to overcome this security measure, probably a security researcher, and another shield will have to be created that deflects the new attack. The point is that if they want the devices to be truly safe, then they shouldn’t send out a radio signal at all.

The government is involved now too. Reps. Anna G. Eshoo (D-CA) and Edward J. Markey (D-MA), senior members on the House Energy and Commerce Committee, have decided to task the the Government Accountability Office (GAO) with contacting the Federal Communications Commission (FCC) about rules regarding the safety and security of implantable medical devices. I can only hope that the outcome will be laws that make it illegal to even perform research on these devices, but more likely, the efforts will result in yet more bureaucracy and red tape.

There are a number of issues that concern me about the whole idea of people wearing radio transmitters and receivers full time. For one thing, there doesn’t seem to be any research on the long term effects of wearing such devices. (I did find research papers such as, “In-Body RF Communications and the Future of Healthcare” that describe the hardware requirements for transmission, but research on what RF will do to the human body when used in this way seems sadly lacking.) These devices could cause cancer or other diseases. Fortunately, the World Health Organization (WHO) does seem to be involved in a little research on the topic and you can read about it in their article entitled, “What are electromagnetic fields?“.

In addition, now that the person has to wear a jammer to protect the implantable medical device, there is a significant chance of creating interference. Is there a chance that the wearer could create unfortunate situations where the device intended to protect them actually causes harm? The papers I’ve read don’t appear to address this issue. However, given my personal experiences with electromagnetic interference (EMI), it seems quite likely that the combination of implantable medical device and jammer will almost certainly cause problems.

In summary, we have implanted medical devices that use radio signals to make it more convenient for the doctor to monitor the patient and possibly improve the patient’s health as a result. So far, so good. However, the decision to provide this feature seems shortsighted when you consider that security researchers just couldn’t leave well enough alone and had to find a way for hackers to exploit the devices. Then, there doesn’t seem to be any research on the long term negative effects of these devices on the patient or on the jammer that now seems necessary to protect the patient’s health. Is the potential for a positive outcome really worth all of the negatives? Let me know at

Security and the Special Needs Person

I’ve written quite a bit about special needs requirements. In my view, everyone who lives long enough will have a special need sometime in their life. In fact, unless you’re incredibly lucky, you probably have some special need right now. It may not be a significant special need (even eyeglasses are a special need), but even small special needs often require another person’s help to fix.

Accessibility, the study of ways to accommodate special needs, is something that should interest everyoneespecially anyone who has technical skills required to make better accessibility aids a reality. It was therefore with great sadness that I read an eWeek article this weekend describing how one researcher used his talents to discover whether it was possible to kill someone by hacking into the device they require to live. Why would someone waste their time and effort doing such a terrible thing? I shook my head in disbelief.

There is a certain truth to the idea that the devices we use to maintain health today, such as insulin pumps, are lacking in security. After all, they are very much like any other Supervisory Control And Data Acquisition (SCADA) device, such as a car, from a software perspective and people are constantly trying to find ways to break into cars. However, cars are not peoplecars are easily replaced devices used for transport. If someone breaks into my car and steals it, I’m sad about it to be sure, but I’m still alive to report the crime to the police. If someone hacks into my pacemaker and causes it to malfunction, I’m just as dead as if they had shot me. In fact, shooting me would probably be far less cruel.

I know that there is a place for security professionals in the software industry, but I’ve become increasingly concerned that they’re focused too much on breaking things and not enough on making them work properly. If these professionals spent their time making software more secure in the first place and giving the bad guys fewer ideas of interesting things to try, then perhaps the software industry wouldn’t be rife with security problems now. Unfortunately, it’s always easier to destroy, than to create. Certainly, this sort of negative research gives the security professionals something to talk about even though it potentially destroys someone’s life in the process.

I’d like to say that this kind of behavior will diminish in the future, but history says otherwise. Unless laws are put in place to make such research illegal, well meaning security professionals will continue dabbling in matters that would be best left alone until someone dies (and even then the legal system will be slow in reacting to a significant problem). I doubt very much that time spent hacking into special needs devices to see just how much damage one can do helps anyone. What is your thought on the matter? Does this sort of research benefit anyone? Let me know what you think at

Sniffing Telnet Using Wireshark

In my previous post about Telnet entitled, “Using Telnet to Perform Tasks” you discovered how to use Telnet to work interactively. Now you have enough information to view some of the security issues with Telnet. It’s incredibly easy for someone to monitor your Telnet session. The only protection you have is firewalls and other security you might have in placeTelnet is completely open and offers nothing in the way of security. Lack of security is one of the reasons I didn’t cover this utility in the Windows Command-Line Administration Instant Reference.” (Telnet is covered from a command line perspective in Administering Windows Server 2008 Server Core.”) However, the lack of security isn’t a problem in some situations and many administrators prefer to use Telnet to manage some network hardware such as switches and routers. Consequently, the main emphasis of this post is building an awareness of the security issues behind using Telnet so that you can make a good decision about using it to meet your needs.

Before you can see the security issues for yourself, you need to download a utility to sniff packets on your network. This post will rely on a free utility named Wireshark because it does the job admirably and is supported on a number of platforms. Because I’m using the 64-bit version of Windows 7, I downloaded the 64-bit Windows installer for the 1.4.7 version of Wireshark. To make things simple, I performed a full install. Part of the Wireshark setup will also install WinPcap, so you don’t need to install this product separately. If you’re using some other version or configuration of Wireshark, your screen may not look precisely like mine.


Using a sniffer is somewhat dangerous and you need administrator privileges to do it. This post isn’t designed to make you an expert in protocol sniffing. In fact, this post is exceptionally simple and is designed only to make you aware of deficiencies in Telnet security. The nefarious individual who gains access to your network to sniff about will have significantly more skills and be able to learn considerably more than you’ll learn using the simple directions in this post.

After you complete the installation, you’ll be able to start Wireshark. Choose Start > All Programs > Wireshark and you’ll see the initial Wireshark display shown here.


Wireshark isn’t configured to work with Telnet at the outset, so you need to tell it what to sniff. Click Capture Options and you’ll see what looks like an incredibly complex Capture Options dialog box like the one shown here.


We’re not going to worry about the vast majority of these options. In fact, you only need to set two options to sniff out Telnet packets. Look first at the Interface field. Make sure it’s set to Local. Select your network adapter from the drop down list box. The network adapter will normally have a human readable name, not something odd as shown in the screenshot.

Next you need to tell Wireshark what to sniff on the interface you’ve selected. Click Capture Filter. Type Telnet in the Filter Name field and port 23 in the Filter String field. Click New. Your dialog box should look like the one shown here.


Click OK. You’ll see the filter criterion entered in the Capture Filter field. More importantly, Wireshark is now configured to offer a Telnet filter anytime you need one. Click Start. The Wireshark display will change, but you won’t see anything on itthe display will be blank.

Open a command prompt and start a copy of Telnet in interactive mode. Make sure you open a command prompt with administrator privileges. The act of starting Telnet won’t create any packets as you can see in Wireshark. In fact, type ? and press Enter. You’ll see that Telnet is still perfectly safeit isn’t generating any packets.

Use the Open command to open a connection to your server. Simply typing O ServerName and pressing Enter generates packets. You can see them in Wireshark like this:


Notice that some of these entries are labeled Telnet Data. In addition, the Source and Destination columns tell you which direction the information is flowing (the client is in this case). Click on the first of these entries and you’ll see that the middle panel contains some information about the Telnet Data. Open the Telnet entry and you’ll see some interesting information as shown in the figure. For example, the packet information tells the viewer that Telnet is set to use the authentication option.

Go back to the command prompt now. Type y and press Enter to send your password information to the server. Of course, one of the big questions you probably have is whether Telnet is exposing your username and password. Near the end of the packets, you’ll find one that contains an Suboption Begin: Authentication Option entry like the one shown here.


In this case, the option entry tells the server that the client won’t forward the authentication credentials. The option works because I’m already signed onto the server and the server already has my credentials. This is one of the items you’ll want to check for your own Telnet setup, however.

Unfortunately, this session isn’t safe by a long shot. Type just a single letter, a D, at the command prompt. You’ll find that typing this single letter generates a packet that you can see with Wireshark like the one shown here.


In fact, you’ll find that every action on your part creates more packetseach of which is easily sniffed by anyone with Wireshark or any other application of the sort. Finish the command by typing ir and pressing Enter. You’ll see the expected response at the command line.

At this point, you can also see the response from the server in Wireshark. The text isn’t as readable because it contains all of the control characters normally used to format the text. However, here’s an example of the response as it appears on my system.


Look at this response carefully and you’ll see that anyone can learn precisely what you’re doing. If you have to enter passwords to perform a particular task, the viewer will get them too. Telnet isn’t a secure method to manage anythingyou need to provide a secure environment in which Telnet can run. This post only touches on the tip of the iceberg, of course. Let me know if you have any questions about it at


Telnet Not Included

Every book I’ve written has required some hard decisions. Believe me, I think about every omission and addition at length, and then I think about them again. In many cases, I’ll ask my editors, especially my technical editor about it. In some cases, the beta readers for my book will get an e-mail about the topic as well. I made these sorts of decisions when writing Windows Command-Line Administration Instant Reference as well. So it was, after trying to wring everything I could out of every page in the book, I was faced with the unpleasant decision of having to leave Telnet out. It wasn’t an easy decision because I had included it in past tomes about the command line, such as “Administering Windows Server 2008 Server Core,” (see page 440 of that book) which also contains a wealth of other commands.

Readers have asked about the Telnet omission. I’ve been surprised to find that quite a number of people still use this utility and would have liked a more comprehensive discussion of it in my current book. There were a number of reasons for the omission. The most important at the time is that Telnet isn’t enabled by default anymore on Windows. You must install it as a separate item. In fact, you must also install the client on newer systems as shown here for Windows 7.


So, why is everyone apparently making it difficult to use Telnet? Well, it turns out that Telnet has been implicated in more than a few security problems. Telnet was designed for a time when you could trust a connection. It doesn’t provide modern security features, such as encryption for the username and passwordit passes this information in the clear so anyone can grab it. In fact, a simple check on Microsoft’s Knowledge Base shows 1,430 hits for Telnet Security Issues (as of this writing). There are many non-Microsoft sites, such as this James Stephens blog entry, that detail the problems with Telnet as well. With pages at a premium, I decided the security issues surrounding Telnet were a good reason not to include it.

I’ve written a number of command line reference books. Each with a different audience in mind. In Windows Command-Line Administration Instant Reference I chose to provide support for administrators who need quick reference to actual commands, rather than simply a command reference. In addition, the page count of this book is smaller and the book itself is a smaller size to make it easy to carry around. The addition of examples and the reduction in size meant that I had to choose which commands to cover quite carefully. As described in another recent post, Techniques for Choosing a Technical Book, it’s important that the reader choose the book that meets their needs. In some cases, readers will be better served by the more complete list of commands provided by Administering Windows Server 2008 Server Core, which is an actual reference book.

Of course, I’m always looking for ways to improve my books to make the next edition better suited to meet your needs. If I receive enough e-mail about Telnet, I may very well included it in the next edition of Windows Command-Line Administration Instant Reference. So please keep those e-mails coming! If you’d really like to see Telnet included in my next book, contact me about it at

So, here’s the short story about Telnet. As with most command line utilities, you can obtain general help by typing Telnet /? and pressing Enter. You’ll see the help screen shown here:


Notice that I’m using an Administrator command prompt. You absolutely have to elevate privileges to use Telnet successfully in Windows 7. In addition, you’ll need to open a hole in your firewall for port 23 (unless the Telnet server you want to contact is at a different porta minimal, but helpful security precaution).

In order to connect to a server, you type Telnet <ServerName>, where ServerName is the name of the server you want to contact. For example, if you want to contact a server named WinServer, you type Telnet WinServer and press Enter. Once you enter Telnet, type ? and press Enter to get help for that session.

It’s important to note that Microsoft provides some Telnet-related commands that you should know about if you really need to use Telnet for administration tasks. For example, the Telnet Server is TlntSvr.exe and you can use the TlntAdmn utility to perform administration tasks. Let me know if you’d like some additional posts on this topic and I’ll be all too happy to pursue it further.