

Bit.ly exploit to brand your short url - mayanks

I don't know if someone has observed this, but if I append any random sub domain name, to a shortened url from bit.ly, it still takes me to the correct url.<p>For example, I picked up this from techrunch's tweet http://bit.ly/12V9c1. I could also create a link called http://mayanks.bit.ly/12V9c1 and it would still take me to techcrunch's site. So I get to brand my own short url.<p>Is this an undocumented feature or something is wrong here?
======
brk
It's likely just a DNS wildcard setting that resolves everything to the same
server.

Not an uncommon practice, and helps ensure that things like the random typo of
ww.site.com by a user still gets them to where they were expecting to go.

So my guess is that it's not an undocumented feature but more of a clever hack
that exploits something that was done for an entirely different, but closely
related, purpose.

~~~
mayanks
I have seen links like <http://om.bit.ly/xyz> on twitter. In a recent bit.ly's
blog I've seen announcement about cbs.bit.ly. So I don't think it is just a
plain DNS wildcard. This must have been an intended feature but looks like its
not completely intended.

For example in case of cbs.bit.ly only links shortened by cbs should be valid.
But try it out any bit.ly shortened link works with cbs. subdomain as well.

~~~
brk
It looks like they are doing DNS wildcarding and basic round-robin DNS-based
load balancing.

My guess would be that for particular subdomains (om, cbs, etc.) they may be
offering some stats on clicks, referrers, etc., so that those users can better
track that sort of stuff.

But, the easiest way to manage this DNS-wise is to use wildcards. The side
effect is that any subdomain becomes valid, but that's usually no issue.

\------------------------------------------------

brks-macbook-pro:Downloads brk$ ping om.bit.ly

PING om.bit.ly (128.121.254.129): 56 data bytes 64 bytes from 128.121.254.129:
icmp_seq=0 ttl=57 time=69.395 ms 64 bytes from 128.121.254.129: icmp_seq=1
ttl=57 time=69.584 ms ^C

\--- om.bit.ly ping statistics --- 2 packets transmitted, 2 packets received,
0% packet loss round-trip min/avg/max/stddev = 69.395/69.489/69.584/0.095 ms

brks-macbook-pro:Downloads brk$ ping cbs.bit.ly

PING cbs.bit.ly (168.143.174.25): 56 data bytes 64 bytes from 168.143.174.25:
icmp_seq=0 ttl=57 time=69.898 ms 64 bytes from 168.143.174.25: icmp_seq=1
ttl=57 time=69.625 ms 64 bytes from 168.143.174.25: icmp_seq=2 ttl=57
time=69.815 ms ^C

\--- cbs.bit.ly ping statistics --- 3 packets transmitted, 3 packets received,
0% packet loss round-trip min/avg/max/stddev = 69.625/69.779/69.898/0.114 ms

brks-macbook-pro:Downloads brk$ ping foo.bit.ly

PING foo.bit.ly (128.121.254.129): 56 data bytes 64 bytes from
128.121.254.129: icmp_seq=0 ttl=57 time=70.048 ms 64 bytes from
128.121.254.129: icmp_seq=1 ttl=57 time=69.509 ms 64 bytes from
128.121.254.129: icmp_seq=2 ttl=57 time=70.003 ms ^C

\--- foo.bit.ly ping statistics ---

3 packets transmitted, 3 packets received, 0% packet loss round-trip
min/avg/max/stddev = 69.509/69.853/70.048/0.244 ms

brks-macbook-pro:Downloads brk$ ping brk.bit.ly

PING brk.bit.ly (168.143.174.25): 56 data bytes 64 bytes from 168.143.174.25:
icmp_seq=0 ttl=57 time=69.191 ms 64 bytes from 168.143.174.25: icmp_seq=1
ttl=57 time=69.489 ms 64 bytes from 168.143.174.25: icmp_seq=2 ttl=57
time=72.154 ms ^C

\--- brk.bit.ly ping statistics ---

3 packets transmitted, 3 packets received, 0% packet loss round-trip
min/avg/max/stddev = 69.191/70.278/72.154/1.332 ms

brks-macbook-pro:Downloads brk$ ping 123.bit.ly

PING 123.bit.ly (128.121.254.201): 56 data bytes 64 bytes from
128.121.254.201: icmp_seq=0 ttl=57 time=69.376 ms 64 bytes from
128.121.254.201: icmp_seq=1 ttl=57 time=70.049 ms 64 bytes from
128.121.254.201: icmp_seq=2 ttl=57 time=75.750 ms ^C

\--- 123.bit.ly ping statistics ---

3 packets transmitted, 3 packets received, 0% packet loss round-trip
min/avg/max/stddev = 69.376/71.725/75.750/2.859 ms

brks-macbook-pro:Downloads brk$ ping 456.bit.ly

PING 456.bit.ly (168.143.174.25): 56 data bytes 64 bytes from 168.143.174.25:
icmp_seq=0 ttl=57 time=69.185 ms 64 bytes from 168.143.174.25: icmp_seq=1
ttl=57 time=69.917 ms 64 bytes from 168.143.174.25: icmp_seq=2 ttl=57
time=69.663 ms ^C

\--- 456.bit.ly ping statistics ---

3 packets transmitted, 3 packets received, 0% packet loss round-trip
min/avg/max/stddev = 69.185/69.588/69.917/0.303 ms brks-macbook-pro:Downloads
brk$

\------------------------------------------------

Also, sub-sub-domains work:

brks-macbook-pro:Downloads brk$ ping ntr.brk.bit.ly

PING ntr.brk.bit.ly (168.143.174.29): 56 data bytes 64 bytes from
168.143.174.29: icmp_seq=0 ttl=57 time=70.208 ms 64 bytes from 168.143.174.29:
icmp_seq=1 ttl=57 time=68.510 ms

<http://ntr.brk.bit.ly/xyz>

~~~
mayanks
Thanks for the quick lookup. I did some dig on some sub-domains as well.
Indeed looks like they have a wild card for sub-domain mapping.

I wonder then what is the extra advantage/feature that om and cbs are getting.
Anyone can brand their bit.ly shortened url with or without bit.ly's consent

------
pplante
Didn't see it mentioned already, but <username>.bit.ly redirects to
bit.ly/user/recent/<username>. So "pplante.bit.ly" redirects to
"bit.ly/user/recent/pplante" which contains the list of my recent shortenings.

This must be an undocumented feature to allow user accounts to brand their
links if desired, since it redirects to the account's recent list. I am
curious if many twitter clients would properly recognize "<user>.bit.ly/xyz"
as a shortened url and try to expand it via the API, my guess is a few out
there might see this as a long url and try shortening it again. What a
unforeseen mess that would cause.

~~~
mayanks
twitterfox that I use as my twitter client does not recognize
"<user>.bit.ly/xyz".

If it is an undocumented feature, it is susceptible to link hijacking. I can
take a url shortened by you (pplante) and brand it as my own
mayank.bit.ly/xyz. That will not be cool...

------
onreact-com
Is it a bug or a feature?

~~~
billpg
URL shorteners in general or this specific observation?

~~~
onreact-com
The specific one of course ;-)

