Security researchers share their biggest initial screwups in some of their key vulnerability discoveries.

BLACK HAT EUROPE 2022 – London – Researcher Douglas McKee was having no luck extracting the passwords in a medical patient-monitor device he was probing for vulnerabilities. The GPU password-cracking tool he had run to lift the layers of credentials needed to dissect the device came up empty. It wasn't until a few months later when he sat down to read the medical device's documentation that he discovered that the passwords had been right there in print the whole time.

"I finally got around reading the documentation, which clearly had all the passwords in plaintext right in the documents," McKee, director of vulnerability research at Trellix, recounted in a presentation here today. It turned out the passwords were hardcoded into the system as well, so his failed password-cracking process was massive overkill. He and his team later discovered bugs in the device that allowed them to falsify patient information on the monitor device.

Failing to pore over documentation is a common misstep by security researchers eager to dig into the hardware devices and software they are studying and reverse-engineering, according to McKee. He and his colleague Philippe Laulheret, senior security researcher at Trellix, in their "Fail Harder: Finding Critical 0-Days in Spite of Ourselves" presentation here, shared some of their war stories over mistakes or miscalculations they made in their hacking projects: mishaps that they say serve as useful lessons for researchers.

"At all conferences we go to \[they\] show the shiny results" and successes in security research like zero-days, Laulheret said. You don't always get to hear about the strings of failures and setbacks along the way when sniffing out vulns, the researchers said. In their case, that's been everything from hardware hacks that burned circuit boards to a crisp, to long-winded shellcode that failed to run.

In the latter case, McKee and his team had discovered a vulnerability in the Belkin Wemo Insight SmartPlug, a Wi-Fi-enabled consumer device for remotely powering on and off devices connected to it. "My shellcode was not getting through to the stack. If I had read the XML library, it was clear that XML filters out characters and there's a limited character set allowed through the XML filter. This was another example of lost time if I had read through the code I was actually working with," he says. "When we deconstructed it, we found a buffer overflow that allowed you to remotely control the device."

**Don't ASSume: Schooled by Distance-Learning App 'Security'**

In another project, the researchers studied a distance-learning software tool by Netop called Vision Pro that, among other things, includes the ability for teachers to remote into students' machines and exchange files with their students. The Remote Desktop Protocol-based feature seemed straightforward enough: "It allows teachers to log in using Microsoft credentials to get full access to a student's machine," McKee explained.

The researchers had assumed that the credentials were encrypted on the wire, which would have been the logical security best practice. But while monitoring their network captures from Wireshark, they were shocked to discover credentials traveling across the network unencrypted. "A lot of times assumptions can be the death of the way you do a research project," McKee said.

Meantime, they recommend having in hand multiple versions of a product you're researching in case one gets damaged. McKee admitted getting a bit overzealous in deconstructing the battery and internals of the B Bruan Infusomat infusion pump. He and his team took apart the battery after spotting a MAC address on a sticker affixed to it. They found a circuit board and flash chip inside, and they ended up physically damaging the chip while trying to get to the software on it.

"Try to do the least invasive process first," McKee said, and don't jump into breaking open the hardware from the start. "Breaking things is part of the hardware hacking process," he said.

Hacker Fails for the Win

A ransomware attack on the company's Hosted Exchange environment disrupted email for thousands of mostly small and midsize businesses.

A Dec. 2 ransomware attack at Rackspace Technology — which the managed cloud hosting company took several days to confirm — is quickly becoming a case study on the havoc that can result from a single well-placed attack on a cloud service provider.

The attack has disrupted email services for thousands of mostly small and midsize organizations. The forced migration to a competitor's platform left some Rackspace customers frustrated and desperate for support from the company. It has also already prompted at least one class-action lawsuit and pushed the publicly traded Rackspace's share price down nearly 21% over the past five days.

**Delayed Disclosure?**

"While it's possible the root cause was a missed patch or misconfiguration, there's not enough information publicly available to say what technique the attackers used to breach the Rackspace environment," says Mike Parkin, senior technical engineer at Vulcan Cyber. "The larger issue is that the breach affected multiple Rackspace customers here, which points out one of the potential challenges with relying on cloud infrastructure." The attack shows how if threat actors can compromise or cripple large service providers, they can affect multiple tenants at once.

Rackspace first disclosed something was amiss at 2:20 a.m. EST on Dec. 2 with an announcement it was looking into "an issue" affecting the company's Hosted Exchange environment. Over the next several hours, the company kept providing updates about customers reporting email connectivity and login issues, but it wasn't until nearly a full day later that Rackspace even identified the issue as a "security incident."

