In the description of the attack, Zdrnya gives the following sequence of actions. After gaining access to the victim's computer, the attacker turns on developer mode in Google Chrome, which allows him to download the extension for him locally, rather than through the store. Thus, a malicious extension disguised as a plug-in of a security product is loaded into the browser.
In the code of the extension itself, the researcher describes a standard method for interacting with the Google cloud infrastructure, which allows arbitrary data to be "exchanged" between two browsers. That is, presumably the attack looked like this: we hack into the computer, install a malicious extension, authorize the browser under a one-time Google account. On the attacker's side, it is enough to log in under the same account to get data from the victim's computer.
What exactly was transferred in this way, the expert does not disclose, but indicates the limitations of the method: the maximum size of "keys" transmitted through the Google Chrome infrastructure cannot exceed 8 KB, and their maximum number is 512. That is, you can transfer 4 MB of data per session. ... This is enough to control the infected computer, as well as to transfer tokens to access corporate cloud services.
Zdrnya emphasizes that there was no other malicious software on the affected system. It will not work just like that to block access to the Google cloud infrastructure at the level of corporate network policies: not only the cloud is tied to them, but also, for example, checking the availability of network access in the browser. As a solution, the researcher proposes the application of policies prohibiting the installation of any extensions in the browser, except those marked in the white list. Such an original method of interacting with the attacked system can be overlooked for a long time - this will open the way for cybercriminals to access corporate data, which under normal conditions is accessible through a browser. In most cases, this can be corporate email, document collaboration tools, and much more.
What else happened
The story of the attack on information security experts (see the previous digest ) was continued. A zero-day vulnerability in the V8 engine was discovered and closed in the Google Chrome browser . Although the developers from Google do not comment on this, there is an assumption that the organizers of the attack used it. In addition, South Korean experts found another vector of the same attack: the victims were sent .mhtml files with malicious code exploiting a previously unknown vulnerability in Internet Explorer 11. The file allegedly contained information about a vulnerability in the Google Chrome 85 browser.
Netscout, citing Chinese researchers from Baidu Labs, is reporting a new method for amplifying a DDoS attack using an incorrectly configured Plex media server.
In the thread at the link above, a researcher under the nickname OverSoft talks about a poorly protected IP video camera with a people counting function. The story begins with a permanent WiFi network identifier and password, and it only gets sadder. Inside the camera, a Raspberry Pi Compute Module was found with the default pi user, documents left over from the developer (including an mp3 file) and a bunch of Python code. The result is a device that, in theory, connects to a corporate network with virtually unsecured WiFi and the ability to gain full access to an account with a standard password and maximum privileges.
Google Project Zero team publishesoverview of zero-day vulnerabilities used in real attacks last year. Of the 24 holes, eight use a new method of exploiting an already known problem. Conclusion: it is possible to complicate the life of attackers somewhat if vulnerabilities are closed after a detailed analysis of the cause so that the solved problem cannot be reopened.
More than a month ago, on January 4th, there was a major glitch in the Slack messenger. A detailed report was published on the results of the incident . The fall was due to a combination of reasons: on the first business day after the holidays in most countries, users loaded the infrastructure more than necessary, and the automatic capacity scaling tool in Amazon Web Services did not work as expected.
A study of the Kobalos malware for Linux systems reveals an unusual attack target: supercomputers.
A new example of an attack on the supply chain: Researchers from ESET found infected NoxPlayer software (emulation of Android applications) distributed directly from the developer's website.