Devido ao teor, este artigo é um aviso de utilidade pública.

Este artigo foi traduzido e adaptado de: https://www.jsof-tech.com/ripple20/

Acesse o paper 

Visão geral – Ripple20

O laboratório de pesquisa JSOF descobriu uma série de vulnerabilidades de dia zero em uma biblioteca de software TCP/IP de baixo nível amplamente usada desenvolvida pela Treck, Inc. As 19 vulnerabilidades, com o nome Ripple20 , afetam centenas de milhões de dispositivos (ou mais) e inclui várias vulnerabilidades de execução remota de código. Os riscos inerentes a esta situação são elevados. Apenas alguns exemplos: dados podem ser roubados de uma impressora, o comportamento de uma bomba de infusão pode ser alterado ou dispositivos de controle industrial podem apresentar problemas de funcionamento. Um invasor pode ocultar código malicioso em dispositivos incorporados por anos. Uma das vulnerabilidades pode permitir a entrada de fora nos limites da rede; e esta é apenas uma pequena amostra dos riscos potenciais.

O interessante sobre o Ripple20 é a incrível extensão de seu impacto, ampliado pelo fator da cadeia de suprimentos. A ampla disseminação da biblioteca de software (e suas vulnerabilidades internas) foi uma consequência natural do “efeito cascata” da cadeia de suprimentos. Um único componente vulnerável, embora possa ser relativamente pequeno por si só, pode se espalhar para impactar uma ampla gama de setores, aplicativos, empresas e pessoas.

Ripple20 alcançou dispositivos IoT críticos em uma ampla gama de campos, envolvendo um grupo diversificado de fornecedores. Os fornecedores afetados variam de butiques individuais a corporações multinacionais da Fortune 500, incluindo HP, Schneider Electric, Intel, Rockwell Automation, Caterpillar, Baxter, bem como muitos outros fornecedores internacionais importantes suspeitos de serem vulneráveis ​​em medicina, transporte, controle industrial , empresa, energia (petróleo / gás), telecomunicações, varejo e comércio e outras indústrias.

Um relatório técnico detalhado de duas das vulnerabilidades e sua exploração pode ser encontrado no whitepaper CVE-2020-11896 / CVE-2020-11898 clique aqui ). 

O JSOF demonstrou a exploração dessas vulnerabilidades em diferentes dispositivos como prova de conceito. Observe-nos desligar o plugue de um no-break:

JSOF fornecerá scripts para a identificação de produtos rodando Treck mediante solicitação.
Para mais informações ou solicitações, entre em contato: [email protected]

Seguindo a trilha do software

A biblioteca de software se espalhou por toda parte, a ponto de rastreá-la ser um grande desafio. Conforme rastreamos a trilha de distribuição da biblioteca TCP / IP de Treck, descobrimos que nas últimas duas décadas essa peça básica de software de rede se espalhou pelo mundo, tanto por uso direto quanto indireto. Como vetor de disseminação, a complexa cadeia de suprimentos fornece o canal perfeito, possibilitando que a vulnerabilidade original se infiltre e se camufle quase indefinidamente.

Nós até descobrimos diferentes ramos em diferentes áreas geográficas. Na década de 1990, Treck colaborou com uma empresa japonesa chamada Elmic Systems. Mais tarde, eles se separaram e seguiram caminhos separados. Isso resultou em dois ramos separados dos dispositivos de pilha TCP / IP – um gerenciado pela Treck e outro gerenciado pela Elmic Systems – comercializados em áreas totalmente separadas, sem nenhum contato entre eles.

Além de ELMIC, a pilha Treck também pode ser conhecida por outros nomes: Net + OS, Quadnet, GHNET v2, Kwiknet.

JSOF foi convidado a falar sobre essas vulnerabilidades na Black Hat USA, agosto de 2020 . 

Mais Informações

Para obter uma descrição detalhada do efeito e impacto da cadeia de abastecimento do Ripple20 e como o JSOF o rastreou, consulte Cadeia de abastecimento divulgação .   

