quarta-feira, 25 de março de 2015

Detectando o tráfego malicioso em redes VoIP

VoIP (Voz sobre IP) aproveita-se da infra-estrutura IP existente em uma rede e muitas vulnerabilidades que afetam comunicações IP tradicionais também afetam comunicações VoIP. Portanto, cavalos de Tróia, ataques DDoS e exfiltração não autorizada de informações confidenciais são uma preocupação dentro das redes habilitados para VoIP. Vamos focar em um desses ataques, o SIP-flood.

O protocolo SIP (Session Initiation Protocol) tornou-se o padrão de fato para a sinalização de camada de aplicação dentro de redes VoIP. Definido pela RFC 3261, as solicitações SIP são compostas dos seguintes itens: REGISTER, INVITE, ACK, CANCEL, BYE e OPTIONS. A parte da requisição SIP que interessa aqui é o INVITE.

A parte do SIP que mais se assemelha a solicitação HTTP-GET é o SIP INVITE, que é a porção do SIP que configura uma sessão entre dois agentes (usuários) e dentro desta configuração reside uma vulnerabilidade de negação de serviço (DoS). O SIP INVITE como o HTTP também utiliza um handshake de três vias por TCP para estabelecer conexões lógicas com hosts remotos, SIP utiliza um método de handshaking semelhante, que consiste em INVITE e mensagens do tipo 200 OK. Quando detectado um número desproporcional de handshakings incompletos, pode ser um sinal revelador de que um ataque SIP-Flood está em andamento.

Então, como detectar esse tipo de tráfego malicioso? Vamos verificar uma solução que faz uso do conhecido Wireshark.


Em primeiro lugar, garanta que o Wireshark está instalado em um dispositivo que pode receber chamadas SIP de dentro da mesma rede do servidor SIP. Abra o Wireshark e selecione a interface que manipula as comunicações VoIP. Isso geralmente é feito em eth0 (placa de Ethernet). Em seguida, inicie a captura de pacotes e uma enxurrada de tráfego de rede deve começar a cruzar o monitor.

Neste ponto, você pode começar a inundar um dos dispositivos SIP, rodando uma ferramenta de inundação de sua escolha. A versão gratuita conhecida como inviteflood  pode ser encontrado na maioria das distros de BackTrack Kali Linux. Suponha que o endereço SIP para um dos dispositivos de final é enduser@192.168.1.10 e a inundação deste endereço com INVITE é de cerca de 200 pedidos por segundo. O Wireshark deve começar a capturar vários pacotes de REGISTER, INVITE, e OK. Em seguida, insira o seguinte filtro no Wireshark:

sip.Method=="INVITE" || sip.Status-Line=="SIP/2.0 200 OK" || sip.Method=="ACK"

Este filtro irá permitir que o usuário final veja todos os INVITE, OK e ACK, e o ataque de sip-flood foi configurado corretamente, o usuário final não deve ver pacotes ACK. Por que isso?

Em um ataque de inundação INVITE tradicional, o invasor envia uma solicitação INVITE para um endereço SIP específico e, quando o dispositivo final SIP, eventualmente, responde com uma mensagem 200 OK, o atacante nunca responde com a terceira parte do three-way handshake - a mensagem de ACK. No entanto, o dispositivo final vitimado não sabe que o pacote ACK esperado nunca vai chegar, por isso aloca previamente os recursos necessários, enquanto mais pacotes INVITE começam a entrar em sua fila. Quando o limite de buffer do dispositivo estoura, o dispositivo final pode falhar ou, em alguns casos, ter um reset de fábrica.

Caso detectado que há muita disparidade na relação INVITE/OK/ACK, os administradores de segurança podem ser alertados para que algumas medidas possam ser implementadas. Por exemplo, bloqueio de endereços IP ou domínios que estão gerando um elevado número de mensagens OK não confirmadas.

terça-feira, 24 de fevereiro de 2015

Lenovo insere malware de propósito em seus dispositivos

Alguns notebooks Lenovo contém um malware que injeta anúncios no navegador e espiona as conexões seguras da máquina. Isso não seria nenhuma novidade se o malware não fosse inserido propositadamente nos dispositivos pela própria fabricante.



O adware, chamado Superfish, está presente nos modelos G40, Y40 e Z50 da Lenovo.

Segundo o Ars Technica o adware instala um certificado HTTPS que pode interceptar o tráfego criptografado
de internet. Além disso, o Superfish usa o mesmo certificado em todos os laptops em que está instalado, tornando o computador vulnerável a ataques man-in-the-middle.




A Lenovo se explicou dizendo que “o Superfish foi temporariamente removido de nossos laptops para consumidores”, mas defendeu a sua presença, explicando que ele “ajuda os usuários a encontrar e descobrir produtos visualmente”, e “analisa instantaneamente imagens na web e apresenta ofertas de produtos idênticos ou similares que podem ter preços mais baixos”.

