Internet of Things (IoT) Security Issues

In the past, I discussed how the Internet of Things (IoT) could eventually cause a wealth of problems on the Internet, including security breaches, in a number of my books and articles. Some of my strongest warnings came in Build Your Own PC on a Budget and Security for Web Developers, but I included warnings in other places as well. Unfortunately, the worst case scenario has occurred according to the ComputerWorld article, Armies of hacked IoT devices launch unprecedented DDoS attacks. Yes, your DVR or smart television might have turned into a zombie at this point and now works for someone else committing crimes. All it takes is a little negligence on your part and your device will take a walk on the dark side.

The article is worthwhile reading because the statistics sound like something out of a bad science fiction novel. If anything, my warnings were too tame and I should have used my imagination a bit more in exploring just how bad things could get. Yet, I’ve received e-mail from readers who found the warnings I did provide barely believable. It didn’t seem possible that something as simple as the router installed to provide broadband support for your digital telephone could possibly cause any sort of problem. After all, your old telephone system never went on the attack. The thing is, any device that connects to the Internet today probably has enough intelligence to do harm, especially the IoT devices that everyone assumes just work.

IoT devices are actually some of the best targets for hackers. The users who have them barely know how they work, have no clue that they should change the password, and wouldn’t care even if they could figure it out. After all, the goal is to see Sunday afternoon football, not to configure security for a device. Vendors share in the blame because anyone with even a modicum of common sense would know that users have no desire whatsoever to change device passwords. IoT devices should go out with a unique password printed in a place that the user can easily find on the device, should it ever become necessary to access the device (and it might not ever become necessary). If hackers faced a unique default password for every device, the IoT devices would likely remain relatively secure unless hackers could somehow figure a pattern out in the password assignments. Ensuring the unique password is printed on the device means the user won’t lose it.

It’s not as if changing IoT device passwords is easy anyway, so hackers have every reason to believe that the default password is still in place for the majority of these devices. A recent device purchase pointed out to me that some IoT devices view even password changes as unwelcome user fiddling—it took nearly 20 minutes of reading to discover how to change the password using an arcane set of remote control clicks. Until this situation changes, you must expect that hackers will continue to use IoT devices to perform various kinds of attacks and that device owners will continue to remain oblivious about their cherished device’s life of crime. Let me know your thoughts on IoT security at John@JohnMuellerBooks.com.

 

Using Java with Windows 10

I’m starting to get more requests for information about using the materials in Java eLearning Kit for Dummies with Windows 10. Java for Dummies eLearning Kit is designed for use with Windows 7, Linux, or Mac OS X, and Java 7. However, as mentioned in the Java 7 Patches and Future post, I’ve tested enough of the code with Java 8 to feel fairly certain that the book will also work fine with Java 8. Unfortunately, using the book with Windows 10 will prove problematic.

The Windows 10 and Java FAQ sheet tells you about the some of the issues in using Java with the new operating system. For example, you can’t use the Edge browser with Java because it doesn’t support plug-ins. You need to install a different browser to even contemplate using Java eLearning Kit for Dummies—I highly recommend Firefox or Chrome, but the only requirement is that the browser support plugins.

Because Java eLearning Kit for Dummies is supposed to provide you with a more intense than usual learning experience, using Windows 10 is counterproductive. For example, none of the procedures in the book will work with Windows 10 because even the act of accessing the Control Panel is different. With this in mind, I truly can’t recommend or support Windows 10 users for this particular book without saying that your learning experience will be less complete than I intended when I wrote the book.

There is still no timeline from the publisher for creating an update of this book. If you really want a Windows 10 version of this book, then you need to contact the publisher directly at http://www.wiley.com/WileyCDA/WileyTitle/productCd-1118098781.html and ask for it. If you have any book-specific questions, please feel free to contact me at John@JohnMuellerBooks.com.

 

Mac Gatekeeper Error

A number of my books, such as C++ All-In-One for Dummies, 3rd EditionBeginning Programming with Python For Dummies, Python for Data Science for Dummies, and Machine Learning for Dummies ask readers to download an IDE or other code and install it on their Mac systems. The problem is that the Mac system won’t always cooperate. For example, you might see an error dialog like the one shown for Code::Blocks:

