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.

 

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.

 

Security Breaches and the Potential Effect on Big Data

There are two interacting forces in big data today that few people are talking about. Perhaps it just hasn’t occurred to anyone that there truly is a serious threat. This particular post is going to talk about big data used for healthcare, but the same issue applies to any use of big data. Organizations, such as Penn Medicine, are using big data to perform real world tasks that really make difference. For example, it’s now possible to predict the potential for diseases well in advance of any critical fallout now—at least for some diseases such as sepsis. The ability to predict an event before it becomes critical is important for all sorts of reasons, but the most important is improving overall health. Of course, it also affects the cost of healthcare and the need to use healthcare in the first place.

However, while writing both Python for Data Science for Dummies and Machine Learning for Dummies, I’ve discovered the fallout of data errors is more critical than anyone can imagine. Ensuring correct data entry is a large part of the solution, but there are other concerns. Yes, algorithms can learn to determine which data is useful and which data isn’t, but the purer the data at the outset, the better.

While writing Security for Web Developers I reviewed many sorts of security breach, some of which involve modifying organizational data. What this means is that an outsider could potentially corrupt the big data used to make assumptions about medical conditions. Do you see where I’m going with this? Having bad data, data that is modified by an outsider and therefore not as likely to gain the attention of someone who can fix it, will cause those algorithms to make some invalid assumptions. Humans help correct the assumptions, but humans aren’t perfect and make assumptions about the behavior of the algorithm. The bottom line is that security breaches of the wrong sort could end up costing lives. It’s something to think about anyway.

The potential for error in big data analysis is just one of a whole bunch of reasons that I’m happy to read that the government is finally looking into ways to bolster the devices used to work with medical data. I’m almost positive that medical practitioners will fight tooth and nail against the new security measures, just like users of every persuasion do, but the security measures really are more important than just protecting individual patient data. As data becomes the centerpiece of all sorts of human endeavors, ensuring it remains as pristine as possible becomes ever more important. Security has to take a bigger role in data management in the future. Let me know your thoughts on securing data that could be used for medical analysis at John@JohnMuellerBooks.com.

 

Old Laws, User Privacy, and Vendors Caught in the Middle

I’ve talked a number of times about researchers creating security busting software just because they can. The software often gets out into the wild where people who wouldn’t normally have a clue as to how to overcome security features can now use it to break the latest security in some product or application. Now the government is trying to force Apple (and probably other vendors) to write such software in pursuit of information hidden by encryption based on the mandates of a 227 year old law written at a time when no one had any idea that modern digital devices would even exist. The decree issued by the judge in charge of the case seems quite reasonable until you consider the fact that once Apple writes the software, it could end up in the wild, where hackers will almost certainly find ways to use it to overcome the security of legitimate users—making it impossible to ensure private information, such as credit card data, really does remain private.

The iPhone comes with some interesting security features that make it a relatively secure device. For example, tampering with certain device hardware will brick the device, which is the sort of security feature more devices should have. Modifying the security hardware should cause the device to lock down in order to protect the data it contains. The encryption that Apple offers with the iPhone is also first rate. No one but the user has the key used to unlock the encryption, which means that only the user can create a security problem by handing the key out to others.

The government is trying to change this scenario to make it easier to learn about anything it can about the data on Syed Rizwan Farook’s iPhone (one of the two San Bernardino shooters). On the surface, it seems like a good idea, if for no other reason than to potentially prevent other shootings. However, the manner in which the government has pursued the information opens the door to all sorts of abuse and then there is the matter of that software getting out into the wild. The issue here is that the law hasn’t kept up with technology, which is a recurrent problem. The government doesn’t have a law to cover the need to break encryption in a reasonable way, so it resorts to a 227 year old law that was never intended to address this need. The fact that the government is using the same law to try to force Apple to breach iPhone security in at least twelve other cases means that the argument that this is a one-off requirement doesn’t hold any water. Once Apple cooperates even once, it sets a precedent that will allow the government to force additional cooperation, even when such cooperation decidedly damages the privacy of innocent parties.

