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.

viernes, 7 de noviembre de 2014

Let's corrupt elves to make orcs to break some shit !



IOActive Labs Research: ELF Parsing Bugs by Example with Melkor Fuzzer
By Alejandro Hernandez @nitr0usmx

Extract from white paper at  http://www.ioactive.com/pdfs/IOActive_ELF_Parsing_with_Melkor.pdf

miércoles, 27 de agosto de 2014

(In)secure, funny and peculiar C code posted on Twitter

No, this is not a post about how secure or insecure is Twitter’s code itself. It’s about code posted on Twitter by ordinary people, coders, ninjas, aliens, etc.
As you might know, the directive #include is used to tell the C pre-processor to include certain portions of code, data structures, data type definitions, etc. within your C program. On the other hand, a hashtag is a word or an unspaced phrase prefixed with the sign # to group messages, tweets, posts, pictures, etc. referring to a specific topic. Therefore, in the cyberspace, specifically social networks, #include is not a directive, it’s just another hashtag.

Having said that, last night I had insomnia and I spent a while looking for #include on Twitter wondering if I would find some interesting C code. Well, in less than two seconds, my screen was full of tweets by people expressing the thrill they felt after writing their first “Hello World”s and other peculiarities in C programming language. You'll notice that most of them were written by Asian people, why? Have no idea.

Have phun:

Following some tweets with c0d3 that caught my attention:

Who said Buffer Overflow? ;-D
https://twitter.com/ryuujinzoku/status/503963506920923136



I can prove that I can allocate and free memory as fast as Chuck Norris pulls the trigger: 
https://twitter.com/hukushu_ramen/status/503915580483579906
 
The devil in on Twitter }:-) 
https://twitter.com/YVT/status/503474782789050368
 
ñ_ñ she likes strcpy():
https://twitter.com/madoka_rinu/status/473022963059421185

This is not code, but I'm pretty sure that that Warning: was because of the percent signs in the text, 10% and 5%, and evidently, sprintf() was expecting two vars for those "format strings":
https://twitter.com/iPhoneplaneta/status/378329901079621632


And some others who know about the weaknesses of those functions just have phun with them... Like the butt overflow by @jduck:


Or this sushi emoji overflow that will not compile ($stomach, confused with PHP, lame) by me:
https://twitter.com/nitr0usmx/status/488749060841414657


Irony:
https://twitter.com/madiemmie/status/460259495625515008
 

I delete the screensh0tz in my Desktop with C cuz I can:
https://twitter.com/Wp120_3238/status/503929231143759872


I want some of diz peculiar dinner that will never compile (? printf(" );?):
https://twitter.com/LunarChanyeol/status/504160998614241280


Accompanied with a big cold beer.h:
https://twitter.com/Chris_Gammell/status/65926440037785600

VX writers everywhere:
https://twitter.com/ObeyRana/status/490863552769830912

 One about girlfriends and $$$:


Such a smart guy !
https://twitter.com/optshiftk/status/480769923770118149



Some help needed:
https://twitter.com/ZhareefAimullah/status/407925173849833472



Someone was sleeping in class zZzzZzzZzZ:
https://twitter.com/jeymileyyy/status/502079076023017473


And the last one, a funny one in Spanish but basically it is a 
printf("They jerk me off .!.");


After this, I think it'd be a cool idea to create a Twitter bot to grab C code from #include (hashtag), pass it through Flawfinder (http://www.dwheeler.com/flawfinder/) and tweet the output back.


Happy c0ding + Social Nets ! B-)
@nitr0usmx

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