Padocon CTF | Warmup100 -- by Ivanlef0u
Ce weekend se déroulait le CTF organisé pour la conférence PAraDOx (twitter) qui se déroule en Corée. La team nibbles était bien sur de la partie et à même finie 14ème (id ox90909090) sur environ 90 inscrits. Un bon CTF (url) d’ailleurs avec plein d’épreuves sympas, on avait des crackmes win et linux, des exploitme (beaucoup en fait :]), du webhack, un peu de crypto relou et des trucs weirds. Le CTF commençait vendredi soir à 22h KST, soit 14h en france et finissait 48h plus tard. Voici la timeline de nos validations :
start @ 22h KST 1. [10/02/05 23:58:55] CrackMe 100, 200 2. [10/02/06 00:45:17] CrackMe 200, 200 3. [10/02/06 00:58:14] CatchMe, 200 4. [10/02/06 02:42:27] web300, 200 5. [10/02/06 06:38:31] warmup100, 200 6. [10/02/06 08:58:53] ddanjin, 300 7. [10/02/06 09:27:44] trililogy100, 400 8. [10/02/06 10:20:42] trililogy200, 400 9. [10/02/06 10:33:20] tomato, 200 10. [10/02/06 10:47:24] warmup200, 200 11. [10/02/06 18:55:44] karma100, 400 12. [10/02/06 19:36:59] karma200, 400
Et le classement final le dimanche à 14h :
1. ???(ADNIM), 5600 (beistlab) 2. GoN(loco), 4700 3. PPP(pwning), 4500 4. lalalulu(lalalulu), 4500 5. Cyworld(abc123), 4500 6. sonic,elnn(1234), 4500 7. PEAK(PEAK), 4500 8. asdf(asdf), 4500 9. Sapheadz(sapheadz), 4400 10. is119(is119), 3900 11. ????(qwer), 3800 12. NollTour(NollTour), 3800 13. clgt(clgtvnsec), 3600 14. Nibbles(ox90909090), 3300 15. ??(bada), 3300
Je vous propose un writeup sur une des épreuves d’exploitme, warmup100, celle-ci nous a laissé dubitatif au début mais on l’a poncé grâce à une technique d’exploitation intéressante.
(Lire la suite…)
ldd(1) is good but objdump(1) is better -- by sbz
Micro post to know shared libraries needed by a ELF binary. We can know them using the common ldd(1) :
(sbz@atemi:~)[0:0] % ldd /usr/local/bin/irssi
/usr/local/bin/irssi:
libgmodule-2.0.so.0 => /usr/local/lib/libgmodule-2.0.so.0 (0x33d29000)
libglib-2.0.so.0 => /usr/local/lib/libglib-2.0.so.0 (0x33d2d000)
libintl.so.8 => /usr/local/lib/libintl.so.8 (0x33ddf000)
libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x33de8000)
libpcre.so.0 => /usr/local/lib/libpcre.so.0 (0x33edf000)
libssl.so.5 => /usr/lib/libssl.so.5 (0x33f11000)
libcrypto.so.5 => /lib/libcrypto.so.5 (0x33f5b000)
libncurses.so.5.7 => /usr/local/lib/libncurses.so.5.7 (0x340b5000)
libc.so.7 => /lib/libc.so.7 (0x340d2000)
libtinfo.so.5.7 => /usr/local/lib/libtinfo.so.5.7 (0x341d5000)
But using objdump(1) is more funny:
(sbz@atemi:~)[0:0] % objdump -x /usr/local/bin/irssi |grep NEEDED
NEEDED libgmodule-2.0.so.0
NEEDED libglib-2.0.so.0
NEEDED libintl.so.8
NEEDED libiconv.so.3
NEEDED libpcre.so.0
NEEDED libssl.so.5
NEEDED libcrypto.so.5
NEEDED libncurses.so.5.7
NEEDED libc.so.7
NEEDED libtinfo.so.5.7
But how it works ?? Just because ELF binary contains a section .dynamic with entries NEEDED used by the dynamic linker.
To get alls the sections, we need to use readelf(1) or use info files in gdb(1):
(sbz@atemi:~)[0:0] % readelf -S /usr/local/bin/irssi
There are 26 section headers, starting at offset 0xb3ee0:
Section Headers:
[Nr] Name Type Addr Off Size ES Flg Lk Inf Al
[ 0] NULL 00000000 000000 000000 00 0 0 0
[ 1] .interp PROGBITS 08048114 000114 000015 00 A 0 0 1
[ 2] .note.ABI-tag NOTE 0804812c 00012c 000018 00 A 0 0 4
[ 3] .hash HASH 08048144 000144 002644 04 A 4 0 4
[ 4] .dynsym DYNSYM 0804a788 002788 005880 10 A 5 1 4
[ 5] .dynstr STRTAB 08050008 008008 005945 00 A 0 0 1
[ 6] .gnu.version VERSYM 0805594e 00d94e 000b10 02 A 4 0 2
[ 7] .gnu.version_r VERNEED 08056460 00e460 000020 00 A 5 1 4
[ 8] .rel.dyn REL 08056480 00e480 000048 08 A 4 0 4
[ 9] .rel.plt REL 080564c8 00e4c8 000a88 08 A 4 b 4
[10] .init PROGBITS 08056f50 00ef50 000011 00 AX 0 0 4
[11] .plt PROGBITS 08056f64 00ef64 001520 04 AX 0 0 4
[12] .text PROGBITS 08058490 010490 087ab4 00 AX 0 0 16
[13] .fini PROGBITS 080dff44 097f44 00000c 00 AX 0 0 4
[14] .rodata PROGBITS 080dff60 097f60 0141c6 00 A 0 0 32
[15] .eh_frame_hdr PROGBITS 080f4128 0ac128 000014 00 A 0 0 4
[16] .data PROGBITS 080f5140 0ac140 005d20 00 WA 0 0 32
[17] .eh_frame PROGBITS 080fae60 0b1e60 00003c 00 A 0 0 4
[18] .dynamic DYNAMIC 080fae9c 0b1e9c 000118 08 WA 5 0 4
[19] .ctors PROGBITS 080fafb4 0b1fb4 000008 00 WA 0 0 4
[20] .dtors PROGBITS 080fafbc 0b1fbc 000008 00 WA 0 0 4
[21] .jcr PROGBITS 080fafc4 0b1fc4 000004 00 WA 0 0 4
[22] .got PROGBITS 080fafc8 0b1fc8 000550 04 WA 0 0 4
[23] .bss NOBITS 080fb520 0b2520 00180c 00 WA 0 0 32
[24] .comment PROGBITS 00000000 0b2520 0018f4 00 0 0 1
[25] .shstrtab STRTAB 00000000 0b3e14 0000cc 00 0 0 1
We will dump them with a gdb(1) batch command:
(sbz@atemi:~)[0:0] % cat >/tmp/bla <<EOF
info files
EOF
(sbz@atemi:~)[0:0] % gdb --batch --command=/tmp/bla /usr/local/bin/irssi
(no debugging symbols found)...Symbols from "/usr/local/bin/irssi".
Local exec file:
`/usr/local/bin/irssi', file type elf32-i386-freebsd.
Entry point: 0x8058490
0x08048114 - 0x08048129 is .interp
0x0804812c - 0x08048144 is .note.ABI-tag
0x08048144 - 0x0804a788 is .hash
0x0804a788 - 0x08050008 is .dynsym
0x08050008 - 0x0805594d is .dynstr
0x0805594e - 0x0805645e is .gnu.version
0x08056460 - 0x08056480 is .gnu.version_r
0x08056480 - 0x080564c8 is .rel.dyn
0x080564c8 - 0x08056f50 is .rel.plt
0x08056f50 - 0x08056f61 is .init
0x08056f64 - 0x08058484 is .plt
0x08058490 - 0x080dff44 is .text
0x080dff44 - 0x080dff50 is .fini
0x080dff60 - 0x080f4126 is .rodata
0x080f4128 - 0x080f413c is .eh_frame_hdr
0x080f5140 - 0x080fae60 is .data
0x080fae60 - 0x080fae9c is .eh_frame
0x080fae9c - 0x080fafb4 is .dynamic
0x080fafb4 - 0x080fafbc is .ctors
0x080fafbc - 0x080fafc4 is .dtors
0x080fafc4 - 0x080fafc8 is .jcr
0x080fafc8 - 0x080fb518 is .got
0x080fb520 - 0x080fcd2c is .bss
Extract the bash history from a process’ memory -- by milo
The problem was: how can I get the bash history of a (rogue) user while his shell is still running. If he’s rogue, one can bet he’s gonna logout with `kill -9 $$’, thus killing his session’s history. So I had to get it from the process memory without him noticing it.
SSLSTRIP, ou l’illusionniste du traffic sécurisé -- by ipv
À l’heure ou la sensibilisation liée aux dangers encourus sur internet devient un enjeu de plus en plus important,
certains outils apparaissent et réduisent (presque) à néant les multiples précautions fournies aux utilisateurs lambda
sur le monde hostile de l’internet.
Je vais vous présenter Sslstrip, un outil développé en python (langage très prisé dans le domaine de la sécurité) par Moxie Marlinspike[1](l’auteur de sslsniff) qui va agir au niveau de la couche application afin de remplacer (d’où le ’strip’) certaines informations précises.
Conversion decimal<=>hexadecimal -- by sbz
On a toujours besoin de faire ces conversions alors je vous propose d’a ajouter dans votre ~/.shellrc les deux fonctions suivantes. Oui, oui on peut le faire avec bc ou autre … mais Python FTW :)
function d2h() { local d d=$1 python -c "print '0x%x' % $d" ou python -c "print hex($d)" } function h2d() { local h h=$1 python -c "print int(\"$h\", 16)" }
On test:
(sbz@atemi:~)[0:0] % source ~/.zshrc
(sbz@atemi:~)[0:0] % d2h 102
0x66
(sbz@atemi:~)[0:0] % h2d 0x66
102
On notera qu’on peut aussi faire plein de conversion facile, par exemple en base 2 avec python -c ‘print int(« 0101″, 2)’ et pour pour le reste on utilisera le module binascii.
Linux bind shellcode (78 bytes) -- by Ivanlef0u
Dans le genre optimisation de shellcodes celui de izik est pas mal. Ce qu’il fait en lui même est assez classique, il s’agit d’un simple portbind(31337) suivit d’un excve(‘/bin/sh’) mais il fait bien en étant le plus petit possible. Tous les tricks employés font qu’on est proche de la perfection.
Linux ppc32 shellcode exceve « /bin/sh » -- by Ivanlef0u
Depuis quelques jours j’ai accès à une debian sur un serveur cluster APPLE Xserve G5 (thx kln pour l’install de roxor !). Vu que j’aime bien m’amuser avec du nouveau stuff j’ai décidé de faire un peu de shellcoding dessus, on sait jamais ca peut toujours servir. J’ai donc écrit un petit shellcode pour powerpc :]
Break your ARMs Part 3 -- by Ivanlef0u
Suite et fin de cette série de posts sur l’exploitation d’un binaire ARM. La dernière fois nous avons vu comment exploiter la vulnérabilité, maintenant nous allons étudier la réalisation d’un shellcode sous architecture ARM. Ça rigole zéro !
Break your ARMs Part 2 -- by Ivanlef0u
Suite du précédent post sur l’exploitation d’un binaire ARM en remote apparu lors du CSAW CTF. Pour rappel il s’agit d’un deamon httpd qui possède une faille applicative, on a la source du binaire et l’image de la machine qui l’héberge. Le but est d’exploiter cette vulnérabilité afin d’aller lire un fichier contenant la clé de validation du challenge. La dernière fois nous avons vu comment configurer correctement le qemu, maintenant on va passer aux choses sérieuses : audit du source, reverse et debugging du code.
Break your ARMs Part 1 -- by Ivanlef0u
Pendant le rutctf l’équipe Nibbles à prit super cher. Le challenge consistait à exploiter différents services tournant sous un émulateur Android depuis une VM Debian sous VirtualBox, la faute de se fiasco à l’émulateur qui crashait régulièrement sans raison apparente. Finalement lors du débriefing on a apprit qu’une team s’était amusé à poncer tout le monde avec un script qui se connectait sur l’émulateur et lui passait une commande le faisant crasher, cool …
Si vous ne le savez pas, Android tourne sous ARM, Baboon et moi avons justement passé pas mal de temps à reverser un binaire ARM, pour finalement pas grand chose …
Bref tout cela pour dire que comprendre correctement l’ARM ca peut être utile parfois. Justement cela m’a rappelé un autre challenge auquel l’équipe Nibbles avait participé, le CTF CSAW, cette fois la team s’est mieux débrouillé ! Dans ce CTF on retrouvait encore des binaires ARM à reverser et exploiter. C’est là le propos de ce post, montré comment il fallait configurer l’image du challenge en local puis exploiter un service vulnérable sur une architecture ARM.