Como remover: http://support.lenovo.com/us/en/product_security/superfish_uninstall

May The Source be with You.

quinta-feira, 15 de janeiro de 2015

KeySweeper ou por que não uso teclado sem fio da Microsoft

O título desse post começa com essa pergunta:
"Por que não uso teclado sem fio da Microsoft"?
Resposta: porque é caro  KeySweeper


O pesquisador de segurança Samy Kamkar criou um carregador USB apelidado de KeySweeper, que registra secretamente as teclas digitadas a partir de teclados sem fio da Microsoft nas proximidades.


O dispositivo baseado em Arduino funciona como um carregador de celular USB genérico, mas ele tem a capacidade de capturar, decifrar e enviar de volta as teclas digitadas a partir de um teclado wireless Microsoft na vizinhança. KeySweeper pode enviar dados capturados de volta para o operador através da Internet ou usando um chip GSM opcional.

KeySweeper is a stealthy Ardunio-based device camouflaged as a wall charger that wirelessly sniffs, decrypts, logs and reports-back all keystrokes from any Microsoft wireless keyboard in the vicinity”  explicou Kamkar.




Kamkar também detalhou os passos para construir o KeySweeper explicando que é fácil e barato para montar o dispositivo de espionagem, os custos variam de $10 a $80 dólares, dependendo das funções incluídas. As instruções sobre como construir o dispositivo estão disponíveis on-line no GitHub.

We are aware of reports about a ‘KeySweeper’ device and are investigating” é o comentário do porta-voz da Micro$oft.

May The Source be with You.

terça-feira, 6 de janeiro de 2015

Falha no Windows 8.1 permite elevação de privilégios. Microsoft ciente há 90 dias ainda não corrigiu o problema.

A Google tornou público os detalhes de uma vulnerabilidade de segurança no Windows 8.1

A Microsoft tinha sido avisada desde setembro e o bug pode permitir que um usuário logado execute código no Windows 8.1 com privilégios de administrador.
A falha está no manuseio da chamada de sistema NtApphelpCacheControl(): um programa deve primeiro obter um token de acesso a partir de um processo de nível de sistema, como o BITS, e, em seguida, chamar a função anteriromente mencionada para inserir uma entrada no cache de compatibilidade de aplicativos - uma operação de nível de administrador. Quando o token de acesso é examinado, o nível de representação do programa não está marcado, permitindo que o software em nível de usuário passe por um programa privilegiado e modifique o cache. A entrada de cache pode levar o Windows a rodar um executável com privilégios elevados.

"Este bug está sujeito a um prazo de divulgação 90 dias", a equipe de segurança do Google relatou quando ele avisaram a Microsoft sobre o erro de programação. "Se 90 dias transcorrer sem um patch disponível, o relatório de erro se tornará automaticamente visível para o público."

Esse prazo já passou, e os detalhes completos do bug foram revelados em 30 de dezembro de 2014 - incluindo o código de prova de conceito (PoC), que a Chocolate Factory disponibilizou tanto em código fonte e formato binário executável.

Mas nem todos concordam com a política de divulgação agressiva do Project Zero, do Google, que foi fundada em julho de 2014, com o objetivo de erradicar bugs em softwares.

"Revelar automaticamente esta vulnerabilidade quando um prazo é alcançado sem nenhum contexto parece-me incrivelmente irresponsável e eu esperava mais cuidado e maturidade de uma empresa como a Google", escreveu um comentarista no relatório do bug.

Outros ressaltaram, no entanto, que só porque um bug ainda não foi divulgado publicamente não significa hackers ainda não estão explorando-a.

"Ninguém está fazendo bem mantendo-o em segredo", escreveu outro comentarista. "Ao expor a vulnerabilidade eles permitem que esses bilhões que podem estar expostos a essa ameaça fiquem ciente da mesma e tomem medidas defensivas."

O pesquisador de segurança do Google, Ben Hawkes, defendeu a política da empresa, escrevendo:

     O Project Zero acredita que os prazos de divulgação são atualmente a melhor abordagem para a segurança do usuário - permite aos fornecedores de software um tempo justo e razoável para exercer o seu processo de gerenciamento de vulnerabilidades, além de respeitar os direitos dos usuários de aprender e compreender os riscos que enfrentam.

     Com isso dito, vamos monitorar os efeitos dessa política muito de perto... Estamos felizes em dizer que os resultados iniciais mostraram que a maioria dos erros que temos relatados... foram corrijidos dentro do prazo, que é um testamento ao trabalho duro dos vendedores.

Em resposta à divulgação, a Microsoft emitiu uma declaração dizendo que está ciente do problema e está preparando uma correção.

"Estamos trabalhando para lançar uma atualização de segurança para resolver um problema de elevação de privilégio", um porta-voz da Microsoft disse via e-mail. "É importante notar que para um possível invasor potencialmente explorar um sistema, ele primeiro precisa ter credenciais de logon válidas e poder fazer logon localmente em uma máquina alvo. Recomendamos aos clientes que mantenham seu software anti-virus atualizados, instalem todas as atualizações de segurança disponíveis e ativem o firewall em seu computador."

