Yea, I think most users think slack is a safe space. They haven't been conditioned to be suspicious of messages on slack like they have with email. It's a pretty ripe attack vector.

Was bored the other week and found a ton of slack web hook urls in public github repos. I think it would be a pretty great way to do some phishing, just need to scrape the urls and brute force channel names with messages with links to websites you own.

I think it's actually a pretty unsurprising assumption. Slack is significantly more vulnerable service than a lot of other chat applications due to the fact that it has a native webclient that allows cookie based authentication. Every chat program in existence is going to use something extremely similar to maintain user sessions - having either authentication credentials or (preferably) an access token written to disk to allow users to avoid re-entering passwords every time the program falls out of memory.

I think with slack the danger is exacerbated by the fact that this value gets stored in a cookie that is a lot easier to gain access to - and, once you have it it has a much better documented format than whatever MSN Messanger might roll in-house. We're essentially just talking about an added layer of security by obscurity when it comes to the format - but actually nabbing a cookie is easier than gaining arbitrary file access.

Modern web doesn’t need cookie auth so let’s hope they move away from it. Cookies in general are an idea past expiration date.

It's the same old same old. Like you correctly identified it's a new place, it looks different. People don't think an attacker could approach them over IM, but they can.

But the problem goes beyond that. Many organizations have disabled sharing executable file formats in attachments over e-mail. GMail flat-out prevents you from sharing executables, and macro enabled word documents as attachments, even when put into a zip file.

But on Microsoft teams? I sent a zip file with 8 unsigned executables to a colleague a few days ago. No warnings, no messages, no nothing :)

For general public I can see how that is helpful if they can't decide if a foreign executable is trust worthy or if they execute everything with admin/root privilege.

As for me, I really hate this "feature". I work with IHVs and often have to share private binaries and it's a chore using xcopy/sfpcopy to their bespoke network path, from where I guess then someone manually copies over to their local subnet.

We should have a more robust mechanism in place than to outright ban sharing of executable files. Windows Smartscreen and Mac's Gatekeeper method of online checksum/signature verification is sort of interesting.

1000 times no.

You need to build security for the lowest common denominator.

Which is what Defender smartscreen and Gatekeeper are. With their full on setting, they give you a big fat warning on running files from internet.

This is like banning guns and cars because they can kill people.

Also, you do 24 hours of lemons?

I don't know if it's true, but a co-worker of mine said that, "in the wild" signed binaries are positively correlated with being malware.

I don't think the signing itself does much.

Perhaps not in itself. The lack of scans is concerning though

Signed by real vendors?

Depends what you mean by that, but probably not. But, signed definitely. The main problem here is that there doesn't seem to be an authoritative vendor list of the "real".

The thing is you need MFA to log into Slack but having a valid cookie bypass that.

On top of that once you're in Slack you can access every public channel, search string etc ... I can tell you that large compagny have a lot of thing displayed on Slack ( CI/CD pipelines results, credentials in logs, alerts ect ... ) you don't even need to talk to someone to have a lot of info.

I work with a large enterprise company that is actively thinking about this problem within their organization. The long and short of it is that everything in Slack is ephemeral past a month or so. Everything gets wiped on a rolling basis, including all media and messages.

If you want some domain to be documented, it happens outside of Slack. Secrets go in a dedicated secret management resource that requires 2FA for every login with strict timeouts and audits.

For the team I work on, this means piling more crap in Jira and Confluence. If a decision is made over Slack, that decision is then codified in a ticket or in a Confluence document. This also means some people constantly send links to the same confluence pages over and over again since there's no history for someone to search through.

I think overall it's a decent solution if you're diligent managing the tradeoffs. I can't really think of a better way to keep things off of a platform where they shouldn't exist, other than taking the nuclear option like they're doing now (albeit with a generous countdown timer).

I don't see how the policies you described would help at all in this situation. The main use of Slack here was to get the one-time-pass, which allowed them to login to the corporate network.

If they did this in your company, then all they'd have to do is scan through the Slack channels till they found a link to the internal company Jira and Confluence sites and then they'd have free reign to start mapping out your network and prepare for an attack.

I think an effective mitigation that could be implemented on the Slack side would be to sign the cookies and include the origin IP as part of the cookie. If you get a request with a cookie issued to a different IP, then you invalidate it and have the user login again.

This might be problematic on mobile devices, so maybe another option might be to include a device id and a nonce in the signed token and each time the cookie is used to establish a connection, the device is issued a new signed token with which to establish the next connection. If a user logs out on a device or the same token is used twice, then Slack could immediately invalidate all tokens.

This is a concern of mine on systems I design/maintain.

How do I mitigate a stolen cookie from successfully authenticating someone else?

Do I store user browser-agent/IP and check that on every request?

I think we are living in a post "IP address" world to be to totally honest.

I can often switch thru many IP addresses in an hour (especially travelling) - various WiFi points, 4G, etc. Services will appear incredibly broken these days if they require a new login per IP address.

Obviously you could force all traffic to be routed thru a VPN and list it there, but it seems people are moving away from that approach.

To me, the better question is how are these cookies get stolen in the first place?

IP based auth is super annoying for legitimate users since it logs them out frequently.

If it's an internal corporate system where all the users sit at assigned machines and have fixed IP addresses, yes you can do stuff like IP address checking.

Otherwise you probably need short-lived cookies that get renewed by the client in the background, with a hard expiry of some reasonable "work day" length such as 8, 12, 16 hrs. Then even if it's stolen, there's a fairly short window of time that it's useful to anyone.

As long as your authentication scheme is based on a bearer token, you can't really prevent it, but binding to IP and setting short expiry can help motivate it.

If you want to avoid this, you have to use something in your authentication scheme that can't leave the device/user, so we're talking certificate or other public key crypto based schemes.

TLS mutual authentication is one common tactic for this, although the scenario itself is uncommon.

In my opinion you don’t. Rely on the authentication provider to handle that responsibility. Services like duo/Okta perform this risk assessment and may opt to request a mfa request.

I've never wanted to completely hand over authentication to a third-party.

Instead what I'd think I'd like is just the risk assessment to be be performed by a third-party when I'm handling authentication (i.e. a third-party that has a broader view of what's happening across multiple services over time). I just send the pieces of information that I'm willing to share as an API call and they make the best risk assessment they can.

Then I can take that risk assessment result and make a final decision if authentication succeeds or not.

There are risk services out there.

https://sift.com/ Is one you call out to that gives you a risk score.

https://datadome.co/ can sit within your cdn layer that does risk assessment.

That's not always an option.

You can downvote all you want. Some projects are sensitive enough to not allow third party authentication (military systems anyone).

Besides, if you're large enough it makes business sense to do it yourself anyway.

If the client device has a TPM or some sort of hardware that can manage the secret you can leverage that. Otherwise, protecting against "attacker has a valid session" is not very easy. Even in the TPM case attackers with code execution on the device can likely bypass it.