9 ms·

The key bit is "The hackers then requested a multifactor authentication token from EA IT support to gain access to EA's corporate network. The representative sa

by sxp 5y ago

The key bit is "The hackers then requested a multifactor authentication token from EA IT support to gain access to EA's corporate network. The representative said this was successful two times." So this was primarily a social engineering hack after Slack was used to get access to a trusted messaging channel.

barbazoo 5y ago
Exactly, doesn't sound like this has anything to do with Slack in particular.
- danso 5y ago
  The problem probably isn't Slack itself, but EA's policies around Slack. I think it's not nothing that the social engineering happened over Slack. For starters, somehow login cookies to the Slack were stolen and then sold, and those were enough to get into the Slack. And then in 2 separate instances, the hackers were able to convince IT to give them 2 new tokens. Maybe the IT team/policy is just weak across the board, and they would've handed keys over the phone or through internal email. But it's not impossible for the IT team to have a complacent mindset around Slack.
  - bostonsre 5y ago
    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.
    - SCHiM 5y ago
      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 :)
      - recursive 5y ago
        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.
        manquer 5y ago
        Perhaps not in itself. The lack of scans is concerning though
        slver 5y ago
        Signed by real vendors?
        recursive 5y ago
        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".
      - zeusk 5y ago
        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.
        650REDHAIR 5y ago
        1000 times no. You need to build security for the lowest common denominator.
        5y ago
    - munk-a 5y ago
      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.
      - slver 5y ago
        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.
    - deleted 5y ago
      [deleted]
  - Thaxll 5y ago
    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.
    - hu3 5y ago
      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?
      - throwawayboise 5y ago
        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.
      - josho 5y ago
        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.
        hu3 5y ago
        That's not always an option.
        hu3 5y ago
        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.
- shadowgovt 5y ago
  Exactly. It has about as much to do with COVID-19 as with Slack. In pre-COVID-19 days, IT handling that kind of request would have required it to come in face-to-face. But since everyone's working from home, that's intractable. The failure point here is that IT should have confirmed via an independent secondary channel the identity of the requester, but it appears they either got lazy or their protocols assumed Slack could not be compromised in this way so the request was already authentic.
  - maccard 5y ago
    > In pre-COVID-19 days, IT handling that kind of request would have required it to come in face-to-face. But since everyone's working from home, that's intractable. In pre covid times it wasn't uncommon for people in my office (which didn't have a dedicated onsite IT person) to ping IT on slack for the person sitting next to them to ask for a PW reset. Face to face doesn't solve anything. If there's a 2000 person company and you can get into the building, chances are you could walk up to the IT desk and say "hey my name is John Doe I'm an engineer here and I locked myself out of X, can I get a reset?" And you'd be given it without any verification
    - throwawayboise 5y ago
      The one time I locked myself out hard at work and had to go "in person" for a password reset, I had to show ID even when the person who was resetting my password knew me by sight. And this was well over a decade ago. And in all but the smallest companies I've worked for, you needed a card swipe at the door (or an escort) to pass from public to internal areas. This is just really, really basic physical security stuff.
      - maccard 5y ago
        That might be true at some companies, but has not been my experience at 3 different companies. > And in all but the smallest companies I've worked for, you needed a card swipe at the door (or an escort) to pass from public to internal areas. And once you're past the barrier of those internal areas, you're unlikely to be questioned in all but the most strictly controlled places.
- grumple 5y ago
  Well, since the user was able to gain access with a stolen cookie, these things are possibly true: 1) Slack does not invalidate sessions after a short enough period of time or inactivity (for a cookie to make it to another site, be purchased and used, probably takes some time). 2) Slack does not properly terminate sessions on logout or inactivity (allowing cookies to be reused after logout). 3) Slack is not using any more clever techniques to make cookies useless to attackers.
  - Ueland 5y ago
    Session invalidation time is someting the slack admin (That is, EA in this case) configures themself. Fun fact, if you want SSO for your Slack, you have to pay extra unless you are already using one of the top tier Slack editions. So either pay up, or have multiple ways of administering your users, with the security implications that causes.
    - whydoyoucare 5y ago
      I've rarely seen any enterprise Slack ever configured for session timeouts. Misplaced trust on the employee device combined with convenience over security.
  - jbkkd 5y ago
    This, and especially #3. Having the same cookie used on a different computer should be the reddest flag of them all. This could be identified by the user agent (different version of the Slack client) and a different IP (cookie accessed from a different country than it was originally created).
- staticassertion 5y ago
  Something important to keep in mind is that Slack has a lot of not so great defaults. Go check your settings - infinite sessions, infinite channel retention, etc.
