Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pingdom.com Services Are Also Possible To Be Claimed. #144

Open
GDATTACKER-RESEARCHER opened this issue Apr 17, 2020 · 4 comments
Open

Pingdom.com Services Are Also Possible To Be Claimed. #144

GDATTACKER-RESEARCHER opened this issue Apr 17, 2020 · 4 comments
Labels
vulnerable Someone has provided proof in the issue ticket that one can hijack subdomains on this service.

Comments

@GDATTACKER-RESEARCHER
Copy link

Service name

Pingdom.com

Proof

https://youtu.be/VuIO1l5RL8k

Documentation

https://help.pingdom.com/hc/en-us/articles/205386171-Public-Status-Page

@janmasarik
Copy link
Contributor

janmasarik commented Oct 9, 2020

@adiffpirate I believe @manasmbellani is right with his signature in subjack.

I did a test with following test cases when I enable public dashboard to stats.masarik.sh (takeoverable cases bold):

  1. Enabled, but don't have any checks enabled. This responds with Public Report Not Activated (fingerprint introduced in New services #159), but it's a false positive as you cannot claim the dashboard with another account. Attempt to do so results in 500: Server Error in the pingdom UI (doesn't seem they check for this on purpose, but it seems secure 🙃)
    image

  2. Enable, with any check enabled. This results in expected state (dashboard shows up), and nobody can takeover it as long as your account is active.
    image

  3. Disable account that had public dashboard enabled. This opens a space for takeover as long as target's CNAME remains pointing to stats.pingdom.com. This works regardless if the dashboard had or hadn't checks enabled before.
    image

  4. Change domain name of public dashboard. This opens a space for takeover as long as target's CNAME remains pointing to stats.pingdom.com.
    image

  5. Point CNAME to stats.pingdom.com, but don't enable it in pingdom. As expected, this opens a space for takeover too (with same response as above.

As far as I can tell, #159 is addressing the false positive case of 1, and we need to address 3, 4 and 5 instead. Or did you have a different example that would allow to takeover This public report page has not been activated by the user cases @adiffpirate?

If you want a robust mechanism that errs on the false positive side, you could check for 404 instead. Both cases return 404, and it's a bit more probable that it will continue to work even if they change wording.

@adiffpirate
Copy link
Contributor

@janmasarik Wow, really nice work testing/documenting that. I created the PR based solely on what I saw at the proof video and the error page that shows up there.

Thank you for going the extra mile. I'm gonna create another PR later and update the fingerprint (or you can do that if you wanna) 😊

janmasarik added a commit to janmasarik/can-i-take-over-xyz that referenced this issue Oct 9, 2020
@janmasarik
Copy link
Contributor

Happy to help @adiffpirate! I've went ahead and made #178 to address this. :-)

@jleuth
Copy link

jleuth commented Nov 9, 2023

Supposedly, as of at least October (but possibly before that), this no longer works. could someone please check?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
vulnerable Someone has provided proof in the issue ticket that one can hijack subdomains on this service.
Projects
None yet
Development

No branches or pull requests

5 participants