1 pontos por GN⁺ 2024-02-25 | 1 comentários | Compartilhar no WhatsApp
  • Tom McKay, do IT Brew, ao deixar o Gizmodo em 2022, disfarçou sua conta do Slack como se fosse o Slackbot e evitou ser excluído por meses
  • O Slack bloqueava o nome “Slackbot”, que já estava em uso, mas McKay contornou a restrição de nome de exibição usando caracteres Unicode parecidos
  • Ele também trocou a foto de perfil por uma versão irritada parecida com o ícone real do Slackbot, e os administradores não perceberam a diferença nas sobrancelhas do Slackbot duplicado
  • Enquanto a conta continuava ativa, McKay conseguiu enviar aos colegas mensagens com aparência de bot, como “Slackbot fact of the day”
  • Dependendo da empresa, podem existir medidas de segurança para impedir esse tipo de brincadeira, por isso é importante fazer a limpeza de contas de ex-funcionários e validar nomes de exibição

Conta do Slack que permaneceu ativa após a saída

  • Tom McKay, do IT Brew, depois de sair do Gizmodo, disfarçou sua conta do Slack como se fosse o Slackbot
  • McKay compartilhou capturas de tela da época no X e também confirmou ao The Verge que a brincadeira foi real
  • A conta disfarçada não foi detectada nem excluída pela administração do Gizmodo por meses

Como ele fez a conta parecer o Slackbot

  • O Slackbot é um bot familiar dentro do Slack que ajuda com notificações, consulta da senha do Wi‑Fi do escritório, alertas de menções em canais dos quais você não participa, entre outras coisas
  • Na época em que saiu, McKay trocou sua foto de perfil antiga por uma imagem de versão irritada parecida com o ícone real do Slackbot
  • Ele também tentou mudar o nome de exibição para “Slackbot”, mas o Slack não permitiu a alteração normal por ser um nome já em uso
  • Em vez disso, usou caracteres Unicode semelhantes a letras para contornar a restrição de nome
    • Ex.: trocar “o” por um caractere Unicode parecido, “о”

O que foi possível fazer por meses

  • Graças a essa mudança, a conta ativa de McKay no Slack evitou ser excluída por meses
  • Enquanto a conta permaneceu ativa, ele pôde enviar mensagens aos colegas com aparência de bot
    • Ex.: “Slackbot fact of the day: Hi, I’m Slackbot! That’s a fact. Have a Slack-ly day!”
  • Victoria Song, que trabalhou no Gizmodo no passado, reagiu dizendo que a situação não era surpreendente

Possíveis defesas por empresa

  • Nem toda empresa cairia no mesmo truque, e algumas têm medidas de segurança para impedir esse tipo de situação
  • A administração do Gizmodo pode ter achado que a conta de McKay já havia sido excluída
  • Ou talvez não tenha olhado com atenção suficiente para notar um Slackbot duplicado com sobrancelhas suspeitas