- whydoineedthis 5y ago
  Aside from that small part of a stolen and long lived cookie working on an untrusted device.
- ljm 5y ago
  It could happen in other scenarios, if you generate incoming webhook URLs and don't treat them as secrets. Once you get your hands on one of those, you've got a fair shot at a phishing attack.
tialaramex 5y ago
I'm interested in what sort of "multifactor authentication token" and how IT support were able to grant this request. Are we talking about a physical token like an old-fashioned SecurID OTP keyfob or a Yubikey? Or something custom? Or are we just talking about a code that real employees get via TOTP or worse SMS? It seems like the same week large employers figured out they would need to FedEx the new guy a laptop since he can't come to the office, they would likewise realise they want to make sure they FedEx that laptop to his actual home, not some building site a scammer told them to send it to. And so you'd hope that physical tokens likewise can't just be sent to some random social engineer based on one chat. Even if you do succeed in getting them to FedEx the token to a building site, that's not a trivial extra step to retrieve. If some teenage "criminal mastermind" gives their parents home address to get the token delivered, they've also told cops where to start looking for the "hacker". Whereas if it's just a code then I can more easily imagine IT support just pastes it into Slack for you.
- LegitShady 5y ago
  >Are we talking about a physical token like an old-fashioned SecurID OTP keyfob or a Yubikey? Or something custom? I used to have a citrix fob that gave me a OTP but then my employer switched to azure and now it's all text message based. That was just last year.
- himinlomax 5y ago
  Token most likely refers to a software OTP token. That would require having an account, but the same would be true for a hardware token.
- pwillia7 5y ago
  A simple Zoom call with your camera on for anything private could have stopped all of this.
  - scoopertrooper 5y ago
    Not really, IT generally have no idea what you look like. I suppose if the company provided your ID photo to tech support, then that could supplement this though. However, I've never seen a company do that.
NaturalPhallacy 5y ago
Humans, the unpatchable vulnerability.
- djmips 5y ago
  Humans are somewhat patchable but I like your point.
andrei_says_ 5y ago
I appreciate being able to open the comments and read the essence of the article along with a clarification correcting the messaging in the clickbaity title. Thank you.
behringer 5y ago
At the companies I've worked for we were prohibited from ever giving out OTP codes. If you lost you ability to generate one it meant you need to submit a request through the ticket system and come into the office if you need to provision it. Certainly a request like this should never come from slack.
technofiend 5y ago
That should have never succeed because the request and the requestor's identity should be confirmed by using other data known and trusted by both parties, and possibly by requiring confirmation by someone up your management chain to boot.

by sxp 5y ago

barbazoo 5y ago

Exactly, doesn't sound like this has anything to do with Slack in particular.

danso 5y ago
The problem probably isn't Slack itself, but EA's policies around Slack. I think it's not nothing that the social engineering happened over Slack. For starters, somehow login cookies to the Slack were stolen and then sold, and those were enough to get into the Slack. And then in 2 separate instances, the hackers were able to convince IT to give them 2 new tokens. Maybe the IT team/policy is just weak across the board, and they would've handed keys over the phone or through internal email. But it's not impossible for the IT team to have a complacent mindset around Slack.
- bostonsre 5y ago
  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.
  - SCHiM 5y ago
    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 :)
    - recursive 5y ago
      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.
      - manquer 5y ago
        Perhaps not in itself. The lack of scans is concerning though
      - slver 5y ago
        Signed by real vendors?
        recursive 5y ago
        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".
    - zeusk 5y ago
      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.
      - 650REDHAIR 5y ago
        1000 times no. You need to build security for the lowest common denominator.
        5y ago
  - munk-a 5y ago
    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.
    - slver 5y ago
      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.
  - deleted 5y ago
    [deleted]
- Thaxll 5y ago
  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.
  - hu3 5y ago
    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?
    - throwawayboise 5y ago
      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.
    - josho 5y ago
      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.
      - hu3 5y ago
        That's not always an option.
        hu3 5y ago
        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.
