Experiência Timeweb
Qualquer empresa precisa de uma perspectiva externa sobre o estado da segurança da informação de serviços e produtos. Este problema pode ser resolvido de diferentes maneiras, uma das quais é a participação em programas Bug Bounty.
Bug Bounty é um programa que fornece recompensas monetárias ou outros benefícios para encontrar bugs, exploits e vulnerabilidades em software. Os programas Bug Bounty são implementados por muitas empresas, incluindo Facebook, Google, Reddit, Apple, Microsoft, etc. Uma
empresa pode lançar tal programa por conta própria, organizando todos os processos e interações por conta própria. A segunda opção é recorrer a plataformas especiais Bug Bounty: concluímos um acordo e o exército de caçadores de insetos começa a trabalhar.
A Timeweb lançou seu programa Bug Bounty há cerca de um ano. Naquela época, a empresa não contava com especialistas com experiência nesta área, tudo tinha que ser feito por tentativa e erro. Na Internet, quase ninguém compartilha recomendações sobre como construir esse processo, por isso as bicicletas são frequentemente inventadas e o conhecimento geralmente é transferido em conversas com colegas na máquina de café.
Neste artigo, vamos lhe dizer como organizar o lançamento do programa Bug Bounty, se você nunca fez isso, o que você deve prestar atenção e de que outra forma você pode verificar o status do sistema de segurança da informação.
Confira!
Por que lançamos o programa Bug Bounty?
Nossa tarefa era elevar o sistema de segurança da informação a um novo nível de qualidade superior e não gastar muito dinheiro. É importante notar que a Timeweb é uma empresa madura com uma infraestrutura complexa e um grande conjunto de serviços críticos, então não era nada óbvio para nós naquela época em que ordem testar serviços e corrigir vulnerabilidades, e o que começar primeiro.
Existem várias maneiras de verificar o sistema de segurança da informação. Antes de lançar o programa Bug Bounty, tentamos considerar e analisar várias opções. Entre eles, a auditoria externa é provavelmente a solução mais comum para o problema. Graças à auditoria, você pode encontrar problemas complexos e fora do padrão, mas mesmo depois de pagar uma grande quantia, você não pode ter certeza de que obterá o que realmente precisa.
Outra forma é treinar a equipe e desenvolver as competências dos colaboradores. Aqui você precisa entender que os recursos da equipe ainda são limitados e, claro, é impossível encontrar todos os bugs possíveis por conta própria.
No que se refere à verificação do sistema de segurança da informação, os tickets e solicitações dos clientes ao suporte técnico também auxiliam se é possível processar com eficiência os comentários e mensagens dos usuários.
Paralelamente, conversamos com colegas e coletamos opiniões de especialistas sobre como está estruturado o processo de localização de bugs em outras empresas. Graças às recomendações, decidimos prestar atenção ao programa Bug Bounty.
Lançando o programa Bug Bounty
O que é importante considerar no início?
Existem muitos tipos diferentes de software e plataformas Bug Bounty.
Na primeira fase, optamos por programas públicos e privados, optando por focar neste último. No programa público, o acesso não é limitado: todos podem buscar bugs. Em um programa privado - por convite. Em ambos os casos, os bugs são divulgados apenas por acordo das partes. Decidimos que é muito cedo para abrirmos um programa público: em primeiro lugar, devemos ter certeza de que nossos serviços e produtos não contêm vulnerabilidades críticas.
Quanto à própria plataforma Bug Bounty, analisamos as opções existentes e escolhemos a mais adequada para nós, a ideal em termos de número de caçadores de insetos e custo dos serviços.
Aqui está uma lista das plataformas Bug Bounty mais famosas do mercado:
Devemos também mencionar a plataforma Open Bug Bounty - uma plataforma Bug Bounty não comercial que une os entusiastas da segurança da informação e populariza o hacking ético. Os pesquisadores podem relatar um bug encontrado no trabalho de qualquer software, para o qual a empresa oferece uma recompensa (pagamentos em dinheiro, mercadorias, descontos ou seus próprios produtos). O Timeweb, por exemplo, oferece hospedagem gratuita para caçadores de insetos. Observe que, de acordo com a política do Open Bug Bounty, você só pode relatar bugs que não impliquem intervenção ativa, por exemplo, você não pode relatar RCE e SQL.
Em primeiro lugar, construímos o trabalho dentro da empresa: definimos como as áreas deveriam interagir entre si, quem é o responsável pela correção de bugs, quem acompanha a atualização do escopo e as respostas aos relatórios.
Antes de iniciar o programa, recomendamos que você certifique-se de ter feito tudo o que pode, encontrado todos os bugs possíveis por conta própria. Também é importante saber por dentro e por fora do produto que você pretende colocar no trabalho dos baghunters: quais são os problemas que existem agora, quais são; se erros sistemáticos aparecem. Essas informações permitirão que você crie o escopo correto - de forma sucinta, mas abrangente, para fornecer dados de entrada e descrever a solicitação para caçadores de bugs.
A plataforma foi selecionada, a preparação feita - começamos
Nós formamos um scop
Vamos contar o que entendemos durante o ano de existência do programa
Scopes, preenchido na plataforma Bug Bounty, uma espécie de oferta - um acordo entre a empresa e a comunidade de bug hunters. As seguintes informações devem ser incluídas no escopo:
- indicar a finalidade: a presença de quaisquer efeitos prejudiciais ou consequências destrutivas que gostaríamos de verificar
- informações sobre bugs já conhecidos, irrelevantes ou desinteressantes para a empresa (nenhuma recompensa é fornecida para encontrá-los)
- regras e limites para procurar vulnerabilidades que devem ser seguidas
- tamanho dos prêmios.
Quanto mais tempo você gasta no escopo, melhor. Tente preencher todos os itens com cuidado e detalhes, para que no futuro você possa resolver todos os incidentes com base nas informações especificadas.
Um exemplo de seções com escopo com o conteúdo de pontos no exemplo de nosso programa atual:
Como você escolhe qual verificar primeiro? Aconselhamos você a incluir no programa um serviço ou aspecto que provavelmente precisa ser verificado. É impossível entender imediatamente o que exatamente precisa ser procurado, você só pode escolher uma direção, é importante encontrar os pontos mais problemáticos. Com cada novo relatório e cada novo programa, aumentamos nossa experiência e entendemos mais claramente o que fazer em seguida.
Até agora, nem todos os nossos serviços e produtos estão listados na plataforma Bug Bounty. Isso foi feito de forma deliberada, já que alguns dos serviços, por exemplo, foram criados com base em soluções de código aberto: equipes terceirizadas estão engajadas em seu desenvolvimento e suporte, por isso acreditamos que não faz sentido exibi-los em nossa plataforma Bug Bounty, pois nossa equipe apenas monitora a relevância desses serviços.
Vale a pena considerar se você pode alterar o produto incluído no programa Bug Bounty: existe uma equipe que pode desenvolvê-lo; as nuances da arquitetura permitem.
De nossa parte, durante os programas Bug Bounty, pesquisamos constantemente todos os serviços e a rede por conta própria. Isso nos permitiu economizar dinheiro: corrigimos os bugs encontrados e atualizamos o escopo.
Um componente importante do programa é determinar o nível de gravidade da vulnerabilidade encontrada e estabelecer a quantidade de recompensa. Tente capturar uma relação transparente entre a gravidade do erro e o tamanho da recompensa. Quanto mais transparente, menos perguntas você terá! É uma boa prática vincular o tamanho do prêmio à escala CVSS(um padrão aberto para avaliar a criticidade da vulnerabilidade). Além disso, as plataformas Bug Bounty geralmente exibem manuais e instruções sobre como determinar o valor da recompensa. Os gerentes do local podem ajudá-lo com isso. Para navegar pelo nível de pagamento pelo trabalho dos caçadores de insetos, você pode acessar o portal HeadHunter e analisar os salários indicados. Se os hackers não estiverem mais ativos, pode valer a pena aumentar a recompensa.
Na Timeweb, avaliamos de forma independente a gravidade da situação em função do impacto no negócio. Nossa escala de gravidade do impacto nos negócios inclui 4 níveis:
- baixo (receber informações não críticas sobre outros usuários, por exemplo, o nome do login ou a capacidade de alterar avatares; bem como violação da integridade e disponibilidade dessas informações)
- medium ( , , ; )
- high ( “” ; : , , , ; )
- critical ( ; ).
Além das informações fornecidas acima, examinamos o tipo de vulnerabilidade (RCE, XSS, injeção de SQL) e a importância do servidor que foi hackeado ou ao qual conseguiu acesso.
Assim, para estabelecer o nível de severidade do bug encontrado, analisamos o tipo de vulnerabilidade, a importância do servidor e o grau de impacto na empresa. Com base nesses critérios, determinamos o nível de cada vulnerabilidade encontrada, o que determina o valor da remuneração do caçador de insetos. No entanto, acrescentamos que é impossível levar tudo em consideração e, muitas vezes, ao determinar o nível de criticidade de um bug encontrado, não se pode prescindir da subjetividade.
Uma descrição mais detalhada do processo de avaliação da gravidade da vulnerabilidade é fornecida nas tabelas:
Tabela de pontuação de servidor / serviço
Linha do tempo do Bug Bounty: como foi?
Programa nº 1
Deixando de lado: painel de hospedagem Timeweb.ru Scop
: Scop foi compilado com base em exemplos de outras empresas. Spoiler: Não faça isso! Mas tivemos que começar de algum lugar.
Resultados: Durante a semana recebemos 20 relatórios, principalmente com indicação de vulnerabilidades críticas, e ... gastamos todo o dinheiro que colocamos na conta (vários milhares de dólares). Durante esses 7 dias, vimos padrões de problemas repetidos: vários problemas com a filtragem de entrada e exibição de dados, várias violações da lógica de negócios do aplicativo, bem como alguns outros riscos para o OWASP Top Ten. Decidimos suspender o programa e, no mês seguinte, estávamos apenas corrigindo os bugs encontrados e analisando-os.
Assim que analisamos esses 20 relatórios, entendemos o que fazer a seguir: onde cavar durante o desenvolvimento, como trabalhar corretamente com segurança.
Programa nº 2 Desistimos
: Timeweb.ru hosting panel (de novo)
Scop : Corrigimos o Scop com base nos relatórios recebidos anteriormente: removemos as vulnerabilidades corrigidas e nos concentramos no que é interessante para nós.
Resultados: Desta vez recebemos muitos relatórios críticos, porém mais específicos e específicos. Todas as tarefas do Bug Bounty foram identificadas como urgentes. Graças ao segundo programa, ajustamos os processos de desenvolvimento e as correções de bugs.
Programa No. 3
Estamos dando para sermos destruídos: painel VDS Timeweb.ru , verifique
Resultados do site oficial : Recebeu cerca de 40 relatórios com bugs de gravidade variada.
Como nossos produtos são semelhantes em funcionalidade, às vezes eles herdam não apenas funções, mas também bugs uns dos outros. Descobriu-se que o novo painel continha bugs que já haviam sido encontrados em programas Bug Bounty anteriores. Esses bugs foram registrados no escopo como uma duplicata, então não tivemos que pagar por eles novamente.
Muitos problemas com formulários e vulnerabilidades de XSS foram encontrados no site. Escopo do
programa nº 4
: O objetivo principal do quarto programa era encontrar injeção de SQL.
Resultados:Antes de lançar o programa, estudamos independentemente como ele funciona e realizamos pesquisas sobre nosso produto: encontramos apenas 1-2 vulnerabilidades não críticas. Duas semanas após o lançamento desse programa à noite, recebemos um relatório muito esperado: um caçador de insetos demonstrou um vetor de ataque com efeito destrutivo em um banco de dados de faturamento usando SQLi cego. Fomos capazes de fechar rapidamente esta vulnerabilidade em 5 minutos: estava na versão global anterior do kernel, que ainda é usado como plug-ins para várias ações nas versões globais mais recentes de painéis de controle (hospedagem virtual, VDS, webmasters). Ficamos muito satisfeitos por poder detectar um problema tão sério e corrigi-lo a tempo. Entre outras coisas, verificamos completamente todas as outras seções de código semelhantes por analogia.
Programa # 5
Estamos à sua mercê: Hospedagem Virtual Timeweb
Hospedagem Virtual é, grosso modo, um servidor físico dividido entre centenas de clientes. Os clientes hospedam seus aplicativos da web e diretórios de trabalho neste servidor, têm acesso SSH e FTP ao servidor. Cada um de nossos clientes tem seus próprios clientes. Nesse servidor, nossos scripts de serviço de serviço, serviços e outras personalizações estão em execução, que interagem com outros serviços de serviço e bancos de dados.
Escopo:O objetivo principal dos caçadores de bugs aqui era simples: encontrar vetores para escalar privilégios para root. Esperávamos também uma busca por vetores de influência sobre outros usuários e seus recursos, uma busca por vetores de influência em nossos scripts de serviço e uma busca por vetores de ataque em outros servidores, tanto de hospedagem virtual quanto de servidores de serviço, aos quais haveria uma acessibilidade hipotética.
Resultados: Alocamos um servidor especial sem clientes para caçadores de bugs, semelhante em funcionalidade aos servidores de produção. No momento, os caçadores de bugs encontraram apenas 10 bugs. Dois relatórios mostraram vetores de ataque com escalonamento de privilégios para root, mas não conseguiram alcançar outros servidores. Esses problemas foram corrigidos imediatamente.
Antes de lançar o quinto programa, mergulhamos na atualização de servidores e software, lidando com pontos fracos, implantando serviços de serviço em uma rede local inacessível à rede externa. Graças a este programa, nós refatoramos os sistemas internos no servidor. Isso nos permitiu notar erros antes mesmo que eles nos escrevessem.
E aonde isso te levou?
Sobre os resultados do programa Bug Bounty
Por quase um ano do programa Bug Bounty, recebemos 72 relatórios. Destes, 36 relatórios não atendem às normas de nosso escopo. No entanto, os caçadores de bug encontraram 7 vulnerabilidades críticas, 9 de alta e 10 de média e baixa gravidade.
Para obter esse resultado, gastamos mais de US $ 15.000 em remuneração para caçadores de insetos (excluindo taxas de plataforma). A menor recompensa foi de $ 50 (por uma vulnerabilidade que permite receber informações sobre a forma de pagamento de qualquer conta por meio do IDOR). A maior recompensa paga até agora é de US $ 1.500. Remuneração média: aproximadamente $ 423.
Quanto aos resultados de qualidade:
preservamos o tônus dos músculos IB
Como o programa Bug Bounty implica uma busca constante e contínua por bugs, nossa equipe de segurança da informação está em alerta 24 horas por dia, 7 dias por semana.
Podemos dizer que os caçadores de bugs simulam as ações de hackers. Eles criam atividades “prejudiciais” sancionadas todos os dias, forçando-nos a manter os olhos abertos e a guarda.
acompanhando a tendência, os
Baghunters usam novos serviços, utilitários desconhecidos e técnicas de hacking modernas. Graças a isso, nossos especialistas podem atualizar suas competências e conhecimentos.
melhoria de serviços e produtos
A segurança da informação em geral e os processos do Bug Bounty em particular estão sempre voltados para a melhoria e desenvolvimento de serviços e produtos para o cliente.
envolver uma comunidade de especialistas
Na implementação da segurança da informação, não apenas nossos administradores internos estão envolvidos, mas também uma comunidade completa de especialistas com várias experiências e conhecimentos.
Frequentemente perguntamos aos caçadores de bugs como reproduzir o bug encontrado e até mesmo como corrigi-lo. Os especialistas estiveram prontos para se comunicar diretamente no Telegram, gravar vídeo, pelo que estamos muito gratos.
Observamos disciplina.
Trabalhando com plataformas Bug Bounty, somos responsáveis por fechar bugs não só para nós mesmos e clientes, mas também para os caçadores de bugs, eles estão aguardando feedback. A interação ocorre de acordo com os regulamentos estabelecidos, devemos atualizar regularmente as informações sobre os relatórios atuais.
Em 3 dias, tivemos que responder ao bughunter ao seu relatório: o erro encontrou um bug, qual é o seu nível de gravidade. Claro, poderíamos dar uma resposta em uma semana, mas esse comportamento não será amigável ao hacker e pode afastar os caçadores de insetos.
Entendemos melhor os usuários
Baghunters são os mesmos usuários e clientes que nos fornecem uma certa experiência de usuário em termos de segurança da informação.
Existe vida depois do Bug Bounty?
Continuamos a trabalhar com um programa Bug Bounty privado com uma plataforma comprovada. Gostaríamos de construir com eficiência todos os processos internos para fechamento e correção de bugs. Assim que entendermos que os caçadores de bugs com os quais estamos interagindo tornaram-se menos ativos, tentaremos mudar para outros sites Bug Bounty maiores, a fim de receber ainda mais relatórios e encontrar todos os problemas possíveis.
Outra área de desenvolvimento para nós foi a implementação dos princípios de desenvolvimento seguro. Normalmente, os desenvolvedores estão fazendo programação funcional e a segurança fica em segundo plano. É importante tornar a revisão de segurança do código uma parte fundamental de qualquer revisão de código.
A equipe da Timeweb está tentando implementar novas e modernas ferramentas para auditoria de segurança da informação de serviços. Aprendemos sobre alguns dos recursos por meio da cooperação com caçadores de insetos.
Gradualmente, vamos envolvendo a equipe de suporte técnico na solução dos problemas de segurança da informação: treinamos colegas e fortalecemos a equipe.
Estamos prontos para falar sobre o programa Bug Bounty indefinidamente. Talvez você ainda tenha perguntas para nossos especialistas - escreva nos comentários, que ainda são interessantes e úteis para ler. Tentaremos responder a todas as perguntas abaixo ou explicar com mais detalhes nos artigos a seguir.