Short.io takeover

[Philippe Delteil]

Service name

Short.io

Proof

dig target.tld

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52054
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;target.tld.		IN	A

;; ANSWER SECTION:
target.tld.	3600	IN	A	52.21.33.16
target.tld.	3600	IN	A	52.2.56.64

Documentation

https://help.short.io/en/articles/4065825-general-subdomain-setup-instruction

[Philippe Delteil]

I also added this template to nuclei.

[Andrii Kostenko]

Hi!

Thanks for checking for domain takeover - we are aware of this type of attack and prevent it from happening.

I'll share our checks:

1. If you connect a domain example.com to Short.io, noone can add example.com subdomain except you
2. You can not delete a domain in our system if it is still marked as configured. We require to disconnect the domain first. It is annoying for our users, but we take security seriously

There can be a corner case when user points DNS records to our IP and does not add a domain, but should be a deliberate action because we display configuration instruction after the user adds a domain in our system.

Also, there can be a corner case when a user adds a domain he does not control, but it does not pose a security risk, only prevents legitimate domain owner from using our service (and this problem is solved by our support engineers).

Feel free to tell us if you don't think these measures are enough

[<<"Spade">>]

Hi!

Thanks for checking for domain takeover - we are aware of this type of attack and prevent it from happening.

I'll share our checks:

1. If you connect a domain example.com to Short.io, noone can add example.com subdomain except you

2. You can not delete a domain in our system if it is still marked as configured. We require to disconnect the domain first. It is annoying for our users, but we take security seriously

There can be a corner case when user points DNS records to our IP and does not add a domain, but should be a deliberate action because we display configuration instruction after the user adds a domain in our system.

Also, there can be a corner case when a user adds a domain he does not control, but it does not pose a security risk, only prevents legitimate domain owner from using our service (and this problem is solved by our support engineers).

Feel free to tell us if you don't think these measures are enough

confirm, not vulnerable anymore.

[Andrii Kostenko]

Can you please update the Readme?

[Andrii Kostenko]

@EdOverflow can you please update details about our website?

[Philippe Delteil]

Hello there @gugu,

I can confirm this takeover is still possible.

[hlynurfrey001]

Hello there @gugu,

I can confirm this takeover is still possible.

How ??

[Andrii Kostenko]

Yes, more details will be helpful addition to your answer

[Philippe Delteil]

Hello there @gugu,
I can confirm this takeover is still possible.

How ??

Adding a custom domain discovered with the template. Test it yourself.

[Philippe Delteil]

Yes, more details will be helpful addition to your answer

where can I send you a report? BBH? 🤣

[hlynurfrey001]

Yes, more details will be helpful addition to your answer

where can I send you a report? BBH? 🤣

At mail [e-mail]

[hlynurfrey001]

a custom domain discovered with the template. Test it you

what do you mean ?