Vulnerabilidade Mutagen Astronomy – Linux Local Privilege Escalation



Após testes, uma equipe de pesquisadores focados em segurança cibernética veio a público com uma prova de conceito (PoC) detalhado sobre uma vulnerabilidade no kernel do Linux, que atualmente afeta as distribuições do CentOS, Debian e do Red Hat Enterprise Linux (RHEL).

A vulnerabilidade foi denominada Mutagen Astronomy e é rastreada como CVE-2018-14634. Ela foi descoberta pela equipe do Qualys Research Labs, que caracterizou essa falha de segurança como um problema de Local Privilege Escalation (escalonamento de privilégio local).

Esse tipo de vulnerabilidade exige que um invasor tenha um acesso estável (shell ou acesso físico) em um sistema vulnerável, mas é uma das falhas de segurança que pode transformar uma invasão simples em algo muito ruim para o administrador do sistema, pois ele pode ser usado para dar acesso a um intruso, fornecendo controle completo sobre os sistemas infectados.

De acordo com os pesquisadores da Qualys, o bug atual reside na função create_elf_tables () do kernel do Linux, em que um exploit habilmente criado, pode causar um estouro de buffer (buffer overflow), que executa código malicioso com privilégios de root.

A vulnerabilidade estava presente no kernel do Linux entre 19 de julho de 2007 (kernel commit: b6a2fea39318) e 7 de julho de 2017 (kernel commit: da029c11e6b1).

"Apesar de todos os kernels Linux serem tecnicamente vulneráveis, esse problema é mitigado por um patch de um ano atrás que foi desenvolvido para a maioria dos kernels de longo prazo, o que impossibilita a exploração. No entanto, o Red Hat Enterprise Linux e o CentOS não deram backport a esse patch e, portanto, são vulneráveis ​​e exploráveis", disse um porta-voz da Qualys.

Em um comunicado publicado, a equipe da Red Hat confirmou esse problema. Além disso, descobriu-se que o CVE-2018-14634 também afeta distribuições Debian mais antigas. "Este problema afeta a versão dos pacotes do kernel como fornecidos com o Red Hat Enterprise Linux 6, 7 e Red Hat Enterprise MRG 2. Futuras atualizações de kernel para Red Hat Enterprise Linux 6, 7 e Red Hat Enterprise MRG 2 irão resolver este problema" disse a equipe da Red Hat.

Até que um patch esteja pronto, a equipe de segurança da Red Hat publicou conselhos básicos de mitigação sobre como proteger sistemas vulneráveis ​​até que um patch seja lançado.
Os pesquisadores da Qualys publicaram uma descrição detalhada (ver em referências) da vulnerabilidade estranhamente chamada de Mutagen Astronomy, junto com dois PoCs [1, 2].

Referências:




https://nvd.nist.gov/vuln/detail/CVE-2018-14634

Evitando RCE por Shellshock



RCE (Remote Code Execution) – que na tradução significa execução de código remota — é a ação de um atacante ao executar códigos remotos utilizando de vulnerabilidades do sistema. Uma dessas milhares de vulnerabilidades detectadas é o Shellshock, que afetou diversas versões de sistemas baseados em linux/unix em 2014, como você pode ver no CVE.
Neste artigo, iremos discorrer como funciona o ataque na prática.
 
O que é shellshock?  

Shellshock é uma vulnerabilidade que ocorre no bash, que permite executar comandos de uma forma arbitraria, já que o ele é inserido depois que uma determinada função é definida.
Errata: No post antigo, Nova Vulnerabilidade: Shellshock, informamos que, ao executar o comando para saber se há a vulnerável, retornaria uma mensagem de erro. Na realidade não há retorno de erro, a aplicação estará vulnerável caso os dois comandos sejam executados, ou seja, ao executar:
 env x='() { :;}; echo vulneravel' bash -c "echo teste"

Se for apresentado apenas “teste”, não há vulnerabilidade. Caso seja apresentado a mensagem “vulnerável” antes de “teste” e também o “teste”, neste caso estará vulnerável.

Então como ocorre o ataque?

