Mitigação II: Contra microcontroller Teensy++ 2.0 (appliance corporativo)

Endpoint Protector 4 – one step ahead the Teensy Board threat

The microcontroller Teensy++ 2.0 is one of the latest threats for endpoint security. It can be plugged into a miniUSB port,  is identified as keyboard or mouse and is able to emulate every keystroke or move made by the usual input devices. With Endpoint Protector 4 you won’t be a victim of Teensy 2.0 or Teensy++ 2.0. The endpoint security solution identifies Teensy Boards, enabling you to block or allow them without affecting the normal use of your keyboard and mouse.

Get in touch now with your local CoSoSys (sales@cososys.com) sales person for more information and customized sales offers.

Essa solução em appliance que pode ser visto no site (http://www.cososys.com/) promete resolver os problemas de acesso a portas USB não autorizadas com o Teensy++ 2.0

Só testando mesmo!

@firebitsbr

 

Mitigação: Contra Acesso Fisico do Teenspy USB em Laptops com Linux (Debian 6)

Não a nada pior que ter bons amigos…rss

Num dia desses, eu estava trabalhando normalmente, quando Ulisses Castro, Erick, Douglas e o Roberto Espreto, estavam próximos da minha mesa, quando de repente, aparecesse com arduino Teenspy USB (http://www.pjrc.com/teensy/) 😉

 

Eu já tinha ouvi falar desse equipamento em 2008 (confesso que queria ter comprado, mas não tinha cartão de crédito na época), que através de uma porta USB, pode “exploitar” qualquer equipamento, desde que preparado para isso.

A primeira vez que eu conheci, foi em uma opção que tinha no framework Social-Engineer Toolkit (SET).

De algumas semanas para cá, comecei a reparar que quando eu espetava um pendrive USB no meu laptop e em qualquer outro com Linux (Debian/Ubuntu e outros que tem autorun por udev ou qualquer outro abistrador de hardware) ele abria automaticamente o conteúdo do pendrive, possivelmente fazia uma execução de comandos, se estivesse implementado.

Via muito isso acontecer com Thunar e Nautilus, que são gerenciadores de arquivos.

Fui buscar algo no /sys/ que dá para setar “on the fly” e restaurar se necessário a opção default.

Ai achei essa linha de comando, que

$ cat /sys/bus/usb/devices/usb1/authorized
$ 1

Sendo que “1” é ligado e “0” desligado, imaginei que podesse setar esse opção, então fiz:

$ echo 0 > / sys/bus/usb/devices/usb1/authorized

Dei um cat:

$ cat /sys/bus/usb/devices/usb1/authorized
$ 0

Então, espetei um pendrive, não houve execução automatica.

O problema é que no meu caso só tenho 3 USBs, mas no /sys/bus/usb/devices/usb  haviam 6 USBs (então as outras 3 são webcam, fingerprint e outro dispositivo que não sei determinar ainda, apesar de não serem removíveis, o sys, entende com USB) e ai fui tentando cada entrada USB, com os comandos que passei acima, apenas mudando o device, para usb2,usb3,usb4,usb5 e usb6 até acertar as outras entradas USB.

Perfeito! Estava, vamos dizer, com hardening físico e logico nessas entradas USB.

Mas havia um problema. Depois que reiniciasse o laptop, as entradas USB, voltavam para opção default que é “1” e o problema aparecia de novo.

Então, tinha 2 opções:

1ª) Não tão inteligente – > adicionar echo 0 > / sys/bus/usb/devices/usb1/authorized de cada entrada USB no arquivo /etc/init.d/rc.local

Problema dessa abordagem, é que se o atacante desligar seu laptop e iniciar com o TeenSpy na porta USB, após descompactação em memória, iria executar várias outras coisas e bem depois a sequencia /etc/init.d/rc.local, ou seja, já “exploitado”.

2ª Mais inteligente – > adicionar no /etc/sysctl.conf não tentei ainda, mas muita coisa, inclusive hardening de conf de kernel é feita pra ficar fixo lá. Eu imagino que logo que o kernel é descompactado, já são lidos as instruções de lá.

Vou testar mais sobre isso e faço um post aqui

@firebitsbr