Hacker News Reader

Comment by simonw | Hacker News Reader

"the process started by purchasing stolen cookies being sold online for $10"

Anyone know the details of how this actually works? Does it mean browser cookies? How do cookies end up being sold in this way?

View on HN

Slack authentication works like many other web applications and once you've successfully authenticated you get a cookie which can be used to read/send messages on your behalf.

If someone managed to get some malware running on a machine where you have logged into slack it's fairly trivial for someone to get your cookie. Something like https://github.com/djhohnstein/SharpChromium is an example of a tool used to pull browser cookies off a compromised host.

I don't know the explicit details of this particular instance, but I imagine the user in question had some kind of malware installed on their phone or computer. ( I keep seeing mention of a browser extension in the comments, and I have seen some working examples of malicious chrome extensions recently that would let you steal cookies once installed.)

PhantomBuster makes you fork over your Slack cookie in order to use it. Could easily be that or something similar.

This would be my guess too. I’d expect common sources to include scraping services (like phantombuster, but also lower-level infrastructure like proxies) and browser extensions.

Wouldn't proxies have to execute a TLS stripping attack to make this work? Those may have been common in the past, but I'd have to imagine it would be hard to make work against the modern Slack website/desktop app

Not if the proxies are for some janky scraping script or .NET application that ignores certificate warnings.

I don’t know for sure, however I presume if you have a compromised browser extension or malware on your device then the cookie can be extracted. And then they’re sold on marketplaces for black hats.

I would guess an EA employee or contractor device had a bot installed that was harvesting data (e.g., cookies). Check out this article on how Genesis Market allows bot herders to monetize this data : https://www.f5.com/labs/articles/threat-intelligence/genesis...

I see browser extensions mentioned. Maybe Tor exit nodes as well? Or a compromised corporate MITM proxy...that would be funny.

Shouldn’t be possible with ssl

In the context of a "MITM proxy" it certainly is.

How would a mitm proxy have a valid certificate for slack.com?

> a compromised corporate MITM proxy

A corporate MITM proxy does has it own certificate authority, or else it wouldn't be able to monitor its traffic like it's expected to do.

Doesn’t certificate pinning break these?

It does, but HPKP is effectively dead, removed from most browsers.

So I could take the cookies from my browser, send them to a friend, and my friend could then save the files and use the cookies? There’s no process to verify it’s being used in the same browser or computer?

There should be. You can't guarantee it will always work, but it's certainly possible to encode some fingerprinting into the cookie so that if the fingerprinting no longer matches what the client requesting data from the server looks like, the server throws up a red flag and asks for the authentication challenge response to be repeated.

But no, it sounds like Slack doesn't do that, which is a problem.

Security I implemented in the 90's: Encode the client IP address into the cookie.

Also include a timestamp to force re-authentication at some point.

This isn't rocket science.

Wouldn't the cookie then be invalidated if you e.g. switched between WiFi and cellular on mobile?

Yes, it would be invalidated. This would not work well on roaming devices.

And now as I connect between ipv4 to v6, connect to my VPN, switch from wifi to mobile data each change requires a login and I very quickly abandon your app for one that doesn’t force multiple authentications throughout the day.

Not only that. I tried the same approach, but one of our clients has some kind of VPN and the user’s IP address would change regularly.

Good luck with that on mobile.

Until CGNAT cripples your concept.

Devices are much more portable since the 90s and are likely to change networks frequently.

This is non-trivial to do without gathering more info about someone's browser than users would be comfortable with (aka fingerprinting). Ideally, a website/app knows nothing about the machine it's running on and is perfectly sandboxed away from everything else.

A private key shouldn't be device dependent. 2FA was the solution here, but was not enforced properly. They were able to social engineer IT into resetting their 2FA token without any proof they were who they said.

The IP is something someone isn't comfortable with? It seems to be quite trivial to include the IP in the cookie/session and verify it's the right one.

Sure it's not perfect in a world where IP are not necessarily static (and a VPN may change it), but having to login again is not that bad, even more so if you are using SSO.

> The IP is something someone isn't comfortable with?

No good. Slack's biggest userbase is corporate, behind corporate VPNs. Many users have the same IP.

Still seems reasonable for preventing an outside attack though.

It can help, for sure. I think the main reason it typically isn't enabled in general is that it's pretty common nowadays for people to switch IPs regularly. It'd be annoying to have to re-login to Slack multiple times per day as you move around with your phone or take your laptop to different places.

(Especially if it's a user who isn't in a corporate environment, where your public IP will probably differ when you connect to different wireless networks. On a corporate network you're more likely to retain the same public IP no matter which room or building you're in.)

If they don't, they should provide an option for corporate administrators to enable IP locking for session cookies.

When I commuted to the office my IP would change multiple times as I crossed from 4G to various WiFis. It would be really annoying to have to log in each time.

This is why pinning user sessions to IPs isn't going to work - in a mobile first world most users have multiple IPs that they might access a service from during the course of a day.

Logging people out also isn't a minor inconvenience, especially for users who haven't figured out password managers yet.

It would be annoying even with a password manager. Most people are going to care a lot more about that multiple times a day inconvenience than the fact that it’s protecting security. On iPhone it is more than the steps of authorizing password manager and having them auto filled. You’ll have to click yes and possibly something else to have touch or Face ID to be activated again.

I know this isn’t actually a major thing. It’s a 20 second process. Still a couple times a day is a couple times a day.

On underground forums you can buy a plethora of compromised accounts from an individual's computer and saved passwords for about this much money.

No idea in this instance, but it's trivial for rogue browser extensions to siphon off cookies

That's the real hack here.

Just ask the girl scouts in your area.

Reply on news.ycombinator.com