By that time, Rackspace had already shut down its Hosted Exchange environment citing "significant failure" and said it did not have an estimate for when the company would be able to restore the service. Rackspace warned customers that restoration efforts could take several days and advised those looking for immediate access to email services to use Microsoft 365 instead. "At no cost to you, we will be providing access to Microsoft Exchange Plan 1 licenses on Microsoft 365 until further notice," Rackspace said in a Dec. 3 update.

The company noted that Rackspace's support team would be available to assist administrators configure and set up accounts for their organizations in Microsoft 365. In subsequent updates, Rackspace said it had helped — and was helping — thousands of its customers move to Microsoft 365.

**A Big Challenge**

On Dec. 6, more than four days after its first alert, Rackspace identified the issue that had knocked its Hosted Exchange environment offline as a ransomware attack. The company described the incident as isolated to its Exchange service and said it was still trying to determine what data the attack might have affected. "At this time, we are unable to provide a timeline for restoration of the Hosted Exchange environment," Rackspace said. "We are working to provide customers with archives of inboxes where available, to eventually import over to Microsoft 365."

The company acknowledged that moving to Microsoft 365 is not going to be particularly easy for some of its customers and said it has mustered all the support it can get to help organizations. "We recognize that setting up and configuring Microsoft 365 can be challenging and we have added all available resources to help support customers," it said. Rackspace suggested that as a temporary solution, customers could enable a forwarding option, so mail destined to their Hosted Exchange account goes to an external email address instead.

Rackspace has not disclosed how many organizations the attack has affected, whether it received any ransom demand or paid a ransom, or whether it has been able to identify the attacker. The company did not respond immediately to a Dark Reading request seeking information on these issues. In a Dec. 6. SEC filing, Rackspace warned the incident could cause a loss in revenue for the company's nearly $30 million Hosted Exchange business. "In addition, the Company may have incremental costs associated with its response to the incident."

**Customers Are Furious and Frustrated**

Messages on Twitter suggest that many customers are furious at Rackspace over the incident and the company's handling of it so far. Many appear frustrated at what they perceive as Rackspace's lack of transparency and the challenges they are encountering in trying to get their email back online.

One Twitter user and apparent Rackspace customer wanted to know about their organization's data. "Guys, when are you going to give us access to our data," the user posted. "Telling us to go to M365 with a new blank slate is not acceptable. Help your partners. Give us our data back."

Another Twitter user suggested that the Rackspace attackers had also compromised customer data in the incident based on the number of Rackspace-specific phishing emails they had been receiving the last few days. "I assume all of your customer data has also been breached and is now for sale on the dark web. Your customers aren't stupid," the user said.

Several others expressed frustration over their inability to get support from Rackspace, and others claimed to have terminated their relationship with the company. "You are holding us hostages. The lawsuit is going to take you to bankruptcy," another apparent Rackspace customer noted.

Davis McCarthy, principal security researcher at Valtix, says the breach is a reminder why organizations should pay attention to the fact that security in the cloud is a shared responsibility. "If a service provider fails to deliver that security, an organization is unknowingly exposed to threats they cannot mitigate themselves," he says. "Having a risk management plan that determines the impact of those known unknowns will help organizations recover during that worst case scenario."

Meanwhile, the lawsuit, filed by California law firm Cole & Van Note on behalf of Rackspace customers, accused the company of "negligence and related violations" around the breach. "That Rackspace offered opaque updates for days, then admitted to a ransomware event without further customer assistance is outrageous,” a statement announcing the lawsuit noted.

**Did the Attackers Exploit "ProxyNotShell" Exchange Server Flaws?**

No details are publicly available on how the attackers might have breached Rackspace's Hosted Exchange environment. But security researcher Kevin Beaumont has said his analysis showed that just prior to the intrusion, Rackspace's Exchange cluster had versions of the technology that appeared vulnerable to the "ProxyNotShell" zero-day flaws in Exchange Server earlier this year.

"It is possible the Rackspace breach happened due to other issues," Beaumont said. But the breach is a general reminder why Exchange Server administrators need to apply Microsoft's patches for the flaws, he added. "I expect continued attacks on organizations via Microsoft Exchange through 2023."

Rackspace Incident Highlights How Disruptive Attacks on Cloud Providers Can Be

Cyberattackers focused on ad fraud and clickjacking stole millions during Black Friday by hijacking shopper accounts and tying up transactions.

Online fraudsters posing as consumers likely siphoned off more than $360 million from the marketing budgets of online businesses by generating fake clicks during Black Friday, while 20% of visits to retail sites on Cyber Monday were bots posing as shoppers and not humans, Web security firms said this week.

The surge in fraud included techniques such ad injection, search engine redirects, and affiliate fraud — and shows the trouble that cybercriminal automation such as bots can cause for online commerce providers. The increase in fraud matched the annual upswing of US holiday sales that start the week of Thanksgiving though the following Monday, also known as Cyber Monday. Overall, online retailers saw a nearly 12% increase in sales during November and a 2.3% increase in purchases on Black Friday.

