The major attack vectors on this sensitive data are identified and mapped.In response to our reported vulnerabilities, indicates that it will not fix the product to protect against attacks carried out by a program running locally on the endpoint.Weaknesses in the protection of this information in Chromium-based browsers have been known for many years, and attack tools have been published that demonstrate how the information can be stolen.This information is a prime target of malicious credential stealers. Sensitive information (passwords, session-cookies, etc.) is processed and stored by browsers.Hence this blog, in which I try to map the known attack vectors on sensitive data in Chromium-based browsers, propose mitigations for these attack vectors, and demonstrate how some of these mitigations already work in at least one security application (CyberArk Endpoint Privilege Manager). Wake up! We are the defense team! GO BLUE! I felt our job was to identify malicious attack vectors and block them before the bad guys do, and a cry was welling up inside me: Naturally, I was disappointed, but to be completely frank – I was also frustrated! We work in a cybersecurity company, and we all embrace the “assume breach” paradigm. When I showed this work to some of the experienced security researchers on my team, the general reaction was that it is not very interesting, since there are other known methods to get the same information. Google’s response to the responsible disclosure was discouraging, stating “Won’t Fix” since “there is no way for Chrome (or any application) to defend against a malicious user who has managed to log into your device as you” ( here). In my previous blog post ( here), I described a technique to extract sensitive data (passwords, cookies) directly from the memory of a Chromium-based browser’s process.
0 kommentar(er)
