Um mergulho mais profundo no incidente de segurança de maio de 2019: feedback da postagem do blog
Acabamos de postar uma atualização do incidente de segurança que aconteceu em maio de 2019 com detalhes técnicos do que aconteceu, como aconteceu e as correções que aplicamos para evitar que um incidente como esse aconteça novamente. Aqui estão alguns trechos da postagem - primeiro da introdução:
Em 12 de maio de 2019, por volta das 00:00 UTC, fomos alertados sobre um aumento inesperado de privilégios para uma nova conta de usuário por vários membros da comunidade. Um usuário que ninguém reconheceu ganhou acesso de moderador e desenvolvedor em todos os sites da Stack Exchange Network. Nossa resposta imediata foi revogar privilégios e suspender essa conta e, em seguida, iniciar um processo para identificar e auditar as ações que levaram ao evento.
Após a descoberta inicial, descobrimos que a escalada de privilégios era apenas a ponta do iceberg e que o ataque realmente resultou na exfiltração de nosso código-fonte e na exposição inadvertida de PII (e-mail, nome real, endereços IP) de 184 usuários da Stack Exchange Network (todos os quais foram notificados). Felizmente, nenhum dos bancos de dados - nem público (leia-se: conteúdo do Stack Exchange) nem privado (equipes, talentos ou empresa) - foi exfiltrado. Além disso, não houve nenhuma evidência de qualquer acesso direto à nossa infraestrutura de rede interna e em nenhum momento o invasor teve acesso a dados em produtos Teams, Talent ou Enterprise.
E a partir do parágrafo final:
Este incidente nos lembrou de algumas práticas de segurança fundamentais que todos devem seguir:
- Registre todo o seu tráfego de entrada. Mantemos registros em todas as conexões internas. Isso possibilitou todas as nossas investigações. Você não pode investigar o que não registra.
- Use 2FA. O sistema restante que ainda usa autenticação legada pode ser sua maior vulnerabilidade.
- Guarde melhor os segredos. O TeamCity tem uma maneira de proteger segredos, mas descobrimos que não estávamos usando-o de forma consistente. Eduque os engenheiros de que "segredos não são apenas senhas". Proteja chaves SSH e strings de conexão de banco de dados também. Na dúvida, proteja-os. Se você precisar armazenar segredos em um repositório Git, proteja-os com git-crypt ou Blackbox .
- Valide as solicitações do cliente. Quanto mais incomum for a solicitação de um cliente, mais importante será verificar se a solicitação é legítima ou não.
- Leve os relatórios de segurança a sério. Agradecemos que nossa comunidade tenha relatado atividades suspeitas tão rapidamente. Obrigada!
Há muito mais na postagem do blog - sinta-se à vontade para fazer perguntas ou comentários relacionados à postagem abaixo e faremos o possível para respondê-las. Não podemos comentar sobre quaisquer outros detalhes relacionados ao ataque além do que está incluído na postagem do blog, devido às investigações em andamento.
Respostas
Você pode fazer algum comentário sobre as intenções dos invasores?
Parece que eles estavam atrás de uma determinada meta / certos dados (do usuário)?
Ou talvez fosse mais um "adolescente curioso" cutucando com gravetos para ver até onde podiam chegar?
PS obrigado pela abertura em relação a este assunto, é muito apreciado!
Está linha:
Esse ato de pesquisar coisas (visitar perguntas) em toda a Stack Exchange Network torna-se uma ocorrência frequente e nos permite antecipar e entender a metodologia do invasor nos próximos dias. (ênfase minha)
faz soar como em tempo real , conforme o ataque estava acontecendo, você poderia identificar o que o invasor faria com base no que ele visitou no Stack Overflow, em vez do que ele fez examinando forense o que viu (após o ataque). Qual você quis dizer?
Várias questões relacionadas principalmente ao invasor:
- O que aconteceu com o atacante?
- Você suspendeu a conta deles?
- SE contatou o atacante em algum ponto?
- Por que você não expõe a identidade do invasor?
- Alguém mais tentou usar esse mesmo método de ataque mais tarde?
Houve um ciclo de sono detectável na outra extremidade dos eventos?
Edite para esclarecer:
Depois de tomar conhecimento do invasor, e como você acompanhou algumas de suas ações à medida que se desenrolavam, você notou algo semelhante a um ciclo biológico, tanto no dia-a-dia quanto retrospectivamente? Ex: comer (intervalos de 1-2 horas), dormir (padrão de inatividade de 8 horas), "cochilos de energia" (90 minutos), etc ...?
Isso não é realmente parte do incidente, mas uma preocupação mais geral sobre as medidas de segurança em torno das contas dos funcionários. Houve várias etapas neste incidente, mas a última foi o aumento dos privilégios de uma conta SE. Posso imaginar maneiras muito mais simples de tentar isso do que obter acesso de administrador ao servidor CI por meio da instância dev para executar SQL na produção, e estou interessado em quais mitigações e práticas de segurança SE implementou para se defender contra tentativas mais simples de ganho acesso a uma conta de funcionário.
Você não pode colocar os principais sites SE atrás do firewall, obviamente, então eles sempre estarão expostos. E o método de login interno do SE não fornece nenhum método 2FA, o que considero um tanto preocupante.
- As contas de funcionários são protegidas pela 2FA por outros meios (ou outros provedores de login)?
- Existem medidas para garantir que nenhum endereço de e-mail privado ou provedor de login seja anexado às contas de funcionários que possam ser menos seguras e ainda ser usadas para receber e-mails de recuperação para obter acesso à conta?
- há monitoramento de tentativas de login de novas fontes para contas de funcionários?
- Existem proteções adicionais para ferramentas perigosas de funcionários no caso de alguém obter acesso a uma sessão em execução de uma conta de funcionário (por exemplo, exigir senha e / ou token 2FA novamente ao acessar ferramentas essenciais para a segurança)
Algo como spear phishing provavelmente ainda é uma das maneiras mais prováveis de alguém tentar obter acesso a uma conta de funcionário.
Mais ou menos na mesma época em que esse incidente de segurança aconteceu, alguns dias depois, alguns usuários começaram a perceber que o oneboxing do Twitter no chat não estava mais funcionando . Posteriormente, um funcionário confirmou, em fevereiro do ano seguinte, que havia realmente sido desativado intencionalmente devido a ter que "fechar algumas lacunas" como resultado deste incidente de segurança.
Podemos obter uma explicação completa de por que o oneboxing do Twitter no chat teve que ser desativado como resultado desse incidente de segurança? A postagem do blog publicada na época afirmava que "outros vetores potenciais" haviam sido fechados então, e a mensagem da equipe de fevereiro de 2020 que eu linkava acima afirmava que o recurso oneboxing do Twitter "fez uso de uma das lacunas que fechamos". O que era aquela coisa e que risco de segurança ela cria?
Por fim, existe alguma maneira de essa funcionalidade ser implementada novamente, de maneira segura? Em agosto de 2020, alguns meses após a mensagem da equipe acima, o relatório de bug arquivado na época foi marcado como status por projeto por outro funcionário. Uma solicitação de recurso para alterar o design de volta (de maneira segura) seria considerada ou é impossível fazer isso sem abrir um vetor de ataque?
Eu sinalizaria que os tipos de parâmetro "senha" no TeamCity não são considerados tão seguros:
O valor da senha é armazenado nos arquivos de configuração em TeamCity Data Directory. Dependendo das configurações de criptografia do servidor, o valor é embaralhado ou criptografado com uma chave personalizada.
O valor do log de construção é oculto com um algoritmo de pesquisa e substituição simples, portanto, se você tiver uma senha comum de "123", todas as ocorrências de "123" serão substituídas, potencialmente expondo a senha. Definir o parâmetro para o tipo de senha não garante que o valor bruto não possa ser recuperado. Qualquer administrador de projeto pode recuperá-lo, e qualquer desenvolvedor que pode alterar o script de construção pode escrever um código malicioso para obter a senha.
Por que o link mágico no dev visível para CMs (presumivelmente apenas no dev) um link mágico real?
Este é realmente um relatório de incidente incrível! Um dos melhores que li.
Obrigado Stack por tornar isso público e Dean por uma ótima redação!
Estou apenas curioso para saber algumas coisas:
- Qual é o tamanho da equipe de resposta a incidentes?
- Houve algum protocolo específico seguido durante a investigação?
- Qual fator-chave foi envolvido para envolver o fornecedor de segurança externo? Quais foram os pontos considerados na escolha desse fornecedor específico?
- Que lições foram aprendidas com o fornecedor de segurança externo? O processo de auditoria deles foi diferente (eficaz / ineficaz) daquele já utilizado pela equipe?
O artigo dá uma boa ideia de toda a arquitetura do Stack e dos processos de desenvolvimento. Uma leitura mais detalhada seria ou link se já houver um artigo sobre isso seria ótimo.
Em "Conselhos para outras pessoas":
Registre todo o seu tráfego de entrada. Mantemos registros em todas as conexões internas. Isso possibilitou todas as nossas investigações. Você não pode investigar o que não registra.
Como uma rede tão ocupada quanto o Stack Exchange pode registrar todo o tráfego de entrada? Esses registros são entradas de servidor da Web, fluxos de IP ou sessões TCP completas?
Eu poderia registrar a maioria das entradas e tentativas de conexão em minha pequena rede, mas não tenho ideia de como uma rede tão grande faz isso.
Você pode explicar mais claramente o que "propriedades acessíveis ao público" significa na citação abaixo?
temos um banco de dados contendo um registro de todo o tráfego para nossas propriedades acessíveis ao público