Para uma visão geral técnica, incluindo uma lista completa de fornecedores afetados, dê uma olhada na seção Visão geral técnica .
Consultas por: ICS CERT , CERT / CC ,  JPCERT / CC , CERT-IL Consultas por: ABB , Aruba Networ ks , B.Braun , Baxter , CareStream , Caterpillar , Cisco , Di gi International , Green Hills , HP , HPE , Intel , Miele , Opto22
     , Rockwell Automation ,  Schneider Electric , Smiths Medical Teradici , Xerox

Para Mitigações e Avaliação de Risco, consulte a seção Risco e Mitigação .

Avaliação e mitigações de risco

Ripple20 representa um risco significativo para os dispositivos ainda em uso. Os cenários de risco potenciais incluem:

  • Um invasor de fora da rede assumindo o controle de um dispositivo dentro da rede, se estiver voltado para a Internet.
  • Um invasor que já conseguiu se infiltrar em uma rede pode usar as vulnerabilidades da biblioteca para atingir dispositivos específicos dentro dela.
  • Um invasor pode transmitir um ataque capaz de controlar todos os dispositivos afetados na rede simultaneamente.
  • Um invasor pode utilizar o dispositivo afetado como uma forma de permanecer oculto na rede por anos
  • Um invasor sofisticado pode potencialmente executar um ataque a um dispositivo dentro da rede, de fora dos limites da rede, ignorando as configurações de NAT. Isso pode ser feito executando um ataque MITM ou envenenamento de cache DNS.
  • Em alguns cenários, um invasor pode ser capaz de realizar ataques de fora da rede, respondendo a pacotes que saem dos limites da rede, ignorando o NAT

Em todos os cenários, um invasor pode obter controle total sobre o dispositivo visado remotamente, sem a necessidade de interação do usuário.

JSOF recomenda tomar medidas para minimizar ou mitigar o risco de exploração do dispositivo. As opções de mitigação dependem do contexto. Os fornecedores de dispositivos teriam abordagens diferentes das operadoras de rede. Em geral, recomendamos as seguintes etapas: 

  • Todas as organizações devem realizar uma avaliação de risco abrangente antes de implantar medidas defensivas.
  • Primeiro implante medidas defensivas em um modo de “alerta” passivo.
  • Mitigação para fornecedores de dispositivos:
    • Determine se você usa uma pilha Treck vulnerável
    • Contate Treck para entender os riscos
    • Atualize para a versão mais recente da pilha Treck (6.0.1.67 ou superior)
    • Se as atualizações não forem possíveis, considere desativar os recursos vulneráveis, se possível
  • Mitigação para operadoras e redes: (com base em recomendações CERT/CC e CISA ICS-CERT)

    • A primeira e melhor mitigação é atualizar para versões com patch de todos os dispositivos.
    • Se os dispositivos não puderem ser atualizados, as seguintes etapas são recomendadas:
      • Minimize a exposição da rede para dispositivos integrados e essenciais, mantendo a exposição ao mínimo necessário e garantindo que os dispositivos não sejam acessíveis da Internet, a menos que seja absolutamente necessário.
      • Separe as redes e dispositivos OT atrás de firewalls e isole-os da rede comercial.
      • Habilite apenas métodos de acesso remoto seguro.
    • Bloqueie o tráfego IP anômalo.
    • Bloqueie ataques de rede por meio de inspeção profunda de pacotes, para reduzir o risco para seus dispositivos Treck habilitados para TCP/IP.

