During the last Patch Tuesday (13th of October 2020), Microsoft fixed a very interesting (and sexy) vulnerability: CVE-2020-16898 – Windows TCP/IP Remote Code Execution Vulnerability (link). Microsoft’s description of the vulnerability:

“A remote code execution vulnerability exists when the Windows TCP/IP stack improperly handles ICMPv6 Router Advertisement packets. An attacker who successfully exploited this vulnerability could gain the ability to execute code on the target server or client.
To exploit this vulnerability, an attacker would have to send specially crafted ICMPv6 Router Advertisement packets to a remote Windows computer.
The update addresses the vulnerability by correcting how the Windows TCP/IP stack handles ICMPv6 Router Advertisement packets.”

This vulnerability is so important that I’ve decided to write a Proof-of-Concept for it. During my work there weren’t any public exploits for it. I’ve spent a significant amount of time analyzing all the necessary caveats needed for triggering the bug. Even now, available information doesn’t provide sufficient details for triggering the bug. That’s why I’ve decided to summarize my experience. First, short summary:

  • This bug can ONLY be exploited when source address is link-local IPv6. This requirement is limiting the potential targets!
  • The entire payload must be a valid IPv6 packet. If you screw-up headers too much, your packet will be rejected before triggering the bug
  • During the process of validating the size of the packet, all defined “length” in Optional headers must match the packet size
  • This vulnerability allows to smuggle an extra “header”. This header is not validated and includes “Length” field. After triggering the bug, this field will be inspected against the packet size anyway.
  • Windows NDIS API, which can trigger the bug, has a very annoying optimization (from the exploitation perspective). To be able to bypass it, you need to use fragmentation! Otherwise, you can trigger the bug, but it won’t result in memory corruption!
Read more



by pi3


We’ve just announced a new version of LKRG 0.8!  It includes enormous amount of changes – in fact, so much that we’re not trying to document all of the changes this time (although they can be seen from the git commits), but rather focus on high-level aspects. I encourage to read full announcement here:

Btw. Among others, we have added support for Raspberry Pi 3 & 4, better scalability, performance, and tradeoffs, the notion of profiles, new documentation, @Phoronix benchmarks, and more

Best regards,



by pi3


We’ve just announced a new version of LKRG 0.7! As I’ve promised, now we have ARM support (AArch64). Additionally, LKRG can now be run under GRSecurity kernels. This release includes a lot of changes and I encourage to read full announcement here:

Best regards,



by pi3

This time I would like to announce sort of a stable release of Linux Kernel Runtime Guard (0.3).

The full announcement can be found here:

Additionally, I was giving a talk on Confidence 2018 security conference about LKRG’s internals (LKRG under the hood). We’ve just released the slides online here:
Additionally, Confidence talks were recorded and you can find a video from my lecture here:




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:,256289

– One of my friend started interesting project – 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,


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,


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:

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,





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,


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 ( pracowałem przy projektach zabezpieczania i rozwijania technologii GRID (np. WLCG, EGEE) oraz projektów takich jak LHC i zajmowałem się 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) 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óż 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 (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ę 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 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 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 miałby ten sam skutek!

Inny scenariusz, który mógłby zaistnieć, to stworzenie dokładnej kopi 1: 1 serwisu 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, Jakie? Przyjrzyjcie się odnośnikowi “Kontakt”, “Audyty & Pentesty” oraz “Reklama”. Najpierw “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, 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”:


Mając kontrole nad tym formularzem, atakujący miałby możliwość wykradzenia wszystkich potencjalnych klientów serwisowi 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 De facto takie samo zagrożenie istnieje dla zakładki “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”:


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 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 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 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 Dodatkowo na samym początku tytuł wpisu na serwisie ( poruszający zaistniały atak brzmiał następująco:

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

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 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 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.”



Adam ‘pi3’ Zabrocki