6 ms·

> A representative for the hackers told Motherboard in an online chat that the process started by purchasing stolen cookies being sold online for $10 and using

> A representative for the hackers told Motherboard in an online chat that the process started by purchasing stolen cookies being sold online for $10 and using those to gain access to a Slack channel used by EA. How much to bet that a browser extension was involved? Man, the whole landscape is the new "Download this shareware EXE file" but with a thin veneer of legitimacy "It's hosted by Google/Mozilla/Microsoft, it can't be bad!".

SV_BubbleTime 5y ago
I have no idea at all, but I would assume that browser extensions are not just an exe with unlimited ability to run arbitrary code, but rather I would think they are sandboxed to have limited scope... right?
- pkulak 5y ago
  They aren't sandboxed at all. Almost all of them request full access to every page you visit. At least an exe might not be able to view and manipulate the dom inside your browser.
  - tomjakubowski 5y ago
    If the extensions have to request permissions for "full access" to the page, doesn't that mean they're sandboxed?
    - pkulak 5y ago
      It doesn't, in practice, if they all ask for it and people are conditioned to always grant it.
  - shadowgovt 5y ago
    This is semi-correct, but basically leans in the right direction. A bit more detail: browser extensions have all manner of permissions and authorizations, generally specified in the manifest file. A lack of permissions translates to constraints on the extension (often in the form of the browser refraining from populating one of the `window` child objects in the context of that extension's JS code). Users downloading extensions can see what the extension is authorized to do. Problem is that much like the security ecosystem for mobile apps, end-users have no idea what any of those permissions mean and lack the technical competency (on average) to determine whether a given permission is high-risk or low-risk (how many end-users even know what CORS or XSRF are, let alone why they matter?). Plus, some of the manifest permissions are basically "keys to the kingdom"-level open permission that allow arbitrary behavior within the limits of the browser sandbox itself. One of the reasons Google is changing permissions in Manifest v3 (as discussed here: https://news.ycombinator.com/item?id=27441898 https://news.ycombinator.com/item?id=27441898) is to nerf some of those permissions (in particular, the Manifest V2 scripting permissions allow an extension's behavior to change by changing some script on a remote site, so an extension that was well-behaved when added to the Chrome Web Store can have its backing server changed or compromised later and become an attack vector).
    - btown 5y ago
      Even with Manifest v3, if you suddenly have access to a browser extension (say, you bought the company making it) with global "inject a known content script that's been vetted by the Web Store and included in the extension bundle" permissions... it's possible to add obfuscated code in that content script that provides RCE on the page to the attacker. Imagine something like a modified form of jQuery that adds and immediately removes a script tag when provided specific inputs - inputs that would be expected to be controlled by the results of a web-based JSON endpoint that's core to the extension's functionality. Is the web store going to code review an entire minified jQuery? Can an automated system detect it? What if attackers hired someone who won IOCCC? The attackers have the upper hand here and can pull the trigger on any website they choose. Which is why Google might say Manifest v3 is all about security, but unless attackers get lazy and let their injectors get fingerprinted, it's all just airport-style security theater... that happens to strangle ad blockers... At any rate, cookies and other methods of XSS will begin to leak more and more, and defense in depth will become the paradigm of the day. Assume your employees' browsers are compromised and plan accordingly.
      - shadowgovt 5y ago
        That's the thing though... 90% of attackers are bad at their job. Even if it traps mostly people who aren't investing IOCCC levels of cleverness into the problem or buying companies for the purpose of getting malicious extensions into the Chrome web store, it makes the system safer for the average user. Certainly safer than the system is if any script kiddie can just use the manifest V2 permissions to turn a clock app into a keylogger. And if the model is as breakable as you claim, I don't worry about the fate of ad blockers.. after all, nothing prevents them from using the exploit you just described, right? Use a modified jQuery to add and remove a script tag to figure out what needs to be blocked?
        btown 5y ago
        As far as I can tell, you could, and will still be able to, make ads invisible based on dynamic data, but under Manifest v3 you would not be able to prevent the ads from downloading (and sharing private information, including your FLOC cohorts) based on dynamic heuristics, because Manifest v3 makes it impossible to use anything other than a simple, limited-length blocklist to prevent a network request from being made. See: https://developer.chrome.com/docs/extensions/mv3/intro/mv3-overview/#network-request-modification https://developer.chrome.com/docs/extensions/mv3/intro/mv3-o... It's a decrease in privacy being sold as an improvement in security and performance. Could they have instead implemented a persistent super-sandbox for network-blocking heuristic code that addresses the performance and security issues, while still enabling dynamic network blocking? Probably! But why would they, when the primary use case is heuristic-based ad blocking? And I suppose you're right - part of any defense in depth is reducing the number of first-level successes. And it's very possible it was script kiddies who sold the cookies to the actual attackers in the EA case. But there's more going on here than just security.