The lockstep growth of sales and fraud underscores the opportunistic nature of attackers, says Guy Tytunovich, CEO of Cheq.

"Fraud is always there, but it is very seasonal in terms of peak times," he says. "\[The trigger\] could be anything — it could be political, like an election, or it could be like Black Friday or Cyber Monday."

Fraudsters have had a significant impact on online businesses, according to data provided to Dark Reading by Cheq and online network-services provider Akamai. By donning the disguise of legitimate consumers, bots can cost advertisers and retailers real money on marketing — typically a loss of 10% to 15% — that is not being seen by human eyes. In addition, bots can be used to buy out popular items, enable credit card fraud, and tie up inventory.

The largest cost to businesses comes during peak times. During the peak on Cyber Monday, consumers spend $12 million every minute, according to Adobe, which collects information on consumer activity. Yet 46 million of those shoppers were bots, leading to $368 million in fake clicks on retail ads, Cheq estimates.

About 20% of sessions overall are "being distorted" because of something happening on the client side, says Patrick Sullivan, chief technology officer for security strategy at Akamai. While businesses tend to focus on attacks against their own infrastructure — the server side — they pay less attention to what is going on with visitors' systems and browsers, he says.

"In general, we've seen over the last five years that no longer can security be focused on the crown jewels just being on the server side," Sullivan says. "Across a number of industries, we see attackers more focused on the client side. We've seen supply chain attacks where the fraudsters gain control of the javascript running on the client side, for example."

**Scalper Bots & Denial-of-Inventory Attacks**

One major fraud scheme enabled by client-side bots are scalper bots/sneaker bots — automated programs running on clients that scrape retailers' sites looking to buy particularly popular items, sometimes purchasing the items with stolen credit cards, says Cheq's Tytunovich.

While credit card fraud continues to be a significant concern for retailers, the increase in attacks that deplete inventory or make inventory unavailable to legitimate buyers is more worrisome, he says.

"While they are not as malicious as other \[cyberattacks\], retailers are extremely scared about scalper bots," he says. "The bots that are wholly aimed at getting those Jordan Ones or PlayStation 5s or whatever, and get the entire stock."

Another major inventory-impacting attack are bots that abandon shopping carts, which typically puts a hold of 10 to 15 minutes on an items — a small amount, but one that can add up quickly with the intensity that only automation can provide. These denial-of-inventory attacks can cause chaos with retailers' visibility into the state of their stocks, Akamai's Sullivan says.

"There are certain industries that almost engineer scarcity — they want people to queue up for sneakers or handbags — but now we have seen it across multiple industries — groups that have traditionally never seen that," he says. "Because of the supply chain issues now, a lot more industries are impacted by these inventory-grabbing bots out there."

**Unwanted, But Legitimate**

However, most of the invalid traffic, or IVT, that companies such as Akamai and Cheq track are not necessarily fraud, but just unwanted by retailers.

In many cases, the influx of non-human traffic included user-installed price-comparison tools, such as Honey and Rakuten, which retailers might prefer that their visitors did not use, but which are not fraudulent nor malicious. In the US during Cyber Week, for example, retailers saw 25% to 30% more sessions that used browser extensions for price comparison, Akamai stated.

Yet such traffic also skews retailers' understand of consumer demand, which can lead to inefficiencies, according to Cheq. Unique site visits are increased by 22% by automated traffic, while sessions duration can dive 41% and the number of new users overestimated by 21%, the company found.

Fraudsters Siphon $360M From Retailers Using 50M Fake Shoppers

Out of more than 80 flaws fixed this month, the most critical was a system component bug that could allow RCE over Bluetooth.

Android's Framework, Kernel, and Google Play were among components that received security updates this month, but the most severe was a critical bug in the System component that, if exploited, could allow remote code execution (RCE) over Bluetooth, without any escalation privileges required. 

In addition to the System vulnerability, tracked under CVE-2022-20411, there are three additional critical flaws addressed by Android this month, including an ID bug in the System component (CVE-2022-20498) and two critical RCE bugs in the Framework component (CVE-2022, 20472 and CVE-2022-20473). 

In total, the Android security update addressed more than 80 vulnerabilities. 

Keep up with the latest cybersecurity threats, newly-discovered vulnerabilities, data breach information, and emerging trends. Delivered daily or weekly right to your email inbox.

Subscribe

Android Serves Up a Slew of Security Updates, 4 Critical

At AWS re:Invent last week, the cloud giant previewed security services including Amazon Security Lake for security telemetry, Verified Permissions for developers, and a VPN bypass service.

