Abusing the Internet of Things (2015)

Chapter 9. Two Scenarios: Intentions and Outcomes

We now have a solid foundation for understanding the security issues pertaining to devices in the market today, as well as the impact that security vulnerabilities may have on IoT device manufacturers and the lives of people using the devices. We have also studied the process of coming up with an idea for an IoT product and building in the right security controls eary on, starting from the prototyping stage. At this point, we have a good sense of how to measure risk by marrying gaps in security controls with our understanding of how agents are likely to take advantage of them.

In addition to understanding security controls, it is important to realize that security incidents, when viewed holistically, are greatly influenced by the individuals who are involved and how those individuals choose to react to the situations at hand.

In this chapter, we will take a look at two different scenarios to gain an appreciation of how people can influence security incidents. In the first scenario, we will examine how an executive at a large corporation attempts to leverage the “buzz” surrounding the topic of IoT with the hope that it will impress the board of directors. In the second scenario, we will look at how an up and coming IoT service provider chooses to engage and respond to researchers and journalists with the intention of preserving the integrity of their business. The goal of this chapter is to illustrate that, ultimately, the consequences of security related scenarios are heavily influenced by the intentions and actions of the people involved.

The Cost of a Free Beverage

The cybersecurity field is riddled with vendors who want to sell software tools that are often ineffective in reducing tangible risk, thereby giving organizations a false sense of security. More specifically, tools that attempt to assess and secure emerging technologies and new attack vectors often take time to improve on accuracy by consistently incorporating feedback and new research.

On the other hand, the marketability and the importance of the Chief Information Security Officer (CISO) role at corporations around the world is at an all-time high. Companies are worried about a spectrum of threat agents who may be able to exploit vulnerabilities to cause them financial harm and severe degradation of their brand. Executives who are able to fill the role of the CISO to guard large and complex infrastructure are in high demand, with salaries exceeding $1 million.

The situation of high demand and low availability of seasoned executives is leaving corporations at risk of investing money and effort on security tools that may not be effective. In this hypothetical scenario, we will take a look at how the emergence of IoT, along with the lack of understanding of a comprehensive corporate security strategy, can leave an organization at risk.

There’s a Party at Ruby Skye

The RSA conference is held in San Francisco every year and it is the biggest cybersecurity conference in the world. Besides the keynote lectures and speaking sessions, the conference is a great opportunity to network and socialize with professionals who come to San Francisco for the conference.

John Smith, newly appointed Vice President and CISO at Acme Inc., had been particularly looking forward to the conference. He had just started working at Acme Inc., where the board of directors had already approved hiring 30 new full-time employees to work under him. John was excited about his new role and wanted to share his excitement with his friends attending RSA.

Sam Cronin, Executive Director and head of sales at Plunk, was also excited about RSA. He had managed to successfully put a business case through to lease the entire dance floor at Ruby Skye, a popular night club in San Francisco. During the RSA conference, vendors are known to rent out popular restaurants and bars to host free parties for conference attendees with the hope that some of the people attending will be impressed enough by these parties to convert to clients.

Plunk is a popular tool used to capture and correlate large amounts of log data that can be analyzed to alert on anomalies to help identify suspicious events that may be related to an attack. Smith RSVP’d to the Plunk party invitation. He was familiar with the product and knew Ruby Skye would be a good time.

Smith showed up to Ruby Skye and flashed his RSA attendee badge at the entrance counter. The Plunk representative immediately noticed the Vice President title on the badge and whisked him to the VIP section, which included top-shelf beverages as well as access to a larger private area reserved for potential clients in executive roles.

Cronin introduced himself to Smith as the head of sales, and they struck up a conversation on the security of IoT devices. Smith also talked about his new job and how he was excited to have the chance to present to the board at Acme Inc. to ask for a higher operating budget to run his team, hire additional personnel, and buy more security products. Upon hearing this, Cronin offered free consulting advice to help Smith prepare for the board meeting. Smith, in return, remarked that he would buy licenses for the Plunk security tool if the board ended up accepting his proposal. They shook hands and decided to catch up in a few days to further the discussion.

Leveraging the “Buzz Word”

A week after the RSA conference, Smith and Cronin connected by phone. Smith’s intention was to “wow” the board and have them approve his plan to hire 55 additional full-time employees and to fund an operating budget of $100 million in capital and operating expenses for the next three years.