Vamos supor que um atacante queira explorar um servidor web e executar um comando especifico, como fazer o driver de DVD abrir. Para tal, um usuário com permissão, apenas digita /bin/eject. Mas, supondo que o servidor esteja vulnerável ao Shellshock, o atacante pode adicionar uma string () { :; };  para o /bin/bash e enviar o comando para o servidor web via HTTP. O servidor deveria receber o comando identificado pelo User-Agent. Entretanto, no caso do servidor vulnerável ao Shellshock, nada é informado.
Por exemplo, se o domínio “domínio.com.br” está vulnerável, utilizando o Curl, o ataque funcionaria assim:
curl -H "User-Agent: () { :; }; /bin/eject" http://dominio.com.br

É o suficiente para que o comando seja executado, fazendo com que o driver de DVD abra.
Isso ocorre pois o atacante modifica a origem do HTTP request e insere a string () { :; };.
Neste cenário, o User-Agent ficaria deste modo:

HTTP_USER_AGENT=() { :; }; /bin/eject

Se a variável passar pelo bash do servidor web, o Shellshock ocorre.

Qual a solução?

A solução é atualizar a versão do Bash para que o mesmo não interprete a string () { :; }; de uma maneira especial.

Depende de outros fatores...

Para que a vulnerabilidade seja explorada neste cenário, o servidor web precisa estar como root. Entretanto, basta utilizar o Shellshock com outra vulnerabilidade para consegui-la. Por exemplo, a falha da má configuração do CGI.

Mas o que é CGI? 
CGI (Common Gateway Interface) é um modulo do Apache, que permite que scripts e programas sejam executados no servidor web. Além disso, o modulo pode dar detalhes da comunicação entre o servidor web e o browser.   
Alguns exemplos de suas funções são:

·         auxiliar no processamento de dados submetidos por forms;
·         fazer as conversões de HTML para SQL;
·         converter os dados do sistema em HTML;
·         retornar o response para o cliente;
·         gerenciar contadores de acesso.

Portanto, um atacante pode usar o CGI para enviar uma determinada variável para o servidor web vulnerável por má configuração do CGI, pois o servidor utiliza o bash para interpretar a variável, que irá executar qualquer comando malicioso contido.
Sendo assim, utilizando ShellShock com o CGI mal configurado, é possível fazer interpretação de comandos no servidor alvo. 


Solução?
Para mitigação, nas configurações do apache em /etc/httpd.conf, altere o ServerTokens de FULL para PRODUCTONLY. Altere o ServerSignature de ON para OFF. Assim, irá mitigar o footprint do sistema utilizado, não deixar o diretório CGI aberto e permitir que apenas um determinado IP seja capaz de executar comandos.



Conclusão
O intuito deste artigo é mostrar, mesmo que de forma superficial, como funciona um ataque e como mitigar um ataque. Pois é possível utilizar de diversas vulnerabilidades em uma aplicação, ou mesmo em diferentes aplicações que se comunicam, para conseguir explorar um determinado alvo.



Referencias:

Password Spraying


Brute Force

Ataques de força bruta são amplamente conhecidos pela facilidade em se descobrir usuários e senhas válidos em aplicações. O ataque consiste em realizar múltiplos testes de login em uma aplicação por tentativa e erro de usuários e senhas comuns. Para isso, o atacante deve conhecer os padrões de usuários aceitos para o login e ter uma lista de senhas comuns ou criadas a partir de palavras-chaves.

No levantamento de nome de usuário, muitas aplicações na internet utilizam o próprio e-mail do usuário para efetuar o login, o que, dado um domínio alvo, é possível encontrar listas de e-mails na internet. Quando o usuário não utiliza seu e-mail para login, padrões comuns de nome de usuário podem fazer parte do teste (primeira letra do nome seguido de ponto e o sobrenome, nome seguido de ponto e o sobrenome, etc).

Já no caso de levantamento de senhas, existem listas e listas de senhas padrões e conhecidas na internet. O atacante pode também utilizar padrões de senhas próprias inserindo o nome do alvo entre as números, caracteres e palavras completas, por exemplo.

Munido destas listas, o atacante realiza várias tentativas de login utilizando todas as opções da lista de senhas para cada usuário da lista de usuários.

