Zero-day used to infect Chrome users could pose threat to Edge and Safari users, too

A computer screen filled with ones and zeros also contains a Google logo and the word hacked.

A secretive seller of cyberattack software recently exploited a previously unknown Chrome vulnerability and two other zero-days in campaigns that covertly infected journalists and other targets with sophisticated spyware, security researchers said.

CVE-2022-2294, as the vulnerability is tracked, stems from memory corruption flaws in Web Real-Time Communications, an open source project that provides JavaScript programming interfaces to enable real-time voice, text, and video communications capabilities between web browsers and devices. Google patched the flaw on July 4 after researchers from security firm Avast privately notified the company it was being exploited in watering hole attacks, which infect targeted websites with malware in hopes of then infecting frequent users. Microsoft and Apple have since patched the same WebRTC flaw in their Edge and Safari browsers, respectively.

Avast said on Thursday that it uncovered multiple attack campaigns, each delivering the exploit in its own way to Chrome users in Lebanon, Turkey, Yemen, and Palestine. The watering hole sites were highly selective in choosing which visitors to infect. Once the watering hole sites successfully exploited the vulnerability, they used their access to install DevilsTongue, the name Microsoft gave last year to advanced malware sold by an Israel-based company named Candiru.

“In Lebanon, the attackers seem to have compromised a website used by employees of a news agency,” Avast researcher Jan Vojtěšek wrote. “We can’t say for sure what the attackers might have been after, however often the reason why attackers go after journalists is to spy on them and the stories they’re working on directly, or to get to their sources and gather compromising information and sensitive data they shared with the press.”

Vojtěšek said Candiru had been lying low following exposes published last July by Microsoft and CitizenLab. The researcher said the company reemerged from the shadows in March with an updated toolset. The watering hole site, which Avast didn’t identify, took pains not only in selecting only certain visitors to infect but also in preventing its precious zero-day vulnerabilities from being discovered by researchers or potential rival hackers.

Vojtěšek wrote:

Interestingly, the compromised website contained artifacts of persistent XSS attacks, with there being pages that contained calls to the Javascript function alert along with keywords like “test.” We suppose that this is how the attackers tested the XSS vulnerability, before ultimately exploiting it for real by injecting a piece of code that loads malicious Javascript from an attacker-controlled domain. This injected code was then responsible for routing the intended victims (and only the intended victims) to the exploit server, through several other attacker-controlled domains.

The malicious code injected into the compromised website, loading further Javascript from stylishblock[.]com
Enlarge / The malicious code injected into the compromised website, loading further Javascript from stylishblock[.]com

Once the victim gets to the exploit server, Candiru gathers more information. A profile of the victim’s browser, consisting of about 50 data points, is collected and sent to the attackers. The collected information includes the victim’s language, timezone, screen information, device type, browser plugins, referrer, device memory, cookie functionality, and more. We suppose this was done to further protect the exploit and make sure that it only gets delivered to the targeted victims. If the collected data satisfies the exploit server, it uses RSA-2048 to exchange an encryption key with the victim. This encryption key is used with AES-256-CBC to establish an encrypted channel through which the zero-day exploits get delivered to the victim. This encrypted channel is set up on top of TLS, effectively hiding the exploits even from those who would be decrypting the TLS session in order to capture plaintext HTTP traffic.

Despite the efforts to keep CVE-2022-2294 secret, Avast managed to recover the attack code, which exploited a heap overflow in WebRTC to execute malicious shellcode inside a renderer process. The recovery allowed Avast to identify the vulnerability and report it to developers so it could be fixed. The security firm was unable to obtain a separate zero-day exploit that was required so the first exploit could escape Chrome’s security sandbox. That means this second zero-day will live to fight another day.

Once DevilsTongue got installed, it attempted to elevate its system privileges by installing a Windows driver containing yet another unpatched vulnerability, bringing the number of zero-days exploited in this campaign to at least three. Once the unidentified driver was installed, DevilsTongue would exploit the security flaw to gain access to the kernel, the most sensitive part of any operating system. Security researchers call the technique BYOVD, short for “bring your own vulnerable driver.” It allows malware to defeat OS defenses since most drivers automatically have access to an OS kernel.

Avast has reported the flaw to the driver maker, but there’s no indication that a patch has been released. As of publication time, only Avast and one other antivirus engine detected the driver exploit.

Since both Google and Microsoft patched CVE-2022-2294 in early July, chances are good that most Chrome and Edge users are already protected. Apple, however, fixed the vulnerability on Wednesday, meaning Safari users should make sure their browsers are up to date.

“While there is no way for us to know for certain whether or not the WebRTC vulnerability was exploited by other groups as well, it is a possibility,” Vojtěšek wrote. “Sometimes zero-days get independently discovered by multiple groups, sometimes someone sells the same vulnerability/exploit to multiple groups, etc. But we have no indication that there is another group exploiting this same zero-day.”

Source

Leave a Reply

Your email address will not be published. Required fields are marked *