Cronin had recently been tasked with selling the Plunk tool with an additional feature that collects log data from IoT products in the enterprise so companies can track their inventory of devices that have been deployed. This is useful for security since devices such as laptops, mobile phones, and IoT products present a huge security risk if they are unaccounted for. This is because it is impossible to measure or reduce security risk posed by devices if the organization has no control over them.

Smith inquired if Cronin had any particular ideas on what topics the board may be interested in. Cronin suggested that the board presentation to be focused on the latest “buzz” in the industry about the upcoming age of IoT devices and the security risks they are bound to introduce. In the previous year, the hot topic at the RSA conference included the use of machine learning and big data to correlate security log data to detect attacks. This year, the latest topic of discussion at the conference was the security implications of IoT products. Smith agreed to focus in on the topic of IoT. He felt the board members would find the topic interesting and it would make his knowledge appear cutting edge and impress the executives.

The Board Meeting

Smith’s presentation was at 10:40am and he had exactly 10 minutes to present his case. He had prepared a slide deck for the meeting but he was told that the board of directors at Acme Inc. did not have time for a PowerPoint presentation. He had to make his case quickly and crisply.

Smith: Thank you for taking the time to have me present to you on the topic of security. As a newly appointed Chief Information Security Officer, I am committed to…

Board Director #1: I have to interrupt. What exactly is the agenda of the discussion you are proposing?

Smith: I’m here to talk about the most important security risks that we need to be prepared to combat.

Board Director #1: Okay, let’s jump right in and skip the introduction. We know you are the CISO. We appointed you. We know what your job description is. Go ahead.

Smith: Okay. I’m sure the board is aware of IoT devices in the marketplace and the majority of these devices are being found to have security risks. We ought to carefully think of partnering with a leading security tool company called Plunk so that we can…

Board Director #2: Hold on a second. We are a health insurance company. Exactly what type of IoT devices do we have in our offices that are in scope? Are you suggesting the risk of IoT devices to our business today is more important than spending our money in shoring up our compliance with health regulations? Or are you talking about risk from IoT devices that you personally predict may impose risk on us in the future?

Smith: My discussion is really about the future. I’m not sure what IoT devices we may need to be worried about today but I was at the RSA conference and all the keynote speakers mentioned the security implications of IoT and I wanted…

Board Director #2: Come back to us when you are able to map the strategy of our business to technology and can talk to us about tangible issues that are based on factual understanding of our technology landscape. That will be all Mr. Smith. Let’s have the next presenter come up.

Smith was escorted out of the conference room. He had predicted the board of directors would be welcoming of his knowledge on cutting edge security topics, yet his presentation lasted about 1 minute an 15 seconds. He was stunned.

Human resources called Smith the next day and asked for his resignation effective immediately. He would be given the 6-month severance pay specified in his employment contract.

Looking back at this scenario, there are multiple things that went wrong. Sam Cronin’s role as the sales executive at a security-tool company made him a biased candidate. Ultimately, Cronin was focused on selling licenses to his updated product, which as not in alignment with what was best for the board of directors at Acme Inc.

Smith should have consulted his peers and other unbiased individuals he had called upon for mentorship in the past. It is clear that Smith did not have experience with presenting to the board. Boards of directors want to know the problem statement at hand and how it connects to the business of what the company does. Instead of focusing on just IoT, Smith should have presented a prioritized list of security issues that could interrupt the business of Acme Inc. in terms of unauthorized access or the loss of confidentiality of their intellectual property. This list could potentially include IoT along with a proposed roadmap of greater adoption of IoT devices. Because Smith focused on IoT only, it was immediately apparent to the board that he had not thought through the entire risk landscape.

The importance of IoT and how it is bound to enable our future lives at home and work is clear. We are going to have frequent conversations about the security of these devices as they enter our world. As is often the case with new forms of technology, individuals and media personnel want to leverage the buzz in the industry to attract attention. In many cases, this is well and good as it informs the public and promotes fruitful conversation. However, in this case, Smith not only wasted the time of the board of directors, but his inability to present a well thought out and holistic security strategy left Acme Inc. with no clear path to shoring up their security controls until they are able to find and hire another CISO to replace him.

A Case of Anger, Denial, and Self Destruction

Consumers are starting to rely upon IoT devices in their homes and offices that are manufactured by a variety of companies such as Philips, Belkin, and Samsung. Organizations like Apple, Microsoft, the SmartThings suite of products, and IFTTT are vying to create unified platforms that allow different devices to work together and provide a seamless user experiences.

