terça-feira, 19 de abril de 2016

Padrão SS7 e falhas de telefonia

     Em uma matéria publicada no dia 17 de abril de 2016 pela CBS no programa 60 Minutes, foi exposta quão frágil é a segurança de celulares através do mundo. Na matéria, a jornalista contactou uma equipe de hackers situados na Alemanha e outra em uma convenção de segurança em Las Vegas.
     O grupo de Las Vegas conseguiu acesso ao celular da jornalista, enquanto o grupo da Alemanha, através de uma vulnerabilidade no protocolo SS7, utilizado pelas operadoras de telefonia acessar o histórico de chamadas, com acesso ao conteúdo das conversas e localização do congressista Ted Lieu.      A falha em si consiste, que através de um apenas um ponto vulnerável na rede, pode se ter acesso a qualquer um dos aparelhos conectados à toda a rede de telecom's. Sendo possível fazer com que a comunicação passe por um destes pontos interceptados, realizando um MITM e por consequência grampeando o telefone.
     É estudado a mudança para o protocolo Diameter, porém, como se deve pensar na compatibilidade com o sistema legado, estes problemas ainda persistirão por um bom tempo.

sexta-feira, 15 de abril de 2016

Sim, o badlock é real

   

     No dia 12 de Abril deste ano, foi revelada a falha de segurança Badlock. O que começou como uma grande campanha de marketing sobre uma falha de segurança, com direito a logomarca e site, o que, diga-se de passagem, não é novidade, vide HearthBleed, o que foi mais condenado neste episódio, foi anunciar que existe uma falha, e manter o suspense por aproximadamente três semanas até a revelar.
     No entanto, não se trata puramente de uma campanha de marketing, a falha existe, e não é inofensiva.
     Como já era cogitado através de pistas dos responsáveis pela descoberta da falha, o problema está na implementação do protocolo DCE/RPC  Distributed Computing Environment/Remote Procedure Call.
     O protocolo é utilizado em redes Windows para acessar o Active Directory,  serviço que é utilizado para administrar vários elementos da rede (logar na rede com conta de administrador, instalar programas remotamente etc, imagina a exploração desta falha com a utilização de um ransomware!), além de servidores SAMBA. A falha do protocolo faz com que um atacante possa burlar a criptografia da troca de mensagens entre o administrador e o AD, possibilitando um ataque de MITM para alguém que esteja farejando os pacotes da rede. Servidores Samba conectados à rede com Active Directory ficam vulneráveis, pois a comunicação com o AD fica comprometida.
No site da RedHat, ainda não está disponível uma atualização de segurança, apenas é aconselhado a não utilizar contas de acesso privilegiado através do protocolo SMB/CIFS, o qual é implementado utilizando o DCE/RPC. 
Não é apenas uma jogada de marketing, a falha é real, portanto, administradores de redes fiquem atentos.

terça-feira, 12 de abril de 2016

Sequestro de dados, a onda do ransonware

     O mais famoso tipo de ataque do momento, ganha cada vez mais notoriedade. O ramsomware é um tipo de malware que funciona criptografando os dados da vítima e em seguida exigindo um resgate em troca da chave criptográfica. O resgate é pago em bitcoins, através de registros onion da rede Tor.
     Os último caso mais famoso foi o ataque à rede de hospitais MedStar em Maryland/EUA, pelo ransomware Samsam. 
     Por possuir uma forma de monetização facilmente estabelecida, este tipo de ataque vem chamando cada vez mais atenção. O ataque não se baseia em nenhum tipo de técnica nova, seus vetores mais comuns para o ataque ainda continuam sendo o Phishing, no caso do Petya e Locky, e exploração de softwares desatualizados. No caso da rede de hospitais citado acima, foi utilizado o ransonware Samsam. O ataque foi possível pela exploração de um servidor JBoss através da ferramenta de pen-test JexBoss (projeto de um brasileiro). 
     O ataque segue a sequência comum, são instaladas ferramentas que facilitem o serviço no servidor e gerenciem a permanência do acesso, como o Mimikatz, software que faz o serviço de sniffing da memória do servidor através de senhas de acesso. 
     A falha mais visada atualmente são servidores JBoss mal configurados, com acesso ao JMX Management Interface liberado em sistemas Windows, mas nada impede que falhas em servidores IIS ou Apache, e até mesmo sites com permissões de acesso mal configuradas se tornem potenciais portas de acesso.  
     Apesar de políticas de back-up terem seu custo tanto monetário quanto em tempo esta ainda é a melhor estratégia de defesa, além de manter seus servidores atualizados, pois neste caso, não podemos contar com a ajuda de Eddie Murphie.