A filtragem preventiva de tráfego é uma técnica eficaz que pode ser aplicada conforme apropriado ao seu ambiente de rede. As opções de filtragem incluem:

  • Normalizar ou bloquear fragmentos de IP, se não houver suporte em seu ambiente.
    • Desabilite ou bloqueie o encapsulamento IP (encapsulamento IPv6-em-IPv4 ou IP-em-IP), se não for necessário.
    • Bloqueia o roteamento de origem de IP e quaisquer recursos IPv6 obsoletos, como cabeçalhos de roteamento VU # 267289
    • Inspeção TCP forçada, rejeitando pacotes TCP malformados.
    • Bloqueie mensagens de controle ICMP não utilizadas, como atualização de MTU e atualizações de máscara de endereço.
    • Normalize o DNS por meio de um servidor recursivo seguro ou firewall de inspeção de DNS. (Verifique se seu servidor DNS recursivo normaliza as solicitações.)
    • Fornece segurança DHCP/DHCPv6, com recursos como rastreamento de DHCP.
    • Desative/bloqueie os recursos multicast IPv6 se não forem usados ​​na infraestrutura de comutação.
    • Desabilite o DHCP onde IPs estáticos podem ser usados.
    • Empregar assinaturas de IDS e IPS de rede.
  • Empregue segmentação de rede, se disponível.

Visão geral técnica

Ripple20 é um conjunto de 19 vulnerabilidades encontradas na pilha Treck TCP/IP. Quatro das vulnerabilidades Ripple20 são classificadas como críticas, com pontuações CVSS acima de 9 e permitem a execução remota de código. Uma das vulnerabilidades críticas está no protocolo DNS e pode ser potencialmente explorável por um invasor sofisticado pela Internet, de fora dos limites da rede, mesmo em dispositivos que não estão conectados à Internet.

 Um segundo Whitepaper, a ser lançado após BlackHat USA 2020, irá detalhar a exploração do CVE-2020-11901, uma vulnerabilidade de DNS, em um dispositivo Schneider Electric APC UPS.  As outras 15 vulnerabilidades estão em vários graus de severidade com pontuação CVSS variando de 3,1 a 8,2, e efeitos que variam de negação de serviço a potencial execução remota de código.

A maioria das vulnerabilidades são verdadeiros dias zero, com 4 delas fechadas ao longo dos anos como parte das alterações de código de rotina, mas permaneceram abertas em alguns dos dispositivos afetados (3 de gravidade inferior, 1 superior). Muitas das vulnerabilidades têm diversas variantes devido à configurabilidade do Stack e às mudanças de código ao longo dos anos.

Ripple20 são as únicas vulnerabilidades relatadas no Treck até o momento, pelo que sabemos, exceto por algumas vulnerabilidades lógicas gerais mencionadas no passado que pertenciam a muitas implementações de pilha e geralmente tinham a ver com interpretações incorretas de RFC ou RFCs obsoletos.

As vulnerabilidades do Ripple20 são únicas em seu efeito e impacto generalizados devido ao efeito da cadeia de suprimentos e são vulnerabilidades que permitem que os invasores contornem o NAT e os firewalls e assumam o controle dos dispositivos sem serem detectados, sem a necessidade de interação do usuário. Isso ocorre devido às vulnerabilidades estarem em uma pilha TCP/IP de baixo nível e ao fato de que para muitas das vulnerabilidades, os pacotes enviados são muito semelhantes aos pacotes válidos ou, em alguns casos, são pacotes completamente válidos. Isso permite que o ataque passe como tráfego legítimo.

Um white paper descrevendo uma terceira vulnerabilidade e exploração no UPS será lançado após o Black Hat USA 2020.

 

As vulnerabilidades incluem:

ID CVE

CVSSv3

Descrição

Impacto potencial

Fixo na versão

CVE-2020-11896

10

Esta vulnerabilidade pode ser acionada pelo envio de vários pacotes IPv4 malformados para um dispositivo com suporte para encapsulamento IPv4. Afeta qualquer dispositivo rodando Treck com uma configuração específica. Ele pode permitir uma execução remota de código estável e foi demonstrado em um dispositivo Digi International. Variantes desse problema podem ser acionadas para causar uma negação de serviço ou uma negação de serviço persistente, exigindo uma reinicialização a frio.

Controlo remoto 

Código 

Execução

6.0.1.66

(versão 30/03/2020)

CVE-2020-11897

10

Esta vulnerabilidade pode ser desencadeada pelo envio de vários pacotes IPv6 malformados para um dispositivo. Afeta qualquer dispositivo executando uma versão mais antiga do Treck com suporte a IPv6 e foi corrigido anteriormente como uma alteração de código de rotina. Pode permitir uma execução remota de código estável.