The Gatekeeper error tells you that it won't allow you to install software from unknown publishers.
Your Mac won’t let you install software.

The problem is one of permissions. The default permissions set for newer Mac systems restrict you to getting your apps from the Mac App Store or from vendors who have signed their files. Fortunately, you can overcome this problem either temporarily or permanently, depending on how you want to use your Mac. The Fix the “App can’t be opened because it is from an unidentified developer” Error in Mac OS X blog post provides you with illustrated, step-by-step directions to perform the task using either method. Let me know if you encounter any other problems getting your Mac to install the software required to use my books at John@JohnMuellerBooks.com.

 

Working with Code in e-Books

Most of my technical readers now use e-books instead of paper books. Of course, there is a convenience factor to storing your entire library on a Kindle, even if it’s a software version of the Kindle. Of course, there are all sorts of e-book formats for your desktop system as well. The point is that electronic format makes a lot of sense when dealing with technical books.

However, e-books can cause some interesting problems and I’ve encountered a few with a number of readers now. The most important consideration is that you can’t cut and paste code from an e-book directly into your IDE and expect it to work. There are all sorts of reasons for this exclusion. For example, cutting and pasting may insert special characters into the output stream or the resulting paste may not have white space in the right places. A common problem is that publishers often convert regular single and double quotes into curly quote equivalents. The two kinds of quotes (both single and double) are completely different and the second type definitely won’t compile.

The best option when working with an e-book is to view the code in the e-book, but still get the downloadable source code for the book from the publishers website. I always provide a blog post detailing where to obtain the downloadable source for a book, when you need source code to use the book. If you can’t find the downloadable source, always feel free to contact me at John@JohnMuellerBooks.com. I want to be sure you have a great reading experience, which means having source code that actually runs in your development environment.

Another potential problem with e-books is that you may see unfortunate code breaks (despite the efforts of the publisher and myself). When you need to understand how white space works with a programming language, always review the downloadable source. The fact that the downloadable source compiles and runs tells you that all the of white space is in the right place and of the correct type. Typing the source code directly out of your e-book could result in added carriage returns or other white space errors that will cause the code to fail, even though the commands, variables, and other parts of the code are all correct.

As always, I’m open to your questions about my books. If you don’t understand how things work, please contact me—that’s why I’m here.

 

Is Security Research Always Useful?

Anyone involved in the computer industry likely spends some amount of time reading about the latest security issues in books such as Security for Web Developers. Administrators and developers probably spend more time than many people, but no one can possibly read all the security research available today. There are so many researchers looking for so many bugs in so many places and in so many different ways that even if someone had the time and inclination to read every security article produced, it would be impossible. You’d need to be the speediest reader on the planet (and then some) to even think about scratching the surface. So, you must contemplate the usefulness of all that research—whether it’s actually useful or simply a method for some people to get their name on a piece of paper.

Some of the attacks require physical access to the system. In some cases, you must actually take the system apart to access components in order to perform the security trick. Unless you or your organization is in the habit of allowing perfect strangers physical access to your systems, which might include taking them apart, you must wonder whether the security issue is even worth worrying about. You need to ask why someone would take the time to document a security issue that’s nearly impossible to see, much less perform in a real world environment. More importantly, the moment you see that a security issue requires physical access to the device, you can probably stop reading.

You also find attacks that require special equipment to perform. The article, How encryption keys could be stolen by your lunch, discusses one such attack. In fact, the article contains a picture of the special equipment that you must build to perpetrate the attack. It places said equipment into a piece of pita bread, which adds a fanciful twist to something that is already quite odd and pretty much unworkable given that you must be within 50 cm (19.6 in) from the device you want to attack (assuming that the RF transmission conditions are perfect). Except for the interesting attack vector (using a piece of pita bread), you really have to question why anyone would ever perpetrate this attack given that social engineering and a wealth of other attacks require no special equipment, are highly successful, and work from a much longer distance.

Another example of incredibly weird security research is found in the article, When the good guys are wielding the lasers. I have to admit it’s interesting in a James Bond sort of way, but we’re talking about lasers mounted on drones. This attack at least has the advantage of distance (1 km or 0.6 mi). However, you have to wonder just how the laser was able to get a line of sight with the attack object, a printer in this case. If a device is critical enough that someone separates it from the Internet, it’s also quite likely that the device won’t be sitting in front of a window where someone can use a laser to access it.