Tim Cook has rightly refused to cooperate with the government. There really is too much at stake in this case and even the government should be able to figure it out. What needs to happen is that our government needs to catch up with technology and write laws that everyone can live with to deal with the need to preserve the privacy engendered by encryption, yet make it possible for the government to obtain information needed to solve a case.

The question here is more complicated than simply managing information properly. It’s also one of keeping good technology (such as that found in Security for Web Developers) working properly and ensuring that government entities don’t abuse their positions. What is your take on the San Bernardino shooting and the information needed to pursue it? How do you feel about keeping your private data truly private? Let me know at John@JohnMuellerBooks.com.

 

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.

 

A Fuller Understanding of the Internet of Things

You can find the Internet of Things (IoT) discussed just about everywhere today because the Internet has become pervasive. IoT is part of most business applications today as discussed in Security for Web Developers and part of any PC you build as discussed in Build Your Own PC on a Budget. It appears as part of smart TVs and Blue-ray players. In fact, you find IoT employed in a lot of places you might not have thought possible even a year ago. The point is that IoT is here to stay and we need to consider some of the ramifications of it on every day life.

One of the issues that hasn’t surprised me too much is the issue of security. Both my smart TV and smart Blue-ray player require me to enter a password to access the Internet through my wireless router (mostly because the router is configured to require one). So these devices do employ security to some extent. However, they remain logged on at all times, so the router is also configured to disconnect devices after a certain time. Each time I turn the devices on, I must reenter the password. It’s a level of security, but not necessarily the best security. Some devices, such as Apple Watch, lack any form of security. (In the case of Apple Watch, the device authenticates through an iPhone, so it still has some level of security, but not security that is part of the device itself.) Some industry pundits are saying that these devices will eventually kill the password, which means that some other form of primary authentication is needed.

The problem is increased by the proliferation of headless devices (products that lack any sort of display, such as a door lock, security system, or robots). In these cases, you can’t enter a password. No one is really sure how to secure these devices, but a solution really is needed and soon. Unless we find a solution, the issues surrounding intentional hacking will increase. A recent InfoWorld article, Welcome to the smart home … of horror!, emphasizes some of the sorts of things that could happen due to a lack of security.

Security and configuration problems aren’t just limited to outsiders gaining access to your home, office, business, or other location due to holes in IoT security. It also turns out that smart devices aren’t particularly smart, so sometimes you lose access to your network and its connected devices due to a combination of security and configuration issues when a failure occurs. In the ComputerWorld article, The Internet of Things: Your worst nightmare, you can hear about one person’s attempt to recover from a simple router failure. It turns out that simply replacing the router wasn’t enough—everything connected to the router needed reconfiguration and sometimes the task was less than easy to perform.

The world is in a age of transformation. The ride will be bumpy and the problems severe. When you consider the immensity of the things that are changing, the future looks incredibly different from anything that has gone on in the past. Not only is there IoT to consider, but the whole issue of robots and other technologies that are coming to fore. As these new technologies become part of everyday life, we have to ensure we can use them safely and that ability of someone to hurt us through them is curtailed. Let me know your thoughts about IoT security and configuration at John@JohnMuellerBooks.com.

 

Wi-Fi Access Point Privacy Issues

One of the issues with using any wireless technology is that any expectation of privacy is akin to screaming at the top of your voice in a mall and expecting no one to hear you. You can’t hear radio signals with your ears, but wireless transmits them in all directions and all it takes is an antenna to receive them. The radio signal doesn’t discriminate between the intended recipient and someone lurking in the background. Few people seem to understand this concept because they can’t actually hear the radio signal or see just how far it transmits.

Unless the communication is properly secured, assuming that you can safely send sensitive data using wireless technology is also a delusion. In fact, the lack of physical security makes wireless connectivity a risky choice anyway. Anyone can create a man-in-the-middle attack to place themselves between you and the access point you think you’re using. In addition, just hearing your supposedly secret conversation can give the hacker access to the data. Network Computing recently ran an article, The 9 Worst WiFi Security Mistakes, that outlines some of the serious consequences of not using Wi-Fi and other wireless connectivity with security in mind.