terça-feira, 5 de abril de 2016

Valve e seus vazamentos

     Nos últimos dias, a atenção de algumas pessoas recaiu sobre uma falha de segurança da empresa Valve. Em um post na plataforma Medium, o usuário Ruby detalhou como conseguiu ter um jogo publicado na Steam Greenlight (que é a plataforma que libera jogos Indie para ficarem à disposição na Loja da Steam) sem passar pela aprovação da Steam, ou pagar a taxa requerida para passar direto pela aprovação. 
     Falhas na plataforma da Steam estão se tornando um evento recorrente, em Julho de 2015, o site Ars Technica noticiou uma falha de segurança em que era possível se apossar de contas da Steam apenas pelo nome da conta. 
     Em 2014, um conjunto de desenvolvedores proeminentes da Steam comunicou sua preocupação com a área de segurança da empresa através de carta aberta. Apontando um comportamento indesejado da Steam, em um certo momento premiando jogadores comuns que descobrem bugs com itens e em outra punindo contas de jogadores enviando-lhes infrações. Foi citado o caso da descoberta do Heartbleed, em que a atualização dos servidores demorou 24 horas para aplicação do patch. Na carta ainda é pedido a adoção por parte da Valve de um plano de Bug Bounty, e um canal aberto e facilitado para a comunicação dos erros, já que hoje em dia não existem canais bem divulgados e documentados para a comunicação de falhas. 
     Infelizmente, o caso de Ruby mostrou que a Valve não está muito animada para criar um sistema que corrija estes problemas. 
     Fica o conselho: pense duas vezes antes de enviar seus dados bancários a uma empresa que parece não estar colocando a segurança em 1º lugar.


quarta-feira, 30 de março de 2016

Badlock - estamos aqui pelo lucro

O mercado de marketing parece estar começando um namoro com o mercado de segurança de informação. Desde a aparição da falha Heartbleed Blug, falhas de segurança agora começam a ter nomes mais atrativos do que apenas códigos CVE.
Algumas falhas de segurança ganharam site, logo e nomes atrativos, como foi o caso do Heartbleed, o DROWN Attack, e mais recentemente o Badlock.
Anunciado como uma falha nos servidores SAMBA e relacionado a estações Microsoft, o site que anuncia o Badlock e  site não apresenta a falha, apenas anuncia que esta será apresentada ao público no dia 12 de abril deste ano, não por coincidência, neste dia a Microsoft irá lançar um patch de segurança para seus sistemas. 
O que gera polêmica, foi a divulgação da existência da falha de segurança, antes da apresentação do respectivo pacote de correção. A empresa ServNet, possui em seu time o desenvolvedor David Litchfield, um grande nome dentro do projeto Samba, além de outros quatro desenvolvedores do projeto Samba, entre eles Stephan Metzmatcher, quem descobriu a vulnerabilidade. Como a vulnerabilidade afeta sistemas SAMBA  e Windows, vem se especulando que a falha seja sobre a implementação do protocolo SMB/CIFS, porém nada foi confirmado oficialmente pela ServNet.
Além da publicação da falha, David Litchfield vem twitando pequenas "pistas" sobre qual seria a falha encontrada. 
Todo este alvoroço sobre a falha de segurança surpresa é uma boa jogada de marketing, já que a ServNet é uma empresa que fornece suporte e consultoria SAMBA.
Na minha opinião, se você tem uma empresa de consultoria, claro que almejaria contratar os grandes nomes por trás dos produtos com que você trabalha. Se encontrasse um ponto sensível, claro que faria alvoroço. Porém, anunciar uma falha de segurança três semanas antes da correção? Lançar vários hackers em uma corrida do ouro, que pode significar um 0-Day com possíveis milhares de pontos sensíveis?
Aqui parece que temos um caso entre os limites da ética e do marketing. O que você faria se uma empresa de segurança veicular criasse um site dizendo que existe uma falha que permite que qualquer um roube o seu carro? Irresponsabilidade ou chantagem? Você decide.

