Full Report
Browser extensions have extra capabilities compared to web pages but are still sandboxed from running full code on the system. Extensions have access to some extra APIs but it's still quite restrictive. Some domains and extensions have "special" privileges in the Opera browser, which is the focus of this research. For instance, the Pin add-on quickly takes a screenshot of the page but this requires extra permissions to do. The author decided to see if there were any domains in the list that were no longer registered to Opera. Several domains, such as crypto-corner.op-test.net, were found not to be registered, even though they had access to these APIs. So, the authors of the bought the domains to gain the special privileges that came with them. What can we do these with privileged APIs? The chrome.cookies API can be used to extract all session cookies and hijack user accounts. Additionally, the settingsPrivate allows for changing of various browser settings. An attacker can even change the DNS settings to create a Man in the Middle attack with this. Although, since most things use TLS, I'm not sure if this is very practical. Opera carefully reviews on extensions before adding them to the store. So, the authors were afraid of their bug report being vetoed for this reason. Instead, they found a workaround. Opera allows for Chrome extensions to be used! So, they wrote their proof of concept as a Chrome extension that another user would download. To remediate it, Opera did a few things. First, they removed content scripting on high-permission domains to prevent obfuscation I think. Next, they removed the privileges from some domains entirely. Overall, a fun vulnerability with some clever workarounds. Personally, I found that the article had a surprising order to me which confused me on my initial read though.
Analysis Summary
This summary is based *only* on the provided context, which is an introductory description of a vulnerability research finding and remediation steps, not the full technical report including CVE assignments.
# Vulnerability: Unsecured Domain Whitelisting Leading to Private API Hijacking in Opera Browser
## CVE Details
- CVE ID: Not explicitly mentioned in the provided context. (Likely assigned post-research, but not present here).
- CVSS Score: Not explicitly mentioned in the provided context.
- CWE: (Not explicitly mentioned, but relates to Improper Access Control or Improper Whitelisting)
## Affected Systems
- Products: Opera Browser
- Versions: Specific vulnerable versions are not detailed, implied to be versions active before remediation.
- Configurations: Installations where malicious extensions (potentially sourced from the Chrome Web Store) are loaded and run while the user is browsing content related to the compromised domains.
## Vulnerability Description
The Opera browser granted special privileges (access to sensitive **Private APIs**) to specific whitelisted domains. The research found that several domains on this privileged list were no longer registered to Opera (e.g., `crypto-corner.op-test.net`). Researchers purchased these domains, thereby inheriting the high-level permissions intended for Opera’s internal use.
These inherited permissions allowed a malicious actor (via a specially crafted browser extension) to use powerful APIs such as `chrome.cookies` to **steal all session cookies** (leading to account hijacking) and `settingsPrivate` to **modify browser settings**, including potentially corrupting DNS settings to facilitate Man-in-the-Middle attacks. Due to Opera's compatibility with Chrome extensions, the Proof of Concept (PoC) was deployed as a Chrome extension, enabling a cross-browser-store attack vector against Opera users.
## Exploitation
- Status: PoC available (The authors developed and used a proof of concept as a Chrome extension).
- Complexity: Medium (Required domain squatting/purchasing to gain the necessary privileges before deploying the extension).
- Attack Vector: Adjacent (Requires installation of a malicious extension, though the source leveraged the Chrome store, making the initial reach wide).
## Impact
- Confidentiality: High (Full session cookie theft allows for account hijacking).
- Integrity: High (Ability to change browser settings, including network configurations like DNS).
- Availability: Low (No direct impact on system availability mentioned, though setting changes can disrupt service).
## Remediation
### Patches
- Opera proactively removed content scripting privileges on high-permission domains.
- Opera entirely removed privileges that were associated with the compromised domains.
### Workarounds
- The research describes the authors' workaround to report the bug (using a Chrome extension) but does not list user-facing workarounds provided by Opera prior to final patching, other than the implied fix which removes the core issue.
## Detection
- Indicators of Compromise: Unexpected changes in browser settings, widespread session termination (if cookies are stolen and invalidated), or unusual network traffic originating from the browser process.
- Detection methods and tools: Not detailed, but typically involves runtime monitoring for API calls related to `chrome.cookies` or `settingsPrivate` from unverified sources/extensions.
## References
- Vendor advisory: Mentioned receipt of disclosure confirmation.
- Relevant links - defanged:
- [guard.io/labs/crossbarking-exploiting-a-0-day-opera-vulnerability-with-a-cross-browser-extension-store-attack](https://guard.io/labs/crossbarking-exploiting-a-0-day-opera-vulnerability-with-a-cross-browser-extension-store-attack)