I’m happy to announce that my moonlight project is finally released. Thanks to Alexander Peslyak (a.k.a. Solar Designer) it is available through Openwall.

Linux Kernel Runtime Guard (LKRG) is a loadable kernel module that performs runtime integrity checking of the Linux kernel and detection of security vulnerability exploits against the kernel. As controversial as this concept is, LKRG attempts to post-detect and hopefully promptly respond to unauthorized modifications to the running Linux kernel (integrity checking) or to credentials (such as user IDs) of the running processes (exploit detection). For process credentials, LKRG attempts to detect the exploit and take action before the kernel would grant the process access (such as open a file) based on the unauthorized credentials. You can download the current experimental version of LKRG at its brand new homepage:

http://www.openwall.com/lkrg/

LKRG has been in (re-)development for a couple of years, and builds upon one of my prior’s experience with a related project in 2011 (for CERN).

Official announcement had been made by Openwall and it can be read here:
http://www.openwall.com/lists/announce/2018/01/29/1

A lot of useful technical information about LKRG can be found on Openwall wiki page:
http://openwall.info/wiki/p_lkrg/Main

If you would like to support LKRG, you are very welcome to do so 😉 It can be done via Patreon website here:
https://www.patreon.com/p_lkrg

Best regards,
Adam ‘pi3’ Zabrocki

18

Apr

by pi3

During Microsoft Patch Tuesday on April (2017) some of the Hyper-V vulnerabilities (found be me) were fixed:

Remote Code Execution – CVE-2017-0181 (details)
Denial of Service – CVE-2017-0182 (details)
Denial of Service – CVE-2017-0186 (details)

23

Sep

by pi3

Linux kernel programming is always a challenge. Especially, when you are playing with very low-level functionality (like manually sending IPI between the CPUs/cores). Unfortunately, this specific functionality kept making troubles for me for a couple of weeks and I haven’t found ANY information on the internet regarding the issue which I hit/met. That’s why I decided it could be useful for other people if I describe my journey with the APIs like smp_call_function_single() / on_each_cpu(), NMI watchdog which can kill correct task and do not inform about problematic CPU/core etc. I’ve been discussing this issue with Alexander (Solar Designer) and he has started a discussion about that on Linux Kernel Mailing List (LKML) which you can find here:

http://lkml.iu.edu/hypermail/linux/kernel/1609.2/03265.html

Thanks,
Adam

Hi,

The journey into CVE-2014-9322 is not straightforward but it is worth to spend some time on it and analyze all available information. I will try my best…

Read more

2

Feb

by pi3

It’s long time I haven’t been posting here. Just quick update, excluding private conferences where I gave a few talks (which I can’t mention), last time I was a speaker on some known conferences:

Security B-Sides in Warsaw 2014 (as anonymous speaker). I was talking about attacks on modern x86/x64 architecture (like TLB-splitting, virtualization, AMT, etc.). Conference has warm and homely atmosphere which helps to integrate every attendee. This is rare opportunity in modern industrial IT sec world…
Secure 2014. Each year conference is more and more well-known and famous. CERT Poland (organizer) strives to keep high value of his baby and every year invites most skilled speakers. This year (2014) I had a chance to gave an official talk on behalf of the Microsoft: “The exploitation arm race between attackers and defenders”. I’ve received massive positive feedback which is for me the largest acknowledgements of my work. Conference is very professional and prepared down to the last detail.

From the most modern news:

– I have found a bug in nginx (on Win32 platform) and official patch can be found here:
http://hg.nginx.org/nginx/rev/78271500b8de
http://forum.nginx.org/read.php?29,256289

– One of my friend started interesting project – hack.it. The aim is to show as realistic as possible documentary / reality about IT security industry. Nowadays IT security is a “hot” topic (more than ever) which doesn’t help to promote proper transmission. It’s is not first time when someone is trying that, unfortunately not many projects was successful on this field. I wish him the best and I hope to receive the highest quality of the documentary which can be done, because I know he can do it 😉

Btw. I hope I’ll have more time to be more active here… 🙂
Btw2. Ponieważ obiecałem znajomemu, że napiszę jakiś post z dedykacją dla niego, dedykuję ten wpis dla Mateusza “shm” Kocielskiego 🙂

Best regards,
Adam

Introduction.

I was heavily playing with Stack Smashing Protector a few years ago. Some of my research (observation) I decided to publish on phrack magazine but not everything. Two years ago my professional life moved to the Windows environment and unfortunately I didn’t have time to play with UNIX world as much as before. One weekend I decided to reanalyze SSP code again and this write-up is describing a few of my observations I’ve made during the work…