Fora dos limites 

Escrita

5.0.1.35

(lançamento 06/04/2009)

CVE-2020-11901

9

Essa vulnerabilidade pode ser acionada respondendo a uma única solicitação DNS feita a partir do dispositivo. Afeta qualquer dispositivo executando Treck com suporte DNS e demonstramos que pode ser usado para executar a execução remota de código em um no-break APC da Schneider Electric. Em nossa opinião, esta é a vulnerabilidade mais grave, apesar de ter uma pontuação de CVSS de 9,0, devido ao fato de que as solicitações de DNS podem deixar a rede em que o dispositivo está localizado, e um invasor sofisticado pode ser capaz de usar essa vulnerabilidade para tomar através de um dispositivo de fora da rede por meio de envenenamento de cache DNS ou outros métodos. Assim, um invasor pode se infiltrar na rede e assumir o controle do dispositivo com uma vulnerabilidade, evitando quaisquer medidas de segurança. 

O pacote malformado é quase totalmente compatível com RFC e, portanto, provavelmente será difícil para produtos de segurança, como firewalls, detectar essa vulnerabilidade. Em versões muito antigas da pilha Treck, ainda em execução em alguns dispositivos, a ID da transação não é aleatória, tornando o ataque mais fácil.

Controlo remoto 

Código 

Execução

6.0.1.66

(versão 03/03/2020)

Vulnerabilidades adicionais estão listadas abaixo.

ID CVE

Pontuação CVSSv3

Descrição

Fixado na versão

CVE-2020-11898

9,1

Tratamento impróprio de inconsistência de parâmetro de comprimento (CWE-130) no componente IPv4/ICMPv4, ao lidar com um pacote enviado por um invasor de rede não autorizado. Possível exposição de informações sensíveis (CWE-200)

6.0.1.66

(versão 03/03/2020)

CVE-2020-11900

8,2

Possível Double Free (CWE-415) no componente de encapsulamento IPv4 ao lidar com um pacote enviado por um invasor de rede. Use depois de graça (CWE-416)

6.0.1.41

(versão 15/10/2014)

CVE-2020-11902

7,3

Validação de entrada inadequada (CWE-20) no componente de encapsulamento IPv6OverIPv4 ao lidar com um pacote enviado por um invasor de rede não autorizado. Possível leitura fora dos limites (CWE-125)

6.0.1.66

(versão 03/03/20)

CVE-2020-11904

5,6

Possível estouro de número inteiro ou Wraparound (CWE-190) no componente de alocação de memória ao lidar com um pacote enviado por um invasor de rede não autorizado

Possível gravação fora dos limites (CWE-787)

6.0.1.66

(versão 03/03/2020)

CVE-2020-11899

5,4

Validação de entrada inadequada (CWE-20) no componente IPv6 ao lidar com um pacote enviado por um invasor de rede não autorizado.

Possível leitura fora dos limites (CWE-125) e possível negação de serviço.  

6.0.1.66

(versão 03/03/20)

CVE-2020-11903

5,3

Possível leitura fora dos limites (CWE-125) no componente DHCP ao lidar com um pacote enviado por um invasor de rede não autorizado.

Possível exposição de informações sensíveis (CWE-200)

6.0.1.28

(versão 10/10/12)

CVE-2020-11905

5,3

Possível leitura fora dos limites (CWE-125) no componente DHCPv6 ao lidar com um pacote enviado por um invasor de rede não autorizado.

Possível exposição de informações sensíveis (CWE-200)

6.0.1.66

(versão 03/03/20)

CVE-2020-11906

5

Validação de entrada inadequada (CWE-20) no componente Ethernet Link Layer de um pacote enviado por um usuário não autorizado.

Underflow inteiro (CWE-191)

6.0.1.66

(versão 03/03/20)

CVE-2020-11907

5

Tratamento impróprio de inconsistência de parâmetro de comprimento (CWE-130) no componente TCP, de um pacote enviado por um invasor de rede não autorizado

Underflow inteiro (CWE-191) 

