Tag: Security

Exercising Personal Privacy

In my post, “Is Privacy a Right?,” I tell developers that they really need to consider the right of the user to a certain amount of privacy. Books such as C# Design and Development will need to include sections on privacy as part of any update. In fact, privacy is a topic not covered to any extent in any development book on my shelf. The few mentions of privacy appear in older books I’ve written, along with a few moldy references to old books by other authors. If you really want to get a modern treatment of privacy as a question of what the individual requires, you need to look at a non-development book such as “Alone Together: Why We Expect More from Technology and Less from Each Other.” Unfortunately, this book discusses social ramifications—not the techniques a developer uses to ensure privacy. Of course, no matter what the developer does, the user can always thwart any effort to provide privacy, which is the topic of this post.

I find it amazing that people willingly give up their privacy for apparently little or no reason. I read John Dvorak’s post, “I’m Not Home Right Now. Please Come In.” with great interest this morning (after having read the news report that he discusses). The idea that a husband would be able to check up on his cheating wife through an iPhone application is amazing to me. The private detective industry should take note that they’ve been replaced by a phone. It won’t be long before someone comes up with an application to surreptitiously take pictures of the dupe who loads one or more of these applications on their cellphone.

After thinking about this issue for a long time, I’ve come to the conclusion that some people have watched one too many episodes of CSI (and shows of that ilk). There is a sense that someone is going to reach out and grab each of us, and that our cellphones are the only way anyone will find us again. It’s also human nature not to be left out. If people don’t know where we are, we might miss out on something that we think is important at the time, but turns out not to be much of an issue at all in hindsight. I’m sure that little Jerry can find his sock just fine without dad’s intervention over the telephone (a little self-sufficiency does everyone good). The announcement that Maggie has a new tooth can easily wait until mom gets home from the store.

There should be alarm bells going off in the minds of every person who currently owns a cellphone, OnStar, or any other tracking technology. Do you really want someone to follow absolutely every move you make in the interest of providing some uncertain sense of security? Privacy, once lost, is incredibly hard to regain. People should learn how to disconnect in comfort, keep their privacy intact, and discover the wonderful world of being alone every once in a while. I think you’ll find that you’re a lot less stressed once you get used to it. Consider Remembering to Rest as not just beneficial to yourself, but those around you.

Most of all, it’s time that people learn to demand privacy from their technology. Whoever created the new tracking application in the iPhone wasn’t thinking and people should disable it sooner than later. It’s not necessary for vendors to track your every move online. No one gains anything by knowing you’ve gone to the store to buy this week’s groceries. All of the applications that are tracking you are stealing your privacy and making you a target for all of the things you fear most. Don’t give criminals (or marketers) an edge. What is your privacy worth to you? Let me know at [email protected].

 

Is Privacy a Right?

One of the readers of C# Design and Development took me to task some time ago for not discussion the matter of security in my book. He has been the only reader to ever ask me about the issue of privacy, so I didn’t think too much about it at the time. When I wrote the book, I thought it far more important to discuss security-keeping the data, application, and user safe. In fact, the book makes security part of an application triad the developer must consider during the design process. My thinking at the time was that privacy is a matter settled by management as part of a policy that is often implemented outside the developer’s control. To a certain extent that perception is still valid, but I’ve since learned that the developer does bear some responsibility toward the user when it comes to privacy.

A recent ComputerWorld article has made me think yet again about the whole issue of privacy. In this case, OnStar is collecting absolutely every last bit of information they can about you, without your permission, and selling it to anyone with a few pennies to spend. (A later article says that OnStar is reversing course on this decision.) They do tell you about spying on you, but you’ll only find this information if you read through the legalese contained in the Terms & Conditions. However, there are some people who don’t think you have any right to privacy in the first place. Industry leaders that include Facebook chief Executive, Mark Zuckerberg, Google chief, Eric Schmidt, Sun Microsystems chief, Scott McNealy, and Oracle chief, Larry Ellison would prefer you not to have any privacy whatsoever. They’d simply love to dig into every aspect of your life. The use of newer technologies, such as super cookies, have also proven that companies have a strong desire to invade your privacy.

The design of supercookies and the obvious desire of some technology leaders to invade your online privacy and collect data on you has subsequently inspired many to find ways to hide their IP address. A lot of the time, we are so caught up in luxurious technology, such as iPhones or Macbooks, that we don’t even realize that these devices are collecting data on us and feeding it to all sorts of websites. It’s no surprise that people are now opting to look into VPN’s and proxies to not only hide their IP and therefore protect their personal data, but to unblock websites on Mac and other devices.

So, the developer is faced with a number of questions when it comes to privacy. The most important of which is whether privacy is a right. According to the ComputerWorld article, the senate has finally woken up and decided that perhaps privacy is a matter they really should consider, especially when it comes to such brazen violations such as the one by OnStar. There is some validity to the belief that the Constitution and Bill of Rights offers at least some protection of privacy. Some laws, such as the Health Insurance Portability and Accountability Act (HIPAA) add additional rights. However, I imagine that we’ll experience years of delays, political wrangling, and legal interpretation before those rights are specifically spelled out in a way that developers (and others) can understand.

Assuming that a certain level of privacy is a right and that it’s legally protected, the developer still has a host of questions to answer. Here are some of the things you should think about as a developer when designing an application.

  • What is the company policy regarding privacy?
  • How does an application specifically guard or expose a user’s privacy?
  • When does a user’s right to privacy override the desire of management to invade it?
  • Which rights does a user forfeit as a member of an organization?
  • Is privacy configurable as an opt in or an opt out selection?
  • Precisely what information does the company collect?
  • Precisely what information does the company actually need to conduct business?


If the developer of the OnStar system had included a simple switch for turning the device off (disallowing any eavesdropping of any sort), the whole issue discussed in the ComputerWorld article would be moot. Unfortunately, no one thought to include such a switch, despite the fact that it would have been an obvious design addition. Of course, we don’t need to look specifically at OnStar as a bad example of privacy thwarted. Many applications today include a “call home” feature and won’t even work if you don’t have an Internet connection. In short, someone somewhere is spying on you constantly.

When you look for privacy-related design information for the developer online or in books, you find it mysteriously missing. The reader who called my book into question was right to do so. I hope that this small article has at least started you thinking about privacy and overcomes the omission in my book. Future posts will fill in some additional gaps, but I’d like to hear your perspective on the issue of privacy first. What questions do you have about privacy? How would you design an application that protects user privacy while meeting organizational needs for information? Let me know at [email protected].

 

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 [email protected].

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 everyone—especially 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 people—cars 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 [email protected].

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 place—Telnet 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.

Wireshark01

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.

Wireshark02

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.

Wireshark03

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 it—the 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 safe—it 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:

Wireshark04

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 192.168.137.131 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.

Wireshark05

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.

Wireshark06

In fact, you’ll find that every action on your part creates more packets—each 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.

Wireshark07

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 anything—you 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 [email protected].

 

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.

TelnetInstallation

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 password—it 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 [email protected].

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:

TelnetHelp

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 port—a 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.