Cloud threats will continue to grow and proliferate in 2023, but organizations can meet the challenges head-on with the right security fundamentals in place, Amazon Web Services CISO CJ Moses said during AWS re:Invent 2022 conference last week.

Malicious activity is on the rise: The volume of DDoS events in AWS between January and September of this year rose 35% compared with the same period in 2021. AWS saw a 256% increase in compromised instances compared with the fourth quarter of 2021.

AWS unveiled new security tools to help enterprise security teams with analyzing security telemetry, permissions management, and key management.

**Gathering Threat Telemetry**

First up was Amazon Security Lake to manage threat intelligence data. AWS CEO Adam Selipsky said Amazon Security Lake would allow organizations to gather security telemetry and data from many sources, clean it up, and make it accessible for analysis. The challenge lies in the fact that security data exists in multiple formats. The new Open Cybersecurity Schema Framework standard, announced last August during Black Hat USA, can be used to normalize security logs and events data across a wide range of products and services, Selipsky said.

Asked whether supporting OCSF members have conducted comprehensive interoperability tests or certification efforts, Splunk distinguished engineer Paul Agbabian explained to Dark Reading how the data is normalized. 

"For an event class to be considered in OCSF, there must be a real implementation of the class via one of the member's example logs," he said. "In addition, OCSF uses a server that can test each implementation of the schema for validation, which includes showing notable errors and violations."

"Increasing threats and risks continue driving the shift to the cloud, where security will be built into everything organizations do up and down their technology stack and across their teams," Moses said. "More and more security can be thought of as a data science problem."

AWS said FINRA, Salesforce, and Tinder are the first customers using Amazon Security Lake. Fernando Montenegro, a senior principal analyst at Omdia, said Amazon Security Lake was the most significant new security offering announced at last week's conference.

"Security Lake is obviously notable as it addresses some of the security 'undifferentiated heavy lifting' that AWS likes to address," Montenegro told Dark Reading. "It's still early, but the expectation is that it can help simplify security analytics at scale. The use of the OCSF standard is also notable, as it can herald easier data integration even outside of AWS environments."

**Verified Permissions for Developers**

A preview of Amazon Verified Permissions is now available, which Moses described as a scalable, fine-grained permissions management and authorization service for custom applications. 

"It gives developers a consistent way to define and manage fine-grained permissions across applications, simplifies changing permission roles without a need to change code, while also improving visibility to permissions," he explained.

Amazon Verified Permissions gives application administrators "a comprehensive audit capability that scales millions of policies using automated reasoning," Moses added. "Authorization requests running through Amazon Verified Permissions are evaluated in milliseconds to provide dynamic real-time decisions."

**Remote Access Without a VPN**

Amazon also released the preview of AWS Verified Access, a new connectivity service that provides secure remote access to corporate applications without requiring a VPN. According to AWS, the new service only grants access to applications if users and their devices meet defined security requirements.

AWS noted that Verified Access validates each application request, regardless of user or network, before granting access. 

"AWS Verified Access should help with the burden of accessing AWS resources in a 'zero trust' manner,'" Omdia's Montenegro said.

**External Key Store (XKS) for AWS KMS**

Amazon also announced its AWS Digital Sovereignty Pledge, which the company describes "as its commitment to offering all AWS customers the most advanced set of sovereignty controls and features available in the cloud."

Previously, customers have had to choose between "the full power of AWS and a feature-limited sovereign cloud solution that could hamper their ability to innovate, transform, and grow. We firmly believe that customers shouldn't have to make this choice," explained AWS senior VP Matt Garman in a blog post.

Effectively, AWS is promising to enable its complete offerings to maintain the growing set of digital sovereignty industry and regional regulations. Moses said the new External Key Store (XKS) for the AWS Key Management Service (KMS) supports the pledge because it lets organizations store and utilize their encryption keys outside of AWS.

"Customers can now store AWS KMS customer-managed keys outside of AWS on hardware security modules, whether they operate on-premises or anywhere else they would like to do so," he said. "XKS supports all the critical features of KMS and works with the over 100 AWS services that already integrate with KMS customer keys."

A user can encrypt data with external keys for most AWS services that support AWS KMS customer-managed keys, including Amazon EBS, AWS Lambda, Amazon S3, Amazon DynamoDB, and over 100 more services. The external key store forwards API calls to securely connect with a customer's hardware security module (HSM). According to an AWS blog post, the data describing the key never leaves the HSM.

Key Security Announcements From AWS re:Invent 2022

Cybercrooks allegedly stole personal data, used it to file IRS tax documents, and routed refunds to bank accounts under their control.

Three Nigerian nationals and one UK citizen are facing extradition to the US following their recent arrest for cybercrimes related to a tax refund scam. 

