Preorder drugiego tomu książki sekuraka: Wprowadzenie do bezpieczeństwa IT. -15% z kodem: sekurak-book
Linuksowy ransomware, czyli jak nie należy szyfrować danych
Ciekawostką ostatnich dni było pojawienie się pierwszego złośliwego programu ransomware wymierzonego w administratorów Linuksowych serwerów. Niestety dla jego twórców, pomimo zastosowania algorytmu AES, program szyfruje dane w sposób łatwy do odzyskania.
O pojawieniu się Linux.Encoder.1 napomknęliśmy już kilka dni temu. Z opisu działania udostępnionego po raz pierwszy przez Dr.Web wynika, że ten nietypowy ransomware może dostawać się do systemu poprzez lukę w Zend Framework (z którego korzysta m.in. CMS Magento) i stara się szyfrować pliki w katalogach domowych użytkowników oraz wielu innych lokalizacjach, w tym związanych z serwerami webowymi:
- /var/lib/mysql
- /var/www
- /etc/nginx
- /etc/apache2
- /var/log
Złośliwy program ostatecznie przeczesuje cały system plików w poszukiwaniu katalogów o nazwach zaczynających się od:
- public_html
- www
- webapp
- backup
- .git
- .svn
Linux.Encoder.1 został napisany w C i każdy z zaatakowanych plików zostaje zaszyfrowany za pomocą 128-bitowego algorytmu symetrycznego AES w trybie CBC.
Unikalny dla każdego z plików klucz szyfrujący zostaje następnie zaszyfrowany algorytmem asymetrycznym (RSA). Ostatecznie żądanie okupu w postaci pliku README_FOR_DECRYPT.txt trafia do każdego z dotkniętych działaniem programu katalogów.
Chcąc więc odzyskać nasze pliki, niezbędny staje się „zakup” prywatnego klucza RSA, który to pozwala na odszyfrowanie kluczy symetrycznych AES. Jak się jednak okazało po przeanalizowaniu (reverse-engineering) sposobu działania samego programu, nie jest to konieczne.
Specjaliści z Bitdefender zauważyli bowiem, że klucze szyfrujące oraz wektory inicjujące algorytmu AES nie są losowe. Program korzysta bowiem z funkcji libc rand() z wartością seed (stan początkowy generatora pseudolosowego) ustawianą na podstawie znacznika czasu utworzenia poszczególnych plików…
To z kolei wystarczyło do opracowania i udostępnienia narzędzia pozwalającego na odszyfrowanie poszczególnych plików na podstawie czasów ich utworzenia.
Wygląda więc na to, że internetowy szantaż jest tak dobrym biznesem, że zaczynają się nim interesować coraz mniej profesjonalnie przygotowani komputerowi przestępcy. Biorąc pod uwagę dostępne gotowe otwarto-źródłowe przykłady implementacji, z pewnością zjawisko to będzie się tylko nasilać.
Powyższy przykład świetnie ilustruje również to, jak łatwo siła algorytmów szyfrujących może zostać zniweczona przez nieprzemyślaną implementację…
— Wojciech Smol
Tak, niech wszyscy o tym napiszą, a fixa do Zenda zgodnie z moim aktualnym stanem wiedzy nie ma, więc Gimbo zmieni rand() na /dev/urandom i pozamiata.
;)
Wystarczy mieć backup, chyba że to lokalny backup w katalogu „backup” :)…
Tak, niech piszą. Zaatakowani przynajmniej dowiedzą się, że istnieje narzędzie odszyfrowujące. Może chociaż część zacznie robić backupy.
Mam pytanie. Dlaczego nielosowy IV jest problemem? Przecież i tak musi być znany, żeby odszyfrować pierwszy blok.
IV rzeczywiście zazwyczaj nie jest tajny, powinien być jednak unikalny (losowy) w ramach tego samego klucza szyfrującego:
[…]poprzez lukę w Zend Framework (z której korzysta m.in. CMS Magento)[…]
To Magento pracuje na luce w Zendzie? ;o) To wiele wyjaśnia… ;-P
Jak widać z luki korzysta nie tylko Magento :).
Łe, już poprawiliście… Co wygrałem? ;o)
Wejściówkę na kolejną edycję tego ;)… http://bit.ly/1QyByRj
Fajnie, ale przy opcji 450 km w jedną stronę niestety nie skorzystam.