A few research pieces become more reasonable by discussing outlandish sorts of hacks that could potentially happen after an initial break-in. The hack discussed in Design flaw in Intel chips opens door to rootkits is one of these sorts of hacks. You can’t perpetrate the hack until after breaking into the system some other way, but the break-in has serious consequences once it occurs. Even so, most hackers won’t take the time because they already have everything needed—the hack is overkill.

The articles that help most provide a shot of reality into the decidedly conspiracy-oriented world of security. For example, Evil conspiracy? Nope, everyday cyber insecurity, discusses a series of events that everyone initially thought pointed to a major cyber attack. It turns out that the events occurred at the same time by coincidence. The article author thoughtfully points out some of the reasons that the conspiracy theories seemed a bit out of place at the outset anyway.

It also helps to know the true sources of potential security issues. For example, the articles, In the security world, the good guys aren’t always good and 5 reasons why newer hires are the company’s biggest data security risk, point out the sources you really do need to consider when creating a security plan. These are the sorts of articles that should attract your attention because they describe a security issue that you really should think about. Likewise, reading articles such as, Software developers aren’t implementing encryption correctly and 4 fatal problems with PKI help you understand why your security measures may not always work as well as anticipated.

The point is that you encounter a lot of information out there that doesn’t help you make your system any more secure. It may be interesting if you have the time to read it, but the tactics truly aren’t practical and no hacker is going to use them. Critical thinking skills are your best asset when building your security knowledge. Let me know about your take on security research at John@JohnMuellerBooks.com.

 

Source Code Placement

I always recommend that you download the source code for my books. The Verifying Your Hand Typed Code post discusses some of the issues that readers encounter when typing code by hand. However, I also understand that many people learn best when they type the code by hand and that’s the point of getting my books—to learn something really interesting (see my principles for creating book source code in the Handling Source Code in Books post). Even if you do need to type the source code in order to learn, having the downloadable source code handy will help you locate errors in your code with greater ease. I won’t usually have time to debug your hand typed code for you.

Depending on your platform, you might encounter a situation the IDE chooses an unfortunate place to put the source code you want to save. For example, on a Windows system it might choose the C:\Program Files folder (or a subdirectory) to the store the file. Microsoft wants to make your computing experience safer, so you don’t actually have rights to this folder for storing your data file. As a result, the IDE will stubbornly refuse the save the files in that folder. Likewise, some IDEs have a problem with folder names that have spaces in them. For example, your C:\Users\<Your Name>\My Documents folder might seem like the perfect place to store your source code files, but the spaces in the path will cause problems for the IDE and it will claim that it can’t find the file, even if it manages to successfully save the file.

My recommendation for fixing these, and other source code placement problems, is to create a folder that you can access and have full rights to work with to store your source code. My books usually make a recommendation for the source code file path, but you can use any path you want. The point is to create a path that’s:

  • Easy to access
  • Allows full rights
  • Lacks spaces in any of the path name elements

As long as you follow these rules, you likely won’t experience problems with your choice of source code location. If you do experience source code placement problems when working with my books, please be sure to let me know at John@JohnMuellerBooks.com.

 

Web Application Security Breach Commonality

If you follow the trade news for even a few weeks, you begin to see a recurring pattern of security breaches based on web application deficiencies, social engineering attacks, or some other weakness in the security chain. The latest attack that is making the rounds is the IRS security breach. However, I’m not picking on the IRS, you can find security breaches galore in every arena of human endeavor simply by performing the required search. Everyone gets hacked, everyone is embarrassed by it, and everyone lies through their teeth about the methods used for the attack, the severity of the attack, and the likelihood of dire results. The attacks serve to demonstrate a simple principle I’ve written about in HTML5 Programming with JavaScript for Dummies, CSS3 for Dummies, and Security for Web Developers—if someone wants to break your security, they’ll always succeed.