6.0.1.66

(versão 03/03/20)

CVE-2020-11909

3,7

Validação de entrada inadequada (CWE-20) no componente IPv4 ao lidar com um pacote enviado por um invasor de rede não autorizado.

Underflow inteiro (CWE-191)

6.0.1.66

(versão 03/03/20)

CVE-2020-11910

3,7

Validação de entrada inadequada (CWE-20) no componente ICMPv4 ao lidar com um pacote enviado por um invasor de rede não autorizado.

Possível leitura fora dos limites (CWE-125)

6.0.1.66

(versão 03/03/20)

CVE-2020-11911

3,7

Controle de acesso impróprio (CWE-284) no componente ICMPv4 ao lidar com um pacote enviado por um invasor de rede não autorizado. Atribuição incorreta de permissão para recurso crítico (CWE-732)

6.0.1.66

(versão 03/03/20)

CVE-2020-11912

3,7

Validação de entrada inadequada (CWE-20) no componente TCP ao lidar com um pacote enviado por um invasor de rede não autorizado.

Possível leitura fora dos limites (CWE-125)

6.0.1.66

(versão 03/03/20)

CVE-2020-11913

3,7

Validação de entrada inadequada (CWE-20) no componente IPv6 ao lidar com um pacote enviado por um invasor de rede não autorizado.

Possível leitura fora dos limites (CWE-125)

6.0.1.66

(versão 03/03/20)

CVE-2020-11914

3,1

“Validação de entrada inadequada (CWE-20) no componente ARP ao lidar com um pacote enviado por um invasor de rede não autorizado.”

Possível leitura fora dos limites (CWE-125) 

6.0.1.66

(versão 03/03/20)

CVE-2020-11908

3,1

Terminação nula imprópria (CWE-170) no componente DHCP ao lidar com um pacote enviado por um invasor de rede não autorizado.

Possível exposição de informações sensíveis (CWE-200)

4.7.1.27

(versão 11/08/07)

Fornecedores Afetados

A lista de fornecedores foi montada cuidadosamente por diferentes meios e representa os fornecedores que podem ser afetados. A lista contém apenas fornecedores que a CISA ICS-CERT listou em um documento interno como tendo sido contatados.

O status de cada investigação interna do fornecedor é fornecido pela CISA ICS-CERT de acordo com a resposta do fornecedor. Os fornecedores declarando que não foram afetados também são registrados para fins de prestação de contas e consultas futuras se forem levantados novamente como tendo produtos potencialmente afetados.

A lista de produtos afetados pode ser encontrada no comunicado do fornecedor com link acima ou diretamente com o fornecedor.

A lista será atualizada de tempos em tempos. Qualquer fornecedor que quiser relatar um status diferente ou acreditar que haja um erro pode fazê-lo por meio de uma agência de coordenação ou enviando um e-mail para [email protected]

Consulte os fabricantes notificados no site da JSOF:https://www.jsof-tech.com/ripple20/

Cadeia de mantimentos

Para lidar efetivamente com os perigos do Ripple20 , o padrão de distribuição generalizado deve ser cuidadosamente rastreado ao longo da complexa cadeia de suprimentos. Durante o processo de divulgação, o JSOF rastreou a cadeia de abastecimento de forma criativa, na tentativa de compreender a escala de distribuição e a abrangência do problema. Foi quando começamos a avaliar o quão extensa era a imagem da cadeia de suprimentos. Durante o processo de divulgação, também fomos notificados de que há 2 vulnerabilidades adicionais divulgadas anonimamente ao mesmo tempo. Isso faz parte das 19 vulnerabilidades do Ripple20, e todas as partes envolvidas têm lidado com essas vulnerabilidades como parte do mesmo processo de divulgação e não há outras ações a serem tomadas pelos fornecedores. 

Podíamos rastrear as trilhas da cadeia de suprimentos, mas precisávamos trabalhar com organizações internacionais para estender nosso alcance dentro de organizações e domínios aos quais não tínhamos acesso. É por isso que o processo de divulgação do Ripple20 está sendo coordenado e supervisionado por várias organizações e reguladores da equipe nacional de resposta a emergências de computadores (CERT). Também temos colaborado com outros fornecedores de segurança. Como pode ser entendido pela escala do problema, o trabalho em equipe aqui é essencial e beneficia todos os jogadores.

