One thing I get a little embarrassed about is my lack of knowledge about cars. I have a few friends who are mechanics, and anytime I experience car trouble, I typically give one of them a call immediately for advice. I’ve never had to fix issues with my own car, and I doubt that I could if I had to.
Recently I was out with one of those mechanic friends who had just returned from a business trip where he was learning how to code and interact with Volkswagens via a command-line interface. I was both surprised and intrigued by this. We spent the next half hour discussing the rapid pace at which cars are evolving, have more in common with a PC than they do with the classic automobiles you might see at a car show. In fact, you can even attend seminars at information security conferences that cover car hacking.
This trend, the convergence of the mechanical and the technological, is not unique to automobiles. In the era of the Internet of Things, so many of the devices manufacturers produce are designed to be connected to the internet. Surveillance cameras, baby monitors and even ovens can be configured for network connectivity. For example, over the holidays my mother asked me to stop over to help her configure her Christmas lights using an app she downloaded to her phone. This type of connection requires software to allow for interaction with the hardware. Unfortunately, all software contains bugs, and as is all too often the case, the developers of this software do not envision a scenario where cybercriminals would hack these devices remotely and use them maliciously.
When I relay these concerns to friends and family, the types of nightmare scenarios that come to mind are surveillance cameras or baby monitors being hacked to spy on unknowing victims. Although this fear is justified, there are also other concerns both manufacturers and their customers should be aware of as more devices rely and promote internet connectivity.
One recent security threat I’ve been tracking that is less talked about is a play in the bad guys’ playbook called a “botnet”. A google search for ‘botnet’ will provide the dictionary definition of “a network of private computers infected with malicious software and controlled as a group without the owners' knowledge, e.g., to send spam messages.”
Imagine the following scenario: You are attempting to introduce yourself to a realtor that you’d like to buy a house from. You go to shake her hand and state your name. Unfortunately, there are one million other people in the same room, and they are all trying to do the same thing. Overwhelmed with handshake requests, she is unable to communicate with anyone. Now imagine that the realtor in this example is a real estate website, and that all of the attempted handshakes were attempted connections to that website, made by compromised devices in the botnet. This is a metaphor for what a “distributed denial-of-service” attack looks like. These types of attacks are extremely dangerous and have shut down major commercial and government websites — impacting service to customers/constituents and revenue.
How do these devices become compromised? It’s often a by-product of software being implemented on connected devices, when security is not taken properly into account before the product is shipped. These products are often shipped from the manufacturer with default login credentials (Think username: Administrator, password: password123). Attackers target those defaults by writing malicious software which scours the internet, looking for connected devices. Once one is found, the malicious software begins using common usernames and passwords to log into the device. If a match is found, the malicious software can then installs code onto the connected device transforming it into another ‘zombie’ working in the attacker’s favor and becoming part of its botnet army.
That device is now effectively on standby until the attacker decides to ‘awaken’ all zombie bots within the botnet. Eventually, the bots will be used to send connection attempts to a targeted website, similar to the handshake example I provided earlier. This is exactly what happened to security researcher Brian Krebs, whose website was targeted last year in what was, at that time, the largest botnet attack in history. The attack was so large that Krebs’ ‘flood insurance’ provider (a nickname for firms that provide protection for websites against DDoS attacks) was forced to end their support for his website, unable to defend against continued attacks of such magnitude.
So, what can manufacturers do in order to stop products from being overtaken by a botnet? The primary key is those pesky default credentials. The best way to keep a device safe from being hacked by the bad guys, and added to the botnet zombie army, is to lock them out. Manufacturers should design systems so that they use unique default passwords. Passwords can be generated based on attributes unique to the device, such as a MAC address. Additionally, manufacturers can design systems so that a password change is required the first time a default password is used to log on to the device. It is important to ensure that there is a way for the purchaser of the device to log on and change the credentials. It is therefore imperative that the manufacturer include the steps on how to do so in the instruction manual.
Finally, I’d be remiss not to stress general security best practices and the important for manufacturers to educate employees about problems that can arise from opening attachments/infected computers on corporate networks. By implementing multiple layers of security within their networks, such as encrypting database fields or implementing an content services platform with advanced data security features, they eliminate internal data security fears.
Josh Gatka is a Security Evangelist at Hyland.