Wi-Fi endangers both security and privacy in a big way (even though the former issue seems to receive the most coverage). A recent article, Wi-Fi access point scans can betray a person’s location, points out that using Wi-Fi really is quite risky from a privacy perspective. Location data can help hackers guess user activities in some cases. The risk isn’t hypothetical or in the laboratory—it’s a real risk that exists right now. The fact that people don’t seem to want to pay attention to it makes the situation worse because hackers and others of ill intent could employ the techniques discussed in the article for a variety of purposes (none of them good). Even though the article focuses on consumer tracking, it isn’t hard to imagine using it for business purposes as well.

Wireless access actually amplifies security issues that are a problem for consumers and businesses alike anyway. A recent article, Don’t count on websites to hide your account info, discusses web site security issues. When you combine a lack of web site security, with wireless privacy and security issues, it becomes nearly impossible to ensure that the connection will remain secure enough to perform any task of a sensitive nature. When the network and endpoint are both suspect, you need to devise a robust app development and usage strategy (as described in Security for Web Developers). That is, unless you really do want everyone to hear you screaming from the rooftop.

Many high-end routers provide you with advanced configuration features (something I discuss to some extent in Build Your Own PC on a Budget). For example, you can choose to use only WPA2 security. According to a number of sources, such as PCWorld, WPA2 is the best solution to wireless security right now. Of course, you still need to use good passwords and employ other router features such as port filtering, IP packet filtering, URL keyword filtering, and MAC address filtering. Make sure you set up a guest account with a real password and change that password after your guest is done using your router. Limit guest access to only those areas a guest actually needs.

Wireless connectivity is a fact of life today—you can’t really get around it because wireless connectivity offers too many benefits to ignore. However, it’s important to remember that wireless lacks the physical security of a wired network connection, which means that you need to be extremely careful when using it or face the consequences. Let me know your thoughts about wireless connectivity security and privacy concerns at John@JohnMuellerBooks.com.

 

Security for Web Developers Released!

My Security for Web Developers book is released and ready for your review! I’m really excited about this book because I was able to explore security in a number of new ways. In addition, I had more technical editor support than just about any other book I’ve written and benefited from the insights of a larger than usual number of beta readers as well. Of course, the success of this book depends on you, the reader, and what I really want to hear is from you. What do you think about this latest book? Do you have any questions about it? Please feel free to contact me about it at John@JohnMuellerBooks.com.

Of course, I’m sure you want to know more about the book before you buy it. Amazon has the usual write-up, which is helpful, but you can also find insights in the beta reader request for this book. Make sure you also check out the blog posts that are already available for this book in the Security for Web Developers category. These value added posts will help you better understand what the book has to offer. More importantly, you get a better idea of what my writing style is like and whether it matches your needs by reading these posts.

Make sure you also get the source code for this book from the O’Reilly site. I highly recommend using the downloadable source, rather than type the code by hand. Typing the code by hand often leads to errors that reduces your ability to learn really cool new techniques. If you encounter errors with the downloaded source, make sure you have the source code placed correctly on your system. When you get to the O’Reilly download page you also find links for viewing the Catalog Page for this book and reporting Errata.

Have fun with my latest book! I’m really looking forward to hearing your comments. Thank you, in advance, for your continued support.

 

Considering the Authentication of Credit Cards in Web Settings

While I was writing Security for Web Developers I considered a great many security scenarios that web developers (and those who work with them) have to face. It always seems as if the hackers are two steps ahead. Of course, one of the biggest problems is static technology. For example, the Credit Verification Value (CVV), a three or four digit addition to a credit card number, is supposed to help safeguard the credit card. It doesn’t appear as part of the card data accessible through the magnetic strip or the chip. The CVV is actually printed on the card as a separate verification for venues such as web applications. The only problem is that this number is static—it remains the same for however long you own the card. Therefore, once a hacker discovers the CVV, it no longer provides any sort of security to the card owner. Interestingly enough, some sites online will sell you both credit card numbers and their associated CVV. The hackers win again.