Assim que o Ripple20 for divulgado, esperamos aumentar a conscientização, permitindo que mais empresas usem as informações para determinar por si mesmas se seus produtos, ou produtos que estão usando, são vulneráveis.

Estaremos lançando uma postagem no blog dedicada aos métodos que usamos para rastrear a cadeia de suprimentos e descobrir suas complexidades.

Vulnerabilidade: dependente da indústria ou setores afetados

No caso do Ripple20, o ponto de partida foi embutido na biblioteca do pacote de protocolos da Internet de baixo nível TCP/IP de Treck. A biblioteca pode ser usada como está, configurada para uma ampla gama de usos ou incorporada a uma biblioteca maior. O usuário pode comprar a biblioteca em formato de código-fonte e editá-la extensivamente. Ele pode ser incorporado ao código e implantado em uma ampla variedade de tipos de dispositivos. O comprador original pode decidir mudar a marca ou pode ser adquirido por uma empresa diferente, com a história da biblioteca original perdida nos arquivos da empresa. Com o tempo, o componente original da biblioteca pode se tornar virtualmente irreconhecível. É por isso que, muito depois que a vulnerabilidade original foi identificada e corrigida, as vulnerabilidades ainda podem permanecer no campo, uma vez que rastrear a trilha da cadeia de suprimentos pode ser praticamente impossível.

O JSOF conduziu análises extensas e profundas, ao longo de muitos meses, dos fornecedores afetados pela vulnerabilidade da biblioteca do protocolo Treck Internet. O primeiro desafio que enfrentamos foi simplesmente ser capaz de identificar os fornecedores relevantes. A identidade do fornecedor poderia ser obscurecida pelas complexidades da cadeia de suprimentos. Mesmo quando os fornecedores são identificados, a implementação do patch é complexa e nem sempre possível. No decorrer do processo de divulgação, descobrimos que embora a aplicação de patches fosse difícil para alguns fornecedores, poderia ser potencialmente ainda mais difícil ou quase impossível para alguns usuários finais instalar os patches. (Por exemplo, se a biblioteca estiver em um componente físico separado ou a empresa que produziu o componente encerrou as operações.)

O número de dispositivos que contêm a biblioteca de base de código vulnerável é apenas uma estimativa preliminar; o número pode realisticamente estar na casa dos bilhões.

Divulgação

Do começo

A história do Ripple20 começa em setembro de 2019, quando decidimos começar algumas pesquisas em tempo parcial sobre a biblioteca Treck TCP/IP. Em alguns meses, percebemos que havia alguns dados preocupantes sobre vulnerabilidades em potencial e contatamos Treck para compartilhar nossas informações, bem como iniciar um processo de divulgação coordenada de vulnerabilidade (CVD). Entendemos desde o início que Treck trabalhava com muitos fornecedores diferentes, com potencial para impactar um grande número de usuários. No entanto, simplesmente não tínhamos ideia da escala e da magnitude da situação, nem de quão complexa se tornou a cadeia de suprimentos. 

Nosso envolvimento com Treck foi inicialmente desafiador. A Treck é uma pequena empresa que atende a uma clientela de nicho e geralmente não está disponível para a abordagem do consumidor individual. Eles também nunca parecem ter sido alvo de pesquisas de segurança independentes. Por fim, conseguimos rastrear um contato de e-mail na Treck e recebemos uma introdução. Nós os notificamos de que encontramos uma vulnerabilidade crítica de segurança em sua biblioteca de pilha TCP/IP e preferimos trabalhar diretamente com eles. Inicialmente, nos deparamos com uma comunicação mínima. Posteriormente, soubemos que Treck estava avaliando as informações internamente e com seus assessores jurídicos. (Também notamos advogados de litígio nos verificando no LinkedIn e em outros lugares).

