Faz tempo que não fazia nenhum tipo de hacking e, coincidentemente, andei com um problema onde precisava entender o que o webserver de um equipamento fazia em determinada situação. Parecia existir um comando oculto não disponibilizado pela API do equipamento e decidi olhar por mim mesmo, já que a empresa se negou a me mandar a senha de root do equipamento. Antes de mais nada, não esperem nomes aqui ou posso ter um problema de contrato.
Munido do bom e velho espírito hacker, fiz o seguinte:
1) Baixei uma imagem do firmware do fabricante. Geralmente existe alguma imagem de atualização no site. Um simples registro no site, em geral, já te dá acesso a isso.
2) Baixei o binwalk, já comentado pelo Alan e para o qual eu gerei um .deb, para faciliar.
3) Rodei o binwalk e pude perceber que era uma composição de um uboot+uboot parameters+kernel linux+imagem do sistema em JFFS2. Nada de inovador, apenas o já esperado. Bom pra mim. Os valores de offset abaixo (número à esquerda) são fictícios, já que não posso dar os detalhes deste firmware:
DECIMAL HEX DESCRIPTION ---------------------------------------------------------------------------- 4660 0x1234 LZMA compressed data .... 9029 0x2345 uImage header, header siz .... 13398 0x3456 gzip compressed .... 17767 0x4567 JFFS2 filesystem .... ....
4) Nenhum mistério. E o que eu precisava,o root file system, estava em JFFS2, esperando minha extração, à partir do offset imaginário 17767:
dd ibs=1 skip=17767 if=firmware.bin of=rootfs.jffs2
5) Montei o JFFS2 em loop, usando uma dica do OpenMoko:
export loop=$(losetup -f) losetup $loop rootfs.jffs2 modprobe block2mtd block2mtd=$loop,131072 modprobe jffs2 modprobe mtdblock mkdir rootfs mount -t jffs2 -o ro /dev/mtdblock0 rootfs
Neste momento, pude inspecionar e olhar o que eu precisava dentro do rootfs.Para minha sorte, o script web dele era implementado em shell script.
6) Como o fabricante me negou o acesso de root, me dando apenas um shell personalizado e bem restrito, resolvi também ver qual eram as credenciais de acesso. Para isto, copiei o rootfs/etc/shadow chamei o meu amigo John:
sudo apt-get install john john -incremental -users:root
Ainda estou esperando terminar (~21 horas e contando), mas em breve terei a senha de root também. Na última fez que fiz isso, com o mesmo fabricante mas uma imagem mais antiga, demorou 3 dias. Só que, naquela época, ele não usava shadow, apenas o /etc/passwd com direito de leitura para todos. Daí, apenas quebrei a senha, não precisei fazer nada do que descrevi aqui.
Happy hacking !
Marcelo Barros
#1 por acassis em junho 6, 2012 - 1:28 pm
Muito massa Marcelo,
Estou na espectativa, vai divulgar a senha de root aqui ne?
Um abraço,
Alan
#2 por Marcelo Barros em junho 6, 2012 - 1:51 pm
Quem sabe um pedacinho dela, nhein ?
Mas até agora, nada …. uma questão de tempo
#3 por acassis em junho 22, 2012 - 1:58 pm
ping!
Nada ainda?
#4 por Djames Suhanko em junho 22, 2012 - 6:19 pm
Grande mestre Marcelo!
Excelente material, valeu por divulgar!
#5 por Marcelo Barros™ (@marcelobarros) em junho 22, 2012 - 6:24 pm
Via john the ripper não rolou, Alan. O Djames está tentando outro programas.
Perguntaram de onde vem o 131072 vem do eraseblock size., usado no mkfs.jffs2 (http://wiki.maemo.org/Modifying_the_root_image)
#6 por cleitonbueno em maio 16, 2013 - 2:25 pm
bueno@vm2:~/tools$ sudo binwalk firmware.bin
.
.
.
1180160 0×120200 Squashfs filesystem, little endian, version 4.0, compression: lzma, size: 2468994 bytes, 540 inodes, blocksize: 131072 bytes, created: Mon Apr 1 03:30:19 2013
bueno@vm2:~/tools$ sudo dd ibs=1 skip=1180160 if=firmware.bin of=rootfs.squashfs
2883584+0 records in
5632+0 records out
2883584 bytes (2,9 MB) copied, 0,805672 s, 3,6 MB/s
bueno@vm2:~/tools$ sudo ./squashfs4.2/squashfs-tools/unsquashfs rootfs.squashfs
Parallel unsquashfs: Using 2 processors
lzma uncompress failed with error code 1
read_block: failed to read block @0x25a765
read_fragment_table: failed to read fragment table index
FATAL ERROR aborting: failed to read fragment table
bueno@vm2:~/tools$ sudo ../squashfs4.2/squashfs-tools/unsquashfs -v
unsquashfs version 4.2 (2011/02/28)
copyright (C) 2011 Phillip Lougher
Até compilei na mão, habilitando LZMA no Makefile e pegando o mais recente da fonte
http://sourceforge.net/projects/sevenzip/files/LZMA%20SDK/9.18/
e compilando porem sem exito.
Em um ultimo suspiro, peguei a versão masi recente do Kernel até esses dias 3.9.2 personalizaei o config para suporte a lzma, squashfs dentre outros e sem exito também.
Sabe como poderia ser feito?
Abraço.
#7 por Marcelo Barros em maio 17, 2013 - 3:34 pm
Estranho, parece que não existe compressão ou não é squashfs. Em que sistema testou ? O firmware era para x86 ou arm ?
#8 por cleitonbueno em maio 17, 2013 - 3:56 pm
Sistema testei com Ubuntu 12.04 64Bits, Linux Mint 13 Maya 64Bits e em casa em uma VM Virtuabox com Debian 6 32Bits.
Esqueci de manda o resto do binwalk:
15568 0x3CD0 uImage header, header size: 64 bytes, header CRC: 0x3AE2AEED, created: Mon Mar 25 06:13:15 2013, image size: 32805 bytes, Data Address: 0×80010000, Entry Point: 0×80010000, data CRC: 0×71407091, OS: Linux, CPU: MIPS, image type: Firmware Image, compression type: lzma, image name: u-boot image