… which can be shortly summarized as:

 

Not security related…

  1. We can change program’s name (from SSP perspective) via overwriting memory region where pointer to “argv[0]” points to.
  2. We can crash Stack Smashing Protector code in many ways:
    1. Via corrupting memory region pointed by “__environ” variable.
    2. Via setting “LIBC_FATAL_STDERR_” to the edge of valid addresses.
    3. Via forcing “alloca()” to fail – e.g. stack exhaustion.
    4. There is one more bug which I’m analyzing more comprehensively at point 4. It may indirectly force SSP to crash. It exists in DWARF stack (state) machine which is responsible for gathering information about the stack trace (“__backtrace()”) and prints it.
  3. We can slightly control SSP’s execution flow. (Un)Fortunately it doesn’t have any influence for the main execution (what about security?). Following scenarios are possible:
    1. Force SSP to open “/dev/tty”
    2. Force SSP not to open “/dev/tty” and assign to the “fd” descriptor “STDERR_FILENO” value:

    #define STDERR_FILENO 2 /* Standard error output. */

    1. Crash SSP via 2b. scenario
  1. We can crash indirectly SSP via unwinding algorithm (read-AV or we can be killed by “gcc_unreachable” or “gcc_assert” function) – DWARF stack (state) machine:
    1. Simulate FDE object was not found
    2. Simulate FDE object was found.

Somehow security related…

  1. We can force SSP to allocate a lot of memory and cause Denial of Service via Resource Exhaustion attack.
  2. Theoretical Information leak:
    1. Stack cookie information leak.
    2. Any kind of information leak
    3. File corruption.

Full write-up is available here 🙂
 
 
Best regards,
Adam ‘pi3’ Zabrocki

C++ supports developers in object-orientated programming and removes from the developer the responsibility of dealing with many object-oriented programming (OOP) paradigm problems. But these problems do not magically disappear. Rather it is the compiler that aims to provide a solution to many of the complexities that arise from C++ objects, virtual methods, inheritance etc. At its best the solution is almost transparent for the developers. But beware of assuming or relying on ‘under-the-hood’ behavior. This is what I want to share in this post – some aspects of how compilers deal with C++ objects, virtual methods, inheritance, etc. At the end I want to describe a real-world problem that I analyzed recently, which I called a “pointer casting vulnerability”.

The full write-up you can find on the Microsoft SRD blog here

Best regards,

Adam

I had a pleasure to give a talk at the Confidence 2013 conference. This year conference was in Krakow (28-29th of May). The first CONFidence conference was organized in 2005 and from the beginning became one of the biggest security event in the Europe. Each year many speakers from all around the world attend to the conference. As you can realize schedule of the conference usually keeps high technical standards.

This year I was talking about Crashdumps. Crashdumps are often underestimated source of very interesting information. It is a common belief that they are used only for application/system bugs/vulnerabilities analysis. In this presentation I would like to show a little bit different approach for this source of information. Microsoft Windows allows to change default configuration for WER/CER protocol in such a way, that all generated crashdumps will be stored in a custom storage. This is very useful in a large corporate networks, where we can find tens, hundreds or even thousands of machines, because more than a hundred crashdumps may be generated per day. In most of the cases administrators are afraid of a critical information leak (XBI, PII) via crashdumps, but could they gain some useful knowledge about the network status via this source? I was trying to show what kind of benefits could be gained if we start analyzing crashdumps independently and in a little bit different perspective…

 

Official topic of my talk was: “Crashdumps: hunt 0days and rootkit”. Now you are able to see it online:
http://www.youtube.com/watch?v=VdHiUK3q_3A

In fact it wasn’t my first talk on this conference. In 2007 I gave a talk about shellcodes on MIPS architecture 😉

 

Some of you may realize that conferences are not only about the presentations! In fact for me the most valuable is possibility to meet old friends and get new one 😉 Especially from the IT sec world… This year I was able to meet my old team from Hispasec 😉 Polish Hispasec division had 4 employees:

– Gynvael Coldwind

– Mateusz ‘j00ru’ Jurczyk

– Marcin ‘icewall’ Noga

– … and me – Adam ‘pi3’ Zabrocki 😉

Because each of us continues their career in own way, it’s very difficult (and rare) to meet together again. CONFidence gave us opportunity for that and this resulted on the following photo (click to enlarge):

 

From the left: j00ru, pi3, Gynvael Coldwind, Icewall…

There is space for next photos 😉

 

Best regards,

Adam

 

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