Chatsubo [(in)Security Dark] Labs

"... A consensual hallucination experienced daily by billions of legitimate operators, in every nation, by children being taught mathematical concepts... A graphic representation of data abstracted from banks of every computer in the human system. Unthinkable complexity. Lines of light ranged in the nonspace of the mind, clusters and constellations of data. Like city lights, receding into the distance... "
--
William Gibson.

jueves, 24 de julio de 2014

Glass Reflections in Pictures + OSINT = More Accurate Location

Finding the location of pictures by analyzing the reflection:


IOActive Labs Research: Glass Reflections in Pictures + OSINT = More Accurate Location:

By Alejandro Hernández - @nitr0usmx



jueves, 9 de enero de 2014

Benchmark of Linux applications loading time before and after "prelink"

The following is a quick benchmark I did in my recently downloaded Ubuntu Linux about the efficiency of the "prelink" utility.

What's prelink? ($man prelink):
"DESCRIPTION
    prelink  is  a  program  that modifies ELF shared libraries and ELF dynamically linked binaries in such a way that the time needed for the dynamic linker to perform relocations at startup significantly decreases.  Due to fewer relocations, the run-time memory consumption decreases as well (especially the  number of  unshareable pages).  The prelinking information is only used at startup time if none of the dependent libraries have changed since prelinking; otherwise programs are relocated normally.

    prelink first collects ELF binaries to be prelinked and all the ELF shared libraries they depend on. Then it assigns a unique virtual address space slot  to each  library  and  relinks  the  shared library to that base address.  When the dynamic linker attempts to load such a library, unless that virtual address space slot is already occupied, it maps the library into the given slot.  After this is done, prelink, with the help of dynamic linker, resolves all relocations  in  the  binary  or  library  against its dependent libraries and stores the relocations into the ELF object.  It also stores a list of all dependent libraries together with their checksums into the binary or library.  For binaries, it also computes a list of conflicts (relocations  that  resolve  differently  in  the  binary's  symbol search scope than in the smaller search scope in which the dependent library was resolved) and stores it into a special ELF section.

    At runtime, the dynamic linker first checks whether all dependent libraries were successfully mapped into their designated address space slots, and  whether they  have not changed since the prelinking was done.  If all checks are successful, the dynamic linker just replays the list of conflicts (which is usually significantly shorter than total number of relocations) instead of relocating each library."


I'll register the lunch time in three programs before and after the prelinking process has been achieved.
- Firefox 24.0               (8 shared libraries)
- Stellarium 0.12.1          (44 shared libraries)
- Wireshark 1.10.2           (78 shared libraries)
- LibreOffice Writer 4.1.2.3 (128 shared libraries)

########### RESULTS ###########
I'd like start presenting the results (later on are the details).
COLD START: Loading time by lauching the application in a terminal after reboot
WARM STAR: Loading time by lauching the application in a terminal after quitting application
It's pretty obvious that prelink helps the applications to load faster:
A picture is worth a thousand words:
 

########### SYSTEM INFO ###########
- Ubuntu Desktop 13.10
- Default install
- Running in a VMWare Virtual Machine
- 1 GB RAM
- 1 CPU 2.30 Ghz

nitr0us@exiled:~$ grep -i ghz /proc/cpuinfo
model name      : Intel(R) Core(TM) i3-2350M CPU @ 2.30GHz
nitr0us@exiled:~$ uname -a
Linux exiled 3.11.0-12-generic #19-Ubuntu SMP Wed Oct 9 16:20:46 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
nitr0us@exiled:~$ top | cat | egrep "Mem|Swap"
KiB Mem:   1010912 total,   728848 used,   282064 free,    46144 buffers
KiB Swap:   784380 total,        0 used,   784380 free,   288764 cached
nitr0us@exiled:~$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1        19G  3,5G   15G  20% /
none            4,0K     0  4,0K   0% /sys/fs/cgroup
udev            484M  4,0K  484M   1% /dev
tmpfs            99M  1,1M   98M   2% /run
none            5,0M     0  5,0M   0% /run/lock
none            494M   76K  494M   1% /run/shm
none            100M   32K  100M   1% /run/user


########### FIREFOX ###########
nitr0us@exiled:~$ file /usr/lib/firefox/firefox
/usr/lib/firefox/firefox: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, BuildID[sha1]=0xa944fe6e66bd599ab22358e014a3c6bcbb29518f, stripped
nitr0us@exiled:~$ ldd /usr/lib/firefox/firefox
        linux-vdso.so.1 =>  (0x00007fffbcf51000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007ffe67855000)
        libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007ffe67551000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007ffe6724c000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007ffe6702f000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ffe66c67000)
        /lib64/ld-linux-x86-64.so.2 (0x0000003000000000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007ffe66a50000)
nitr0us@exiled:~$ ldd /usr/lib/firefox/firefox | wc -l
8
nitr0us@exiled:~$ sudo cp /usr/lib/firefox/firefox /usr/lib/firefox/firefox.original
nitr0us@exiled:~$ ls -l /usr/lib/firefox/firefox
-rwxr-xr-x 1 root root 96464 sep 17 12:10 /usr/lib/firefox/firefox
nitr0us@exiled:~$ ls -lh /usr/lib/firefox/firefox
-rwxr-xr-x 1 root root 95K sep 17 12:10 /usr/lib/firefox/firefox
nitr0us@exiled:~$ md5sum /usr/lib/firefox/firefox
08dd67d50643bad5195b2ee550f64f39  /usr/lib/firefox/firefox
nitr0us@exiled:~$ readelf -WSl /usr/lib/firefox/firefox
There are 29 section headers, starting at offset 0x17190:

Section Headers:
  [Nr] Name              Type            Address          Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            0000000000000000 000000 000000 00      0   0  0
  [ 1] .interp           PROGBITS        0000000000000270 000270 00001c 00   A  0   0  1
  [ 2] .note.ABI-tag     NOTE            000000000000028c 00028c 000020 00   A  0   0  4
  [ 3] .note.gnu.build-id NOTE            00000000000002ac 0002ac 000024 00   A  0   0  4
  [ 4] .gnu.hash         GNU_HASH        00000000000002d0 0002d0 0002c4 00   A  5   0  8
  [ 5] .dynsym           DYNSYM          0000000000000598 000598 001008 18   A  6   3  8
  [ 6] .dynstr           STRTAB          00000000000015a0 0015a0 000f44 00   A  0   0  1
  [ 7] .gnu.version      VERSYM          00000000000024e4 0024e4 000156 02   A  5   0  2
  [ 8] .gnu.version_r    VERNEED         0000000000002640 002640 000120 00   A  6   6  8
  [ 9] .rela.dyn         RELA            0000000000002760 002760 000408 18   A  5   0  8
  [10] .rela.plt         RELA            0000000000002b68 002b68 0006d8 18   A  5  12  8
  [11] .init             PROGBITS        0000000000003240 003240 00001a 00  AX  0   0  4
  [12] .plt              PROGBITS        0000000000003260 003260 0004a0 10  AX  0   0 16
  [13] .text             PROGBITS        0000000000003700 003700 00de6f 00  AX  0   0 16
  [14] .fini             PROGBITS        0000000000011570 011570 000009 00  AX  0   0  4
  [15] .rodata           PROGBITS        0000000000011580 011580 0011d0 00   A  0   0 16
  [16] .eh_frame_hdr     PROGBITS        0000000000012750 012750 000a44 00   A  0   0  4
  [17] .eh_frame         PROGBITS        0000000000013198 013198 003324 00   A  0   0  8
  [18] .tbss             NOBITS          0000000000216970 016970 000010 00 WAT  0   0  8
  [19] .init_array       INIT_ARRAY      0000000000216970 016970 000008 00  WA  0   0  8
  [20] .fini_array       FINI_ARRAY      0000000000216978 016978 000008 00  WA  0   0  8
  [21] .jcr              PROGBITS        0000000000216980 016980 000008 00  WA  0   0  8
  [22] .data.rel.ro      PROGBITS        0000000000216990 016990 000198 00  WA  0   0 16
  [23] .dynamic          DYNAMIC         0000000000216b28 016b28 000240 10  WA  6   0  8
  [24] .got              PROGBITS        0000000000216d68 016d68 000298 08  WA  0   0  8
  [25] .data             PROGBITS        0000000000217000 017000 000078 00  WA  0   0 16
  [26] .bss              NOBITS          0000000000217080 017078 0003d8 00  WA  0   0 16
  [27] .gnu_debuglink    PROGBITS        0000000000000000 017078 00000c 00      0   0  1
  [28] .shstrtab         STRTAB          0000000000000000 017084 000108 00      0   0  1
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings), l (large)
  I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown)
  O (extra OS processing required) o (OS specific), p (processor specific)

Elf file type is DYN (Shared object file)
Entry point 0x37dc
There are 10 program headers, starting at offset 64

Program Headers:
  Type           Offset   VirtAddr           PhysAddr           FileSiz  MemSiz   Flg Align
  PHDR           0x000040 0x0000000000000040 0x0000000000000040 0x000230 0x000230 R E 0x8
  INTERP         0x000270 0x0000000000000270 0x0000000000000270 0x00001c 0x00001c R   0x1
      [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
  LOAD           0x000000 0x0000000000000000 0x0000000000000000 0x0164bc 0x0164bc R E 0x200000
  LOAD           0x016970 0x0000000000216970 0x0000000000216970 0x000708 0x000ae8 RW  0x200000
  DYNAMIC        0x016b28 0x0000000000216b28 0x0000000000216b28 0x000240 0x000240 RW  0x8
  NOTE           0x00028c 0x000000000000028c 0x000000000000028c 0x000044 0x000044 R   0x4
  TLS            0x016970 0x0000000000216970 0x0000000000216970 0x000000 0x000010 R   0x8
  GNU_EH_FRAME   0x012750 0x0000000000012750 0x0000000000012750 0x000a44 0x000a44 R   0x4
  GNU_STACK      0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RW  0x10
  GNU_RELRO      0x016970 0x0000000000216970 0x0000000000216970 0x000690 0x000690 R   0x1

 Section to Segment mapping:
  Segment Sections...
   00
   01     .interp
   02     .interp .note.ABI-tag .note.gnu.build-id .gnu.hash .dynsym .dynstr .gnu.version .gnu.version_r .rela.dyn .rela.plt .init .plt .text .fini .rodata .eh_frame_hdr .eh_frame
   03     .init_array .fini_array .jcr .data.rel.ro .dynamic .got .data .bss
   04     .dynamic
   05     .note.ABI-tag .note.gnu.build-id
   06     .tbss
   07     .eh_frame_hdr
   08
   09     .init_array .fini_array .jcr .data.rel.ro .dynamic .got
nitr0us@exiled:~$ sudo prelink -v /usr/lib/firefox/firefox
Laying out 1 libraries in virtual address space 0000003000000000-0000004000000000
Assigned virtual address space slots for libraries:
/lib64/ld-linux-x86-64.so.2                                  0000003000000000-0000003000224268
/lib/x86_64-linux-gnu/libc.so.6                              0000003000400000-00000030007c7438
/lib/x86_64-linux-gnu/libdl.so.2                             0000003000800000-0000003000a03128
/lib/x86_64-linux-gnu/libgcc_s.so.1                          0000003000c00000-0000003000e15420
/lib/x86_64-linux-gnu/libm.so.6                              0000003001000000-0000003001303148
/lib/x86_64-linux-gnu/libpthread.so.0                        0000003001400000-000000300161c448
/usr/lib/firefox/firefox                                     0000003001800000-0000003001a17458
/usr/lib/x86_64-linux-gnu/libstdc++.so.6                     0000003001c00000-0000003001f03420
Prelinking /usr/lib/firefox/firefox
nitr0us@exiled:~$ ldd /usr/lib/firefox/firefox
        linux-vdso.so.1 =>  (0x00007fff0631a000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x0000003000800000)
        libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x0000003001c00000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x0000003001000000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x0000003001400000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x0000003000400000)
        /lib64/ld-linux-x86-64.so.2 (0x0000003000000000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x0000003000c00000)
nitr0us@exiled:~$ ldd /usr/lib/firefox/firefox.original
        linux-vdso.so.1 =>  (0x00007fffbcf51000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007ffe67855000)
        libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007ffe67551000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007ffe6724c000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007ffe6702f000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ffe66c67000)
        /lib64/ld-linux-x86-64.so.2 (0x0000003000000000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007ffe66a50000)
nitr0us@exiled:~$ file /usr/lib/firefox/firefox
/usr/lib/firefox/firefox: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, BuildID[sha1]=0xa944fe6e66bd599ab22358e014a3c6bcbb29518f, stripped
nitr0us@exiled:~$ ls -l /usr/lib/firefox/firefox
-rwxr-xr-x 1 root root 99368 sep 17 12:10 /usr/lib/firefox/firefox
nitr0us@exiled:~$ ls -lh /usr/lib/firefox/firefox
-rwxr-xr-x 1 root root 98K sep 17 12:10 /usr/lib/firefox/firefox
nitr0us@exiled:~$ md5sum /usr/lib/firefox/firefox
59396941d528839966740301ddd46eff  /usr/lib/firefox/firefox
nitr0us@exiled:~$ readelf -WSl /usr/lib/firefox/firefox
There are 32 section headers, starting at offset 0x17c28:

Section Headers:
  [Nr] Name              Type            Address          Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            0000000000000000 000000 000000 00      0   0  0
  [ 1] .interp           PROGBITS        0000003001800270 000270 00001c 00   A  0   0  1
  [ 2] .note.ABI-tag     NOTE            000000300180028c 00028c 000020 00   A  0   0  4
  [ 3] .note.gnu.build-id NOTE            00000030018002ac 0002ac 000024 00   A  0   0  4
  [ 4] .gnu.hash         GNU_HASH        00000030018002d0 0002d0 0002c4 00   A  5   0  8
  [ 5] .dynsym           DYNSYM          0000003001800598 000598 001008 18   A  6   3  8
  [ 6] .dynstr           STRTAB          00000030018015a0 0015a0 000f44 00   A  0   0  1
  [ 7] .gnu.version      VERSYM          00000030018024e4 0024e4 000156 02   A  5   0  2
  [ 8] .gnu.version_r    VERNEED         0000003001802640 002640 000120 00   A  6   6  8
  [ 9] .rela.dyn         RELA            0000003001802760 002760 000408 18   A  5   0  8
  [10] .rela.plt         RELA            0000003001802b68 002b68 0006d8 18   A  5  12  8
  [11] .init             PROGBITS        0000003001803240 003240 00001a 00  AX  0   0  4
  [12] .plt              PROGBITS        0000003001803260 003260 0004a0 10  AX  0   0 16
  [13] .text             PROGBITS        0000003001803700 003700 00de6f 00  AX  0   0 16
  [14] .fini             PROGBITS        0000003001811570 011570 000009 00  AX  0   0  4
  [15] .rodata           PROGBITS        0000003001811580 011580 0011d0 00   A  0   0 16
  [16] .eh_frame_hdr     PROGBITS        0000003001812750 012750 000a44 00   A  0   0  4
  [17] .eh_frame         PROGBITS        0000003001813198 013198 003324 00   A  0   0  8
  [18] .tbss             NOBITS          0000003001a16970 0164c0 000010 00 WAT  0   0  8
  [19] .init_array       INIT_ARRAY      0000003001a16970 016970 000008 00  WA  0   0  8
  [20] .fini_array       FINI_ARRAY      0000003001a16978 016978 000008 00  WA  0   0  8
  [21] .jcr              PROGBITS        0000003001a16980 016980 000008 00  WA  0   0  8
  [22] .data.rel.ro      PROGBITS        0000003001a16990 016990 000198 00  WA  0   0 16
  [23] .dynamic          DYNAMIC         0000003001a16b28 016b28 000240 10  WA  6   0  8
  [24] .got              PROGBITS        0000003001a16d68 016d68 000298 08  WA  0   0  8
  [25] .data             PROGBITS        0000003001a17000 017000 000078 00  WA  0   0 16
  [26] .bss              NOBITS          0000003001a17080 017078 0003d8 00  WA  0   0 16
  [27] .gnu_debuglink    PROGBITS        0000000000000000 017078 00000c 00      0   0  1
  [28] .gnu.liblist      GNU_LIBLIST     0000000000000000 017084 00008c 14     29   0  4
  [29] .gnu.libstr       STRTAB          0000000000000000 017110 000069 00      0   0  1
  [30] .gnu.prelink_undo PROGBITS        0000000000000000 017180 000970 01      0   0  8
  [31] .shstrtab         STRTAB          0000000000000000 017af0 000133 00      0   0  1
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings), l (large)
  I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown)
  O (extra OS processing required) o (OS specific), p (processor specific)

Elf file type is DYN (Shared object file)
Entry point 0x30018037dc
There are 10 program headers, starting at offset 64

