0
0
Na quinta-feira, 9 de dezembro de 2021, meus filhos jovens viciados em Minecraft ainda estavam completamente alheios às vulnerabilidades do Log4j em seu jogo favorito. Então, novamente, assim como todos os profissionais de segurança cibernética do mundo.
Tudo isso mudou quando o projeto Apache Log4j anunciou o CVE-2021-44228 (também conhecido como Log4Shell) – uma vulnerabilidade de dia zero no método padronizado da Log4j de lidar com arquivos de log usados por aplicativos em todo o mundo, do Minecraft da Microsoft ao Twitter, Tesla e ao iCloud da Apple. Isso levou a uma chama de histórias sobre como a internet está “em chamas”.
Essas manchetes gritantes fazem sentido para nós na indústria de software e serviços digitais. Essa vulnerabilidade, que continua a ser seguida por outros, é uma má notícia. E é difícil encontrar uma metáfora para descrever uma vulnerabilidade de zero dias facilmente explorável em um grande número de alvos de alto valor.
Racionalmente, quase todas as empresas, organizações e governos que fazem qualquer coisa relacionada ao software entraram em modo de crise. É difícil imaginar alguém não ter sido afetado, e muito provavelmente muitos ainda estão em alerta máximo, mesmo depois de quase duas semanas.
No entanto, para a maioria dos usuários da Internet, a vida continuou como de costume.
Se eles leram sobre a tempestade de fogo Log4Shell, os usuários médios provavelmente concluíram que essa história era toda fumaça e sem fogo: Minecraft funciona, o Facebook funciona, o iPhone deles é carregado. Quem se importa? Os serviços da Amazon nos EUA têm estado um pouco ligados e desligados ultimamente, mas essas foram interrupções não relacionadas.
Felizmente, meus filhos, como a maioria das pessoas, provavelmente não têm ideia de quão ruim isso poderia ficar—pelo menos ainda não. Mas se você trabalha em segurança cibernética, sabe que uma coisa é verdade: a maioria de nós teve sorte, até agora.
Poderíamos ter evitado o Log4Shell
A verdade é que não temos ideia de quão severamente os atacantes aproveitaram as vulnerabilidades no Log4j. Os atacantes podem ofuscar suas intrusões com relativa facilidade e é improvável que as centenas de milhares de empresas que estiveram ocupadas corrigindo seus sistemas tenham se envolvido em qualquer tipo de resposta a incidentes para detectar se a vulnerabilidade foi explorada antes da atualização.
Sem dúvida, este é um incêndio na lixeira. E a maioria das pessoas em nosso setor está fazendo o seu melhor para garantir que não salte e consuma seu entorno. Talvez nossa triagem valha a pena. Talvez os consumidores nem se lembrem das manchetes histéricas da Log4Shell que olharam entre as vendas de fim de ano. Mas para quem se preocupa com a segurança cibernética, o fedor é impossível de ignorar.
E aqui está a pior parte.
Ainda não ouvi falar de um único serviço ou produto que seria afetado negativamente pela configuração do Log4j para desativar as pesquisas, o recurso que expôs os aplicativos à pior vulnerabilidade divulgada.
Isso levanta uma pergunta: onde ele está realmente sendo usado? E quem precisa disso?
Se um recurso não estiver sendo usado, qualquer CISO ou caçador de ameaças ou estagiário de segurança cibernética lhe dirá que ele não deve ser ativado. Acontece que o recurso vulnerável foi adicionado em 2013 como uma adição “legal de se ter”, praticamente sem debate. Até mesmo os mantenedores atuais do Log4j não gostam e foram rápidos em inadimplentemente para um estado desativado em uma atualização lançada na segunda-feira, 13 de dezembro.
Se as orientações básicas de higiene de TI tivessem sido seguidas, o Log4j teria sido facilmente imune a esse tipo de vulnerabilidade, mas a internet não foi exatamente construída por meio de higiene.
Favorecendo recursos em detrimento da segurança – mesmo desnecessários
As macros do Microsoft Office, que foram desenvolvidas pela primeira vez na década de 1990, são uma poderosa série de comandos que podem ser usados para automatizar uma tarefa repetida. Ainda assim, ninguém em sã consciência permitiria que os usuários executassem macros à vontade, e ninguém deveria ter permissão para enviar documentos carregados de macros não solicitados de fontes não confiáveis. No entanto, é exatamente isso que continua acontecendo por padrão.
A maneira como nosso setor trata as macros do Office representa a maneira como tratamos quase todas as decisões em que precisamos escolher entre recursos e segurança.
A vulnerabilidade SNMP e ASN.1 descoberta pelo Oulu University Secure Programming Group (OUSPG) em 2001 e lançada em 2002 acabou forçando a Marinha dos EUA a chamar todos os submarinos movidos a energia nuclear de volta do mar para atualizações de software de emergência. O ASN.1 é uma linguagem sintática excessivamente complexa usada basicamente por todos os protocolos de comunicação. Encontre um bug lá e você quebra todas as implementações de protocolo. Isso é essencialmente o que a OUSPG fez há duas décadas. E versões da mesma coisa continuam acontecendo.
A vulnerabilidade Heartbleed de 2014 afetou todas as implementações de Transport Layer Security baseadas em OpenSSL e permitiu que atacantes despejassem informações de sistemas expostos à Internet. Heartbleed tem semelhanças estranhas com o incidente Log4j, pois ambos eram projetos de código aberto, ambos os projetos sofriam de recursos insuficientes e ambos ficaram inchados ao longo do tempo. No entanto, ambos ainda estavam sendo cegamente confiáveis por milhares de projetos e produtos comerciais.
Se você estava por perto em Heartbleed, não pode agir surpreso agora com o Log4j.
Uma vez que um recurso supostamente inofensivo e inócuamente engraçado ganha uma base de usuários grande o suficiente, as possíveis consequências de uma vulnerabilidade de repente se tornam críticas. E isso acontece uma e outra vez.
Ninguém pode resolver todos os problemas de segurança cibernética sozinho
Imagino que muitos usuários da Internet — até mesmo meus filhos pequenos — ficariam chocados ao aprender um software como o Log4j, que é implantado por algumas das maiores empresas do mundo que fazem trilhões em dólares em negócios, é o produto de uma operação voluntária, onde profissionais altamente treinados trabalham inúmeras horas de graça—especialmente agora.
A frágil interdependência da internet raramente foi mais óbvia como é agora. Todos nós usamos ferramentas semelhantes, se não as mesmas. Todos nós somos vulneráveis a zero dias que ameaçam o núcleo de nossos negócios. Todos nós devemos aprender uns com os outros e desenvolver o trabalho que os outros fazem, ou todos corremos o risco de falhar—sozinhos. Essa confiança mútua construiu a internet moderna, mas também parece ter levado a um foco em correções de curto prazo que nos deslizam de crise em crise sem abordar os problemas sistêmicos que enfrentamos.
Somente um foco nos resultados – uma fixação nos sistemas e resultados que queremos criar – pode nos mover de um setor onde preenchemos as lacunas um do outro para um que realmente colabora para a segurança desde o design.
Então, como mudamos para a esquerda para melhores resultados?
Um primeiro passo óbvio é reconhecer que as empresas que usam esses componentes disponíveis gratuitamente devem descobrir maneiras de retribuir.
E pagando de volta, não quero dizer apenas cortar um cheque, como muitos sugeriram recentemente no Twitter hot takes. As empresas podem testar vários componentes quanto à segurança do nosso tempo de pesquisa. Podemos contribuir com código para correções, melhorias de estabilidade e recursos do nosso orçamento de pesquisa e desenvolvimento. E podemos nos oferecer para tirar um pouco da carga dos voluntários do projeto, permitindo que os desenvolvedores gastem tempo em projetos enquanto estão no trabalho.
Já estamos fazendo tudo isso até certo ponto, é claro. Não estou sugerindo alguma nova teoria quântica aqui. No entanto, poderíamos fazer mais—e deveríamos fazer mais. E não porque somos uma instituição de caridade, mas porque é um investimento inteligente.
Basta pensar no número de horas faturáveis (por falta de um prazo melhor) que foram gastas na busca do número de maneiras pelas quais o componente Log4j foi incorporado em nossos resultados, sistemas de back-end e em nossa cadeia de suprimentos. A gravidade do risco excede em muito a chamada alocação em tempo de paz da nossa contribuição para projetos de código aberto.
Pensamento positivo não é suficiente
O velho ditado diz: “Não chore por causa do leite derramado.” Quando se trata de Log4j, a indústria de segurança cibernética serviu muito leite em um copo rachado. Uma vez que percebemos que a rachadura estava lá, soltamos um grito primordial. Enquanto isso, ainda estamos servindo óculos novos para os espectadores, que se perguntam do que se trata todo esse alarido.
Quebramos isso; temos que consertar!
Nossa indústria gerou trilhões de valor com a promessa de ser maravilhas de engenharia, oferecendo software e serviços digitais bem pensados e funcionando sem problemas. Como mostra esta crise, basta arranhar a superfície e fica evidente que grande parte dessa promessa é construída sobre desejos e pura sorte.
É hora de começar a consertar a dívida técnica que acumulamos e começar a consertar as partes mais críticas da nossa infraestrutura digital. E dado o risco que todos enfrentamos, seríamos tolos em não recuar e pelo menos olhar para o que estamos colocando em nossas lixeiras.
FONTE: HELPNET SECURITY