IoT products in the marketplace today contain substantial security design flaws, as showcased in the other chapters in this book. These products are already being used by consumers at home. This situation creates the possibility of a a single point of failure leading to the compromise of families’ IoT ecosystems. Traditionally, software vendors have been able to issue critical patches to quickly remediate high-risk vulnerabilities. The negative implications to end users have typically been limited to the nuisance of having to reboot their computers to get rid of nagging software update popups.

Platforms that bring together IoT devices manufactured by different vendors speaking different protocols have a profound responsibility to enable patching of security issues as well as protecting their own infrastructure from being compromised or abused by internal employees. Unlike operating systems and apps, it may not be possible or even feasible for IoT platform providers to quickly implement a security fix to a known vulnerability without disrupting services that the users rely on for their daily activities. In this hypothetical scenario, we will go through exactly such a situation so that we’re aware of the possibilities of disruption that may result from lapses in security.

The Benefit of LifeThings

One great benefit of working at LifeThings was the great work culture. Even though the startup grew from 20 employees to 1,000 in a span of 9 months, the CEO upheld the promise of maintaining a flat organization where an employee’s value was measured based on their contributions and not their title.

LifeThings’ business strategy was to unify the IoT devices in homes so that consumers didn’t have to worry about downloading a separate app for each device they bought. Their product was a hub that would plug into the user’s home WiFi network and detect IoT devices on the network. From wireless doorlocks to cars to lighting to baby monitors, LifeThings struck up partnership with big players like SmartThings, Philips, Foscam, and many other device manufacturers to integrate into the LifeThings hub.

Piggybacking on real-estate in San Francisco and Seattle, LifeThings leveraged construction of new high rise condominiums by offering consumers their product for free for life. They struck deals with builders to install their hub in new condos so customers could use them as soon as they moved in. The presence of the LifeThings hub caused condominium owners to buy and install wireless lighting, connected door locks, and video monitors to take advantage of the free service offered by LifeThings. People loved the seamless interoperability offered by LifeThings. They could create recipes to control their lighting, share electronic keys with friends to allow them to enter their homes, and so much more. Based on word of mouth and positive reviews, LifeThings quickly become a household name and their business skyrocketed.

Simin Powell operated the customer support team for LifeThings. According to a recent survey, satisfaction with LifeThings’ customer support was at 99.8%, rivaling most other technology companies. She publically went on record promising that every customer-support issue would be solved within 5 minutes of the customer initiating the support call. For the most part, Simin was able to deliver on her promise. Parents would call LifeThings customer support to let their children into their homes upon returning from school, or to check the status of their main door if they couldn’t recall locking it. A lot of these requests could be handled by the LifeThings app, but the company always complied with phone requests because they wanted to provide a concierge service to best serve their customers when they had issues.

Social Engineering Customer Support by Spoofing SMS

A couple of security researchers who were LifeThings users noticed that customer support would automatically greet them by name. While most customers felt this was a delightful service experience, the researchers quickly realized that LifeThings trusted the incoming phone number by correlating the caller ID with customer records to identify the user. They tried calling customer support to report the issue but the service agents were not able to comprehend and insisted that their services were “secure from hackers”. Without any avenue to successfully report the issue, the researchers released their findings by blogging about it and demonstrating how easy it is to spoof caller ID information using a commercial service such as SpoofCard (Figure 9-1).

Figure 9-1. SpoofCard allows anyone to easily fake the incoming Caller ID

The security researchers even released audio files of them calling LifeThings customer service with someone else’s Caller ID using SpoofCard and instructing customer service to help them unlock the main door. Simin Powell released this response to the media:

The security and privacy of our customers is of utmost importance to us. We feel the individuals who have released information on how to social-engineer our customer service team demonstrated unprofessionalism by exposing this information and that hacking services such as SpoofCard enable malicious activities such as these and should be banned. That said, we are continuously researching ways to serve our customers using the most efficient and secure methods.

The problem with Powell’s response is that it is solely based on an emotional response towards the researchers and offers no tangible solution to address the risk posed to the customers. This is common in situations where companies do not fully appreciate the risk to their business and their customers. It is also common in cases where organizations are under pressure to provide experiences to customers but they haven’t had the time to think through the security controls. Moreover, the fact that the researchers attempted to report the issue was not acknowledged in Powell’s statement.

The (In)Secure Token

Since the service agents at LifeThings had to do their best to solve customers’ problems within 5 minutes, they spent the first 2 minutes evaluating whether it was a non-technical issue or a frequently asked question they could answer. If not, the agents could remotely log into the LifeThings hub at the customer’s location to service the request. To do this, they’d type in the following command on to their computer terminals:

$ create-secure-token customer@email.com

Secure-token: a7144596f20fe4daf3a3c75f7011c4c5

Assuming the customer’s email address is customer@email.com, the Secure-token value was used to access the customer’s hub. The service agent would have to ssh into a server located at secure.lifethings.com using the Secure-token as a password:

$ ssh -l customer@email.com secure.lifethings.com

Password: a7144596f20fe4daf3a3c75f7011c4c5

The agent would then query the hub for attached devices using the hub command:

$ hub -l

1. [Thermostat] [Status: 69F]

2. [Lock: Main door] [Status: Locked]

3. [Lock: Garage door] [Status: Locked]

4. [Light switch: Living room lamp] [Status: Off]

5. [Baby monitor: Bedroom 2] [Status: Inactive]

Here is an example of how the temperature of the customer’s thermostat could be changed:

$ hub "Thermostat" -s "80"

[Thermostat] [Status: 80F]

And here is how the customer’s main door could be unlocked:

$ hub "Lock: Main door" -s "Unlocked"

[Lock: Main door] [Status: Unlocked]

It was also possible to listen in on 2 minutes of the audio captured by the baby monitor by accessing audio1.mp3 after running the following command:

$ hub "Baby monitor: Bedroom 2" -s "2m" -o audio1.mp3

[Baby monitor: Bedroom 2] [Status: Capturing audio to audio1.mp3 for 120s.

Press ^C to abort]

The hub tool located on secure.lifethings.com allowed the service agents to easily check and change the status of devices connected to the LifeThings hub. This made it easy for them to quickly assist customers who were having trouble with certain devices, and even cases where the customers were locked out of their homes.

Total Ownage

Exactly a year after exposing the SMS security issue, the researchers were scheduled to present at a security conference. They wondered if they could analyze the system further. After unscrewing the top cover of their LifeThings hub, they located a Micro SD card and found the file /etc/config with the following contents:

SSH_REMOTE=secure.lifethings.com

USER=researchers@email.com

MD5=93a4c0c0da435f4434f828c95cf70d6a

They were able to quickly find out that secure.lifethings.com was running an ssh service they could log into. They assumed the username was researchers@email.com since it was assigned to the string USER in the /etc/config file and it was their own email address that they had used to sign up for their LifeThings account. but it did not occur to them that the MD5 hash value was actually the password. After tinkering around for the evening, they decided to call it a night and investigate the next day.

The following morning, they pulled out the SD card again and looked at the /etc/config file again:

SSH_REMOTE=secure.lifethings.com

USER=researchers@email.com

MD5=a0536156e0267d5ed71a59cca90f2692

The value of MD5 had changed. They put the SD card back into the hub for a few hours and removed it again the same day to find that the value of MD5 this time was still a0536156e0267d5ed71a59cca90f2692. This meant that the value was changing daily and is likely to be associated with the date. The date was June 10, 2015 so they tried various combinations of strings:

$ md5 -s "June 10, 2015"

MD5 ("June 10, 2015") = 21c0f5e21aea63e9c1e3055a3eda6cb9

$ md5 -s "06102015"

MD5 ("06102015") = 14e2234a4c2d9ba4490b548972d6b794

$ md5 -s "06-10-2015"

MD5 ("06-10-2015") = 579949533abab20c4b07f5ed7d56b70d

None of the hash values matched up. Then it dawned upon them that the value may be a concatenation of the USER value and the date. After a few attempts, they cracked it!:

$ md5 -s 'researchers@email.com06102015'

MD5 ("researchers@email.com06102015") = a0536156e0267d5ed71a59cca90f2692

This made complete sense because they got the previous MD5 value when they put in the previous day’s date:

$ md5 -s 'researchers@email.com06092015'

MD5 ("researchers@email.com06092015") = 93a4c0c0da435f4434f828c95cf70d6a

Bingo! The researchers then realized the most elementary issue here they had missed previously, the MD5 value was the password to log into the ssh server:

$ ssh -l researchers@email.com secure.lifethings.com

Password: a0536156e0267d5ed71a59cca90f2692

After logging in and finding the hub command, they figured out they had access to their own hub. But they also knew of a friend who had the LifeThings hub. Based on today’s date, they calculated their friend’s password:

$ md5 -s 'friend@email.com06102015'

MD5 ("friend@email.com06102015") = b6ebb2b704bc66c2d50b5d5ed2425e5c