A solution to this problem is to change the CVV periodically. Unfortunately, trying to change a printed CVV is impossible without replacing the card. One possible way to overcome this problem involves the addition of an e-paper space on the back of the card that would allow the credit card companies to change the CVV, yet keep it out of the magnetic stripe or chip. A lot of devices currently use e-paper, such as Amazon’s Kindle. The technology provides a matte paper-like appearance that reflects light similar to the way in which paper reflects it, rather than emitting light like an LED does. The difference is that e-paper is often easier to read.

Oberthur, the inventor of the Motion Code technology used to create the updated CVV, isn’t saying too much about how the technology works. There must be an active connection between the card and a server somewhere in order to update the CVV once an hour as specified in the various articles on the topic. The only problem is in understanding how the update takes place. If the technology relies on something like a Wi-Fi or cell connection, it won’t work in rural areas where these connections aren’t available. Even so, the technology does promise to reduce the amount of fraud that currently occurs—at least, until hackers find a way to thwart it.

What is your feeling about credit card data protection? Does Motion Code technology actually provide a promising solution or is it another dead end? How do you deal with potential fraud when creating your applications? Send  your ideas to me at John@JohnMuellerBooks.com.

 

Web Apps and Outdated Software

A particular problem that developers face when creating web apps is that users are notoriously lax in updating their software. A problem piece of software may make it easy for a hacker to gain access to the system. In some cases, the user will blame your application because it depends on software that could be outdated on the user’s system. A recent InfoWorld article, 10 old, risky applications you should stop using, brings the issue to light. Many of these pieces of software see use in Web apps. You may think that the user will rely on the newest version of the software, but the user may, in fact, have a piece of software that’s several generations old, yet runs your web app just fine.

Most of my web development books at least hint at the issue of dealing with outdated libraries, APIs, and microservices. Security for Web Developers makes the strongest case for verifying that web apps rely on the latest third party products to ensure the web app is less likely to cause a security breach, but both HTML5 Programming with JavaScript for Dummies and CSS3 for Dummies discuss the issue as well. The point is that you need to know that a user is relying on the latest software if at all possible. Otherwise, you may find your web app blamed for a security breach actually caused by another piece of software, such as a web browser.

The fear that many users have is that your web app will stop working if they upgrade to newer software. This fear has a strong foundation in broken applications of all sorts in the past. The problem can become quite severe. Looking at the InfoWorld article, you find several interesting bits of information. For example, many existing applications rely on Microsoft XML Core Services 4.x, despite the fact that the software is no longer supported and represents a huge security hole that hackers are only too happy to exploit. If the user removes this software to keep their systems safe, they may also have to give up on one or more mission critical applications. Testing is the developer’s tool of choice in this case. Make sure you test your web apps with the lasted software and then publish the results online. Keep users informed of potential problems and your plan for fixing them so that they can continue making required updates to keep their systems safe.

It may not be entirely possibly to fix every security problem immediately. The fact is that software today is so interdependent on every other piece of software that even when your web app has fully supported underpinnings, the software you depend upon may not. The dependencies cascade in convoluted ways that make it entirely possible that a hacker will find a way to breach your application despite your best efforts. Consequently, you not only need to maintain a firm grasp on testing, but also of potential problems with the software used to reduce your development effort and make the application perform better. In short, you need to have a contingency plan in place for those times when a hacker finds a way to break your web app because a determined hacker will fine a way.

Outdated software is the bane of developers everywhere, yet users remain clueless as to how much damage they invite by not making required updates. One of the issues that I’m constantly striving to solve in my books is this whole concept of software dependency and how it affects application reliability, security, and speed. If you find that some of the materials I’ve put together are especially helpful (or possibly not helpful enough), please let me know about them at John@JohnMuellerBooks.com. I want to be sure that the security features of my books really do help you past the whole outdated software issue because users really won’t be much help at all.