Red Alert

A grande questão deste ataque é que já existem diversos mecanismos para detecção e mitigação do mesmo. Bloqueio de conta após 3 tentativas de login, captcha para verificação de tentativa real de login e bloqueio temporário de acesso à página são alguns dos mecanismos mais conhecidos de mitigação.

A técnica não só é mitigada, como diversos tipos de proteções encontradas no mercado podem gerar logs e alertas para os seus analistas, visto que este ataque é categorizado com uma alta criticidade e o acionamento das equipes de segurança geram todo um trabalho para encontrar as origens do ataque.

A “Solução”?
Como forma de burlar os sistemas de bloqueios por tentativa de login das aplicações, o atacante pode rotacionar os logins utilizando apenas uma senha.

Na técnica de password spray o atacante seta uma lista de usuários que serão testados com senhas padrões conhecidas. Porém, em vez de testar todas as senhas para cada usuário, ele testa todos os usuários para cada senha.

Se a quantidade de usuários da lista de senhas for relativamente grande, é possível até burlar o sistema de bloqueio por tempo de tentativa de login. O tempo de teste de login entre uma senha e outra para cada usuário pode ser grande o suficiente para não alertar o sistema sobre tentativas excessivas de acesso com um único login em um curto espaço de tempo.

Possíveis técnicas de mitigação

Nível Técnico
  • Forçar usuários ao uso de senhas complexas (exigir quantidade mínima de caracteres, forçar uso de caracteres especiais, letras maiúsculas e minúsculas, numerais, etc);
  • Implementação de Captcha após um número limitado de tentativas de login;
  • Implementação de 2FA (Two Factor Authentication).

Nível Humano
  • Documentação de procedimentos de segurança;
  • Conscientização das equipes no uso de e-mails profissionais em locais inadequados;
  • Não compartilhamento de senhas;
  • Não reutilizar senhas em diversos serviços.

Conclusão
Neste artigo vimos que a técnica de brute force pode ser usada também em usuários, não só em senhas. Com isso, o elo mais fraco da segurança (pessoas) pode ser explorado para encontrar nomes de usuários válidos em aplicações web. Além disso, a utilização de senhas fracas e aplicações que possibilitem o uso senhas de simplistas torna o cenário ainda mais fácil de ser encontrado.


O artigo é pequeno e o assunto simples, mas pode ajudar muitos administradores de sistema a pensarem fora da caixa e entenderem porque existem tantas linhas de erro de login em seus logs de acesso sem acionamento de alarmes.



Referências
https://www.cybrary.it/0p3n/password-spraying-vulnerable/ https://christierney.com/2018/03/28/password-spraying/
https://www.trustwave.com/Resources/SpiderLabs-Blog/Simplifying-Password-Spraying/
https://cloudblogs.microsoft.com/enterprisemobility/2018/03/05/azure-ad-and-adfs-best-practices-defending-against-password-spray-attacks

Principais Tópicos do GDPR



A popularização da internet trouxe alguns desafios em relação à segurança das informações. A divulgação recente do vazamento de dados pessoais de usuários armazenados por uma rede social de abrangência mundial, colaborou, e muito, com a publicidade sob o General Data Protection Regulation (GDPR).  

Foram quatro anos de debates até a aprovação pelo Parlamento da União Europeia em 14 de abril de 2016. Contudo, o regulamento somente entrou em vigor em 25 de maio de 2018, sendo esta a data inicial para aplicação das penalidades previstas no GDPR. 

A finalidade do regulamento é estabelecer um conjunto de regras claras no intuito de proteger os cidadãos europeus contra a violação da privacidade de seus dados. Entretanto, a jurisdição territorial estendida do GDPR abrange todas as empresas que processam os dados pessoais dos usuários residentes na União Europeia, independentemente da localização da empresa. 

Conforme as orientações do GDPR, são direitos do usuário em relação a privacidade dos dados:

Notificação de violação: Prazo estabelecido de até 72 horas para que o detentor dos dados comunique ao proprietário quaisquer incidentes que porventura impliquem em vazamento ou violação;
Direito de acesso: Permitir que o usuário tenha a opção de autorizar o uso de seus dados pessoais, bem como a maneira como eles devem ser tratados, informando sempre o que está sendo coletado e para quais fins. E, se houver necessidade, deve ser disponibilizada uma “cópia digital” de seus dados;
 • Direito de ser esquecido (data erasure): A qualquer tempo, o proprietário da informação deve ter a possibilidade de solicitar a exclusão de seus dados pessoais ou impedir a coleta; 
Portabilidade: Operações de migração dos dados entre serviços são permitidas, e as solicitações devem ser atendidas respeitando as necessidades dos usuários; 
Privacidade por design: As orientações do GDPR em relação à privacidade dos dados devem ser previstas desde o início no projeto dos sistemas; 
Oficiais de proteção de dados: Por vezes, será necessário estabelecer um ponto focal em relação à proteção dos dados. Essa pessoa, um executivo aqui denominado DPO (Data Protection Officer), será o responsável por supervisionar a forma como os dados privativos serão manipulados. Todavia, sua responsabilidade também inclui responder as autoridades, prestando esclarecimentos, quando necessário, sobre o assunto. 

Outra recomendação é que os dados sensíveis sejam protegidos, ocultados ou substituídos, aumentando a dificuldade da identificação do usuário (conceito de pseudonimização). 

Também é importante ressaltar que o regulamento prevê que a linguagem utilizada seja clara e compreensível nas comunicações direcionadas a todo e qualquer usuário, indiferente do seu nível de conhecimento. Termos de serviços longos são desencorajados, bem como as informações de consentimento, que devem ser destacadas dos demais assuntos, facilitando seu acesso e as operações de permitir ou negar. 


Penalidades Previstas na GDPR

De forma escalonada, uma empresa pode ser notificada por violações do GDPR. As organizações que de alguma maneira descumpram as determinações propostas, incorrem em multas máximas de 4% em relação ao faturamento anual ou 20 milhões de euros (o que for maior). 

Outras porcentagens podem ser aplicadas conforme a gravidade da violação. Todavia, cabe ressaltar que essas penalidades são compartilhadas por “controladores” e “processadores”, logo, não isentando “clouds” (nuvens) da responsabilidade quanto a privacidade dos dados dos cidadãos da União Europeia. 


Enquanto isso em terras tupiniquins…. 

A divulgação do GDPR fez-se de maneira muito diferente das iniciativas brasileiras em relação à proteção e privacidade dos dados pessoais. Recentemente, os artigos publicados mostram quais são os efeitos do regulamento europeu para resto do mundo, incluindo o Brasil. Contudo, muito pouco é abordado em relação à legislação em vigor no país. 

O Brasil não foi o pioneiro na regulamentação do tratamento da privacidade dos dados dos usuários. Contudo, desde 23 de abril de 2014, está em vigor a Lei nº 12.965, também conhecida como “Marco Civil da Internet”, que conforme texto de lei: “Estabelece princípios, garantias, direitos e deveres para o uso da Internet no Brasil”. Embora não seja uma iniciativa que regulamenta exclusivamente as possíveis violações de privacidade dos dados do usuário, esta legislação engloba também, mesmo que superficialmente, tais quesitos. 

Recentemente, foi aprovado na Câmara do Deputados o Projeto de Lei (PL) nº 4060/2012, que tramita no Congresso Nacional desde 13 de junho de 2012. Esse PL “dispõe sobre o tratamento dos dados pessoais” dos cidadãos brasileiros e, embora não possua correlação com o GDPR, tem muitas semelhanças. 

Entretanto, o assunto deste post é GDPR .... 


Então qual é a ideia? 

A ideia é que, seja você um cidadão europeu ou não, se seus afazeres incluírem gestão de dados de cidadãos da União Europeia, é importante estar atento às regras que foram estabelecidas pelo GDPR, pois ignorar este regulamento pode ser muito prejudicial ao “bolso”. 



Referências:

Ataque GLitch: o uso de rowhammer para ataques em telefones Android


Novo ataque de rowhammer permite ataques de hijacking em smartphones Android