A Micro$oft não declarou se planeja ter uma correção para o problema até o Patch Tuesday deste mês, que será dia 13 de janeiro.

May The Source be with You.

Governo Indiano bloqueia GitHub, Pastebin, Sourceforge.net e mais 30 sites

Na véspera de ano novo, o governo indiano bloqueou mais de 30 sites, incluindo GitHub e Sorceforge.net por razões de segurança. De acordo com o IT Cell, esses sites podem ter conteúdo relacionado com o grupo pró-terrorista ISIS, e uma resposta negativa de cooperar nas investigações levaram ao amplo bloqueio no país asiático. Todos os fornecedores de serviços Internet no país foram aconselhados a bloquear o acesso a esses sites.
Arvind Gupta, chefe da IT Cell, twittou: "Os sites foram bloqueados baseando-se em um comunicado do Esquadrão Anti-Terrorismod, e estavam fornecendo conteúdo Anti Índia e pró ISIS. Os sites que tiverem o conteúdo censurado removidos e/ou colaborarem com as investigações serão desbloqueados."

A decisão recebeu um grande clamor dos cidadãos sobre os sites de redes sociais. No entanto, os funcionários do IT Cell disseram que alguns dos sites serão desbloqueados quando cooperarem com as investigações.

De acordo com um agente do IT Cell, esses sites têm alguns dos códigos mais perigosos do planeta. Eles podem ser usados para causar dano a qualquer tipo de serviço on-line. No entanto, o que é importante saber é que existem vários outros sites, incluindo exploit-db, que fornecem os códigos e exploits para fazer isso. Pastebin, GitHub e Sourceforge.net não podem ser os únicos culpados de ter esse tipo de código.

O Governo indiano baseou-se na seção 69A da Lei de Informática (2000) e Tecnologia da Informação (Procedimento e Salvaguarda para Bloqueio de acesso à Informação Pública) e Rules ("As regras de bloqueio") para restringir o acesso a esses sites.

Houve uma revolta dos ativistas da Internet, e principalmente por parte dos desenvolvedores pelo bloqueio de acesso ao GitHub. Aparentemente, o governo não está ciente do fato de que esses sites são para compartilhar e desenvolver código de forma colaborativa.

May The Source be with You.

segunda-feira, 5 de janeiro de 2015

Norma sobre Segurança da Informação do Governo Federal tem cláusula de estímulo ao software livre retirada da pauta

O governo publicou em meados do mês passado uma revisão da norma sobre o tratamento das informações no âmbito da administração federal. Entre as principais modificações, exige-se a identificação da pessoa ou órgão responsável por determinada informação, a ampliação do uso de criptografia de Estado. Também pela segurança descartou-se o privilégio de adoção de formatos abertos e não proprietários.
Trata-se da primeira revisão da Norma 20, do Departamento de Segurança da Informação e Comunicações – documento que trata de diretrizes de segurança do processo de tratamento da informação. Em si, ela trata das regras a serem seguidas por todos os órgãos públicos federais sobre acesso, classificação e tratamento de informações.

Uma das alterações parece atingir diretamente o estímulo ao software livre. Na versão original, “os órgãos e entidades da APF [Administração Pública Federal] deverão priorizar a adoção de formatos abertos e não proprietários, sempre que possível, para preservar as informações digitais e permitir seu amplo acesso, conforme padrões de interoperabilidade do Governo Eletrônico.

O texto revisado não inclui mais nenhuma menção aos “formatos abertos e não proprietários”, muito menos a prioridade de adoção dos mesmos. Em seu lugar, a referência ficou restrita a: “Recomenda-se a observância dos padrões de interoperabilidade do Governo Eletrônico”.

No campo criptográfico, as regras do DSIC já previam que informações sigilosas devem ser submetidas a criptografia que utilize algoritmo de Estado – ou seja, um sistema criptográfico desenvolvido dentro do governo. Vale dizer, com uso dos algoritmos do Centro de Pesquisas e Desenvolvimento para a Segurança das Comunicações, Cepesc, ligado à Abin.

Com a revisão qualquer informação classificada deve ser “produzida e custodiada”, “armazenada em meios eletrônicos” sempre com “uso de criptografia baseada em algoritmo de Estado”. Mais do que isso, mesmo no “transporte, transmissão e distribuição de mídias que contenham informação sigilosa” também precisa ser usada a criptografia.

A norma revisada inclui conceitos novos como do “custodiante da informação” – qualquer indivíduo ou estrutura do órgão “que tenha a responsabilidade formal de proteger a informação” – de “informação pessoal” ou ainda “proprietário da informação” –  o indivíduo que, pelo cargo que ocupa, é o responsável pela sobrevivência da informação.

May the Source be with You.

terça-feira, 30 de dezembro de 2014