Program Headers:
  Type           Offset   VirtAddr           PhysAddr           FileSiz  MemSiz   Flg Align
  PHDR           0x000040 0x0000003001800040 0x0000003001800040 0x000230 0x000230 R E 0x8
  INTERP         0x000270 0x0000003001800270 0x0000003001800270 0x00001c 0x00001c R   0x1
      [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
  LOAD           0x000000 0x0000003001800000 0x0000003001800000 0x0164bc 0x0164bc R E 0x200000
  LOAD           0x016970 0x0000003001a16970 0x0000003001a16970 0x000708 0x000ae8 RW  0x200000
  DYNAMIC        0x016b28 0x0000003001a16b28 0x0000003001a16b28 0x000240 0x000240 RW  0x8
  NOTE           0x00028c 0x000000300180028c 0x000000300180028c 0x000044 0x000044 R   0x4
  TLS            0x016970 0x0000003001a16970 0x0000003001a16970 0x000000 0x000010 R   0x8
  GNU_EH_FRAME   0x012750 0x0000003001812750 0x0000003001812750 0x000a44 0x000a44 R   0x4
  GNU_STACK      0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RW  0x10
  GNU_RELRO      0x016970 0x0000003001a16970 0x0000003001a16970 0x000690 0x000690 R   0x1

 Section to Segment mapping:
  Segment Sections...
   00
   01     .interp
   02     .interp .note.ABI-tag .note.gnu.build-id .gnu.hash .dynsym .dynstr .gnu.version .gnu.version_r .rela.dyn .rela.plt .init .plt .text .fini .rodata .eh_frame_hdr .eh_frame
   03     .init_array .fini_array .jcr .data.rel.ro .dynamic .got .data .bss
   04     .dynamic
   05     .note.ABI-tag .note.gnu.build-id
   06     .tbss
   07     .eh_frame_hdr
   08
   09     .init_array .fini_array .jcr .data.rel.ro .dynamic .got

nitr0us@exiled:~$ objdump -s -j .gnu.liblist /usr/lib/firefox/firefox

/usr/lib/firefox/firefox:     file format elf64-x86-64

Contents of section .gnu.liblist:
 0000 01000000 662fcf52 1769ecfe 00000000  ....f/.R.i......
 0010 00000000 0c000000 662fcf52 49caf704  ........f/.RI...
 0020 00000000 00000000 1b000000 662fcf52  ............f/.R
 0030 6037efe0 00000000 00000000 25000000  `7..........%...
 0040 662fcf52 57c29a83 00000000 00000000  f/.RW...........
 0050 35000000 662fcf52 19b9f20d 00000000  5...f/.R........
 0060 00000000 3f000000 662fcf52 981508e1  ....?...f/.R....
 0070 00000000 00000000 5b000000 662fcf52  ........[...f/.R
 0080 dd8f2840 00000000 00000000           ..(@........
nitr0us@exiled:~$ objdump -s -j .gnu.libstr /usr/lib/firefox/firefox

/usr/lib/firefox/firefox:     file format elf64-x86-64

Contents of section .gnu.libstr:
 0000 006c6962 646c2e73 6f2e3200 6c696273  .libdl.so.2.libs
 0010 7464632b 2b2e736f 2e36006c 69626d2e  tdc++.so.6.libm.
 0020 736f2e36 006c6962 70746872 6561642e  so.6.libpthread.
 0030 736f2e30 006c6962 632e736f 2e36002f  so.0.libc.so.6./
 0040 6c696236 342f6c64 2d6c696e 75782d78  lib64/ld-linux-x
 0050 38362d36 342e736f 2e32006c 69626763  86-64.so.2.libgc
 0060 635f732e 736f2e31 00                 c_s.so.1.
nitr0us@exiled:~$ objdump -s -j .gnu.prelink_undo /usr/lib/firefox/firefox

/usr/lib/firefox/firefox:     file format elf64-x86-64

Contents of section .gnu.prelink_undo:
 0000 7f454c46 02010100 00000000 00000000  .ELF............
 0010 03003e00 01000000 dc370000 00000000  ..>......7......
 0020 40000000 00000000 90710100 00000000  @........q......
[cut]

-- RESULTS:
- Loading time by lauching the application in a terminal after reboot (cold start)

Before Prelink:
nitr0us@exiled:~$ time /usr/lib/firefox/firefox
real    0m11.651s
user    0m1.130s
sys    0m1.050s

After Prelink:
nitr0us@exiled:~$ time /usr/lib/firefox/firefox
real    0m9.514s
user    0m0.811s
sys    0m1.234s

- Loading time by lauching the application in a terminal after quitting application (warm start)
Before Prelink:
nitr0us@exiled:~$ time /usr/lib/firefox/firefox
real    0m3.209s
user    0m1.054s
sys    0m0.164s

After Prelink:
nitr0us@exiled:~$ time /usr/lib/firefox/firefox
real    0m2.893s
user    0m1.020s
sys    0m0.172s

########### STELLARIUM ###########
nitr0us@exiled:~$ file /usr/bin/stellarium
/usr/bin/stellarium: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, BuildID[sha1]=0x31b1aaa0544241cc5a73f00bf82bed0a9d69e021, stripped
nitr0us@exiled:~$ sudo cp /usr/bin/stellarium /usr/bin/stellarium.original
nitr0us@exiled:~$ ls -l /usr/bin/stellarium
-rwxr-xr-x 1 root root 8186032 jun 26  2013 /usr/bin/stellarium
nitr0us@exiled:~$ ls -lh /usr/bin/stellarium
-rwxr-xr-x 1 root root 7,9M jun 26  2013 /usr/bin/stellarium
nitr0us@exiled:~$ ldd /usr/bin/stellarium
        linux-vdso.so.1 =>  (0x00007fff6c9fe000)
        libQtOpenGL.so.4 => /usr/lib/x86_64-linux-gnu/libQtOpenGL.so.4 (0x00007fb6d67f5000)
        libQtScript.so.4 => /usr/lib/x86_64-linux-gnu/libQtScript.so.4 (0x00007fb6d634e000)
        libQtGui.so.4 => /usr/lib/x86_64-linux-gnu/libQtGui.so.4 (0x00007fb6d569b000)
        libQtNetwork.so.4 => /usr/lib/x86_64-linux-gnu/libQtNetwork.so.4 (0x00007fb6d5353000)
        libQtCore.so.4 => /usr/lib/x86_64-linux-gnu/libQtCore.so.4 (0x00007fb6d4e72000)
        libGL.so.1 => /usr/lib/x86_64-linux-gnu/mesa/libGL.so.1 (0x00007fb6d4c13000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x0000003000400000)
        libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fb6d49fa000)
        libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x0000003001c00000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x0000003001000000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x0000003000c00000)
        libfreetype.so.6 => /usr/lib/x86_64-linux-gnu/libfreetype.so.6 (0x00007fb6d4756000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x0000003000800000)
        libXrender.so.1 => /usr/lib/x86_64-linux-gnu/libXrender.so.1 (0x00007fb6d454c000)
        libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x00007fb6d4216000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x0000003001400000)
        libfontconfig.so.1 => /usr/lib/x86_64-linux-gnu/libfontconfig.so.1 (0x00007fb6d3fda000)
        libaudio.so.2 => /usr/lib/x86_64-linux-gnu/libaudio.so.2 (0x00007fb6d3dc1000)
        libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0 (0x00007fb6d3ac0000)
        libpng12.so.0 => /lib/x86_64-linux-gnu/libpng12.so.0 (0x00007fb6d389a000)
        libgobject-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 (0x00007fb6d3648000)
        libSM.so.6 => /usr/lib/x86_64-linux-gnu/libSM.so.6 (0x00007fb6d3440000)
        libICE.so.6 => /usr/lib/x86_64-linux-gnu/libICE.so.6 (0x00007fb6d3224000)
        libXi.so.6 => /usr/lib/x86_64-linux-gnu/libXi.so.6 (0x00007fb6d3013000)
        libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 (0x00007fb6d2e01000)
        librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fb6d2bf8000)
        /lib64/ld-linux-x86-64.so.2 (0x0000003000000000)
        libglapi.so.0 => /usr/lib/x86_64-linux-gnu/libglapi.so.0 (0x00007fb6d29d2000)
        libXdamage.so.1 => /usr/lib/x86_64-linux-gnu/libXdamage.so.1 (0x00007fb6d27cf000)
        libXfixes.so.3 => /usr/lib/x86_64-linux-gnu/libXfixes.so.3 (0x00007fb6d25c8000)
        libX11-xcb.so.1 => /usr/lib/x86_64-linux-gnu/libX11-xcb.so.1 (0x00007fb6d23c6000)
        libxcb-glx.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-glx.so.0 (0x00007fb6d21af000)
        libxcb-dri2.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-dri2.so.0 (0x00007fb6d1fa9000)
        libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007fb6d1d8b000)
        libXxf86vm.so.1 => /usr/lib/x86_64-linux-gnu/libXxf86vm.so.1 (0x00007fb6d1b85000)
        libdrm.so.2 => /usr/lib/x86_64-linux-gnu/libdrm.so.2 (0x00007fb6d1978000)
        libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 (0x00007fb6d174e000)
        libXt.so.6 => /usr/lib/x86_64-linux-gnu/libXt.so.6 (0x00007fb6d14e7000)
        libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007fb6d12e3000)
        libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007fb6d10a4000)
        libffi.so.6 => /usr/lib/x86_64-linux-gnu/libffi.so.6 (0x00007fb6d0e9b000)
        libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x00007fb6d0c96000)
        libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007fb6d0a8f000)
nitr0us@exiled:~$ ldd /usr/bin/stellarium | wc -l
44
nitr0us@exiled:~$ sudo prelink -v /usr/bin/stellarium
Laying out 36 libraries in virtual address space 0000003000000000-0000004000000000
Assigned virtual address space slots for libraries:
/lib64/ld-linux-x86-64.so.2                                  0000003000000000-0000003000224268
/usr/lib/x86_64-linux-gnu/libQtGui.so.4                      0000003002000000-0000003002cb1328
[cut]
Prelinking /usr/lib/x86_64-linux-gnu/mesa/libGL.so.1.2.0
Prelinking /usr/lib/x86_64-linux-gnu/libQtOpenGL.so.4.8.4
Prelinking /usr/lib/x86_64-linux-gnu/libQtScript.so.4.8.4
Prelinking /usr/lib/x86_64-linux-gnu/libQtNetwork.so.4.8.4
Prelinking /usr/bin/stellarium
nitr0us@exiled:~$ ls -l /usr/bin/stellarium
-rwxr-xr-x 1 root root 8572864 jun 26  2013 /usr/bin/stellarium
nitr0us@exiled:~$ ls -lh /usr/bin/stellarium
-rwxr-xr-x 1 root root 8,2M jun 26  2013 /usr/bin/stellarium

-- RESULTS:
- Loading time by lauching the application in a terminal after reboot (cold start)

Before Prelink:
nitr0us@exiled:~$ time /usr/bin/stellarium
real    0m8.189s
user    0m1.899s
sys    0m0.790s

After Prelink:
nitr0us@exiled:~$ time /usr/bin/stellarium
real    0m4.847s
user    0m1.469s
sys    0m0.800s

- Loading time by lauching the application in a terminal after quitting application (warm start)
Before Prelink:
nitr0us@exiled:~$ time /usr/bin/stellarium
real    0m2.390s
user    0m1.579s
sys    0m0.157s

After Prelink:
nitr0us@exiled:~$ time /usr/bin/stellarium
real    0m2.207s
user    0m1.363s
sys    0m0.198s
########### WIRESHARK ###########
nitr0us@exiled:~$ file /usr/bin/wireshark
/usr/bin/wireshark: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, BuildID[sha1]=0x722fa5bb6e37b458abd7c162d262a802cebb32c3, stripped
nitr0us@exiled:~$ ldd /usr/bin/wireshark | wc -l
78
nitr0us@exiled:~$ ls -l /usr/bin/wireshark
-rwxr-xr-x 1 root root 2366840 sep 11 17:47 /usr/bin/wireshark
nitr0us@exiled:~$ ls -lh /usr/bin/wireshark
-rwxr-xr-x 1 root root 2,3M sep 11 17:47 /usr/bin/wireshark
nitr0us@exiled:~$ sudo prelink /usr/bin/wireshark
nitr0us@exiled:~$ ls -l /usr/bin/wireshark
-rwxr-xr-x 1 root root 2372144 sep 11 17:47 /usr/bin/wireshark
nitr0us@exiled:~$ ls -lh /usr/bin/wireshark
-rwxr-xr-x 1 root root 2,3M sep 11 17:47 /usr/bin/wireshark


-- RESULTS:
- Loading time by lauching the application in a terminal after reboot (cold start)
Before Prelink:
nitr0us@exiled:~$ time /usr/bin/wireshark
real    0m8.759s
user    0m0.809s
sys    0m1.273s

After Prelink:
nitr0us@exiled:~$ time /usr/bin/wireshark
real    0m6.814s
user    0m0.850s
sys    0m0.627s

- Loading time by lauching the application in a terminal after quitting application (warm start)
Before Prelink:
nitr0us@exiled:~$ time /usr/bin/wireshark
real    0m2.697s
user    0m0.949s
sys    0m0.118s

After Prelink:
nitr0us@exiled:~$ time /usr/bin/wireshark
real    0m2.596s
user    0m1.038s
sys    0m0.131s


########### LIBREOFFICE (WRITER) ###########
nitr0us@exiled:~$ file /usr/lib/libreoffice/program/soffice.bin
/usr/lib/libreoffice/program/soffice.bin: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, BuildID[sha1]=0x9a2b11672d8b09ee8f9620dda7c96793c575dec7, stripped
nitr0us@exiled:~$ ldd /usr/lib/libreoffice/program/soffice.bin | wc -l
128
nitr0us@exiled:~$ ls -l /usr/lib/libreoffice/program/soffice.bin
-rwxr-xr-x 1 root root 6240 oct  3 10:29 /usr/lib/libreoffice/program/soffice.bin
nitr0us@exiled:~$ ls -lh /usr/lib/libreoffice/program/soffice.bin
-rwxr-xr-x 1 root root 6,1K oct  3 10:29 /usr/lib/libreoffice/program/soffice.bin
nitr0us@exiled:~$ sudo prelink /usr/lib/libreoffice/program/soffice.bin
[sudo] password for nitr0us:
nitr0us@exiled:~$ ls -l /usr/lib/libreoffice/program/soffice.bin
-rwxr-xr-x 1 root root 48680 oct  3 10:29 /usr/lib/libreoffice/program/soffice.bin
nitr0us@exiled:~$ ls -lh /usr/lib/libreoffice/program/soffice.bin
-rwxr-xr-x 1 root root 48K oct  3 10:29 /usr/lib/libreoffice/program/soffice.bin

-- RESULTS:
- Loading time by lauching the application in a terminal after reboot (cold start)

Before Prelink:
nitr0us@exiled:~$ time /usr/lib/libreoffice/program/soffice.bin --writer
real    0m18.543s
user    0m1.294s
sys    0m0.831s

After Prelink:
nitr0us@exiled:~$ time /usr/lib/libreoffice/program/soffice.bin --writer
real    0m7.295s
user    0m1.148s
sys    0m0.489s

- Loading time by lauching the application in a terminal after quitting application (warm start)
Before Prelink:
nitr0us@exiled:~$ time /usr/lib/libreoffice/program/soffice.bin --writer
real    0m4.845s
user    0m1.160s
sys    0m0.253s

After Prelink:
nitr0us@exiled:~$ time /usr/lib/libreoffice/program/soffice.bin --writer
real    0m4.196s
user    0m1.168s
sys    0m0.203s

I hope this benchmark helps you to improve your Linux performance.
Thanks

miércoles, 4 de diciembre de 2013

IOActive Labs Research: A Short Tale About executable_stack in elf_read_implies_exec() in the Linux Kernel

by Alejandro Hernández @nitr0usmx
This is a short and basic analysis I did when I was uncertain about code execution in the data memory segment. Later on, I describe what’s happening in the kernel side as well as what seems to be a small logic bug.... 

READ THE WHOLE PAPER HERE:
IOActive Labs Research: A Short Tale About executable_stack in elf_read_implies_exec() in the Linux Kernel

...
Anyway, perhaps that’s the normal behavior of the Linux kernel for some compatibility issues or something else, but isn’t it weird that making the stack executable or deleting the PT_GNU_STACK header all the memory segments are loaded with execution permissions even when the PF_EXEC flag is not set?
What do you think?

miércoles, 16 de octubre de 2013

"Binary Diffing" visual en Linux con Radare2

Binary Diffing o simplemente Bindiffing es una técnica utilizada para la visualización de código (mayormente en ensamblador) y así detectar patrones de conducta, así como también diferentes rutas de ejecución después de una modificación a un programa original, como una actualización o un parche de seguridad. Esta técnica es actualmente utilizada por muchos reverse engineers para identificar muchísimas cosas, malware, parches de seguridad mal implementados, backdoors, cambios en actualizaciones en software, cracking, y muchas cosas más.

"UNA IMAGEN DICEN MÁS QUE MIL PALABRAS"

Y bien, este blog post es básicamente una demostración básica del análisis visual para identificar diferencias entre binarios ELF en Linux utilizando Radare2. Esta es una gran herramienta para ingeniería inversa, e incluye un gran set de otras herramientas como un debugger, editor hexadecimal, etc.

Para las pruebas hice el siguiente código en C, el cual consta de simples comparaciones (if-else), un ciclo for, incremento de variables y un par de funciones de libc:
#include <stdio.h>
#include <stdlib.h>

int main(int argc, char **argv)
{
    if(strtol(argv[1], NULL, 16) == 0x41414141)
        printf("FOO\n");
    else if(strtol(argv[1], NULL, 16) == 0x42424242)
        printf("BAR\n");
    else {
        int i = 0xdead;

        for(int k = 0; k < i; k++)
            k++;

        printf("0x%x\n", i);
    }

    exit(0);
}
Compilamos con $gcc if.c -o if


Una vez descargado Radare2, es posible ver el listado convencional de código ensamblador de nuestro binario recién creado con $radare2 ./if y pdf @ sys.main dentro de Radare2:


Ahora, crearemos una copia de nuestro ejecutable con $cp if if2. Posteriormente editaremos una simple instrucción en esamblador para de allí detectar el cambio de forma visual  viendo el flujo del programa. Para este paso utilizaremos el editor HTE, en el cual una vez cargado ($ht ./if2), le damos View - ELF image, buscamos el código referente a la primer comparación contra el valor 0x41414141, y editamos cualquier jmp hacia cualquier otra etiqueta. Este es solo un ejemplo demostrativo e hice que saltara al printf("0x%x\n", i); del final, en la línea 16 del código en C, guardé el archivo y salí a la shell:


En la ejecución, lo único que cambia es lo que está en rojo, cuando se le pasa el parámtro 0x41414141. A diferencia del if normal, este imprime 0x00 ya que saltamos directo al printf() y el for anterior no se ejecutó, por lo tanto la variable que se imprime sigue siendo cero.


Ahora la parte interesante. El bindiffing más básico es ejecutar $radiff2 if if2, dando el offset y la diferencia de bytes, en este caso fue el offset de un simple jmp, así que solo cambió un byte:

Con el parámetro -C se analizan las funciones y se listan para ver si son iguales o no (notar el UNMATCH de la primer línea, correspondiente a la función main() ):


Finalmente, la opción más interesante, -g <función o dirección de memoria> para enviar la salida a formato xdot y poder visualizar las diferencias a través de un gráfico:


Con los comandos xdot ejecutados anteriormente se abrirán dos ventanas mostrando las diferencias:


A partir de aquí, lo interesante es la interpretación gráfica de los bloques de ensamblador. Este es un ejemplo bastante sencillo con pocos bloques de código y es muy fácil de identificar ciertos patrones visuales, por ejemplo:

  • Los bloques marcados en amarillo son los que cambiaron, es la diferencia binaria como tal (bindiff) ya que cambió la dirección a la que el jmp saltará.
  • A lo lejos, en la imagen de arriba, es posible ver que el path de ejecución de enmedio (el de la flecha azul vertical) en la imagen de la izquierda, simplemente se pasó a ser el path de ejecución de la derecha en la imagen de la derecha. Ese es el trozo de código que imprime "BAR". No se modificó en nada.
  •  Lo siguientes es un ciclo for. En el primer bloque de hasta arriba, el de la etiqueta loc.00400605 corresponde a la inicialización de una variable con el valor 0xdead y una variable con 0 (cero, que es el contador del for). De allí entra al bloque del for como tal, en donde se hace la comparación (instrucción cmp) para ver si continuar dentro del for o salir saltando al bloque de código que imprime el valor de la variable incrementada (flecha roja). En caso de seguir con el ciclo for, salta al pequeño bloque con dos instrucciones iguales las cuales suman 1 a la misma variable en la pila. Esta variable en nuestro código en C es k y se incrementa dos veces, en for(..;..; k++) k++;

  • La siguiente captura es la diferencia binaria, el cambio de ejecución. Nótese detenidamente  que en el primer código, del bloque amarillo se salta directamente al código de salida, con la función exit(), mientras que en el código modificado, después del código en amarillo se salta al código que imprime el valor de la variable incrementada después del ciclo for (como no se ejecutó el for, la variable tendrá un valor de cero y por eso nuestro programa en la shell imprime FOO 0x00) y posteriormente al bloque de salida (exit())
  • Por último, en la primer ejecución hay tres formas de llegar al bloque de exit() (el bloque donde dice call dword imp.exit):

mientras que en la segunda solo hay dos paths de ejecución para llegar allí:


Como es posible ver, el bindiffing es una técnica bastante útil para de forma visual identificar ciertos patrones de cambio entre dos binarios.

Espero les haya gustado este pequeño post y ojalá le encuentren provecho.

Happy Bindiffing B-) !

Alejandro.
@nitr0usmx

martes, 10 de septiembre de 2013

twitCheck.py - Identificador de amigos inactivos en Twitter por @EternalTodo

El día de ayer estuve jugando un poco con twitCheck.py que hizo un researcher que conocí apenas en el pasado Hack Cup en Las Vegas, José Miguel Esparza (@EternalTodo). En su blogpost explica la actualización de twitCheck.py a la nueva API 1.1 de Twitter y bueno, la herramienta se me hizo bastante util y fácil de configurar. 

twitCheck.py básicamente sirve para identificar a cuentas inactivas que sigues en Twitter, y después de la 1era ejecución, compara su base de datos para determinar si ganaste o perdiste followers.



Para hecharlo a andar solo se requiere:
1.- Obtener las cuatro credenciales (CONSUMER_KEY, CONSUMER_SECRET, ACCESS_TOKEN, ACCESS_TOKEN_SECRET) que requiere la nueva API 1.1 de Twitter desde https://dev.twitter.com/apps/
2.- $ git clone https://github.com/abraham/twitteroauth.git 
3.- Autenticar dichas credenciales con Twitter utilizando el script en PHP en http://www.webdevdoor.com/php/authenticating-twitter-feed-timeline-oauth/. Guardar el script get-tweets1.1.php en $HOME. Luego de agregar el username de twitter y las cuatro credenciales obtenidas, ejecutar el script. La salida deben ser los últimos tweets de la cuenta:


4.- $sudo pip install tweepy
5.- $wget http://eternal-todo.com/files/scripts/twitCheck.py
6.- Editar twitCheck.py y agregar las cuatro credenciales obtenidas.
7.- Ejecutar ./twitCheck.py twitter_username

Directa o indirectamente esta herramienta podría servir para OSINT (Open Source INTelligence).
Se la recomiendo ;-).

Happy OSINT ! ;-)

martes, 16 de abril de 2013

IOActive Labs Research: Can GDB's List Source Code Be Used for Evil Purpos...

IOActive Labs Research: Can GDB's List Source Code Be Used for Evil Purpos...: By Alejandro Hernández @nitr0usmx One day while debugging an ELF executable with the GNU Debugger (GDB), I asked myself, "How...

miércoles, 27 de marzo de 2013

DotDotPwn - The Directory Traversal Fuzzer: New Contributions to DotDotPwn !

DotDotPwn - The Directory Traversal Fuzzer: New Contributions to DotDotPwn !: We're happy to announce these two great contributions to DotDotPwn - The Traversal Directory Fuzzer. The 1st one was from...

sábado, 16 de marzo de 2013

ssl_hostname_resolver.pl : CN (Common Name) grabber on X.509 Certificates over HTTPS

I had this simple idea in my previous pentest where, for some reason, I couldn't resolve some IP addresses to their corresponding hostnames, but their CN fields (SSL certs on HTTPS) had resolvable hostnames. So, I did this simple script !

For some security scanners, such as Nessus and Nikto2, it's considered a security vulnerability:
"Standard certificate validation procedures require the subject CN field of a certificate to match the actual name of the entity presenting the certificate. For example, in a certificate presented by https://www.example.com/, the CN should be www.example.com."

Source:  X.509 Certificate Subject CN Does Not Match the Entity Name
http://www.rapid7.com/vulndb/lookup/certificate-common-name-mismatch


You can download it directly at:
http://packetstormsecurity.com/files/120634/Common-Name-Grabber-Script.html

Or...

#!/usr/bin/perl
# 
# ssl_hostname_resolver.pl
# CN (Common Name) grabber on X.509 Certificates over HTTPS
#
# Copyright (c) 2013 by Alejandro Hernandez, IOActive, Inc.
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 3 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
#
# I had this simple idea in my previous pentest where, for 
# some reason, I couldn't resolve some IP addresses to their 
# corresponding hostnames, but their CN fields (SSL certs 
# on HTTPS) had resolvable hostnames. So, I did this simple script !
#
# ----------------------------------------------------------------- 
#
# For some security scanners, such as Nessus and Nikto2,
# it's considered a security vulnerability:
#
# "Standard certificate validation procedures require the subject 
# CN field of a certificate to match the actual name of the entity 
# presenting the certificate. For example, in a certificate presented 
# by https://www.example.com/, the CN should be www.example.com."
# Source:  X.509 Certificate Subject CN Does Not Match the Entity Name
# http://www.rapid7.com/vulndb/lookup/certificate-common-name-mismatch
#
#
# Alejandro Hernandez < alejandro.hernandez [at] ioactive.co.uk >
# http://twitter.com/nitr0usmx
#
# IOActive Labs Research
# http://blog.ioactive.com
# 

use Net::CIDR::Lite;
use NetAddr::IP;
use Net::SSL;

$connection_timeout = 3; # seconds
$SIG{ALRM} = sub { }; # Do nothing when the connection timeout is reached instead of die

print <
-=[ ssl_hostname_resolver.pl
-=[ by \@nitr0usmx
-=[
-=[ CN (Common Name) grabber on X.509 Certificates over HTTPS

HDR

sub usage
{
print <-=[ Usage: $0  [port to connect (443 default)]
-=[ E.g. CIDR block : $0 192.168.1.0/24
-=[      IP Range   : $0 192.168.1.1-192.168.13.37
-=[      Single IP  : $0 192.168.1.254

USG
}

my $targets = shift or (usage and die "No targets given!\n");
my $port    = shift || 443;

my $cidr_lite = Net::CIDR::Lite->new($targets);
@cidr_list = $cidr_lite->list;

print "-=[ Connecting every host on port: $port\n\n";

print "-------------------------------------------------\n";
print "      IP        =>   CN (Common Name)\n";
print "-------------------------------------------------\n";

for my $cidr( @cidr_list ){
  my $n = NetAddr::IP->new($cidr);

  for my $ip( @{ $n->splitref( $n->bits() ) } ){
    printf("%-15s =>   %s\n", $ip->addr, getCNFromX509($ip->addr));
  }
}

sub getCNFromX509
{
  my $ip = shift;

  eval{
    alarm($connection_timeout); # No. of seconds of connection timeout

    $ssl = Net::SSL->new(
          PeerAddr => $ip,
          PeerPort => $port,
          Timeout => 5 # Never reached, alarm() will be triggered before
          );
  };

  alarm(0);

  if($@){ # some error occurred 
    return "(Couldn't connect to port $port)";
  }

  $ssl->get_peer_certificate->subject_name =~ /CN=(.*)/g;

  return $1;
}

 
ch33rs !!!
 

miércoles, 19 de diciembre de 2012

IOActive Labs Research: Striking Back GDB and IDA debuggers through malfor...

IOActive Labs Research: Striking Back GDB and IDA debuggers through malformed ELF executables

By Alejandro Hernández @nitr0usmx 

Day by day the endless fight between the bad guys and good guys mostly depends on how fast a countermeasure or anti-reversing protection can be broken. These anti-reversing mechanisms can be used by attackers in a number of ways: to create malware, to be used in precompiled zero-day exploits in the black market, to hinder forensic analysis, and so on. But they can also be used by software companies or developers that want to protect the internal logic of their software products (copyright).

The other day I was thinking: why run and hide (implementing anti-reversing techniques such as the aforementioned) instead of standing up straight and give the debugger a punch in the face (crashing the debugging application). In the next paragraphs I’ll explain briefly how I could implement this anti-reversing technique on ELF binaries using a counterattack approach.
...

lunes, 8 de octubre de 2012

My experience @ Ekoparty 2012

After a 10 hours delayed flight, finally I landed to Buenos Aires. As soon as I could, I went straight to the VIP party to meet with the IOActive team and to prepare some Mexican tacos and quesadillas with Diego Bauche @dexosexo

 




When the door opened, I saw my friend @XavaDu who started to take some pictures and drink some tequila from the gun-shaped bottle I brought from México XD. 


 After a while, I prepared him a special taco, with Argentinian Asado, Guacamole and Mexican spicy sauce:



Meanwhile, César Cerrudo (@cesarcer) was killing some drunk h4x0rs... 


Also, our boss, Jennifer Steffens (@SecureSun) couldn'd avoid a gun-shot of tequila B-)


After feeding some hungry people, we started to drink just a little bit more (;-D) and even played ping-pong.

The next day, Thursday, I had the chance to be at the Stephan Chanette's talk (@StephanChenette), which was a really interesting presentation about automated malware generation and future expectations. His presentation had a good structure because he started with the current state of malware generation/defense and later he explained the future of malware generation/defense passing through the actual malware trends. 
The same day, I enjoyed the Esteban Fayo's talk (@estemf) because he showed a live demo on how to crack an Oracle password taking advantage of some flaws in the Oracle authentication protocol.


The venue, KONEX, the same as the last year, was really cool, there were vendors booths, old computers, video games (where I spent like two hours playing Super Mario Bros) as well as a cocktail bar, obviously the IOActive booth ;).


In conclusion, I really had a great time with my mexican friends and my fellow workers, drinking red wine and argentine asado, besides amazing conferences.

 Mexicans rocking @ Ekoparty [ ]
Definitely, I hope to be there next year !
Cheers !

viernes, 1 de junio de 2012

Dubstep Warz 2006 - Breezeblock - BBC Radio 1 (REVIEW)

After a couple of weeks in UK, I've been looking (and still looking) for Drum n' Bass and Dubstep parties, 'cause this is the place where it all began... What I've got? FREAKING AWESOME PARTY at FabricLondon ! just take a look:

DJ Hype:


Biome:


That nite, I met a couple of Londoners very close to the local Dubstep scene. After dancing and listening crushing tunes, we were talking about the early times of the dubstep scene, the most influencing producers, etc. and suddenly, it came to the talk one of the landmarks of the genre. They suggested me to listen to:

DUBSTEP WARZ 2006 - BBC RADIO 1 - BREEZEBLOCK
(Hosted by Mary Ann Hobbs)


(Mary Ann Hobbs,  even though I consider myself a dubstep phan, I had never heard of her until the last month that my friend hkm shared me a dubstep mix by Kode9 also hosted by Mary Ann H.)

I'm listening "the warz" and throwing these lines at the same time, and after doing some research about that show, I found a couple of URLs that I'll mention bellow:

http://www.dubstep-mixes.co.uk/deep-dubstep-mixes-dj-sets/breezeblock-skream-mala-distance-loefah/ :
"Landmark Show for Dubstep hosted by Mary Ann Hobbs. Sounds of the future feat. Distance, Mala of Digital Mystikz, Skream, Kode 9 & Space Ape, Vex’d, Loefah, and Hatcha. This show is an essential for anyone who hasn't heard it!"

http://warfacelx.wordpress.com/2010/01/15/bbc-radio-1-dubstep-warz-2006/ :
"Esse especial, que foi ao ar na madrugada do dia 09/01/06 na BBC Radio 1, reuniu os principais expoentes do gênero. Comandado por Mary Anne Hobbs, o programa trouxe sons de Burial, Skream, Benga, Kode 9, Digital Mystikz, entre outros."

Yeah, it was what it was, it is what it is, that nite was a special nite for the DUBSTEP scene ! and sincerely, I was entirely shocked after listening the 2-hours set !..

The INTRO is amazing, from UK, US, Brazil and Canada, dubstep warriors broadcasting dubstep to the masses !

Some of the quotes I heard and really liked:
-- "They're getting the virus, they're being attached to something new and in '06 .."
 
-- "it's a hard job being a soldier, breaking dubstep to the masses..."

-- "This is the breezeblock dubstep warz special. Tonight you're gonna feel the energy of the most exciting underground scene in the UK. Emerging out the south of London and now... every corner of the planet, from Brighton to Baltimore, from Bristol to Brazil... From 7 of the scene's most gifted players... We've the god fathers ... Hatcha, and Kode9... And we have next generation producers that you'll see blazing on the underground this year, we've got Skream on the place, we've got Loefah, Distance is here...It's January of 2006 and if you're looking for music that's gonna change your life, it's here, it's live, on the Breezeblock tonite..."

-- "his name is Mala... u ready to do this Mala?.." "the sound has space in it... It's not the same frequency as like house music, it's not the same freq as in DnB.. It's its own frequency"

-- "With more of the sonic fire-storms we love so much... this is Vex'd ..."


And obviously, I wouldn't be cool to write too much of the warz without sharing it ! ;-)....
MP3


Skream was a KID !!! he was 19 !, and nowadays, pffff, world famous dubstep producer... He played its famous "Rutten" in the min 26:54 (only for connoisseurs: you will realize that it's not as good as the modern Rutten (remixed by himself) ;-D)

Kode9 & SpaceApe , playing the famous "Space Ape" in the min 47:14 (only for connoisseurs: the same, it's not as good as the version with Burial ;-D)

Loefah, definitely I enjoyed his 13:40 minutes set, and if you only want to listen to this part only:


Distance, playing his classic hard-styled dubstep, "Traffic" at 1:50:05 :


If you really enjoy dubstep music, it's a MUST ! (Personally I liked >80% of the tracks). If you're looking for *NOISY* dubstep, this is not the right place dudeee ;-).

List of Dubstep Warriors (lineup):
Mala (Digital Mystikz)
Skream
 Kode 9 & Space Ape 
Vex'd
Hatcha & Crazy D
Loefah feat Sgt. Pokes
Distance
DJ Pinch
 
Cheers !!! B-)

- nitrØus