Later analysis of the IRS attack brings out some important issues that you need to consider as part of your development efforts. The first is that you really do need to expend the effort to create the most secure environment possible. Many of the successful attacks use simple methods to obtain the desired result. Training really does help reduce social engineering attacks, updates really do help close security issues that a hacker can use to access your system, good programming practices keep hackers at bay, make applications easier to use, and reduce errors that result in security issues. All of these methods help you remain secure. However, remaining vigilant is important too. Monitoring your application and the libraries, APIs, and microservices on which they depend are all important. Despite protestations to the contrary, the IRS probably could have done more to prevent the breach, or at least mitigate the results of the breach.

A focal point of the analysis for me is that the IRS currently has 363 people working security and a budget of $141.5 million to ensure your data remains safe. The author is a bit harsh and asks whether the IRS Commissioner Koskinen thinks his people are stupid because he keeps making the claim that these hackers are quite skilled. Yet, the hacks used are really quite simple. Breaches happen to every organization at some point, no matter how much money you want to throw at the problem. Organizations get blindsided because hackers attack from a direction that is unexpected in many cases or the organization simply isn’t keeping track of the current threats. Again, I’m not heaping insult on the IRS, simply pointing out a problem that appears common to most of the breaches I read about. What is needed in this case is a frank admission of the facts and a whole lot less in the way of excuses that simply make the organization look weak or stupid anyway.

The IRS, like many organizations, later came back and increased the tally on the number of individuals affected by the breach. This is another common issue. Instead of investigating first and speaking later, many organizations provide numbers at the outset that really aren’t based on solid facts. When an organization has a breach, the public does need to know, but the organization should wait on details until it actually does know what happened.

The application that caused the breach is now dead. It’s a demonstration of a final principle that appears in many of my books. If you really want to keep something secret, then don’t tell anyone about it. Breaches happen when data is made public in some manner. Yes, it’s convenient to access tax information using a web application, but the web application will be breached at some point and then the confidential details will appear in public. Organizations need to weigh convenience against the need to keep data secure. In some cases, security has to win.

The more I read about security breaches, the more convinced I become that they’re unavoidable. The only way to prevent data breaches is to keep the data in a closed system (and even then, a disgruntled employee could still potentially make a copy). Being honest about data breaches, providing the public with solid facts, and ensuring remediation measures are effective are the only ways to control the effects of a data breach. Let me know your thoughts on this issue at John@JohnMuellerBooks.com.

 

Security = Scrutiny

There is a myth among administrators and developers that it’s possible to keep a machine free of viruses, adware, Trojans, and other forms of malware simply by disconnecting it from the Internet. I’m showing my age (yet again), but machines were being infected with all sorts of malware long before the Internet became any sort of connectivity solution for any system. At one time it was floppy disks that were the culprit, but all sorts of other avenues of attack present themselves. To dismiss things like evil USB drives that take over systems, even systems not connected to the Internet, is akin to closing your eyes and hoping an opponent doesn’t choose to hit you while you’re not looking. After all, it wouldn’t be fair. However, whoever said that life was fair or that anyone involved in security plays by the rules? If you want to keep your systems free of malware, then you need to be alert and scrutinize them continually.

Let’s look at this issue another way. If you refused to do anything about the burglar rummaging around on the first floor while you listened in your bedroom on the second floor, the police would think you’re pretty odd. More importantly, you’d have a really hard time getting any sort of sympathy or empathy from them. After all, if you just let a burglar take your things while you blithely refuse to acknowledge the burglar’s presence, whose fault is that? (Getting bonked on the back of the head while you are looking is another story.) That’s why you need to monitor your systems, even if they aren’t connected to the Internet. Someone wants to ruin your day and they’re not playing around. Hackers are dead serious about grabbing every bit of usable data on your system and using it to make your life truly terrible. Your misery makes them sublimely happy. Really, take my word for it.

The reason I’m discussing this issue is that I’m still seeing stories like, “Chinese hacker group among first to target networks isolated from Internet.” So, what about all those networks that were hacked before the Internet became a connectivity solution? Hackers have been taking networks down for a considerable time period and it doesn’t take an Internet connection to do it. The story is an interesting one because the technique used demonstrates that hackers don’t have to be particularly good at their profession to break into many networks. It’s also alarming because some of the networks targeted were contractors for the US military.

