Cisco confirmed Oct. 18 that it experienced a breach on its public-facing DevHub environment, but that no internal systems were compromised.
According to Cisco, only a small number of files that were not authorized for public download may have been published.
DevHub runs as a resource center that lets Cisco support its customers by making available software code and scripts as needed. As a cautionary move, Cisco disabled public access to DevHub until it completes its investigation.
The recent Cisco breach was reportedly first announced on a cybercrime forum on Oct. 14 by the hacker known as IntelBroker. On the crime site, IntelBroker claimed to have obtained GitHub and SonarQube projects, as well as many other sensitive assets, including source code, hardcoded credentials, certificates, confidential documents, Jira tickets, API tokens, AWS private buckets, and encryption keys. One of the recent victims — Deloitte — also said publicly that the breach by IntelBroker did not involve sensitive data.
Future attacks possible from Cisco breach
Security pros responded to Cisco’s claims that the breach was limited in scope with cautious optimism.
“Even if the compromised environments were meant to be public-facing, exposing sensitive information such as source code, credentials, and API tokens can have significant security implications,” said Eric Schwake, director of cybersecurity strategy at Salt Security. “It's crucial to remember that attackers often exploit seemingly minor vulnerabilities to gain a foothold and potentially pivot to more sensitive systems.”
Schwake said these intrusions run the risk of attackers using the exposed information to launch additional attacks. Exposed source code can reveal vulnerabilities that attackers can exploit in other systems, and hardcoded credentials and API tokens can grant unauthorized access to sensitive resources and data, said Schwake.
“Even seemingly harmless information, such as Jira tickets or internal documents, can provide valuable intelligence to attackers, allowing them to create more targeted and effective attacks,” Schwake explained.
While Cisco may not have had its core systems directly compromised, the data obtained — including source code, API tokens, certificates, and credentials — represents significant risks if leveraged for future attacks, said Jason Soroko, senior fellow at Sectigo.
“Public-facing environments are often seen as less critical. But in reality, they can expose sensitive information that serves as stepping stones to deeper intrusions,” said Soroko.
Evan Dornbush, a former NSA cybersecurity expert, said there are two main issues with these types of intrusions.
First, the narrative is an incomplete picture, said Dornbush: Cisco might not have been breached internally, but the third-party service Cisco uses to host its data still has Cisco data. Knowing where data resides, understanding who’s responsible for securing it, and who’s accountable for post-breach disclosures is complex, and not all organizations are set up to manage the rise of third-party cloud technologies.
The second issue, said Dornbush, is that an attacker who obtains access to the disclosed data, which includes proprietary code and access measures, can now use that information to develop zero-day exploits and other methods to access or manipulate customer-owned devices, efforts we won’t see immediately.
“Although its list is quantifiable and finite, if IntelBroker has what it claimed: hardcoded credentials, encryption keys, and API tokens, then Cisco has a decent amount of work ahead to prevent those assets from being used in production,” said Dornbush. “Even though Cisco felt comfortable sharing Cisco-proprietary source code and scripts with select customers, it may want to do additional review of what was posted since source code access can be a gold mine to competitors and security researchers alike.”