Posteriormente, começamos a entrar em contato com alguns fornecedores selecionados (como Digi, HP, Intel e Quadros) que sabíamos que usavam produtos Treck e sua biblioteca de pilha TCP/IP vulnerável, e pedimos que nos ajudassem a fazer a conexão apropriada com Treck. Depois desse contato com o vendedor, a bola começou a rolar com Treck.

Trabalhando com Treck

Depois que Treck entendeu a gravidade das vulnerabilidades, trabalhamos juntos em cooperação, e o JSOF forneceu-lhes descrições das vulnerabilidades e algumas outras informações.

Era importante para nós que Treck garantisse que seus clientes fossem notificados sobre as vulnerabilidades em questão. Devido a NDAs e outras complexidades, Treck não foi capaz de nos fornecer uma lista de seus clientes e usuários da biblioteca de códigos. Este foi nosso primeiro contato com alguns dos desafios da cadeia de suprimentos. Como resultado, Treck acabou assumindo a liderança no processo de divulgação, já que eram os mais adequados para notificar seus clientes e fornecer os patches adequados.

Curiosamente, o processo de remediação da vulnerabilidade levou alguns dos clientes de Treck a renovar contratos de suporte, portanto, Treck parece ter acabado lucrando com a situação. Quando essas empresas foram notificadas sobre o Ripple20 e compreenderam bem os riscos potenciais, logo perceberam a necessidade de manutenção contínua e a importância do acesso aos patches. No final, muitas das empresas trabalharam com Treck para renovar seus contratos ou fazer outros acordos. Esta é uma lição instigante para pequenos e grandes fornecedores, preocupados com os problemas de segurança. Uma abordagem de resposta de segurança proativa significa que os clientes têm um motivo para pagar pela manutenção e suporte para manter o software atualizado.

A prática padrão da indústria é não divulgar uma vulnerabilidade até que haja um patch disponível para corrigi-la. Nós concordamos com um período padrão de 90 dias dentro do qual Treck consertaria as vulnerabilidades e notificaria seus clientes sobre o patch. Treck estava com o patch disponível no final de março – 45 dias antes do prazo de 90 dias, e nos informou que eles entrariam em contato com todos os clientes afetados para informá-los sobre essas vulnerabilidades. 

A divulgação foi adiada duas vezes após a solicitação de mais tempo de alguns dos fornecedores participantes, com alguns deles divulgando atrasos relacionados à Covid-19. Fora de consideração para essas empresas, o prazo foi estendido de 90 dias para mais de 120 dias. Mesmo assim, algumas das empresas participantes tornaram-se difíceis de lidar, pois fizeram demandas extras e algumas, em nossa perspectiva, pareciam muito mais preocupadas com a imagem de sua marca do que em corrigir as vulnerabilidades.

Após algumas deliberações, o dia 16 de junho foi a data escolhida para a divulgação do Ripple20 . Nesse ínterim, uma vez que entendemos a extensão das vulnerabilidades e os números absolutos envolvidos, nos concentramos em como usar melhor nosso tempo (120 dias de paciência) para identificar e ajudar a resolver todas as partes que poderiam estar em risco.

Um esforço internacional

Como a Treck não foi capaz de nos fornecer uma lista completa de sua clientela, decidimos criar a nossa própria, a fim de descobrir quem foi afetado e garantir que todos fossem notificados e teriam a vulnerabilidade corrigida. Usamos uma abordagem criativa de rastreamento da cadeia de suprimentos, na tentativa de compreender a escala de distribuição e a extensão do problema. Logo começamos a perceber e apreciar o quão complexo o quadro da cadeia de suprimentos realmente era.

Ficou claro para nós que rastrear a extensão da distribuição da biblioteca Treck era muito grande para apenas uma pequena equipe. Podíamos rastrear as trilhas da cadeia de suprimentos, mas precisávamos trabalhar com organizações internacionais para estender nosso alcance dentro de organizações e domínios aos quais não tínhamos acesso.