The Department of Justice unsealed indictments of Akinola Taylor, Olayemi Adafin, Olakunle Oyebanjo, and Kazeem Olanrewaju Runsewe, who are accused of breaching US company servers, stealing personal information, and using that data to file fraudulent Internal Revenue Service (IRS) tax documents and collect refunds. 

The group, on at least once occasion, used cybercrime forum xDedic Marketplace to purchase access to compromised servers and users all over the world, which were then leveraged to steal enough information on US citizens to file false tax returns, the DoJ said. The four men would allegedly direct the returns to accounts under their control and convert the proceeds to purchase prepaid debit cards for their use. 

"Adafin and Oyebanjo assisted in the collection fraud proceeds directed to prepaid debit cards in their possession or to addresses or bank accounts they controlled or to which they had access and transferred a share of the fraud proceeds to other conspirators," according to the DoJ announcement. 

If convicted, each will face a maximum penalty of up to 20 years in prison, the DoJ said. 

Keep up with the latest cybersecurity threats, newly-discovered vulnerabilities, data breach information, and emerging trends. Delivered daily or weekly right to your email inbox.

Subscribe

4 Arrested for Filing Fake Tax Returns With Stolen Data

Learn how BOD 23-01 asset inventory mandates can help all organizations tighten cybersecurity.

Do you know what IT devices are in your business or on your network right now? If not, you may have cybercriminals _and_ the White House knocking on your door very soon.

Binding Operational Directive 23-01, or BOD 23-01, is a new directive from the US Cybersecurity and Infrastructure Security Agency (CISA) that orders federal agencies to keep track of their IT assets and any vulnerabilities on their networks. The guidance is designed to improve the way systems are tracked, managed, and protected against unauthorized access and attacks such as ransomware.

**What Is BOD 23-01?**

The wide-ranging BOD 23-01 cybersecurity directive orders all US Federal Civilian Executive Branch (FCEB) agencies to create a complete and accurate inventory of all software assets. The intention of the new directive is to prevent situations such as the 2020 SolarWinds attack, in which several government agencies and organizations were compromised by malicious code injected into software systems.

BOD 23-01 also is designed to make federal civilian agencies more accountable for their own systems and what resides on their networks, as well as for any cyber breaches or attacks on their systems. The directive covers only federal civilian agencies in the US, but CISA also has urged the private sector and state governments to review and implement similar asset and vulnerability practices.

**What Issues Does BOD 23-01 Address?**

Threat actors continue to target critical infrastructure, networks, and devices to exploit weaknesses within unknown, unprotected, or under-protected assets. Previous and even current methods of preventing infiltration and attacks have had varying levels of success — hence, the need for another layer of protection.

At a basic level, businesses still aren’t tracking the devices and software beneath their own roof, with about one in three IT teams saying they don't actively track the software used by employees within the business.

The hope with the new directive is that, at minimum, agencies and government departments have access to an up-to-date inventory of assets. You can't protect what you can’t see, so by providing this visibility organizations will be one step ahead of the game.

Of course, there's no point in knowing what's under threat if you can't prevent or stop an attack.

The vast majority of companies are vulnerable to external attackers breaching their network perimeters and gaining access to sensitive data.

**What Does the Order Mean for IT Teams?**

The attack surface — the points of entry and vulnerabilities that serve as attack vectors — is expanding rapidly. New technologies, recent changes to implement remote and hybrid workplaces, and the BYOD model again gaining momentum are threatening to overpower IT teams, which is why new methods of cyber asset attack surface management (CAASM) are becoming vital in managing and protecting organizations.

For agencies looking to become compliant with the new directive, creating an IT asset inventory will be seen as a significant administrative challenge. We're talking about having to locate, identify, record, and report on potentially hundreds or thousands of pieces of hardware and software.

**Asset Visibility and Vulnerability Detection**

There are two key areas IT teams need to focus on: asset inventory and vulnerability scans. Together, these are seen as vital in gaining the visibility needed to protect federal organizations against outside threats.

By April 3, 2023, asset discovery scans will need to be run every seven days, while vulnerability assessments across those assets every 14 days. Agencies will also have to prove that they have the ability to run such tests on demand, with CISA requesting proof within 72 hours of receiving a written request.

If IT teams don’t have one already, they will need to create and maintain an up-to-date inventory of IT assets on their network, as well as identify vulnerabilities and share relevant information with CISA at regular intervals.

IT teams are already under pressure, and the only realistic and cost-effective way organizations can become compliant is to automate IT inventory. With new devices added on an almost daily basis and current tech needing to be constantly updated, it's virtually impossible to handle this manually.

Knowing what's on your network is necessary for any organization to reduce risk. In today's digital-first world, with more attack surfaces than ever before, taking stock of what you have is the first step in protecting and preventing the worst from taking place.

