Resumo do Vídeo sobre Segurança Cibernética e a Vulnerabilidade Log4j

Olá pessoal, hoje eu vou falar de Cyber Security, segurança cybernética. Vou comentar de um exemplo do Log4j que veio à tona recentemente. Log4j. Então vamos começar. Você tem que entender alguns temas de segurança cybernética, deixa só comentar nesses temas. Então quando você tem software e existe algum bug ou alguma falha que permite alguém criar um exploit, algum arranjar uma maneira de tomar vantagem e conseguir alguma coisa sobre isso, essas vulnerabilidades podem ser relatadas e armazenadas em um banco de dados. Existe banco de dados, vários bancos de dados hoje que tem essa lista de vulnerabilidades. Então vamos falar aqui dos temas. Existe um banco de dados chamado NVD, National Vulnerability Database, banco de dados de vulnerabilidades nacional, mas isso é do Estados Unidos. Esse NVD é parte do NIST, que é o National Institute of Standards in Technology, do Departamento de Comércio dos Estados Unidos. Então esse NVD, esse banco de dados de vulnerabilidades, existe em várias entradas e cada entrada é descrita e associada a um certo identificador. Esse identificador a gente chama de número de CVE. Então CVE no inglês. CVE vem de uma instituição chamada MITRE. CVE é como vulnerabilidades e expositores, exposições e vulnerabilidades comuns. São as descrições dessas vulnerabilidades. Então cada vulnerabilidade ganha esse número de CVE. Então vamos agora comentar a vulnerabilidade que viu a tona recentemente, que afeta muitos sistemas, se não a maioria da internet hoje. Então esse foi um exploit que descobriram, que dá para fazer através do Log4J, que é uma biblioteca usada para logar requisições no servidor. Logo o Log4J vem do Apache, você usa o servidor Apache Web Server. Então essa vulnerabilidade que foi descoberta, eles dão o número de CVE para poder identificar essa vulnerabilidade. Então para essa vulnerabilidade o número foi, deixa eu ver aqui. Se você vai na Banco de Dados de Vulnerabilidade Nacional, Nacional do Estados Unidos, CVE traço 2021 traço 44228. Então esse é o número identificador dessa vulnerabilidade do Log4J que foi encontrada recentemente. Recentemente sendo, eu estou falando hoje, dia 17 de dezembro de 2021. Então ocorreu aqui, essa foi publicada dia 10 de dezembro, esse CVE. Então CVE traço o ano, nesse caso 2021 traço o número, nesse caso 44228. Então o número CVE 2021, 44228 corresponde a essa vulnerabilidade. Então se você ler aqui, se você for nesse banco de dados, ou até outros, tem outros bancos de dados também com a mesma informação. Se eu for lá no nvd.nist.gov e buscar por esse CVE 2021, 44228 aparece os detalhes. Então está dizendo aqui que o Apache Log4J 2, 2.0 traço beta 9 até 2.12.1 e 2.13.0 até 2.15.0. Features do Jndi, acho que Java Name Directory, usado em configuração, mensagem de log, parâmetros, não protegem contra LDAP controlado pelo atacante e outros Jndi endpoints relacionados a isso. Um attacker, que é o atacante, o cara que toma vantagem, pode controlar as mensagens de log ou parâmetros da mensagem de log e pode executar qualquer código arbitrário carregado de servidores de LDAP quando a feature, essa funcionalidade chamada Message of Location Substitution, é habilitada. Substituição de busca de mensagem. Então diz aqui que na versão do Log4J 2.15.0 o comportamento foi desabilitado por padrão para poder mitigar a vulnerabilidade. No entanto, somente da versão 2.16.0 a que a funcionalidade foi completamente removida para que os hackers não consigam mais fazer esse ataque. Então se você tiver algum servidor, algum sistema que usa a parte e que usa o Log4J, você deve atualizar para a versão 2.16.0 A recomendação para que os hackers não consigam mais fazer esses ataques. Então deixa eu ver se tem mais aqui para falar disso. Como é que esse ataque é? Então essa biblioteca Log4J é usada para logar as requisições do servidor, fazer login. Então os caras arranjaram uma maneira de quando você enviar qualquer mensagem do cliente e essa mensagem que passa a ser logada lá no servidor eles arranjaram uma maneira de qualquer coisa que você digita lá no cliente, a enviar para o servidor e do servidor aquilo que for digitado de alguma maneira permite a exakução de código remoto. Então tem um negócio chamado RCE Remote Code Execution, a execução de código remoto que acontece aqui. Também já comentaram quando ele lia ali sobre a vulnerabilidade que uma das maneiras que isso acontece é através da serialização e de serialização. No inglês serialization e des serialization, o que é esse processo? Então por exemplo linguagem Java que é orientada a objetos, você tem os objetos e tem as informações que são armazenadas nesse objeto mas como é que eu faço para poder enviar essas informações para outro local? Então a maneira que se faz isso é, primeiro faz a serialização e você pega a informação desse objeto e coloca dentro de uma string e quando você coloca dentro do string você pode mandar essa string para outro canto, mandar através da internet da rede. Então manda para outro servidor, o outro servidor pega essa string e vai ter que construir o objeto novamente. E para fazer isso chama des serialization, des serialization. E esse processo é que ele pega a string e extrai os valores para poder construir o objeto de novo a partir desses valores. Então nesse processo é que eles encontraram um exploit, o cara que mandava lá um string que quando o processo de des serialization de construir o objeto novamente, ele construiu esse objeto novamente e pegava aquela parte da string que foi injetada, que foi adicionada pelo atacante, pelo hacker, você poderia adicionar qualquer coisa lá que quisesse fazer e ele iria ser configurado naquele novo objeto. Então vamos lá comentar mais aqui, ver uns comentários que fizeram aqui. Então essa vulnerabilidade também é chamada de log4shell, o apelido, descoberta por um membro da equipe de segurança da nuvem do Alibaba, a Componha Chinesa. E afeta praticamente muitos servidores da web, porque eles usam o apelido que usa o log4j e tal e tal. Então diz aqui que afetou iCloud da Apple, Steam, que é de jogo, portal de jogos, até Minecraft. E vários negócios, businesses foram afetados, então se você tem o log4j essa versão antes do 2.16 ou até antes 2.15, 2.15 eles desabilitaram, mas ainda não foi removido, só no 2.16 que removeram a funcionalidade que permite o exploit. Então essa vulnerabilidade descoberta na biblioteca log4j, que é open source, para fazer login de servidor. O bug permite os hackers entrar no sistema de computadores, onde pode espalhar malware, roubar dados e muito mais. Então aqui um exemplo do Minecraft que deram aqui. Eles conseguiram reproduzir esse exemplo do Minecraft, que eles conseguiram fazer execução de código remoto, aquele que eu falei remote code executionerc é no servidor de jogo, depois de mandar mensagem através da caixa do chat. Então ele mandava mensagem lá do jogo do cliente do Minecraft, mensagem de texto no chat, no bot papo, isso irá bater lá no código do log4j. Os caras conseguiram tomar vantagem disso. Então eles dizem que atualizar a proverção 2.15 pelo menos, que é a desabilita, mas não remove completamente a funcionalidade que permite o exploit. Então a recomendação eu recomendo você atualizar a proverção 2.16, que não tem mais a funcionalidade que permite o exploit. Lembrando aqui os termos de cyber security para você, essa vulnerabilidade log4j tem um número de CVE como vulnerabilities and exposures, exposições e vulnerabilidades comuns, que a descreve a vulnerabilidade. O CVE que tem lá você pode acessar na National Vulnerability Database NVD, Data Base de Vulnerabilidade Nacional, nesse caso dos Estados Unidos, CVE 2021-44-228. Então vamos falar mais disso. Então aqui então tem esse lance do JNDI, Java Name Directory, que eles usaram aqui para poder fazer isso também. Se você aí conhece Java e conhece log4j, deve ser familiar para você. Mostra que o onV timeline, como é que aconteceu isso. Então vamos ver aqui dia 24 de novembro de 2021. Pesquisador do Alibaba, companhia chinesa, notificou a APAT Software Foundation, que é a fundação do software APAT, que mantém o servidor APAT e a biblioteca log4j. Notificou de uma vulnerabilidade de execução de código remoto, RCE, Remote Code Execution, no log4j, log4j. Então cinco dias depois, no dia 29 de novembro de 2021, a vulnerabilidade que eles chamaram de log4j, de CVE 2021-44-228, tem um patch lançado com a versão 2.15 de log4j, 2.15.0, rc1, mas não foi um concerto completo. Alguns dias depois, dia 5 de dezembro, log4j, versão 2.15.0, rc2, lançada. Essa versão restringe protocolos que anteriormente foram permitidos, mas ainda permite os ataques usando o que se chama de Gadget Chain, código de Gadget Chain dentro do log4j. Quatro dias depois, no dia 9 de dezembro, um exploit, um proof of compasit, significa um exploit que conseguir criar um protótipo, foi circulado na internet e vários atores malciosos, tiveram acesso a esse exemplo que criaram de exploit, então ainda estava lá. E no dia 13 de dezembro de 2021, a versão 2.16.0 do log4j foi lançada. Essa versão removeu algumas das funcionalidades de login e também desabilitou o JNDi, que é chamado de Java Name Directory, e isso me digou, concertou a monarabilidade. Agora vamos ver sobre mais atores do ataque. Esse exploit do log4j, da função de busca de mensagem, message lookup function, fácil de conduzir simplesmente ao mandar um texto, um string, para o servidor, somente via HTTP. Esse processo, a vulnerabilidade funciona através do processo de serialização, quando você tem a string, e essa string é usada para construir o objeto. Esse processo de converter string para construir o objeto novamente, pode ser usado pelos atacantes, para executar arquivos de classe arbitrária, no sistema. Do processo de serialização, eu já expliquei anteriormente, você tem o objeto que se torna string, e é transferido para outro canto, e desse outro canto a string é usada para construir o objeto. Então, o problema de segurança emerge nesse processo, quando esse objeto contém dados controlados pelo usuário. Aqui no exemplo ele fala, um link para um arquivo de classe de Java vai executar, por exemplo, os atacantes, os hackers podem usar esse método com o Jndi, que é o Java Name Directory, para apontar para um servidor de LDAP, LDAP Lightweight Directory Access Protocol, que eles controlam. Então eles controlam o servidor LDAP, e os atacantes usam o método com Jndi para apontar para o servidor deles de LDAP. Então o exploit usa Jndi com o LDAP, e especifica o host e o path, quando isso é processado, e é evaluated, que é avaliado, ele vai para o servidor e baixa o código e executa o código. Então ele diz aqui que uma das maneiras que as organizações têm feito para mitigar esse problema, no caso do lado da rede, é para não permitir a comunicação externa de sistemas que eles acham que estejam rodando logo for Jndi. Então ele fala que como uma das maneiras que as empresas poderiam se proteger disso, ou mitigar o problema, ao não permitir que qualquer sistema que está aí rodado logo for Jndi, que não pode permitir comunicação de fora, porque esse exploit funciona através do log for Jndi, se comunicando com o servidor de LDAP, que é do hacker, e o hacker manda uma coisa de volta, que ele pode executar aquele código na máquina que roda o log for Jndi. Aqui explica que a razão que os ataques funcionam é porque o Jndi, JavaNaming, DirectlyDiscovery, não tem controle de segurança nos requerimentos de LDAP. Eles não esperavam isso, parece que não esperavam que alguém ia fazer isso. Também aqui comentaram que o cara fala aqui do CrowdStrike, que teve um blog post do CrowdStrike que explica, eles comentaram, abriaço também o LDAP, contrário a outros protocolos de Jndi, suportam o carregamento de classes de recursos remotes. Então é isso, essa unarabilidade cujo CVE é atrasso 2021, atrasso 42428, que afeta o log for Jndi do APAT. Você deve atualizar a prevação 2.16.0 para a hora que os ataques não tomam vantagem do seu sistema. Então essa biblioteca log for J, usada para login, a biblioteca de código aberto do APAT, se você tem um servidor de APAT, vão ficar ligados aí e ver se consegue atualizar se você está usando essa versão comprometida. Então vimos que essa unarabilidade, qualquer pessoa pode mandar, está lá no Minecraft, manda uma mensagem através do chat, e isso bate lá no log for J, que o processo de seremização, quando a string é usada para reconstruir o objeto, os ataques tem um servidor de LDP, o log for J se comunica com LDP através da C exploit e eles podem rodar qualquer coisa lá, mandar mensagem para o servidor log for J para fazer qualquer coisa através de remote code execution RCE. Tá pessoal, então por essa só espero que tenham gostado desse comentário sobre segurança cibernética, cybersecurity e até a próxima.