terça-feira, 22 de março de 2016

Martela o martelão - Row Hammering

     O distúrbio apelidado de “Row Hammering”, que consiste na manipulação de setores de memória sem possuir acesso direto à estes,  começou a levantar o interesse de grupos de segurança.
     No dia 9 de março de 2015, a iniciativa de segurança Project Zero Google, publicou um post em seu blog, tendo como base o artigo científico “ Flipping Bits in Memory Without Accessing Them: An Experimental Study of DRAM Disturbance Errors” (Alterando bits de memória sem acessá-los: um estudo experimental sobre os erros em distúrbios da DRAM, em tradução livre). 
     O post coloca de forma simplificada o artigo científico, explicando que o distúrbio consiste na ideia de que varias mudanças de dados entre duas células de informação de forma rápida e constante podem influenciar uma terceira, através de interferência eletromagnética, isto é possível, já que as células de memória são cada vez menores e alinhadas de forma mais próxima. Como o ataque depende da posição física da memória, a célula atacada, pode estar em um espaço fora da memória virtual do processo, possibilitando ataques de escalonamento de privilégio, saída de sandbox, etc. O time Project Zero conseguiu desenvolver dois exploits baseados no Row Hammering: o primeiro deles, consistia no escape da sandbox NaCi, utilizada no navegador Chrome e o segundo consistia em um escalonamento de privilégio em sistemas Linux. Como o primeiro exploit consistia em um perigo potencial para os navegadores da empresa, uma forma de contornar o problema foi desabilitar a instrução CLFLUSH da sandbox NaCi, necessária para o funcionamento  do exploit.
     Porém, este ajuste pode não ser suficiente, já que pesquisadores da universidade de Cornell publicaram um paper em que propõem um ataque de row hammering através de puro javascript! A prova de conceito row-hammer.js apresentou resultados positivos em um caso muito específico: um Lenovo x230 Ivy Bridge Laptop, com as configurações padrão com microarquitetura Haswell CPU (presente na linha Intel i). Porém ainda não foi apresentada a implementação de um exploit baseado nesta prova de conceito. 
     Esta vulnerabilidade era primeiramente tida como excepcionalmente de modelos de memória DDR3. Porém, em um paper publicado pela  Third I/O, uma empresa provedora de banda larga de Austin, Texas, parece mostrar que o distúrbio pode ser explorado em memórias DDR4, mesmo que possuam a tecnologia ECC (error-correction code), na nova abordagem da empresa Third I/O, eram aplicados padrões de informação randômicos em setores de memória.
     Parece que o maior obstáculo para a criação de ataques efetivos do row-hammering é a coincidência de um posicionamento físico próximo entre as células de memória e um posicionamento virtual que forneça uma boa vantagem, porém agora com a crescente curiosidade dos pesquisadores e hackers de plantão, talvez nos próximos meses novidades interessantes poderão ser vistas.
     Um distúrbio de hardware de uma ordem desta magnitude, e um possível vetor que pode ser aplicado em qualquer site é um prato tentador para qualquer indivíduo disposto a fazer algum estrago. =)

Links:
http://googleprojectzero.blogspot.com.br/2015/03/exploiting-dram-rowhammer-bug-to-gain.html (Post do Project Zero)
http://arstechnica.com/security/2015/08/dram-bitflipping-exploit-for-attacking-pcs-just-add-javascript/ (Row Hammering através de javascript)
http://arstechnica.com/security/2016/03/once-thought-safe-ddr4-memory-shown-to-be-vulnerable-to-rowhammer/ (row-hammering pode afetar DDR4)