Will New CISA Guidelines Help Bolster Cyber Defenses?

Data protection company Piiano officially launches a vault for sensitive customer data, the first among a suite of privacy tools for developers.

**TEL AVIV, Israel, Dec. 07, 2022 (GLOBE NEWSWIRE)** — Piiano, a data protection company co-founded by celebrated security experts Gil Dabah, CEO and Ariel Shiftan, CTO, today announced the release of the Piiano Vault, a secure database for enterprises to safely store and use sensitive personal data and comply with evolving privacy regulations. Basic functionality is now available for free. Deployed directly in an enterprise’s own cloud environment, the Vault provides complete control over critical customer data and was designed to be the most secure database on the market.

Enterprises that collect sensitive data face mounting pressure to protect it and maintain customer privacy in the wake of high-profile data leaks and broadening regulations. Gartner findings demonstrate intensifying budgetary spending across data privacy and security by 14.2% and 16.9%, respectively. According to a survey conducted by Piiano on privacy best practices, 80% of companies now attempt to treat sensitive data differently, with 45% highly prioritizing Personal Identifiable Information (PII) protection.

However, operationalizing such practices at scale requires the involvement of developers tasked with embedding security into the very frameworks of their enterprise environments. This is an enormous undertaking, and many developers find themselves scrambling to retrofit privacy and security into existing environments and workflows. In most cases, such a feat requires companies to embark on a years-long, expensive development project even as the underlying risk grows and becomes a moving target. By contrast, Piiano intends to significantly accelerate such transformations and deliver unprecedented ROI on related initiatives.

As enterprise R&D outpaces security efforts, the safety and protection of customer data remains disorganized and consequently highly vulnerable to potential breaches. Piiano’s solution is based on embedding security and de-identifying data as part of product development. The company’s approach starts by isolating customer secrets and similar types of sensitive data in a separate, zero-trust vault. It is a best practice already exercised by large companies like Google, Netflix, USAA and JPMC. Both Dabah and Shiftan assert that keeping sensitive data separate and untouchable can all but nullify the true privacy risk.

“By centralizing sensitive data into one place with Piiano, developers can easily integrate with existing building blocks like field-level encryption, tokenization, masking, data retention and granular access control. Even more exciting are the major breakthroughs we’ve made in providing capabilities to search through encrypted data,” says Shiftan. “In this way, the Piiano Vault simplifies regulatory compliance by providing developers with out-of-the-box support for staples of GDPR and CCPA requirements, such as data subject access rights, consent, retention, minimization, traceability and more.”

In praise of Piiano’s approach, author of "Data Privacy: A Runbook for Engineers" and Piiano board advisor Nishant Bhajaria said, “Gil and Ariel’s groundbreaking technology has the potential to be an incredible service to enterprises in an age where the sale of stolen sensitive customer data has become so widespread and lucrative. I commend them for helping companies seamlessly incorporate privacy into day-to-day operations.”

For more information visit: https://piiano.com/pii-data-privacy-vault/

**About Piiano**

Piiano provides developer infrastructure to protect customer secrets and ensure their privacy — even in the event of a breach. Safely use and store sensitive data in our Vault and leverage our Scanner to quickly identify PII usages across source code for full visibility into your privacy issues. With Piiano’s building blocks, engineers and security leaders can save time, effort and resources while achieving secure and compliant applications.

Piiano Equips Developers to Stop Sensitive Data Breaches

A world of increasingly connected devices has created a vast attack surface for sophisticated adversaries.

The explosion in connected devices, ranging from the Internet of Things to networking devices and operational technology (collectively known as the Extended Internet of Things, or xIoT), has created a vast, diverse, and largely unmapped attack surface that sophisticated adversaries are actively exploiting.

This growing risk is reflected in many recent reports from companies like Microsoft, Intel 471, and Zscaler that have found a significant uptick in both targeted and untargeted attacks on these devices, with a high rate of malware infections.

However, these threats — particularly when they target IoT devices — are often misunderstood or dismissed, as companies tend to view them as less significant than a traditional network attack. Part of the reason for this is the mistaken belief that IoT threats are mostly limited to botnet malware used for cryptomining and distributed denial-of-service (DDoS) attacks. In reality, IoT attacks are becoming much more sophisticated and now pose serious threats to corporate network integrity, data security, and even physical security systems.

Here are three xIoT attacks every company should be aware of:

**Pivoting From the xIoT Device**

Since many xIoT devices lack even basic native cybersecurity protections, disallow the installation of traditional endpoint security software, and are often unmonitored, they are an effective initial access point for attackers looking to gain a beachhead on a company and then move laterally across its network.

Once the xIoT device has been compromised, the adversary can use this foothold to upload tools, sniff network traffic, search for other exploitable devices, and exfiltrate sensitive data. For example, an attacker can transition from an IoT device into the main IT network, as well as the operational technology (OT) network.

