it-swarm-pt.tech

Blueborne - Esclarecimento do cenário de ataque

Com base no white paper técnico

http://go.armis.com/hubfs/BlueBorne%20Technical%20White%20Paper-1.pdf?t=1505319664351

Depois de ler, entendi o seguinte (Página 13, parte inferior)

Portanto, para explorar (vulnerabilidade RCE do kernel do Linux - CVE-2017-1000251), existem dois atores Atacante e Vítima

1) O invasor envia a solicitação de configuração com o elemento EFS com o tipo definido como L2CAP_SERV_NOTRAFIC

2) O invasor envia a resposta de configuração com o campo de resultado definido como L2CAP_CONF_PENDING e parâmetros possivelmente repetidos, por exemplo, muitos valores de MTUs, para acionar o estouro de pilha

Estou confuso, pois pensei que a Vítima deveria enviar a Resposta de Configuração com base na solicitação de Configuração do Atacante, mas no papel é descrito como acima.

Isso está correto? Eu interpretei mal? Alguém pode me explicar/corrigir sobre isso?

Obrigado,

Atualização 1:

Quando ajudar alguém, aqui está um rastreamento do Conf Request Wireshark.

Tenha estes 2 adaptadores

Cliente - 00: 1A: 7D: DA: 71: 13

Servidor - 34: F3: 9A: 10: 52: C9

Aqui com o cliente eu configurei MTU para 2000

./l2cap-client 00:1A:7D:DA:71:13
mtu: ok

./l2cap-server 
accepted connection from 34:F3:9A:10:52:C9

enter image description here

Alguém pode explicar isso? Tenho plano de fundo TCP/IP ....

O que significa localhost ()?

Por que ele envia do localhost () para o cliente (Conf req) do que do cliente para o localhost () (Redvd Conf Req) do que o servidor envia para o localhost () (Recvd Conf Req) e do localhost () para o servidor (Sent Conf Response) é enviado e no final o Cliente e o Servidor enviam para localhost () Recv Conf Response - Sucesso?

Atualização 2:

Encontrado isso, com base nisso, cada dispositivo deve enviar uma solicitação de conf e cada solicitação deve receber uma resposta de conf.

L2CAP Channel Establishment

Por que parece tão estranho do que no meu rastreamento do Wireshark?

Atualização 3:

Ok, eu acho, eu descobri ....

Atacante

Envia:

Solicitação de configuração enviada (DCID: 0x0040)

O invasor envia a solicitação de configuração com o elemento EFS com o tipo definido como L2CAP_SERV_NOTRAFIC

Recebe ao mesmo tempo um pedido de conf de outra parte:

Solicitação de configuração de Rcvd (DCID: 0x0040)

Envia:

O invasor envia a resposta de configuração com o campo de resultado definido como L2CAP_CONF_PENDING e parâmetros possivelmente repetidos, por exemplo, muitos valores de MTUs, para acionar o estouro de pilha

Atualização 4:

Indo para a próxima etapa ... elaborando os frames, aqui estão minhas próximas perguntas se alguém estiver interessado no SO:

https://stackoverflow.com/questions/46317365/bluetooth-reply-data-frame-using-l2test

7
dev

O Linux usa o Bluz para implementar a pilha bluetooth que integra o bluetooth na comunicação de soquete universal. Assim, você pode se comunicar com o dispositivo bluetooth usando o mecanismo de soquete tradicional. Mais detalhes aqui: https://people.csail.mit.edu/albert/bluez-intro/x559.html

1
Os Tiger