Black Hat In Brief Victor Zhora, Ukraine’s lead cybersecurity official, made an unannounced visit to Black Hat in Las Vegas this week, where he spoke to attendees about the state of cyberwarfare in the country’s conflict with Russia. The picture Zhora painted was bleak.
Zhora, who is the deputy director of Ukraine’s State Service of Special Communications and Information Protection, said cyber incidents in the country have tripled since February, when Russia invaded.
Zhora told attendees that Ukraine had detected over 1,600 “major cyber incidents” so far in 2022, but reports don’t include elaboration on how such incidents are classified. A number of huge incidents happened between March and April, Zhora said, including discovery of the “Industroyer2,” an apparent successor to the Industroyer malware discovered in 2017.
Industroyer was a particularly nasty strain that was able to control electrical substation software and cause power blackouts, as well as damage equipment. Ukraine was hit by a similar malware called BlackEnergy in 2015.
Online attacks against Ukraine were a common tactic in the leadup to Russia’s invasion of the country in late February he said. DDoS attacks took many of Ukraine’s government agencies offline, and new malware strains were discovered in the leadup to the invasion as well.
The Russo-Ukraine conflict has had global cybersecurity implications, including leading to a large spike in data-wiping malware, of which six significant new strains have been found this year.
Fortinet, which reported the jump, said it hadn’t uncovered more than one significant file wiper a year since 2012, and several years when it didn’t spot a new one at all. Of the strains discovered in 2022, all have been used against Ukrainian infrastructure and organizations – in other words the gloves are off.
Back at Black Hat, Zhora didn’t mince words on the severity of Russia’s cyber operations against Ukraine. “This is perhaps the biggest challenge since World War Two for the world, and it continues to be completely new in cyberspace.”
Zero Day Initiative shortens some disclosure timelines
Hoping to spur vendors to take quicker action, Trend Micro’s Zero Day Initiative (ZDI) bug bounty program announced changes to its disclosure timelines, with a 30-day relaease deadline for serious stuff because vendors aren’t taking the issue seriously.
Announced yesterday at Black Hat, ZDI said it planned to implement a tiered disclosure system, but said that the Initiative’s standard 120-day disclosure timeline would remain, and most vulnerabilities would continue to fall into that category.
“For bug reports that result from faulty or incomplete patches, we will use a shorter timeline,” ZDI said.
A 30-day timeline would apply to critical-rated cases where exploitation has been detected or is expected, while critical- and high-severity bugs with a released patch offering some level of protection would get 60 days. A 90-day disclosure will also be used for other severities where no imminent exploitation is expected.
ZDI, which calls itself the “world’s largest vendor-agnostic bug bounty program,” pointed its finger straight at vendors in its statement announcing the timeline changes. “Over the last few years, we’ve noticed a disturbing trend – a decrease in patch quality and a reduction in communications surrounding the patch,” ZDI said.
The new timelines are one of the few ways ZDI said it’s able to pressure vendors into moving more quickly to release security patches. The Initiative previously reduced its disclosure timeline from 180 days to 120 days, and said the change led to a positive result.
ZDI operates its bug bounty program by purchasing vulnerabilities from security researchers and acting a middleman. One of its central platforms is stopping vendors sweeping vulnerabilities under the rug.
ZDI also launched a new Twitter handle at Black Hat that will exclusively publish high CVSS, 0-day and Pwn2Own vulnerabilities.
New HTTP smuggling technique lets researcher into Amazon, Akamai, and more
James Kettle, director of research at PortSwigger, demonstrated a new method of HTTP request smuggling at Black Hat that allowed him to compromise Apache servers, break into Akamai and Amazon, and compromise multiple web VPNs.
The trick lies in browser-powered desync attacks, which get around limitations of traditional methods that only allow them to work on websites that use a front-end/back-end architecture. Kettle’s new system, on the other hand, desyncs a website’s front end from a visitor’s browser, which PortSwigger said exposes “a whole new range of websites to server-side request smuggling,” as well as allowing an attacker to force a victim’s browser to deliver bad requests on their behalf.
Four exploits were involved in Kettle’s discovery, he told the Black Hat crowd:
- A request validation exploit in which an attacker sends two requests down the same connection in a bid to gain access to the host in the second request,
- A first-request routing exploit that tricks the front-end into sending all subsequent requests to the same backend as the first request,
- A method he discovered to detect connection-locked request smuggling vulnerabilities,
- A desyc vulnerability known as CL.0/H2.0, which belongs to a known but lesser-explored class of attacks that exploit connection-locked requests.
During his talk, Kettle said he was able to use the exploit chain on Amazon to gain access to user accounts and steal their requests, including login tokens. Kettle notified Amazon, who fixed the problem, but Kettle said he was surprised he was able to perform the exploit using a legitimate HTTP request.
“It’s understandable when servers get confused by requests that use header obfuscation to hit edge-cases, but getting desync’d by a completely valid, RFC-compliant HTTP request is something else,” Kettle said.
After notifying Amazon, Kettle realized he could have created a desync worm capable of spreading to every active Amazon user, as “the attack request was so vanilla that I could have made anyone’s web browser issue it using fetch(),” he said.
Kettle said the wormable element was a cool finding, but also warned that the exploit sequence as a whole contained shades of what could become a new class of attack.
IBM releases source code attack simulation tool
IBM’s X-Force security team announced a new tool at Black Hat that those using GitHub Enterprise, GitLab Enterprise and Bitbucket Server should look into: A source code management (SCM) attack simulation tool.
SCM tools, X-Force Red’s Brett Hawkins wrote in a blog post, are vital to organizations, but are often a security afterthought. Case in point: The SolarWinds breach, which Hawkins called “one of the most notable software supply chain attacks.” Like other SCM attacks, the bad actors behind SolarWinds used infected source code to spread beyond its maker and into other organizations.
When an attacker is able to successfully inject code into an SCM system, Hawkins said, they can conduct reconnaissance, manipulate user roles, take over repositories, pivot to other DevOps systems, impersonate users and gain persistent access. IBM’s new source code management attack toolkit (SCMKit) can do most of that too, Hawkins wrote, but with the added benefit of not being an actual attacker.
“The goal of this tool is to provide awareness of the abuse of SCM systems, and to encourage the detection of attack techniques against SCM systems,” Hawkins said.
The kit allows users to specify the type of SCM system and attack module to use, but the publicly-available version leaves out user impersonation, credential-searching modules and other unnamed capabilities, presumably because IBM wanted to limit the capabilities of a tool that could easily be turned to nefarious uses.
Those who don’t want to try running SCMKit on their own networks can still take some practical SCM security advice from the X-Force Red team. In the blog post, they mention tips including always using MFA, forcing the expiration of SSH keys and personal access tokens, limiting the number of administrator accounts, requiring approval for each code commit, increasing logging and operating on a policy of least privilege.
“These systems are a high value to an attacker, and need more visibility from the information security community, as they are currently an afterthought compared to other systems such as Active Directory,” Hawkins said.
Concentric, CrowdStrike launch AI-powered security tools
AI-driven security software was in the air at Black Hat this year, as both CrowdStrike and Concentric launched their own “industry first” security tools that automate away security tasks, the companies claim.
Crowdstrike’s new AI tool is designed to detect indicators of attack (IoA), which look at behavioral indicators to detect a forthcoming or active attack. Crowdstrike, which claims it invented IoAs over a decade ago, said their tool doesn’t concern itself with malware or exploits, instead focusing solely on “real adversary behavior.”
CrowdStrike said AI-powered IoAs have identified over 20 novel adversary patterns “which have been validated by experts.” The new tool will be available on the CrowdStrike Falcon platform and is now generally available to Falcon Prevent and Falcon Insight customers.
As for Concentric, its tool is all about finding and cleaning up an organization’s data security posture, which it said has only become worse as messaging and communications tools have become more popular. The new module is available now for Semantic Intelligence customers with an enterprise license.
“Limited visibility into content, context and access routinely allows regulated personal information, critical business documents, and other sensitive data to fall into the wrong hands,” Concentric said.
Focusing on files shared via email and business messaging apps like Slack and Teams, Concentric said the tool examines where sensitive data is being shared and highlights who has inappropriate access. The tool’s AI capabilities, Concentric claims, allow it to identify sensitive and regulated data inside documents and remediate issues by disabling access, recalling messages and integrating into end-user and SOC workflows.
According to Concentric, the “staggering volumes” of data being exchanged among an organization and outside of it make automation “essential to any practical data security posture.” Marketing principles may apply.
CrowdStrike appears to agree, even going as far as to suggest it should be just one among many security tools an organization should deploy. “No security tool can detect every attack,” CrowdStrike said, citing a Forrester report. If more highly-specialized AI security tools like these emerge, diversification may not be an option. ®