shadowgovt 5y ago
Exactly. It has about as much to do with COVID-19 as with Slack. In pre-COVID-19 days, IT handling that kind of request would have required it to come in face-to-face. But since everyone's working from home, that's intractable. The failure point here is that IT should have confirmed via an independent secondary channel the identity of the requester, but it appears they either got lazy or their protocols assumed Slack could not be compromised in this way so the request was already authentic.
- maccard 5y ago
  > In pre-COVID-19 days, IT handling that kind of request would have required it to come in face-to-face. But since everyone's working from home, that's intractable. In pre covid times it wasn't uncommon for people in my office (which didn't have a dedicated onsite IT person) to ping IT on slack for the person sitting next to them to ask for a PW reset. Face to face doesn't solve anything. If there's a 2000 person company and you can get into the building, chances are you could walk up to the IT desk and say "hey my name is John Doe I'm an engineer here and I locked myself out of X, can I get a reset?" And you'd be given it without any verification
  - throwawayboise 5y ago
    The one time I locked myself out hard at work and had to go "in person" for a password reset, I had to show ID even when the person who was resetting my password knew me by sight. And this was well over a decade ago. And in all but the smallest companies I've worked for, you needed a card swipe at the door (or an escort) to pass from public to internal areas. This is just really, really basic physical security stuff.
    - maccard 5y ago
      That might be true at some companies, but has not been my experience at 3 different companies. > And in all but the smallest companies I've worked for, you needed a card swipe at the door (or an escort) to pass from public to internal areas. And once you're past the barrier of those internal areas, you're unlikely to be questioned in all but the most strictly controlled places.
grumple 5y ago
Well, since the user was able to gain access with a stolen cookie, these things are possibly true: 1) Slack does not invalidate sessions after a short enough period of time or inactivity (for a cookie to make it to another site, be purchased and used, probably takes some time). 2) Slack does not properly terminate sessions on logout or inactivity (allowing cookies to be reused after logout). 3) Slack is not using any more clever techniques to make cookies useless to attackers.
- Ueland 5y ago
  Session invalidation time is someting the slack admin (That is, EA in this case) configures themself. Fun fact, if you want SSO for your Slack, you have to pay extra unless you are already using one of the top tier Slack editions. So either pay up, or have multiple ways of administering your users, with the security implications that causes.
  - whydoyoucare 5y ago
    I've rarely seen any enterprise Slack ever configured for session timeouts. Misplaced trust on the employee device combined with convenience over security.
- jbkkd 5y ago
  This, and especially #3. Having the same cookie used on a different computer should be the reddest flag of them all. This could be identified by the user agent (different version of the Slack client) and a different IP (cookie accessed from a different country than it was originally created).
staticassertion 5y ago
Something important to keep in mind is that Slack has a lot of not so great defaults. Go check your settings - infinite sessions, infinite channel retention, etc.
whydoineedthis 5y ago
Aside from that small part of a stolen and long lived cookie working on an untrusted device.
ljm 5y ago
It could happen in other scenarios, if you generate incoming webhook URLs and don't treat them as secrets. Once you get your hands on one of those, you've got a fair shot at a phishing attack.

tialaramex 5y ago

I'm interested in what sort of "multifactor authentication token" and how IT support were able to grant this request. Are we talking about a physical token like an old-fashioned SecurID OTP keyfob or a Yubikey? Or something custom? Or are we just talking about a code that real employees get via TOTP or worse SMS? It seems like the same week large employers figured out they would need to FedEx the new guy a laptop since he can't come to the office, they would likewise realise they want to make sure they FedEx that laptop to his actual home, not some building site a scammer told them to send it to. And so you'd hope that physical tokens likewise can't just be sent to some random social engineer based on one chat. Even if you do succeed in getting them to FedEx the token to a building site, that's not a trivial extra step to retrieve. If some teenage "criminal mastermind" gives their parents home address to get the token delivered, they've also told cops where to start looking for the "hacker". Whereas if it's just a code then I can more easily imagine IT support just pastes it into Slack for you.

LegitShady 5y ago
>Are we talking about a physical token like an old-fashioned SecurID OTP keyfob or a Yubikey? Or something custom? I used to have a citrix fob that gave me a OTP but then my employer switched to azure and now it's all text message based. That was just last year.
himinlomax 5y ago
Token most likely refers to a software OTP token. That would require having an account, but the same would be true for a hardware token.
pwillia7 5y ago
A simple Zoom call with your camera on for anything private could have stopped all of this.
- scoopertrooper 5y ago
  Not really, IT generally have no idea what you look like. I suppose if the company provided your ID photo to tech support, then that could supplement this though. However, I've never seen a company do that.

NaturalPhallacy 5y ago

Humans, the unpatchable vulnerability.

djmips 5y ago
Humans are somewhat patchable but I like your point.

andrei_says_ 5y ago

I appreciate being able to open the comments and read the essence of the article along with a clarification correcting the messaging in the clickbaity title. Thank you.

behringer 5y ago

At the companies I've worked for we were prohibited from ever giving out OTP codes. If you lost you ability to generate one it meant you need to submit a request through the ticket system and come into the office if you need to provision it. Certainly a request like this should never come from slack.

technofiend 5y ago

That should have never succeed because the request and the requestor's identity should be confirmed by using other data known and trusted by both parties, and possibly by requiring confirmation by someone up your management chain to boot.