They were then able to log in as their friend and control his devices remotely just like customer service agents could. Having tried to report the SMS issue previously and being blamed by LifeThings for being “unprofessional”, the researchers exposed the issue at a security conference a year later, showing how attackers could remotely gain access to all devices connected to LifeThings as long as they knew the target’s email address.

The Demise of LifeThings

A week after the researchers presented their findings, investigative journalist Stan Goodin wrote an article correlating the researchers’ findings to multiple cases where the insecure design of the LifeThings infrastructure had recently been exploited:

1. Statistics collected from police department reports showed an unusually high number of burglaries in the high-rise condominiums powered by LifeThings.

2. Private audio recordings of high-profile political candidates discussing secret campaign details with their spouses at home had been leaked on the Internet. All four of the candidates targeted in this leak were known to live in houses served by LifeThings.

Stan Goodin’s article was picked up and syndicated across various media groups around the world. Simin Powell issued this response on behalf of LifeThings:

The leadership at LifeThings take the privacy and security of our customers very seriously. The recent article by Mr. Goodin is unfounded since it is based on unreliable statistics and hearsay. Customers should contact LifeThings customer support directly to report any suspicious activity.

Yet again, the statement released by LifeThings didn’t address any efforts made by the company to actually investigate the matter. By this time, there was still no advertised method to contact LifeThings to report a security issue.

A few weeks after Goodin’s article, the researchers who exposed the secure token issue wrote a blog post stating that they had evidence to prove that the United States and the Chinese government of logging into the secure.lifethings.com server. They stopped short of providing any tangible evidence or any additional information about what exactly they had found the two governments to be using the server for.

Two days later, a hacktivist group with the twitter handle @against_world_gov tweeted: “Don’t mess with us, LifeThings. We know you are working with the NSA to violate our people’s privacy. This Denial of Service is on us”. Simultaneously, the hacktivist group launched a Denial of Service attack on secure.lifethings.com, which prevented all LifeThings devices from being controllable from the hub. The same day, LifeThings issued the following statement:

We are investigating an ongoing Denial of Service attack against our networks that has caused the LifeThings hub to become unresponsive. We are committed to finding the perpetrators and returning our service to normal.

However, no matter how hard LifeThings worked with their Internet Service Providers to curtail the attack, the hacktivist group continued to use different armies of botnets to lunach attacks from various locations. Two days after the previous statement, LifeThings issued the following notice:

LifeThings is committed to returning our services to normal. Customers have been emailed step by step instructions on how to exchange their LifeThings hub with a new hub (LifeThings2) that is not susceptible to the ongoing issues we are facing. We thank you for your patience.

This notice from LifeThings illustrates that the company had no mechanism to modify their server architecture or update the firmware in the installed hubs to get around the ongoing attack. The only solution was to physically swap the old hub for a new one. At the time, it wasn’t clear what extra precautions or security architecture were present in the new hub.

Not many customers took the time and effort to physically mail back the hub. Many high-profile citizens simply unplugged the hub and terminated their LifeThings service. The secure.lifethings.com server was eventually taken offline and the venture-capital firm backing LifeThings refused to provide it with additional funding, causing the company to file for bankruptcy.

Looking back, it is clear that the engineers who designed the architecture to include the secure.lifethings.com server did not comprehend security best practices. The organization did not have an avenue for security researchers to report issues. Even after researchers exposed the SMS security issue, LifeThings called the researchers unprofessional and did not institute a mechanism for additional security issues to be reported. They even dismissed Stan Goodin’s analysis, demonstrating that they had no understanding of it or regard for their customers’ privacy or security. Their architecture was not designed in a way that could withstand denial of service attack without issuing every customer a new physical hub, the cost of which was borne by LifeThings and required customers to mail back the hub and install the new one.

There are multiple lessons learnt here:

1. IoT device manufacturers and platform service providers have a tremendous responsibility to make sure their devices can be patched remotely to withstand and heal from basic attack vectors.

2. Words such as “secure” in design or server names do not indicate that the engineers have experience in secure design. It is important for the proposed architecture to be inspected and assessed by an independent, qualified third party.

3. A clearly defined communication process should be defined for researchers who want to report security issues.

4. Security issues exposed by researchers should be paid attention to and investigated.

5. A single security issue—or in this case, a series of reported issues—when not taken seriously, can seriously hurt the provider’s business and, ultimately, the protection promised to the customers.

Every IoT device or platform provider may at some point face a situation where their architecture is proven insecure in one way or the other. This scenario is a clear illustration of how the continued lack of due diligence can (and often will) lead to the demise of customer confidence and the provider’s business.