There is no tool, software, connection method, or secret incantation that can protect your system from determined hackers. I’ve said this in every writing about security. Yes, you can use a number of tools to make it more difficult to get through and to dissuade someone who truly isn’t all that determined. Unfortunately, no matter how high you make the walls of your server fortress, the hacker can always go just a bit further to climb them. Headlines such as “Advanced Attackers go Undetected for a Median of 229 Days; Only One-Third of Organizations Identify Breaches on Their Own” tell me that most organizations could do more to scrutinize their networks. Every writing I read about informed security is that you can’t trust anyone or anything when you’re responsible for security, yet organizations continue to ignore that burglar on the first floor.

There is the question of whether it’s possible to detect and handle every threat. The answer is that it isn’t. Truly gifted hackers will blindside you can cause terrifying damage to your systems every time. Monitoring can mitigate the damage and help you recover more quickly, but the fact is that it’s definitely possible to do better. Let me know your thoughts about security at John@JohnMuellerBooks.com.

 

Use of the title Attribute

I try to keep up with accessibility issues so that the content I provide is always as friendly as possible. With this in mind, I’ve used the title attribute for links and wherever else it might be needed for many years now. At one time, the title attribute was actually mandated to make pages accessible by organizations such as the World Wide Web Consortium (W3C). The attribute also makes an appearance in a number of my books, such as Accessibility for Everybody: Understanding the Section 508 Accessibility Requirements with full documentation as to the benefits of using it.

However, today I find myself having to take a new direction and actually tell people not to use the title attribute because it could potentially make pages less accessible. Part of the reason that the title attribute isn’t used anymore is that some people became confused about it and started using it for Search Engine Optimization (SEO) uses and that was never the point. A lack of browser support and all sorts of other issues added to the demise of the title attribute as a useful link feature. The point is that there is a reason for the title attribute, but no one was using it and people with special accessibility needs found ways around it. At one point, the screen readers I used actually did make use of the title attribute, but newer screen readers don’t. In fact, the new approach is to ensure that links contain enough text to ensure someone with a screen reader knows what they mean. It’s a situation where a specific programming technique didn’t get the job done so another technique is now in use—one that seems more natural and that people are actually using.

So, what cued me into the fact that the title attribute is no longer particularly useful? Well, I use WordPress to create blog posts and noted recently that they had removed the title attribute from the dialog box for creating links. For a while I was adding the title attribute in by hand because I really did feel I was making the page more accessible. However, after talking with a friend about the issue and experimenting with the latest screen readers myself, I find that the title attribute is one of those “also ran” features that simply doesn’t see use often enough to make it worthwhile using. The new strategy is to ensure you provide enough text as part of your link to ensure the link is clear all by itself (even if you need to hide part of that text from view). If you have a copy of one of my books that espouses the use of the title attribute, make sure you change your practice to match what the rest of the world is doing today. Let me know if you have any questions about the use of the title attribute at John@JohnMuellerBooks.com.

 

Java 7 Patches and Future

It’s always important to keep your software updated with the latest patches. This is especially true with Java because so many hackers target even the smallest weaknesses. According to a recent ComputerWorld article, Java 7 has reached the end of its public life for updates. You need to upgrade to Java 8 in order to continue receiving free updates from Oracle. The rapid pace of updates that vendors rely on now is made necessary by hackers who apparently create malware updates even faster. Even at the fast release pace that Oracle is using, the malware just keeps rolling out. In other words, as a developer you need to exercise proactive coding to keep security risks at bay, in addition to relying on Oracle and other vendors for help.

A number of people have asked me about updates to Java eLearning Kit for Dummies. As far as I know, the publisher currently doesn’t have plans for an update. Of course, that could change at some point. Until the next update, however, the examples I’ve tested with Java 8 work fine on a Windows system. I’ll be performing additional testing on both OS X and Linux. However, I don’t have quite the number of people testing the book code as I had when I wrote it. If anyone does encounter a problem with the code, I’d greatly appreciate hearing about it at John@JohnMuellerBooks.com. I can’t guarantee that I’ll be able to fix absolutely every issue, but I’ll try to find workarounds and publish them on the blog for you.

As always, please don’t send me your personal code—I only work with book-specific code. Using the downloadable source is always the best way to get the most you can from a book. I’ve also created the Using My Coding Books Effectively post to help you get the most from my books. It’s important to me that you get the most you can from my books.