This type of "pivot attack" has already been observed in the wild by multiple companies. My company has seen a growing number of corporate cyberattacks, in which the company was first compromised through a security camera, door controller, or other device, then targeted with ransomware, espionage, or data theft through its IT network.

In 2019, Microsoft Threat Intelligence Center detected an adversary that exploited three different IoT devices (a VoIP phone, a printer, and a video decoder), from which the actor established a presence on the network while looking for further access. Researchers also unveiled a proof-of-concept ransomware that can spread from an xIoT device to an IT network.

**Atypical Data Theft**

xIoT devices can also be direct targets of espionage and data theft.

Certain office devices like connected printers and document scanners are storehouses of sensitive corporate information that is largely unprotected. In the healthcare industry, CT scanners and MRI machines also contain valuable personal and medical information. Industrial devices can pose data breach risks too. Certain OT devices, like programmable logic controllers (PLCs), can contain privileged manufacturing and processing details, such as temperature and pressure ranges, chemical mixing.

This type of sensitive data storage in xIoT devices is often overlooked by traditional information security audits, and the devices themselves offer little, if any, data protection. For remote attackers, gaining access to these devices is usually a trivial matter.

My company has found that 50% of xIoT devices use default passwords, 68% of devices have high-risk or critical CVEs in their firmware, and 26% of these devices are end-of-life and no longer supported. This means in literally half of these cases, all an attacker needs to do is enter in a default password to gain access to privileged data.

**xIoT as a Persistence Strategy**

Threat actors who have already breached a corporate IT network through traditional means like phishing may also carry out a second-stage attack on xIoT devices to achieve long-term persistence inside the organization.

One example is the threat actor UNC3524, which Mandiant recently discovered had been installing a backdoor called QuietExit in opaque network appliances and IoT devices like security cameras, remaining undetected on victims' networks for at least 18 months.

xIoT devices are an ideal hiding place for sophisticated adversaries. These devices are poorly monitored, lack anti-malware and intrusion detection coverage, and are not easy to analyze during incident response. My company has found that over 80% of security teams can't even identify the majority of xIoT devices they have in their networks. They also fall into an administrative gray area in terms of who is responsible for managing them (is it the IT team, the security team, the operations team, or the vendor?), which leads to confusion and inaction.

An adversary can easily install a backdoor in any one of these overlooked xIoT devices that will be exceedingly difficult for the security team to detect. The average enterprise has anywhere from tens of thousands to millions of xIoT devices, and typically relies on manual processes for monitoring and maintaining them. Detecting such a backdoor will be like trying to find a needle in an enormous haystack (or haystacks).

**Preventing the Full Range of xIoT Attacks**

In spite of their many risks, xIoT devices can be sufficiently protected without imposing high costs on a company.

Basic measures such as strong password management and keeping firmware up to date will drastically reduce the risk. Accurate inventorying and regular monitoring are also key.

Where companies will be challenged is in terms of the volume of devices they must protect. This is why automation is important, as manually changing passwords and updating firmware on such a vast array of devices isn't feasible for most companies.

3 xIoT Attacks Companies Aren't Prepared For

After an uproar, the city board voted to rescind last week's bill to allow police to use robots to deliver deadly force. The fight isn't over, but there's a good reason it should be.

On Nov. 29, the San Francisco Board of Supervisors voted to allow the San Francisco Police Department (SFPD) to use armed robots for lethal force, a month after public outcry caused the police in nearby Oakland to rescind a similar request. A week later, the board voted again — this time to explicitly deny permission for deadly force and send the original bill back to committee. Many questions about that original bill remain unanswered, but one obvious one is: If we allow civilian agencies to arm robots, how do we guard against misuse — by police themselves, yes, but also by unauthorized users?

Security researchers Cesar Cerrudo and Lucas Apa tackled those questions as IOActive consultants back in 2017. The issues are still prevalent today, according to Cerrudo, now an independent cybersecurity researcher.

"As any piece of technology, robots could be hacked; it could be easy or extremely difficult, but possibilities are there," he tells Dark Reading. "In order to reduce hacking possibilities, robot technology has to be built with security in mind from the very beginning and then all the robot technology properly audited to identify all potential vulnerabilities and to eliminate them."  

The categories of vulnerabilities Cerrudo and Apa discovered included insecure communications, authentication issues, missing authorization, weak cryptography, privacy concerns, insecure default configurations, and easily probed open source frameworks.

While the researchers didn't test military or police robots, such machines are likely to be similarly vulnerable. "These robots are some of the most dangerous when hacked, since they are often used to manipulate dangerous devices and materials, such as guns and explosives," they wrote in the paper.