Pesquisadores do grupo de pesquisa VUSEC, da Vrije Universiteit, em Amsterdã, publicaram um artigo que detalha uma nova forma do ataque de rowhammer que eles chamaram de "GLitch".
Como nas versões anteriores, ele usa o ataque de rowhammer para induzir vazamentos na memória e alterar os zeros e vice-versa nos dados armazenados lá - os chamados "bits de virada". Mas, a nova técnica pode permitir que um hacker execute códigos maliciosos em alguns telefones Android quando a vítima simplesmente visita uma página da web cuidadosamente desenvolvida, tornando-se a primeira implementação remota do ataque do rowhammer.

Como os pesquisadores identificaram a falha?


Os pesquisadores decidiram analisar se poderiam usar um código em execução na GPU utilizando um dispositivo Android para executar truques de rowhammer que não seriam possíveis por meio de técnicas tradicionais de programação. Para tornar o problema ainda mais específico e interessante, eles também queriam verificar se poderiam fazer tudo isso sem precisar de um Android configurado como root e sem depender de um aplicativo de malware pré instalado.
O objetivo final dos pesquisadores era fazer um ataque de rowhammer pelo navegador, usando nada mais do que o JavaScript exibido em uma página da web.
A pesquisa foi batizada de GLitch, onde as letras GL vêm de WebGL, abreviação de Web Graphics Library - biblioteca de programação incorporada em navegadores modernos que permite que o código JavaScript trabalhe em conjunto com a GPU para melhorar o desempenho em aplicativos online que utilizam muito a parte gráfica.
Os pesquisadores assumiram que os recursos adicionados do WebGL trariam riscos adicionais, e por causa disso conseguiram identificar o que estavam procurando.



O ataque GLitch é a primeira técnica remota de rowhammer que explora as unidades de processamento gráfico (GPU), que é encontrada em quase todos os processadores móveis.
Como os processadores ARM dentro dos smartphones Android incluem um tipo de cache que dificulta o acesso a linhas de memória direcionadas, os pesquisadores fazem uso da GPU, cujo cache pode ser mais facilmente controlado, permitindo que os hackers façam buscas nas linhas sem interferência.

O que fazer para mitigar o problema?


Como o rowhammer explora uma vulnerabilidade no hardware do smartphone, nenhum patch de software pode corrigir completamente o problema.
Até agora, os pesquisadores têm um conjunto limitado de ataques que funcionam sob circunstâncias controladas, em um dispositivo desatualizado de sua própria escolha, executando uma versão antiga do Android. No entanto, o GLitch nos lembra que quando você adiciona recursos e desempenho, seja ao criar GPUs em chips para telefones celulares ou ao adicionar bibliotecas sofisticadas de programação gráfica a navegadores, podem existir consequências.
Os pesquisadores enfatizam que a ameaça de rowhammer não é apenas real, mas também tem o potencial de causar danos reais e severos.

Sobre os ataques rowhammer


O ataque de rowhammer é uma vulnerabilidade relativamente antiga, que origina-se no fato que os chips DRAM atuais usam geometrias de processo muito pequenas, que reduzem o número de elétrons armazenados na célula, enquanto a proximidade das “linhas” vizinhas acelera a taxa na qual os elétrons vazam para dentro e para fora da célula. Se muitos elétrons forem removidos ou adicionados a uma célula, ela mudará de estado.

Para que a vulnerabilidade ocorra quando uma linha de DRAM é ativada repetidamente, é necessário que vários acessos ocorram em uma linha antes que as linhas adjacentes internas tenham sido ativadas ou atualizadas. A carga da linha sobreativada, vazará para as linhas adjacentes, fazendo com que os bits mudem de estado. Este não é um erro permanente. A célula manterá seus dados em circunstâncias normais, mas perderá dados se a linha de sequência apresentar uma atividade excepcionalmente alta.

Simplificando, o ataque de rowhammer significa ler os mesmos endereços de memória DRAM repetidamente, concentrando a atividade eletrônica em uma pequena parte do chip por tempo suficiente para interferir nas células de memória próximas. De tempos em tempos, algumas dessas células próximas podem mudar sua carga elétrica, invertendo os valores binários 0 para 1 ou de 1 para 0.

Referências: