.
Na semana passada, escrevemos sobre como a empresa de segurança Rapid7 jogou a JetBrains, a empresa por trás da popular plataforma de CI/CD TeamCity, sob o ônibus por causa de alegações de patch silencioso. Agora, a JetBrains partiu para a ofensiva.
O desenvolvedor de software publicou seu lado da história na época, mas sentiu a necessidade de dar um passo adiante com outra postagem no blog esta semana, reforçando seu argumento de que agiu de forma responsável e dentro das normas de divulgação de vulnerabilidades.
Além disso, classificou a abordagem do Rapid7, que consistia em divulgar detalhes completos das duas vulnerabilidades do TeamCity, bem como informações suficientes para que invasores pouco qualificados desenvolvessem código de exploração apenas cinco horas após a entrada dos patches, “totalmente antiético e prejudicial” para seus clientes.
“Apoiamos totalmente a divulgação oportuna de detalhes de vulnerabilidade quando uma correção é lançada”, escreve Daniel Gallo, engenheiro de soluções TeamCity da JetBrains. “No entanto, fornecemos apenas os detalhes necessários para que os clientes entendam o escopo e a gravidade da vulnerabilidade, permitindo-lhes tomar as ações apropriadas, mas sem divulgar tantas informações que facilitem a exploração direta.
“Também estamos totalmente comprometidos em divulgar detalhes completos da vulnerabilidade (e as etapas de exploração) para beneficiar os pesquisadores de segurança, mas somente depois de vermos que um número significativo de clientes realmente atualizou seus sistemas para versões seguras ou instalou patches”.
Após a divulgação detalhada do Rapid7, em poucas horas os usuários locais do TeamCity relataram ter sido atingidos por ataques de ransomware. A JetBrains observa que outros clientes tinham contas de administrador instaladas em suas máquinas e provavelmente estavam sendo recrutados para uso em campanhas DDoS.
“Isso se deveu à disponibilidade imediata de exemplos de exploração documentados publicamente e publicados pela Rapid7, o que significava que invasores de qualquer nível de habilidade tinham todos os recursos necessários para explorar rapidamente as vulnerabilidades em estado selvagem”, diz Gallo.
Ver este tipo de guerra pública de palavras é uma raridade no espaço da infosec que, em geral, é composto por membros que formam uma comunidade colaborativa e cumprem normas acordadas.
Perguntamos ao Rapid7 se ele teve uma resposta, mas ele não respondeu imediatamente.
Procedimentos não padronizados
Falando nessas normas, a JetBrains fez questão de destacar as normas de divulgação de outros grandes fornecedores do setor, como Google e Microsoft.
A equipe do Project Zero do Google segue uma política que concede aos fornecedores 90 dias para lançar correções para vulnerabilidades e mais 30 dias após o lançamento, antes que informações detalhadas sobre elas sejam divulgadas.
A Microsoft adota uma abordagem mais equilibrada, reconhecendo que a divulgação antecipada força os fornecedores a desenvolver correções mais rapidamente e os administradores de sistemas a aplicá-las também mais rapidamente, mas também observa que a divulgação de informações que podem levar ao desenvolvimento de exploração aumenta significativamente o nível de risco.
Da mesma forma, o OWASP reconhece os méritos de ambos os lados e sugere encontrar um compromisso nas políticas de divulgação se as duas partes diferirem substancialmente. No entanto, observa que seria “sensato” que os detalhes sobre vulnerabilidades graves tivessem um atraso na publicação para limitar o potencial de danos.
As autoridades nacionais e internacionais de cibersegurança geralmente concordam que é necessário um atraso entre a notificação e a divulgação pública de detalhes das vulnerabilidades, embora esses atrasos possam variar entre os países.
A Espanha, por exemplo, publicará detalhes de um problema de segurança se o fornecedor não conseguir corrigi-lo no prazo de 60 dias. O prazo padrão do Luxemburgo é menor, de 30 dias, embora com flexibilidade incorporada para situações mais complexas, enquanto a Agência de Segurança Cibernética e de Infraestrutura (CISA) dos EUA pode divulgar uma vulnerabilidade 45 dias após a primeira tentativa de contactar o fornecedor relevante.
A agência de cibersegurança da UE, ENISA, estabelece nas suas orientações para o desenvolvimento de uma política de divulgação que um patch deve ser sempre desenvolvido no prazo máximo de 90 dias. Ele também aconselha que os relatores devem “respeitar um período razoável” a partir do momento em que um patch é criado antes de divulgar publicamente os detalhes da vulnerabilidade, permitindo que os usuários a apliquem com prioridade.
A política de divulgação da Rapid7 prioriza divulgações oportunas. A política diz: “Através de divulgações de vulnerabilidades transparentes, abertas e oportunas, o Rapid7 ajuda toda a Internet a proteger e defender os ativos e serviços essenciais para a civilização moderna”.
A política estipula que os fornecedores têm 60 dias a partir do ponto de divulgação para lançar uma correção antes da divulgação pública, com a oportunidade de estender esse prazo por mais 30 dias se uma correção não puder ser desenvolvida nesse período e, o que é crucial, o fornecedor trabalha em boa fé.
Ele também diz que a empresa publicará detalhes de vulnerabilidade dentro de 24 horas se suspeitar que um fornecedor corrige vulnerabilidades silenciosamente.
O cronograma de divulgação da Rapid7 indica que tanto ela quanto a JetBrains diferiram em sua definição do que se entende por “patches silenciosos”, e depois de ver os patches TeamCity da JetBrains entrarem no ar, foi isso que desencadeou a publicação completa do pesquisador.
Além disso, como a própria JetBrains admitiu, decidiu quatro dias após a divulgação do Rapid7 que não seguiria uma divulgação coordenada com os pesquisadores. Isso ocorreu devido à relutância em permitir um atraso na publicação após o lançamento dos patches.
A JetBrains disse que esta foi uma decisão tomada para proteger seus próprios clientes de explorações, mas a Rapid7 provavelmente viu isso como uma relação de trabalho de má-fé.
Onde agora?
Pode muito bem ser o caso de ambos os fornecedores terem dado a sua opinião e uma resolução não poder ser alcançada, por isso pode ser a última vez que ouviremos falar disso.
No entanto, as idas e vindas devem informar futuras discussões sobre divulgações públicas, e os ataques de ransomware contra clientes do TeamCity não devem ser encarados levianamente. O custo médio de remediar um ataque é de aproximadamente US$ 1,5 milhão, o que significa que os fornecedores devem considerar seriamente o momento de suas divulgações públicas.
Mesmo que a Rapid7 pensasse que a JetBrains estava corrigindo vulnerabilidades silenciosamente, uma afirmação que a JetBrains nega, esperar uma semana antes de divulgar o desenvolvedor pode ter ajudado os clientes a aplicar patches para evitar esses ataques caros.
Também não há garantia de que esperar esse tempo teria levado os administradores a agir para corrigir as falhas, portanto, há argumentos a serem apresentados para ambos os lados. Talvez o conselho do OWASP para chegar a um compromisso, através de uma boa comunicação, possa ter sido o melhor resultado aqui.
Um porta-voz da Rapid7 nos enviou uma declaração: “A Rapid7 cumpre suas políticas de divulgação”. ®
.
