High-Impact Subdomain Takeover

hiddeco commented 1 year ago

Report

:warning: reported via security@weave.works on January 18...

Describe

High-Impact Subdomain Takeover

FQDN: wkp.weave.works
IP address: 13.49.241.153

Overview of the Vulnerability

A subdomain takeover is when a misconfigured Domain Name System (DNS) record is re-registered to an endpoint owned by an attacker. An attacker is then able to redirect users to the endpoint and capture data such as cookies and credentials, perform Cross-Site Scripting (XSS) attacks, and potentially take over accounts in the legitimate application.

A high-impact subdomain takeover vulnerability was identified which could impact the reputation and brand of the business. An attacker can register a subdomain on behalf of the target domain and use it to create a HTML document with JavaScript payload that triggers a Cross-Site Scripting (XSS) attack. The target domain can also be used to create a scenario where an attacker can harvest user credentials by phishing users who then visit and login on a cloned version of a legitimate website.

You could imagine an attacker creating any sort of website using this subdomain, including phishing sites, ransomware attacks, hosting malware, distributing porn or illegal content such as copyrighted materials. You could also imagine an attacker creating any number of other NFT or DeFi scam web pages, all under your company banner.

Business Impact

High-Impact subdomain takeover could lead to data theft and indirect financial loss through the attacker’s ability to interact with legitimate users. These malicious actions could also result in reputational damage for the business through the impact to customers’ trust.

Steps to Reproduce

    Browse to the URL https://wkp.weave.works/proof.txt
    You will see my name
    Browse to the URL https://weave.works/ and login
    Browse to the URL https://wkp.weave.works/cookie-thief.php
    You will see the cookies an attacker could steal, and possibly use to compromise an account
    Click the COOKIE BOMB button
    Browse to the URL https://weave.works/
    You will receive an error and not be able to access this site or anything related until you clear your cookies, resulting in DoS

References

https://groups.google.com/a/weave.works/g/security/c/x3mMxh_nEhk

Handling

If you are reporting a potential vulnerability, you could ignore this section. It is intended to be managed by a Vulnerability Manager

[ ] Reporter notifies Weaveworks team (Receiver) about a potential vulnerability via any of the Security Vulnerability Sources. Receiver acknowledges it. If likely to be a legitimate request, Receiver creates a private issue of type CVE in https://github.com/weaveworks/weave-gitops-private to start the formal intake.
[ ] Vulnerability Manager triages the request to either accept or rejects it:
[ ] In case of accepted, Vulnerability Manager starts the coordination of the vulnerability based on the created issue. The vulnerability is treated as highest priority and directed to the respective Product Team.
[ ] In case of rejected, if needed, a response to Reporter is provided about the rejection and the process terminates.
[ ] Product Team evaluates the vulnerability with help from Vulnerability Manager. The evaluation should include which products and versions are affected.
[ ] If the vulnerability does not pose a threat to the product or service, Vulnerability Manager responds back to the Reporter with proper reasoning.
[ ] If the reported request is considered a vulnerability, Vulnerability Manager responds back to the Reporter, accepting the issue. Vulnerability Manager communicates and coordinates to the rest of internal stakeholders. Vulnerability Manager engages with CX to start the discovery of customers being affected.
[ ] Product team provides a workaround, Vulnerability Manager makes it available to the Reporter and notifies CX. CX manages with customers the workaround.
[ ] Product Team works to identify a fix and produce a time estimation (ETA) to create the fix for the product or service.
[ ] Vulnerability Manager adds a 4 weeks buffer to the ETA. This date becomes the public announcement date.
[ ] Vulnerability Manager e notifies the Reporter of the public announcement date. Vulnerability Manager asks the Reporter if they want to be credited. A Public Security Advisory will be issued accordingly.
[ ] Vulnerability Manager creates a Private Security Advisory for the vulnerability, including the impact, and any available mitigations. It would be created using this template. An example of a Security Advisory is CVE-1126.
[ ] CX would announce with customers the vulnerability sharing the Security Advisory.
[ ] Product Team delivers the fix and communicates to Vulnerability Manager. Vulnerability Manager provides it to the Reporter and all affected customers via CX. CX manages the application of the fix on the customer side.
[ ] A Public Security Advisory will be issued after all the fixes are issued to the customers and the public announcement date has been reached.

lizwarner-weave commented 1 year ago

@morancj is investigating