É por isso que o processo de divulgação do Ripple20 está sendo coordenado e supervisionado por várias organizações e reguladores da equipe nacional de resposta a emergências de computadores (CERT). Todos estão colaborando para alcançar o maior número possível de fornecedores afetados antes que as vulnerabilidades se tornem públicas. Nossos colaboradores inicialmente incluíam:

  • O CERT Coordination Center ( CERT/CC ), o centro mundial para coordenar informações sobre segurança na Internet na Carnegie Mellon University. Este é o primeiro (e mais conhecido) CERT.
  • A Cybersecurity and Infrastructure Security Agency ( CISA ), parte do Departamento de Segurança Interna ( DHS )

Os grupos CERT se concentram em maneiras de identificar e mitigar riscos de segurança. Por exemplo, eles podem atingir um grupo-alvo muito maior de usuários em potencial com anúncios explosivos, “e-mails em massa” que eles transmitem para uma longa lista de empresas participantes para notificá-los sobre a vulnerabilidade potencial. Depois que os usuários são identificados, a mitigação entra em jogo. Embora a melhor resposta possa ser instalar o patch Treck original, há muitas situações em que a instalação do patch original não é possível. CERTs trabalham para desenvolver abordagens alternativas que podem ser usadas para minimizar ou eliminar efetivamente o risco, mesmo se a correção não for uma opção.

O JSOF auxiliou na coordenação do processo de divulgação, incluindo o fornecimento de scripts de prova de conceito para algumas das vulnerabilidades, sugerindo mitigações e fornecendo listas adicionais de usuários da biblioteca Treck. Rastreamos esses usuários de várias maneiras criativas, incluindo o trabalho com parceiros, bem como algumas coleções de inteligência de código aberto interessantes.

Trabalhar com grupos internacionais era essencial neste caso por outro motivo. Na década de 1990, Treck colaborou com uma empresa japonesa chamada Elmic Systems. As informações publicadas sugerem que as duas empresas co-desenvolveram a pilha TCP/IP, embora não tenhamos certeza de como essa colaboração evoluiu ao longo dos anos. Treck e Elmic mais tarde se separaram e seguiram caminhos separados. A Treck agora comercializa esta pilha como Treck TCP/IP nos Estados Unidos, enquanto a Elmic Systems, agora chamada de Zuken Elmic, a comercializa como Kasago TCP/IP na Ásia. Isso resultou em dois ramos separados dos dispositivos de pilha TCP/IP – um gerenciado por Treck e outro gerenciado pela Elmic Systems – comercializados em áreas geográficas totalmente separadas, sem nenhuma cooperação entre eles, até onde sabemos, até que relatamos as vulnerabilidades. Tentamos entrar em contato com Zuken Elmic no início, mas não tiveram sucesso; eles pararam de responder após uma curta correspondência por e-mail. (Nós até tentamos enviar alguns e-mails em japonês!) Mais tarde, CERT/CC conseguiu coordenar com JPCERT/CC, uma organização CERT nacional do Japão, que está lidando com o acompanhamento com Elmic Systems e outras empresas afetadas no Japão/Cadeia de abastecimento asiática. Confirmamos com Zuken Elmic que sua pilha TCP/IP é afetada por algumas das vulnerabilidades Treck. A pesquisa inicial mostra que o Kasago é amplamente utilizado, proporcionando o início de uma cadeia de suprimentos completamente diferente. quem está lidando com o acompanhamento com a Elmic Systems e outras empresas afetadas na cadeia de suprimentos japonesa/asiática. Confirmamos com Zuken Elmic que sua pilha TCP/IP é afetada por algumas das vulnerabilidades Treck. A pesquisa inicial mostra que o Kasago é amplamente utilizado, proporcionando o início de uma cadeia de suprimentos completamente diferente. quem está lidando com o acompanhamento com a Elmic Systems e outras empresas afetadas na cadeia de suprimentos japonesa/asiática. Confirmamos com Zuken Elmic que sua pilha TCP/IP é afetada por algumas das vulnerabilidades Treck. A pesquisa inicial mostra que o Kasago é amplamente utilizado, proporcionando o início de uma cadeia de suprimentos completamente diferente.