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

10 listopada 2015, 23:17 | Aktualności | komentarzy 10

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
Linux.Encoder.1 żąda okupu...

Linux.Encoder.1 żąda okupu… (źródło: drweb.com)

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

Spodobał Ci się wpis? Podziel się nim ze znajomymi:



Komentarze

  1. józek

    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.

    ;)

    Odpowiedz
    • Wystarczy mieć backup, chyba że to lokalny backup w katalogu „backup” :)…

      Odpowiedz
    • yzq

      Tak, niech piszą. Zaatakowani przynajmniej dowiedzą się, że istnieje narzędzie odszyfrowujące. Może chociaż część zacznie robić backupy.

      Odpowiedz
  2. darek

    Mam pytanie. Dlaczego nielosowy IV jest problemem? Przecież i tak musi być znany, żeby odszyfrować pierwszy blok.

    Odpowiedz
    • IV rzeczywiście zazwyczaj nie jest tajny, powinien być jednak unikalny (losowy) w ramach tego samego klucza szyfrującego:

      An initialization vector has different security requirements than a key, so the IV usually does not need to be secret. However, in most cases, it is important that an initialization vector is never reused under the same key. For CBC and CFB, reusing an IV leaks some information about the first block of plaintext, and about any common prefix shared by the two messages.

      Odpowiedz
  3. […]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

    Odpowiedz

Odpowiedz