Remember Heartbleed? Se você acredita na propaganda de hoje, Shellshock está nessa liga e com um nome igualmente impressionante, embora sem um logo legal (alguém do departamento de marketing desses abutres precisa entrar nessa). Mas com toda a seriedade, ele tem o potencial de ser um grande sucesso e, como eu fiz com o Heartbleed, eu queria montar algo definitivo, tanto para mim, para me adaptar à situação, quanto para outros, para dissecar o hype do verdadeiro risco subjacente.
Para montar o cenário, deixe-me compartilhar algum conteúdo do post do blog de Robert Graham, que tem feito uma excelente análise sobre isso. Imagine um pedido HTTP como este:
target = 0.0.0.0/0port = 80banners = truehttp-user-agent = shellshock-scan (http://blog.erratasec.com/2014/09/bash-shellshock-scan-of-internet.html)http-header = Cookie:() { :; }; ping -c 3 209.126.230.74http-header = Host:() { :; }; ping -c 3 209.126.230.74http-header = Referer:() { :; }; ping -c 3 209.126.230.74
Que, quando emitido contra uma gama de endereços IP vulneráveis, resulta nisto:
Ponte sucintamente, Robert acaba de orquestrar um monte de máquinas externas para pingá-lo simplesmente emitindo um pedido cuidadosamente elaborado através da web. O que é realmente preocupante é que ele fez com que essas máquinas efetivamente emitissem um comando arbitrário (embora um ping bastante benigno) e isso abre todo um mundo de possibilidades muito sérias. Deixe-me explicar.
O que é o Bash e porque precisamos dele?
Skip isto se são notícias antigas, mas o contexto é importante para aqueles que não estão familiarizados com o Bash, por isso vamos estabelecer um entendimento de base. Bash é uma shell *nix ou, por outras palavras, um interpretador que lhe permite orquestrar comandos em sistemas Unix e Linux, normalmente ligando-se através de SSH ou Telnet. Ele também pode operar como um interpretador para scripts CGI em um servidor web, como nós normalmente veríamos rodando no Apache. Ele existe desde o final dos anos 80 onde evoluiu de implementações shell anteriores (o nome é derivado da shell Bourne) e é enormemente popular. Existem outros shells para variantes Unix, mas o Bash é o shell padrão para Linux e Mac OS X, que são obviamente sistemas operacionais extremamente prevalecentes. Isso é um factor importante no porquê deste risco ser tão significativo – a ubiquidade do Bash – e está a ser descrito como “um dos utilitários mais instalados em qualquer sistema Linux”.
Pode ter uma ideia da pegada do Bash quando olhar para as últimas estatísticas do servidor web Netcraft:
Quando metade da rede está a correr o Apache (que é tipicamente encontrado no Linux), isso é um tamanho significativo de uma tarte muito, muito grande. Esse mesmo artigo do Netcraft está relatando que acabamos de passar a marca de um bilhão de websites também e enquanto um monte deles está compartilhando os mesmos hosts, isso ainda é um monte de instalações do Bash. Oh – isso também são apenas servidores web, não se esqueça que há um monte de outros servidores a correr Linux e voltaremos a outros dispositivos com o Bash um pouco mais tarde.
Bash pode ser usado para uma série de funções administrativas típicas, tudo desde configurar websites até ao controlo de software incorporado num dispositivo como uma webcam. Naturalmente esta não é uma funcionalidade que pretende ser aberta ao mundo e, em teoria, estamos a falar de utilizadores autenticados que executam comandos que foram autorizados a executar. Em teoria.
Qual é o bug?
Deixem-me começar com o CVE da base de dados de vulnerabilidades do NIST porque ele dá uma boa noção da severidade (destaque meu):
GNU Bash até 4.3 processos que seguem strings após definições de funções nos valores das variáveis de ambiente, o que permite que atacantes remotos executem código arbitrário via ambiente crafted, como demonstrado por vetores envolvendo o recurso ForceCommand no sshd do OpenSSH, os módulos mod_cgi e mod_cgid no Apache HTTP Server, scripts executados por clientes DHCP não especificados, e outras situações em que a configuração do ambiente ocorre através de um limite de privilégios da execução do Bash.
Vão para classificá-lo como “10 em 10” por severidade ou, em outras palavras, por pior que seja. Isto é agravado pelo facto de ser fácil executar o ataque (a complexidade de acesso é baixa) e talvez mais significativamente, não há necessidade de autenticação ao explorar o Bash através de scripts CGI. O resumo acima é um pouco convoluto, mas vamos resumi-lo à mecânica do bug.
O risco centra-se na capacidade de definir arbitrariamente variáveis de ambiente dentro de uma shell Bash que especifica uma definição de função. O problema começa quando o Bash continua a processar comandos shell após a definição da função, resultando no que nós classificaríamos como um “ataque de injeção de código”. Vamos ver o exemplo do Robert novamente e vamos pegar esta linha:
http-header = Cookie:() { :; }; ping -c 3 209.126.230.74
A definição da função é () { :; }; e o comando shell é a instrução ping e parâmetros subsequentes. Quando isto é processado dentro do contexto de uma shell Bash, o comando arbitrário é executado. Em um contexto web, isto significaria através de um mecanismo como um script CGI e não necessariamente como um cabeçalho de requisição também. Vale a pena ter uma leitura através do aconselhamento seclists.org onde eles entram em mais detalhes, incluindo afirmar que o caminho e a query string podem ser vectores potenciais para o ataque.
O claro que um meio de mitigar este vector de ataque em particular é simplesmente desactivar qualquer funcionalidade CGI que faça chamadas a uma shell e de facto alguns estão a recomendar isto. Em muitos casos, porém, isso vai ser uma mudança séria e, no mínimo, vai requerer alguns testes extensivos para garantir que não cause problemas imediatos no website, o que em muitos casos, vai.
A prova HTTP acima é simples mas eficaz, embora apenas uma implementação sobre um protocolo comum. Uma vez que você começa a lançar no Telnet e SSH e aparentemente até mesmo no DHCP, o escopo aumenta dramaticamente, então de forma alguma estamos apenas falando sobre a exploração de servidores de aplicações web aqui. (Aparentemente o risco só está presente no SSH pós-autenticação, mas numa fase tão precoce da divulgação pública veremos inevitavelmente outros vectores de ataque a surgir ainda.)
O que também precisa de se lembrar é que o âmbito dos danos potenciais vai muito além de pingar um endereço arbitrário como no exemplo de Robert, isso é simplesmente uma pequena prova clara de que ele poderia orquestrar uma máquina para emitir um comando shell. A questão torna-se esta: Que danos pode um atacante fazer quando pode executar um comando shell da sua escolha em qualquer máquina vulnerável?
Quais são as potenciais ramificações?
O potencial é enorme – “obter shell” numa caixa sempre foi uma grande vitória para um atacante devido ao controlo que lhes oferece sobre o ambiente alvo. Acesso a dados internos, reconfiguração de ambientes, publicação do seu próprio código malicioso, etc. É quase sem limites e também é prontamente automatizável. Já existem muitos, muitos exemplos de exploits por aí que poderiam ser facilmente disparados contra um grande volume de máquinas.
Felizmente quando se trata de execução arbitrária de código numa shell em até metade dos websites na internet, o potencial é bastante amplo. Um dos óbvios (e particularmente desagradáveis) é o despejo de arquivos internos para recuperação pública. Arquivos de senhas e arquivos de configuração com credenciais são os óbvios, mas poderiam se estender a qualquer outro arquivo no sistema.
Likewise, a mesma abordagem poderia ser aplicada para escrever arquivos para o sistema. Este é potencialmente o vector de desfaccionamento do website mais fácil que já vimos, para não mencionar uma forma muito fácil de distribuir malware
Or que tal isto: uma palavra que continuo a ver muito é “worm”:
Quando falamos de worm num contexto de computação maliciosa, estamos a falar de um ataque auto-replicável onde um actor malicioso cria código que é capaz de se propagar através de alvos. Por exemplo, vimos uma implementação muito eficaz disto com o MySpace XSS Worm do Samy, onde alguns criadores cuidadosos de JavaScript conseguiram “infectar” um milhão de páginas de vítimas em menos de um dia.
A preocupação com o Shellshock é que um ataque desta natureza pode replicar-se a um ritmo alarmante, particularmente cedo, enquanto a maioria das máquinas permanece em risco. Em teoria, isto poderia tomar a forma de uma varredura de máquina infectada em busca de outros alvos e propagar o ataque para eles. Isto também não estaria de forma alguma limitado a máquinas que enfrentam o público; colocar isto atrás do firewall corporativo e o céu é o limite.
As pessoas estão trabalhando para explorar isto agora mesmo. Isto é o que torna estes primeiros dias tão interessantes como a corrida de armas entre aqueles que lutam para remendar e aqueles que lutam para atacar aquece.
Que versões do Bash são afectadas?
As manchetes dizem tudo até 4.3 ou, por outras palavras, cerca de 25 anos de versões do Bash. Dado que todos continuam a comparar isto com o Heartbleed, considere que as versões impactadas do OpenSSL duraram apenas dois anos, o que é uma gota no oceano em comparação com o Shellshock. Sim as pessoas actualizam as suas versões, mas não o fazem de forma consistente e seja qual for a forma como o corta, a largura das máquinas de risco vai ser significativamente maior com o Shellshock do que com o Heartbleed.
Mas o risco pode muito bem estender-se para além de 4.3 também. Já estamos vendo relatos de patches não sendo totalmente eficazes e dada a velocidade com que estão sendo lançados, isso não é tão surpreendente assim. Este é o tipo de coisa em que aqueles que foram atingidos por ele querem estar muito atentos e não apenas “remendar e esquecer”.
Quando é que soubemos disto pela primeira vez e há quanto tempo estamos em risco?
A primeira menção que encontrei nas ondas aéreas públicas foi este breve resumo em seclists.org que funciona por volta das 14:00 GMT de quarta-feira (por volta da meia-noite desta manhã para aqueles de nós no extremo leste da Austrália). O detalhe veio no aviso que mencionei anteriormente uma hora mais tarde, portanto, chegando ao meio da tarde de quarta-feira na Europa ou pela manhã nos EUA. Ainda é uma notícia muito recente com todas as habituais especulações da imprensa e as previsões da Chicken Little; é muito cedo para observar qualquer exploração generalizada na natureza, mas isso também pode vir muito em breve se o risco atingir o seu potencial.
Voltar atrás para além do que foi revelado publicamente e o bug foi aparentemente descoberto na semana passada por Stéphane Chazelas, um tipo “Unix/Linux, especialista em redes e telecomunicações” no Reino Unido. Tendo dito isto, no post da Akamai sobre o bug, eles falam sobre a sua presença por “um longo período de tempo” e claro que as versões vulneráveis do Bash remontam já a duas décadas e meia. A questão, como no Heartbleed, será se os actores maliciosos estavam ou não conscientes disto antes e se estavam ou não a explorá-lo activamente.
As nossas “coisas” são afectadas?
É aqui que se torna interessante – temos muitas “coisas” potencialmente a correr o Bash. Claro que quando uso este termo estou a referir-me à “Internet das Coisas” (IoT) que é a prevalência crescente de bater um endereço IP e um adaptador sem fios em tudo, desde os nossos talheres até às fechaduras das portas e aos nossos globos de luz.
Muitos dispositivos IoT executam distribuições Linux embebidas com o Bash. Esses mesmos dispositivos já demonstraram sérias vulnerabilidades de segurança em outras áreas, por exemplo, os globos de luz LIFX há apenas alguns meses atrás foram encontrados vazando as credenciais wifi. Embora não seja uma vulnerabilidade Bash como o Shellshock, ele nos mostra que ao conectar nossas coisas estamos entrando em um mundo totalmente novo de vulnerabilidades em lugares que nunca estiveram em risco antes.
Edit: Algumas pessoas se referiram à prevalência do BusyBox rodando o Ash shell em dispositivos móveis. Dispositivos rodando isso não parecem estar correndo risco de Shellshock. A dificuldade para um consumidor é que ele não sabe o que está rodando em seus dispositivos, e isso inclui “coisas” mais tradicionais como roteadores também. A longa história deste bug significa que temos mais de duas décadas de dispositivos por aí que passaram por várias evoluções de diferentes SO embutidos e agora temos um cenário muito diversificado de máquinas e shells que se estendem por um longo período de tempo.
Isto traz consigo muitos novos desafios; por exemplo, quem está pensando ativamente que eles devem consertar regularmente suas lâmpadas? Considere também a longevidade dos dispositivos em que este software está a aparecer e se eles são realmente mantidos activamente. Em um caso como o das vulneráveis câmeras Trendnet de alguns anos atrás, há sem dúvida um grande número delas ainda sentadas na web porque em termos de correção, elas são praticamente uma proposta “set and forget”. Na verdade, nesse caso, há uma conta inteira no Twitter dedicada a transmitir as imagens que ele capturou de proprietários insuspeitos de versões vulneráveis. É um grande problema sem correcções fáceis e vai ficar connosco por muito tempo.
Mas os Bash shells também estão presentes em muitos dispositivos mais comuns, por exemplo os nossos routers domésticos que geralmente estão virados para a Internet. Lembras-te da última vez que corrigiste o firmware no teu router? Ok, se estás a ler isto então talvez sejas o tipo de pessoa técnica que realmente faz correcções no seu router, mas coloca-te no lugar do Average Joe Consumer e pergunta-te isso novamente. Exactamente.
Todas as nossas coisas estão na pilha da Microsoft, estamos em risco?
Resposta curta “não”, resposta longa “sim”. Vou abordar o fácil primeiro – o Bash não é encontrado nativamente no Windows e embora existam implementações Bash para Windows, certamente não é comum e não vai ser encontrado em PCs de consumo. Também não é claro se produtos como o win-bash são realmente vulneráveis ao Shellshock em primeiro lugar.
A resposta mais longa é que só porque você opera num ambiente predominantemente centrado na Microsoft não significa que você não tenha o Bash a funcionar em máquinas que servem outros propósitos discretos dentro desse ambiente. Quando escrevi sobre Heartbleed, referenciei o post de Nick Craver sobre a movimentação do Stack Overflow em direcção ao SSL e referi-me a este diagrama da sua infra-estrutura:
Existem componentes não-Microsoft sentados em frente à sua pilha de aplicações Microsoft, componentes pelos quais o tráfego precisa de passar antes de atingir os servidores Web. Estes também são componentes que podem ter privilégios elevados por trás do firewall – qual é o impacto se o Shellshock for explorado neles? Pode ser significativo e esse é o ponto que estou fazendo aqui; Shellshock tem o potencial de impactar ativos além das implementações de Bash em risco quando ele existe em um ecossistema mais amplo de outras máquinas.
Eu sou um administrador de sistemas – o que posso fazer?
Primeiro, descobrir se você está em risco é trivial, pois é um risco tão facilmente reproduzível. Existe um teste muito simples O Register sugere que está apenas a correr este comando dentro da sua shell:
env X="() { :;} ; echo busted" /bin/sh -c "echo stuff"env X="() { :;} ; echo busted" 'which bash' -c "echo completed"
Recusou o echo’d e explorou com sucesso o bug.
De certeza que a prioridade aqui vai ser a aplicação de patches em sistemas de risco e o patch resume-se essencialmente a garantir que nenhum código pode ser executado após o fim de uma função Bash. As distros Linux como a Red Hat estão lançando orientações sobre como aplicar patches nos sistemas de risco, então pule sobre isso como prioridade.
Vamos inevitavelmente também definições para sistemas de detecção de intrusão e certamente haverá padrões comuns a serem procurados aqui. Isso pode ser uma boa implementação imediata para muitas organizações, particularmente onde pode haver requisitos de testes onerosos antes de aplicar os patches em sistemas de risco. Qualys’ têm como objetivo ter uma definição para detectar o ataque muito rapidamente e inevitavelmente outros provedores de IDS também estão trabalhando nisso 24 horas por dia.
Outras opções mais drásticas incluem a substituição do Bash por uma implementação de shell alternativa ou o cordonamento de sistemas em risco, ambos os quais podem ter ramificações de longo alcance e são improváveis que sejam decisões tomadas de ânimo leve. Mas esta provavelmente será a natureza deste bug para muitas pessoas – decisões difíceis que poderiam ter impacto tangível nos negócios, a fim de evitar ramificações potencialmente muito mais significativas.
O outro problema que agora começará a surgir muito é a questão de se o Shellshock já foi explorado em um ambiente. Isto pode ser difícil de determinar se não há registro dos vetores de ataque (muitas vezes não haverá se for passado pelo cabeçalho de pedido HTTP ou pelo corpo do POST), mas é mais provável que seja pego do que com o Heartbleed quando não estiver cheio de pcaps, a carga de batimentos cardíacos normalmente não teria sido registrada em nenhum lugar. Mas mesmo assim, a resposta mais comum a “onde fomos atacados via Shellshock” será esta:
unfelizmente, isto não é “Não, nós temos evidências de que não houve compromissos;” ao invés disso, “nós não temos evidências que abranjam toda a vida desta vulnerabilidade”. Duvidamos que muitas pessoas o façam – e isto deixa os proprietários do sistema na posição desconfortável de não saberem o que, se é que houve algum compromisso, pode ter acontecido.
Deixe a especulação sobre se o NSA estava neste início…
Sou um consumidor – o que posso fazer?
Depende. O Shellshock afecta os Macs, por isso se estiver a correr OS X, nesta fase parece estar em risco, o que por um lado é mau devido à prevalência do OS X, mas por outro lado será facilmente (e esperemos que rapidamente) remediado devido a um mecanismo de actualização bastante bem provado (ou seja, a Apple pode remotamente empurrar as actualizações para a máquina).
Se estiver num Mac, o risco é facilmente testado como descrito nesta resposta Stack Exchange:
É um teste fácil, embora duvide que o utilizador médio de um Mac se sinta confortável ao passar pela correcção sugerida que envolve recompilar o Bash.
A maior preocupação são os dispositivos sem caminho de remendo fácil, por exemplo o seu router. A não ser que se verifique a actualização do firmware com o website do fabricante, este vai ser um problema muito difícil de resolver. Muitas vezes os routers fornecidos pelos ISPs são bloqueados para que os consumidores não estejam a mudar aleatoriamente de configuração ou firmware e nem sempre existe um caminho de actualização remota que eles possam activar. Combine isso com a enorme variedade de dispositivos e idades que estão lá fora e isso pode ser particularmente complicado. Claro que também não é o tipo de coisa que o seu consumidor médio se vai sentir confortável a fazer sozinho.
Em resumo, o conselho aos consumidores é o seguinte: preste atenção às actualizações de segurança, particularmente no OS X. Fique também atento a qualquer conselho que possa receber do seu ISP ou de outros fornecedores de dispositivos que tenha que executem software incorporado. Seja cauteloso ao solicitar informações ou instruí-lo a executar software – eventos como este são frequentemente seguidos por ataques de phishing que capitalizam os medos dos consumidores. Hoaxes atualmente têm pessoas colocando seus iPhones no microondas, então não pense por um momento que eles não vão rodar um software enviado por e-mail como uma “correção” para Shellshock!
Sumário
Em toda a probabilidade, nós nem sequer começamos a sondar a amplitude desta vulnerabilidade. É claro que há muitas comparações sendo feitas com o Heartbleed e há uma série de coisas que aprendemos com esse exercício. Uma é que demorou um pouco de tempo para nos afundarmos quando percebemos até que ponto éramos dependentes do OpenSSL. A outra é que ele tinha uma cauda muito longa – meses depois de ter atingido ainda havia centenas de milhares de hospedeiros conhecidos que ficaram vulneráveis.
Mas de uma maneira, a comparação do Heartbleed não é justa – isto é potencialmente muito pior. Heartbleed permitiu o acesso remoto a pequena quantidade de dados na memória das máquinas afetadas. Shellshock está permitindo a injeção de código remoto de comandos arbitrários pré-autenticados, o que é potencialmente muito mais terrível. A esse respeito, tenho de concordar com Robert:
É muito, muito cedo ainda – apenas meio dia desde que atingiu pela primeira vez as ondas de ar no momento da escrita – e suspeito que até agora só estamos a arranhar a superfície do que ainda está por vir.
Segurança