Shellshock é um bug na shell da linha de comandos Bash que existe há 30 anos e foi descoberto como uma ameaça significativa em 2014. Hoje, o Shellshock continua a ser uma ameaça para as empresas.
A ameaça é certamente menos arriscada do que no ano da descoberta. No entanto, em um ano em que as prioridades de segurança se recalibraram para acompanhar o cenário caótico, é uma boa hora para olhar para trás e para os fatores subjacentes que mantêm esses ataques vivos hoje.
Por que o Shellshock é relevante em 2020?
O Shellshock é uma vulnerabilidade crítica devido aos privilégios crescentes concedidos aos atacantes, que lhes permitem comprometer os sistemas à vontade. Embora a vulnerabilidade ShellShock, CVE-2014-6271, tenha sido descoberta em 2014, sabe-se que ela ainda existe em um grande número de servidores no mundo. A vulnerabilidade foi atualizada (CVE-2014-7169) logo depois e foi modificada até 2018.
A principal razão pela qual o Shellshock ainda está em uso não é um choque. Esta vulnerabilidade é um ataque simples e barato que maus atores podem implantar contra um alvo desconhecido. Patches estão disponíveis desde a entrada do CVE, mas qualquer organização sem sistemas de gerenciamento de patch apropriados ainda pode estar vulnerável.
Shellshock ainda era proeminente em 2017. Quando todos os atacantes precisam de algumas habilidades básicas de programação, um servidor e acesso a malware, não é surpreendente. Além disso, o custo para realizar um ataque não é muito mais do que alguns dólares por mês. A matemática está a favor dos atacantes. Conhecimento mínimo, pouco esforço e baixo custo equivale a uma estratégia de hacking fácil.
Apesar de toda a extensa cobertura da mídia de segurança cibernética e até mesmo um alerta do Departamento de Segurança Nacional, alguns sistemas permanecem sem patch. Em um exemplo, os funcionários do Center for Election Systems não aplicaram um patch que comprometeu os sistemas eleitorais da Geórgia.
Como funciona o Shellshock?
Em termos leigos, Shellshock é uma vulnerabilidade que permite que sistemas contendo uma versão vulnerável do Bash sejam explorados para executar comandos com privilégios mais altos. Isto permite que atacantes potencialmente assumam o controle desse sistema.
Divergindo mais profundamente na técnica, Shellshock é um bug de segurança no Bash shell (GNU Bash até a versão 4.3) que faz com que o Bash execute comandos bash não intencionais a partir de variáveis de ambiente. Os atores de ameaças que exploram a vulnerabilidade podem emitir comandos remotamente no host alvo. Embora o Bash não esteja inerentemente virado para a Internet, muitos serviços internos e externos, como servidores web, usam variáveis de ambiente para se comunicar com o sistema operacional do servidor.
Se esses inputs de dados não forem higienizados – o processo padrão de codificação que garante que o código não faça parte do input – antes da execução, os atacantes podem iniciar comandos de solicitação HTTP executados através do shell do Bash.
Vulnerabilidade em detalhes
Os servidores Web não são os únicos recursos de rede vulneráveis. Servidores de e-mail e servidores DNS que utilizam BASH para se comunicar com o sistema operacional também podem ser afetados. Enquanto a BASH é normalmente encontrada em sistemas baseados em Unix, as organizações que usam sistemas baseados em Windows não são imunes. Estas provavelmente estão alavancando aparelhos ou hardware que são vulneráveis. Lembre-se, a BASH pode fazer parte de roteadores domésticos, muitos dispositivos IoT e sistemas embutidos.
Shellshock pode até ser usada para lançar ataques de Negação de Serviço (DOS).
Aqui está a linha de código (uma declaração de função Bash seguida por um ponto-e-vírgula e o comando ‘sleep’ executado a partir de três caminhos possíveis para garantir que ele seja executado):
new_function() { :;} ; /bin/sleep 20 /sbin/sleep 20 | /usr/bin/sleep 20
Este comando “sleep” força o servidor a esperar vinte segundos antes de responder. Ao fazê-lo, os recursos na máquina são essencialmente mantidos reféns porque a máquina não pode fazer mais nada durante vinte segundos.
Um comando “sleep” pode ser inofensivo, mas um atacante pode ser capaz de substituir isto por código malicioso. Então, esse código pode algemar o servidor ou recurso para que ele seja incapaz de lidar com quaisquer pedidos.
O risco de permitir que usuários prejudiciais da Internet executem comandos de sua escolha remotamente é alto. Ao usar a abertura, os maus atores podem lançar programas no sistema, criar conexões de saída para seus próprios sistemas e executar softwares maliciosos.
Talvez de forma mais crítica, a vulnerabilidade pode ser aproveitada para roubar dados confidenciais e informações armazenadas no sistema, como detalhes de cartão de crédito, senhas e informações pessoalmente identificáveis (PII).
Is Shellshock Still Rampant?
Shellshock não é tão prevalente como era quando foi descoberto em 2014. Imagine o desafio de ter que remendar todos os servidores vulneráveis de sua empresa (e, havia muitos na época).
Dito isto, Shellshock continua a ser um problema.
Por exemplo, há uma campanha ciberameaça e vulnerabilidade em curso chamada “Sea Turtle” que aproveita os registros DNS para obter acesso a sistemas sensíveis. Para que os ataques sejam bem-sucedidos, são necessárias várias vulnerabilidades comuns de hardware e software – sendo o Shellshock uma delas.
Embora não seja tão desenfreado como antes, toda empresa deve certificar-se de que todo o hardware e software estão corretos e atualizados.
Como saber se você é afetado
Porque Shellshock tem seis anos, muitos scanners de vulnerabilidade estão disponíveis. Alguns deles são gratuitos. Um deles, bashcheck, pode ser baixado usando o Github.
Para aquelas pessoas técnicas, digitando um simples comando no prompt do Bash também fará o truque:
env X=”() { :;} ; echo Bash is Infected” /bin/sh -c “echo completed”
env X=”() { :;} ; echo Bash is Infected” `which bash` -c “echo completed”
env VAR='() { :;} ; echo Bash is Infected’ bash -c “echo completed”
Se o prompt retornar uma mensagem “Bash is Infected”, é hora de atualizar e corrigir. Se o seu output não retornar “Bash is Infected”, ele irá responder com algo como:
bash: warning: VAR: ignorando a tentativa de definição da função
bash: erro ao importar a definição da função para `VAR’
Bash Test
Se você gostaria de testar a vulnerabilidade para websites ou scripts CGI específicos, a seguinte ferramenta pode ajudar: Ferramenta de Teste ‘ShellShock’ Bash Vulnerability CVE-2014-6271. Em qualquer um dos dois campos de entrada, digite a URL do website ou do script CGI que você gostaria de testar e clique nos botões azuis.
O que podemos aprender sobre ameaças cibernéticas de segurança
A maior lição para a empresa aqui – e vale a pena repetir – é remendar seus sistemas.
Equipes que podem reduzir os tempos de remendo estão em melhor posição para mudar esses recursos para preocupações de segurança mais urgentes. Enquanto algumas empresas consideram o gerenciamento de patches mais uma responsabilidade de TI do que uma responsabilidade de segurança, o gerenciamento de patches deve sempre estar no topo das preocupações dos departamentos de segurança, pois é crítico para a postura de segurança de uma empresa.
Se os seus sistemas ainda estão vulneráveis hoje em dia, há provavelmente algumas questões operacionais subjacentes que devem ser abordadas. Shellshock é uma vulnerabilidade muito antiga com patches disponíveis para quase todos os sistemas. A melhor maneira de se proteger contra esse tipo de vulnerabilidade é manter seus sistemas atualizados, aplicando todas as correções lançadas para esse exploit.
Ao aplicar patches em ativos, normalmente um processo simples, você deve adotar uma abordagem estratégica.
Os patches testados minuciosamente são uma ótima maneira de minimizar o impacto nos negócios – como um servidor de missão crítica rodando um SO antigo, por exemplo. Se um sistema não pode ser corrigido imediatamente, o risco potencial da vulnerabilidade deve ser ponderado contra o impacto nos negócios.
Shellshock é apenas um em uma longa lista de vulnerabilidades com as quais a empresa deve lidar. Gerenciar o fluxo aparentemente infinito de vulnerabilidades é e sempre será uma estratégia crítica que sustenta a ciber-segurança.
Checklist for a Secure Organization
Para um gerenciamento bem-sucedido de vulnerabilidades, as empresas devem ter a capacidade de ter sucesso nestas três áreas:
- Identificar vulnerabilidades potencialmente impactantes rapidamente: A velocidade é tudo aqui. Ter todos na mesma página com um plano sólido deve promover tempos de reação mais rápidos.
- Determinando o nível de severidade da vulnerabilidade: Conhecer a tolerância da sua organização ao risco irá determinar o quão grave uma vulnerabilidade pode ser. Dependendo da infraestrutura de sua rede, algumas vulnerabilidades são mais prejudiciais do que outras.
- Ter um plano de ação que equilibre a urgência da segurança com o potencial impacto sobre os ambientes de produção: Equilibrar segurança com produção e produtividade é um obstáculo constante, mas organizações com os planos mais bem definidos para gerenciamento de vulnerabilidades normalmente encontram o melhor equilíbrio.
Para o pesquisador independente de segurança Rod Soto, a maior lição aprendida da Shellshock foi que a Internet é baseada em muitas aplicações vulneráveis e sempre carrega o potencial de comprometer uma grande parte de seus segmentos.
“A maneira de gerenciar essas potenciais vulnerabilidades no futuro é manter a comunicação aberta e transparente entre desenvolvedores, mantenedores e profissionais de segurança”, diz Soto. “Portanto, se uma vulnerabilidade tão extensa e significativa for encontrada, a coordenação entre todas as partes afetadas pode ser usada para corrigir ou mitigar os sistemas afetados”.
Pois em que sua empresa seja bem-sucedida na mitigação de riscos para a Shellshock ou qualquer outra vulnerabilidade, você não pode assumir que seu plano de resposta é perfeito. O plano de resposta deve ser um documento vivo, respirável, e deve ser revisto com freqüência para que sua organização possa responder às ameaças rapidamente.
Finalmente, como em qualquer cenário pós-ataque, há perguntas que você deve fazer ao revisar cada fase do plano.
- Que partes do plano foram bem sucedidas?
- Que partes do plano não foram bem sucedidas?
- O que não fizemos que agora percebemos que precisávamos fazer?
- O que aprendemos que nos permite estar mais preparados para a próxima vulnerabilidade que nos surge?
O choque pode ser um ataque antigo, mas para um atacante, faz tic-tac a todas as caixas para explorar as vítimas que não têm uma higiene de segurança adequada.