asddubs 5y ago
reminds me of the good old days when httponly didn't exist and basically every website was vulnerable to xss somewhere.

SV_BubbleTime 5y ago

I have no idea at all, but I would assume that browser extensions are not just an exe with unlimited ability to run arbitrary code, but rather I would think they are sandboxed to have limited scope... right?

pkulak 5y ago
They aren't sandboxed at all. Almost all of them request full access to every page you visit. At least an exe might not be able to view and manipulate the dom inside your browser.
- tomjakubowski 5y ago
  If the extensions have to request permissions for "full access" to the page, doesn't that mean they're sandboxed?
  - pkulak 5y ago
    It doesn't, in practice, if they all ask for it and people are conditioned to always grant it.
- shadowgovt 5y ago
  This is semi-correct, but basically leans in the right direction. A bit more detail: browser extensions have all manner of permissions and authorizations, generally specified in the manifest file. A lack of permissions translates to constraints on the extension (often in the form of the browser refraining from populating one of the `window` child objects in the context of that extension's JS code). Users downloading extensions can see what the extension is authorized to do. Problem is that much like the security ecosystem for mobile apps, end-users have no idea what any of those permissions mean and lack the technical competency (on average) to determine whether a given permission is high-risk or low-risk (how many end-users even know what CORS or XSRF are, let alone why they matter?). Plus, some of the manifest permissions are basically "keys to the kingdom"-level open permission that allow arbitrary behavior within the limits of the browser sandbox itself. One of the reasons Google is changing permissions in Manifest v3 (as discussed here: https://news.ycombinator.com/item?id=27441898 https://news.ycombinator.com/item?id=27441898) is to nerf some of those permissions (in particular, the Manifest V2 scripting permissions allow an extension's behavior to change by changing some script on a remote site, so an extension that was well-behaved when added to the Chrome Web Store can have its backing server changed or compromised later and become an attack vector).
  - btown 5y ago
    Even with Manifest v3, if you suddenly have access to a browser extension (say, you bought the company making it) with global "inject a known content script that's been vetted by the Web Store and included in the extension bundle" permissions... it's possible to add obfuscated code in that content script that provides RCE on the page to the attacker. Imagine something like a modified form of jQuery that adds and immediately removes a script tag when provided specific inputs - inputs that would be expected to be controlled by the results of a web-based JSON endpoint that's core to the extension's functionality. Is the web store going to code review an entire minified jQuery? Can an automated system detect it? What if attackers hired someone who won IOCCC? The attackers have the upper hand here and can pull the trigger on any website they choose. Which is why Google might say Manifest v3 is all about security, but unless attackers get lazy and let their injectors get fingerprinted, it's all just airport-style security theater... that happens to strangle ad blockers... At any rate, cookies and other methods of XSS will begin to leak more and more, and defense in depth will become the paradigm of the day. Assume your employees' browsers are compromised and plan accordingly.
    - shadowgovt 5y ago
      That's the thing though... 90% of attackers are bad at their job. Even if it traps mostly people who aren't investing IOCCC levels of cleverness into the problem or buying companies for the purpose of getting malicious extensions into the Chrome web store, it makes the system safer for the average user. Certainly safer than the system is if any script kiddie can just use the manifest V2 permissions to turn a clock app into a keylogger. And if the model is as breakable as you claim, I don't worry about the fate of ad blockers.. after all, nothing prevents them from using the exploit you just described, right? Use a modified jQuery to add and remove a script tag to figure out what needs to be blocked?
      - btown 5y ago
        As far as I can tell, you could, and will still be able to, make ads invisible based on dynamic data, but under Manifest v3 you would not be able to prevent the ads from downloading (and sharing private information, including your FLOC cohorts) based on dynamic heuristics, because Manifest v3 makes it impossible to use anything other than a simple, limited-length blocklist to prevent a network request from being made. See: https://developer.chrome.com/docs/extensions/mv3/intro/mv3-overview/#network-request-modification https://developer.chrome.com/docs/extensions/mv3/intro/mv3-o... It's a decrease in privacy being sold as an improvement in security and performance. Could they have instead implemented a persistent super-sandbox for network-blocking heuristic code that addresses the performance and security issues, while still enabling dynamic network blocking? Probably! But why would they, when the primary use case is heuristic-based ad blocking? And I suppose you're right - part of any defense in depth is reducing the number of first-level successes. And it's very possible it was script kiddies who sold the cookies to the actual attackers in the EA case. But there's more going on here than just security.

asddubs 5y ago

reminds me of the good old days when httponly didn't exist and basically every website was vulnerable to xss somewhere.