Dangers of IoT Privilege Management Blind Spots Exposed in Verkada Security Camera Breach

Let’s start with a candid discussion on IoT and Internet Security. If you are an IoT vendor, you bear some fundamental responsibilities to protect your company, infrastructure, and the security and privacy of your clients—whether they are other businesses you are selling to or consumers. You would absolutely want to architect and deploy a solution that in no way—EVER—could a single credential or account be used to jeopardize the trust and well-being of your clients and solution. Moreover, your customers should have every expectation that should be the case. Right?

With that in mind you would want these basic security controls in place:

• Segregation of access to the IoT devices you service, this would include enforcing the separation of privilege concept. No one account should have access to everything—or much at all, for that matter.
• Two-factor authentication enabled for all clients
• Multi-factor authentication (MFA) enabled for all employees, vendors, and contractors
• Restricted access to all sensitive accounts from only approved zones
• Privileged credential management to rotate, manage, secure, and provide certification for all administrative accounts
• An established workflow to allow access to the most sensitive accounts, adhering to just-in-time access models. This means any administration or elevation of privileges by IT, other users, or even tasks, should occur for the finite period necessary to complete a task. This is just smart enforcement of least privilege to reduce attack surfaces and threat windows.

Many of the above practices can best be implemented using privileged access management (PAM) and other identity-centric security solutions.

How did the Verkada IoT Breach Happen & What are the Implications?

Unfortunately for a provider of IoT cameras and support services, Verkada, and their customers, none of the above security best practices were enabled. On March 9^th, Bloomberg reported a massive security breach into the Verkada network that exposed the live feeds of 150,000 security cameras used in jails, hospitals, and even companies like Tesla. The exposure revealed live feeds from some incredibly sensitive environments including women’s health clinics, psychiatric facilities, and even police departments.

As a former senior-level employee told Bloomberg: “We literally had 20-year-old interns that had access to over 100,000 cameras and could view all of their feeds globally.” The hackers were apparently stunned at just how easy it was to access such a vast trove of sensitive data for all of Verkada’s customer, remarking that it was “incredibly surreal”.

The mingling of Verkada customer data to a single, allegedly secure, location was purportedly for facial recognition services used to identity people captured on monitored footage. The threat actors claim they had full access to archives of full video for all Verkada customers, making the security and data privacy issues even more complex.

This leads us to consider some questions with profound data privacy implications:

• Did organizations know that the live feeds could have been a beta version for facial recognition services?
• Did organizations that enabled the beta facial recognition technology disclose to patrons or workers that facial recognition software was in use?
• Did businesses and employees know or consent to data retention of their likeness being captured for archival purposes?
• How does Verkada filter out, secure, or process, any intellectual property in the videos (if using object tracking)?

Could the Verkada IoT Breach have been Prevented or Mitigated? Yes.

This was not a sophisticated attack and, as speculated early on, the proper security controls were not in place.

In response to the breach, Verkada put out a statement saying, “We have disabled all internal administrator accounts to prevent any unauthorized access. Our internal security team and external security firm are investigating the scale and scope of this issue, and we have notified law enforcement.”

The threat actors obtained “root” access to the Verkada cameras using built-in functionality that escalated their privileges to “Super Admin”. This superuser/root account permitted access to all of Verkada’s camera feeds, potentially jeopardizing security and privacy at every customer environment.

The web is littered with millions, even billions, of compromised credentials that attackers can easily feed into automated tools to make their jobs a cakewalk. That’s why uniqueness for every credential, and rotation for privileged credentials (including after each user for the most powerful credentials) is one of the most longstanding and basic of all cybersecurity best practices.

With the above in mind—the initial Verkada account compromise occurred due to exposure of a username and password for an administrative account on the Internet (single factor authentication)! From what is known about the breach and what the hacker group has claimed, no malware or advanced persistent threats (APTs) were involved in this breach. The compromised administrative account was also accessible from the Internet, with no monitoring or active response raised due to an inappropriate location attempting access.

Based on these facts, the privileged attack vector allowed the threat actors to infiltrate the environment, exfiltrate highly sensitive video feeds, and exposed critical flaws, giving bad actors the ability to:

• View unrestricted, live camera feeds from hundreds of thousands of cameras including some from very sensitive environments, violating proper segregation of client data and separation of roles and responsibilities for administrators.
• Login to critical systems via a single factor username and password for a company administrator, violating security best practices and potential regional regulatory compliance laws for secure privileged access to personally identifiable information (PII).
• Circumvent credentials for individual client IoT camera feeds by using flaws built-in as features to existing camera infrastructure allowing privileged escalation. This means Verkada essentially undermined some of the security their customers could have implemented.

This breach is already triggering security and privacy concerns for government, corporate, and civilian agencies that, no doubt, will lead to a wide variety of lawsuits. The breach may also reignite legislation around IoT security and facial recognition technology.

While this is another breach added to the list of eye-opening security incidents in 2021, all companies should take notice—especially those providing IoT services via the web. If you provide IoT products and services, you should perform proper segmentation, but most importantly, implement secure administrative accounts using a privileged access management solution. A PAM solution can manage your privileged credentials according to best practices, remove unnecessary admin rights and granularly enforce least privilege, enable just-in-time access models, support separation of privileges, and much more. At absolute minimum, you should never allow single factor authentication for any privileged account.

Customers searching for IoT solutions should always ask if their cloud vendors are SOC and ISO certified. While not perfect, it does give a level of confidence that many of the cybersecurity malpractices responsible for the initial Verkada breach as well as the broad fallout, are not a concern.

Related Reading:

Privilege Password Management Explained (white paper)

Privilege Escalation Attack and Defense Explained (blog)

Universal Privilege Management (solutions)