How to rickroll Spotify for Android | Hacker News Reader

How to rickroll Spotify for Android

github.com

193 pointskjempelodott28 comments

Apart from being a very funny, this is a very nice MiTM "Hello World". A real-world application of something that is not very easy and straight forward. I remember trying to learn this stuff a few years ago and could never find a simple way of doing it.

Really great stuff.

This raises the question of: why is Spotify on HTTP for the first seconds? Would it be to bypass the TLS handshake, hence a faster "start" time? Wouldn't a constant connection (à la WebSocket with TLS) fix this?

I'm not sure if Spotify does this, my experience is mostly in video, but if some or all content is going to be encrypted, you start with a small http/unencrypted section and then get the license to play the encrypted part. This is because you can put the unencrypted section on a edge CDN but getting a license is going to have to go through a server that could have some significant time (say up to a couple of seconds depending). This makes it so you start right away (better UX).

I do have some experience in music, and this is likely for uncompressed or hidef playback. Some labels force encryption for hidef (but in general most of the music services stream straight progressive unencrypted even though their contracts require encryption in all cases).

Edit: but doing this is really tough. You're going to need to stitch together those two stream without a gap. This takes a lot of engineering. I've done this in flash and pure js. So this is not an arbitrary decision.

Couldn't the preview always end after N seconds, and the licensed stream always begin at the very next frame? Then it's just a matter of appending the licensed stream to the playback buffer after exhausting the preview stream.

Exactly. This is how you do it. But you'd be surprised how complicated this is.

They could still serve the first few seconds from a CDN at the edge via TLS.

My guess because it will save them a few $$$. Millions at stake here. Why would someone do a MITM attack against 5 secs of intro audio?

Obviously the NSA would.

Edit: exclusives. https://qz.com/949942/spotifys-new-deal-with-universal-gives...

Forget MITM, it also leaks information about your listening history which some may be uncomfortable with.

HTTP works in most places. When the music has started playing, the client can try other methods, versus waiting for a timeout.

HTTPS works in most places too.

Edit: the HTTP vs HTTPS is interesting. My guess is because it is slightly cheaper to use HTTP and they serve a fuck load of music. But this only saves you from MITM attacks. People can still grab music out of their cache. So confusing.

Maybe because of captive portals? Anyone connected to hotel wifi for example will just get an unresponsive application if it doesn't try to connect over http before switching to tls. Not sure Spotify should trust that connection as much as it appears to though.

Also, as long as it's only streaming audio over http (no auth details etc) the security risk is fairly low considering the added overhead, so it might not be a terrible decision.

It's pretty concerning whatever the reason is. Either it's worth encrypting the traffic or it isn't.

Is it really that concerning? What's the worst case scenario here? If the worst thing that can happen is you get served audio that you weren't expecting then I don't really see the big deal. I'm not immediately aware of any way that someone might use this as an attack vector, but then I'm not really a security guy..

If say, Spotify used a vulnerable audio decoder (or called into an OS one that was vulnerable), it could be used by an attacker to deploy an exploit against your device.

Now - is that very likely? Probably not, even if such a vulnerability exists modern exploit mitigation tactics often are able to prevent it from becoming very harmful. But it's worst case.

Android itself has had big media decode vulnerabilities in the past (looking at you libstagefright) but they basically turned out not to be readily exploitable due to ASLR on modern devices.

> Android itself has had big media decode vulnerabilities in the past (looking at you libstagefright) but they basically turned out not to be readily exploitable due to ASLR on modern devices.

That's what the optimist says.

The pessimist says, "Android itself has had big media decode vulnerabilities in the past and they only turned out not to be readily exploitable due to ASLR on modern devices".

Haha, yeah, I was actually sort of looking forward to the fallout from an MMS worm, brings back the good ol' days of Blaster and Sasser. Might have beat Android updates into shape too.

Unfortunately that dream never came to light.

iOS too: (these were just fixed, vs. the mid-2016 ones)

http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-2...

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-2462

Ok that makes sense, thanks!

Unless the encryption only exists due to a contractual obligation because "someone might steal it".

I would like to know why too. Perhaps the Spotify devs should look into another way to secure traffic if TLS adds too much latency (such as the noise protocol)?

I'm guessing a constant connection would use more battery/data?

AFAIK the Spotify apps already use a persistent connection to their messaging service to facilitate instant, cross-device changes when you do something like saving a track to your library.

or use of http2

Is the song information unencrypted? If so, it could be a loophole to sell customer data without their consent.

Tried this both on Android and iOS and can confirm that it works :)

I too feel that it's better to try alternate methods once the music starts playing

Can also be used to intercept Instagram images: http://imgur.com/3cYnSzl

Nice!

Reply on news.ycombinator.com