1 comentários

 
GN⁺ 2024-02-25
Comentários do Hacker News
  • Um ex-funcionário que conheci anos atrás criou um perfil de provisionamento de dial-up/ISDN chamado Ringing em um módulo controlador de rack de modems. Fez isso para evitar criar no servidor RADIUS, onde seria óbvio demais
    Na página de status do rack de modems, aparecia um estado Ringing junto dos usuários conectados, como se fosse apenas uma chamada ainda não atendida, e ele usou o serviço ISDN de 128 Kbit por mais de um ano sem ser completamente descoberto
    Claro, não recomendo fazer esse tipo de coisa. Especialmente hoje, quando o CFAA às vezes é interpretado de um jeito que incluiria até mudar parâmetros de URL ou atirar meleca no carpete

    • Fico curioso se há base para essa afirmação sobre o CFAA. Na verdade, parecia bem possível que mudar parâmetros de URL não fosse um problema
      Pela lei de Nova Jersey, para haver condenação por “acesso sem autorização ou acesso além da autorização”, o governo precisava provar que houve contorno de uma barreira baseada em código ou senha, e nesse caso a ideia era que só acessaram parte de uma tela pública de login e coletaram informações que a AT&T expôs sem querer
      https://law.justia.com/cases/federal/appellate-courts/ca3/13...
    • Isso me lembra um pouco da vez em que, no modo LAN de Warcraft II, quando dois irmãos jogavam cooperativo contra o computador, eu mudei meu nome para Computer e entrei escondido
    • No emprego anterior, esperei em silêncio por meses para que removessem minha conta do Slack. Quase um ano depois, eu ainda tinha acesso total a muitos canais internos, o que era realmente estranho
      As pessoas próximas a mim estavam certas, mas não era porque tinham me deixado por gentileza; era porque a gestão de contas do Slack e a integração com o Google Office eram uma bagunça
    • Não entendi a história do CFAA e da meleca. Mesmo pesquisando, não encontrei nenhuma referência
  • Lembro do glorioso dia, por volta de 2016, em que descobrimos numa consultoria que era possível mudar os nomes no Slack uns dos outros. Por um tempo, o nome de todo mundo era simplesmente dad

    • Parece muito com quando as crianças percebem que qualquer um pode mudar o nome e a foto dos perfis da Netflix/Disney+
    • Gosto da ideia, mas vou insistir em grandad. Ou então vou soltar minhas netas, e elas são impiedosas
    • Isso ainda é possível?
      O time de frisbee da universidade usa Slack
  • Muita gente recomenda impedir a mudança de nomes, mas isso não resolve completamente o problema. Pode muito bem existir alguém cujo nome real seja Jira em algum lugar
    Na empresa $company onde trabalhei antes, os painéis dos clientes ficavam em curingas baseados em https://*.$company.com. Por exemplo, algo como https://foo.$company.com
    Mas, se alguém escolhesse um slug de painel que entrasse em conflito com um registro real, como www ou blog, aquele painel ficava totalmente inacessível. Como a configuração para mudar o prefixo também ficava em https://$dashboard.$company.com, o cliente não conseguia corrigir isso sozinho e precisava do suporte. Naturalmente, a ferramenta de suporte também não expunha uma função para alterar diretamente o prefixo $dashboard
    Definir uma lista de bloqueio também não é trivial. Você precisa incluir entradas DNS existentes, prefixos $dashboard já existentes, palavrões, símbolos Unicode, o prefixo xn-- do Punycode, redirecionamentos de prefixos antigos e reservas para impedir apropriações futuras
    Não é surpreendente que o Slack tenha uma brecha dessas. É um problema inerentemente difícil

    • O Zendesk coloca os painéis dos clientes em subdomínios diretos do seu domínio principal. Também permite domínios próprios e, para usar isso, é preciso criar um CNAME apontando para o subdomínio fornecido pelo Zendesk
      https://support.zendesk.com/hc/en-us/articles/4408838571930-...
      Acho melhor, como fazem GitHub e Shopify, colocar os subdomínios de páginas de clientes em pelo menos um domínio separado. O GitHub usa GitHub.com como seu próprio domínio e GitHub.io como domínio das páginas dos usuários, e a Shopify também separa Shopify.com e myshopify.com
      A vantagem de um domínio separado para clientes é reduzir conflitos com subdomínios atuais e futuros que a empresa queira usar diretamente, além de permitir colocar esse domínio na Public Suffix List para evitar problemas potenciais. Ainda assim, é preciso filtrar termos ofensivos ou enganosos
      https://publicsuffix.org/
    • No trabalho do meu cônjuge, existe mesmo um funcionário chamado Admin. O pessoal de TI está quebrando a cabeça para decidir como lidar com isso
    • Estão mesmo tentando defender o Slack aqui? o e о estão entre os casos mais fáceis possíveis de ataque de homógrafos
      https://en.wikipedia.org/wiki/IDN_homograph_attack
      A história diz que, ao sair da empresa, McKay trocou a foto do perfil por um ícone do Slackbot com cara mais irritada e mudou o nome para Slackbot; o Slack bloqueava o nome Slackbot por já estar em uso, mas funcionava ao trocar o o pelo caractere Unicode о
      Esse par de caracteres latino/cirílico já foi usado em um dos primeiros ataques com glifos homógrafos, divulgado em 2001
      https://web.archive.org/web/20200102175251/http://www.cs.tec...
      Em 2022, o Slack valia algo em torno de 20 bilhões de dólares e já operava havia quase 10 anos. Além disso, é um software baseado em nomes de usuário voltado a organizações e empresas que precisam de segurança
    • Basta restringir os caracteres permitidos e, antes de autorizar a alteração, verificar literalmente se aquela página já está sendo resolvida. Assim o cliente não fica trancado para fora e também fica mais difícil se passar por outro alvo com caracteres
      Se quiser permitir alguns símbolos, dá para usar uma lista de permissões ou verificar se o nome de usuário tem distância de Levenshtein suficiente de nomes críticos como slackbot, para então proibir ou marcar para revisão humana
      É inerentemente difícil bloquear tudo, mas não é difícil bloquear os problemas maiores
    • Neste caso, “garanta que espaços de nomes fundamentalmente diferentes não entrem em conflito” não é um problema tão difícil assim
  • O melhor lugar para se esconder é parecer uma conta de serviço daquelas que ninguém quer mexer, com medo de quebrar algo ao desativá-la. Bem jogado

    • Em compensação, uma pessoa de TI exageradamente zelosa no nosso trabalho já apagou a conta de automação Jira. Ela não sabia por que aquela conta existia e achou suspeito o nome $CompanySecretary
      Alguns dias depois, tivemos um baita trabalho para encontrar e corrigir todos os fluxos e tickets que faziam referência àquele usuário antes que algo realmente importante quebrasse
    • Isso me lembra malwares famosos e seus nomes de processo
  • “Claro que nem toda empresa cairia nessa pegadinha”, mas a empresa pode ser a que ri por último: https://en.wikipedia.org/wiki/Computer_Fraud_and_Abuse_Act

    • Por isso o ponto é que ele esperou 2 anos para contar. Bate certinho com o prazo de prescrição da CFAA
    • Foi exatamente nisso que pensei quando vi a expressão “pegadinha leve”
    • Quem pode rir por último é o Slack. Afinal, ele acaba tendo acesso a muitos “dados comerciais sensíveis”
  • Trocar caracteres ASCII por caracteres Unicode parecidos é um truque antigo. Existem muitos desses caracteres, e dá para usá-los no código para pregar peças nos colegas desenvolvedores. O dia 1º de abril também está chegando
    Também fizeram um plugin do Vim que destaca esses caracteres “perigosos”: https://github.com/vim-utils/vim-troll-stopper
    Nunca passei por uma pegadinha com caracteres Unicode, mas já aconteceu de um consultor japonês inserir sem querer um caractere de “espaço japonês” num arquivo de tradução, e isso quebrou o app. Como eu sempre deixava o plugin do Vim ligado, descobri a causa bem rápido

    • Muitos apps começaram, prestativamente, a trocar dois hífens por um travessão Unicode mais bonito, e por causa disso ferramentas de linha de comando quebravam
    • Lembro disso: https://news.ycombinator.com/item?id=10438363
    • Até caracteres lixo acidentais podem ir longe. Lembro de alguém num relatório médico usar um O sobrescrito como se fosse o símbolo de grau
      Depois aquilo foi convertido para um caractere que não era sobrescrito, e o significado mudou bastante. O mais desagradável é que, depois dessa tentativa de símbolo, a pessoa ainda escreveu a palavra degrees junto
  • Se o Slack não permitir bloquear a mudança de nome, isso parece uma baita falha de segurança para grandes empresas
    Se alguém mudar o nome para o do CEO e acertar também a imagem de perfil, a chance de perceberem a diferença antes que seja tarde demais é baixíssima. Mudar para Slackbot parece pouca coisa

    • Dá para bloquear a mudança de nome. Estou numa organização Enterprise Grid, e o nome de exibição e o nome de usuário ficam sincronizados com o perfil do funcionário
      Também é obrigatório usar SSO sempre que o app desktop é aberto, então, se alguém sai da empresa, nunca mais consegue entrar. As contas também são desativadas bem rápido, então provavelmente o mobile também não é uma grande preocupação
      Na prática, as únicas coisas que dá para mudar sem abrir ticket são a foto e alguns campos de texto livre pouco importantes
    • Isso dá para configurar nas definições da organização. O mesmo vale para a questão de SAML/SSO abaixo. Se dá para mudar o nome, é mais provável que não exista administrador de TI ou que ele seja preguiçoso
    • Empresas grandes usam SAML ou outro tipo de autenticação federada para impedir login sem autenticação corporativa
    • Ao mesmo tempo, a função de mudar o nome também é uma grande bênção
      A gente até abusa disso colocando disponibilidade direto no nome de exibição. Por exemplo, algo como mike-2/12~16vac. para que quem for entrar em contato consiga estimar o tempo de resposta, ou saber se vale a pena repassar trabalho quando as férias já estão próximas
      Ninguém parecia olhar o atributo real de status, e isso era melhor do que ir até o calendário conferir
    • Acho que esse é provavelmente um dos motivos pelos quais a nossa empresa removeu recentemente a função de as pessoas mudarem o nome no sistema de videoconferência
  • Pelas capturas de tela das pessoas respondendo a ele, fica claro que sabiam que ele não era o Slackbot, e até o chamavam de Tom. Então isso contradiz um pouco o título. Ele claramente não estava “sem ser detectado”
    No nosso Slack também ainda há ex-funcionários. Às vezes eles aparecem para dar oi, e é bom ver isso. Se um deles um dia começasse a imitar o Slackbot de forma sarcástica, acho que a gente também levaria na esportiva

    • O sentido aqui é que ele não foi detectado pela gerência. Isso também aparece claramente na matéria. Os amigos sabiam que ele estava lá e estavam rindo junto
    • Aqui é parecido. O Slack não era o principal canal de comunicação, mas era usado para consultores externos, e pessoas que já tinham saído continuavam lá sem serem expulsas, marcando almoços
  • Num lugar onde trabalhei antigamente, a desativação de contas do Slack era lenta. Então, ao sair da empresa, criei um canal privado chamado #daves_cave e convidei amigos
    De vez em quando eu deixava uma historinha curta ou uma frase espirituosa, e foi divertido até a gerência perceber e desativar minha conta

    • Tenho um time pessoal pago no Slack, acho que custava uns 10 dólares por mês. Dá para convidar pessoas de outros times pagos do Slack para uma sala e conversar
      A vantagem desse jeito é que ele é “projetado para isso”, então é menos provável que seja fechado e também menos provável que esbarre em leis sobre uso indevido de computadores
  • Acho que, na empresa, considerariam single sign-on a resposta para esse problema
    Hoje em dia não administro mais TI, mas quando fazia isso, marcávamos ex-funcionários como desativados no Azure Active Directory. Aí eles não conseguiam fazer login em nenhum serviço como Office 365, Outlook, Teams etc., nem em serviços de terceiros que usassem o SSO da Microsoft. Não seria o caso de integrar o Slack nisso também?

    • Qualquer departamento de TI competente ou com pessoal suficiente faz isso, claro. Só que também pode ter acontecido de outro departamento configurar o Slack sem consultar a TI