One example of the scale of the danger is a 2007 failure in an automatic anti-aircraft cannon in South Africa that killed nine soldiers and wounded a dozen more in a span of 0.8 seconds. Now imagine what would happen if someone successfully turned an armed police robot back toward the officers or toward the public.

The possibility that robots can be hacked is not so far-fetched. Last year hacktivists gained access to a network of 150,000 surveillance cameras, including those inside of prisons, by obtaining the super admin account information. Hackers have successfully seized control of a Jeep Cherokee driving down a highway and grabbing control of other cars via a key fob hack that has gone mainstream. Even entire buildings have been hacked.

**Taking Back Permission to Kill**

"I simply do not feel arming robots and giving them license to kill will make us safer," said Supervisor Eric Mar on Dec. 6 before voting to send the original bill back to committee.

On Nov. 29, the board had voted 8-3 to approve the bill allowing deadly force; on Dec. 6, the vote was 8-3 to rescind it. "It was a rare step," the San Francisco Chronicle reported. "The board's second votes on local laws are typically formalities that don't change anything."

What does change things in San Francisco is public protest. "We've all heard from a lot of constituents ... on the idea that we as a city will have robots deliver deadly force," said Supervisor Dean Preston at the Dec. 6 meeting.

Three of the supervisors — Shamann Walton (also board president), Hillary Ronen, and Preston — attended one such protest at city hall on Monday, organized by the Quakers, where a crowd held placards reading "no killer robots." 

"We will fight this legislatively at the board, we will fight this in the streets and on public opinion, and if necessary, we will fight this at the ballot," Preston said. That last threat might have been the most persuasive; city voters are not afraid to govern directly through ballot initiatives.

The SFPD has about a dozen robots purchased between 2010 and 2017, the department said in a statement. 

"The robots are remotely controlled and operated by SFPD officers who have undergone specialized training," according to the statement. "Our robots are primarily used in EOD/bomb situations, hazardous materials incidents, and other incidents where officers may need to keep a safe distance before rendering a scene secure."

The SFPD statement continued: "In extreme circumstances, robots could be used to deliver an explosive charge to breach a structure containing a violent or armed subject. The charge would be used to incapacitate or disorient a violent, armed, or dangerous subject who presents a risk of loss of life," although such use "could potentially cause injury or be lethal."

While the Dec. 6 vote was a setback for the SFPD, the San Francisco Standard pointed out that the issue isn't necessarily finalized. The rules committee might be able to sit on it long enough that public attention fades, or they could come up with language that lets a majority of supervisors return their support. But for now, murderbots are explicitly forbidden, and it seems decided.

**Not the First Robo-Cops**

Unmanned aerial vehicles (UAV) have been part of military tactics for half a century, and there are several examples of police departments using remotely operated drones. In 2015, North Dakota legalized arming drones with less-than-lethal weapons like tasers. Of course, tasers can be lethal, and drones are notoriously vulnerable to hacking.

Another prominent police use of unmanned robotics was the NYPD's failed Digidog experiment in 2020-2021, which sent remote-controlled Boston Dynamics robots into dangerous situations, such as standoffs and hostage situations, to minimize risk to personnel. Public reaction to the spidery, fast-moving, stair-climbing robots was so negative, however, that the department ended the contract early.

Proponents of unmanned mobile equipment usually base the technology's mission on saving lives, whether of hostages or police. Indeed, the SFPD's statement asserted, "Robots equipped in this manner would only be used to save or prevent further loss of innocent lives." We have already seen how that plays out in real life.

**Police Robots Have Already Killed**

American police have already used a robot to deliver lethal force. Dallas PD sent a robot rigged with explosives to kill Micah Johnson back in 2016, ending a standoff after Johnson shot 12 Dallas officers, killing five. A grand jury cleared the police of any wrongdoing in that incident, where the police used the ruse of sending the shooter a phone to get the robot close enough. Some of the SFPD's dozen existing robots are "wheeled bomb-disposal robots with extending arms similar to the one used by Dallas officers in 2016," according to the Washington Post.

After that 2016 Dallas use of force, UC Davis law professor Elizabeth E. Joh wrote in the New York Times: "And a robot is unlike a gun in that a gun may misfire, but it can't be hacked. The market for police robots is emerging, but we as a society — and that includes the police — should be wary of any armed police robot that is vulnerable to takeover by third parties. Experience with the security of electronic devices doesn't inspire confidence: If third parties can hack cars or toy drones, they can certainly hack police robots."

Cerrudo's assessment aligns with that warning. 

"If I were to deploy these robots, I would make sure that they were built with security in mind and that they have been properly security-audited by experts," he says. "Failing to do this is exposing the robots to possible cyberattacks that could turn a robot into a dangerous weapon."

Source

DARKReading