Jeżeli prowadzisz swoją stronę internetową – i nie ma znaczenia, czy jest to prywatny blog, witryna firmowa, sklep, czy forum – i nie spotkałeś się jeszcze z procesem szyfrowania plików, teraz jest najlepszy moment, aby nadrobić stracone zaległości. Już nie tylko komputery schowane za NAT-em są celem cyberprzestępców i złośliwego oprogramowania, które przy pomocy asymetrycznego algorytmu RSA-2048 i symetrycznego AES potrafi w taki sposób zaszyfrować dane na dysku twardym, że proces faktoryzacji staje się niemożliwy do przeprowadzenia, w wyniku czego odzyskanie plików bez kopii zapasowej z góry spisane jest na porażkę.
Krypto-ransomware zaszyfruje pliki na serwerze WWW
Pierwsze wersje krypto-ransomware zaczęły pojawiać się w roku 2013, by systematycznie, boleśnie i skuteczne uderzać w nieświadomych zagrożeń internetowych użytkowników. Najczęstszym wektorem infekcji z udziałem wirusa z rodziny ransomware (teraz zwane krypto-ransomware) jest oczywiście e-mail w formie szkodliwego załącznika, a obecnie coraz popularniejsze złośliwe kampanie malvertising.
Teraz powody do zmartwień mają nie tylko użytkownicy domowi oraz administratorzy firm, ale właściwie każda osoba, która prowadzi swoją stronę internetową, no i przede wszystkim administratorzy większych portali, które hostowane są na serwerach dedykowanych i VPS-ach.
Przyczyna zaszyfrowania plików?
Luki. Dotyczy to słabo zabezpieczonych serwerów, autorskich skryptów, tych darmowych, jak i płatnych systemów do zarządzania treścią (CMS). Zasadniczo, im bardziej popularny CMS, tym będzie częściej atakowany (analogicznie jak systemy operacyjne). A można tutaj wymienić choćby kilka z nich: WordPress, Joomla, Magento, Typo3, Drupal.
Ransomware został napisany w języku C dla systemu Linux z użyciem biblioteki PolarSSL. Po dostaniu się na serwer i uruchomieniu z uprawnieniami administratora, trojan ładuje do pamięci listę swoich plików, które zawierają instrukcję odzyskania plików zdefiniowaną przez autora w:
- ./readme.crypto-file – nazwa pliku z żądaniami
- ./index.crypto-HTML – plik HTML z żądaniami
Jako argument, otrzymuje ścieżkę do pliku zawierającego klucz publiczny RSA, który potrzebny jest do odszyfrowania plików (wymagany jest jeszcze klucz prywatny, który znajduje się po stronie serwera cyberprzestępcy). Gdy wszystkie pliki na serwerze zostaną przeskanowanie, szkodliwy program uruchamia się jako demon i usuwa te oryginalne.
Ale najpierw szyfruje pliki w następujących katalogach:
- /home
- /root
- /var/lib/mysql
- /var/www
- /etc/nginx
- /etc/apache2
- /var/log
Następnie szyfruje wszystkie pliki w katalogach domowych, po czym wraca na początek do ścieżki „/” i szuka katalogów pod nazwami:
- public_html
- www
- webapp
- backup
- .git
- .svn
I szyfruje w nich pliki z rozszerzeniami:
".php", ".html", ".tar", ".gz", ".sql", ".js", ".css", ".txt" ".pdf", ".tgz", ".war", ".jar", ".java", ".class", ".ruby", ".rar" ".zip", ".db", ".7z", ".doc", ".pdf", ".xls", ".properties", ".xml" ".jpg", ".jpeg", ".png", ".gif", ".mov", ".avi", ".wmv", ".mp3" ".mp4", ".wma", ".aac", ".wav", ".pem", ".pub", ".docx", ".apk" ".exe", ".dll", ".tpl", ".psd", ".asp", ".phtml", ".aspx", ".csv"
Nie szyfruje katalogów:
- /
- /root/.ssh
- /usr/bin
- /bin
- /etc/ssh
Aby zaszyfrować każdy plik, trojan generuje klucz symetryczny za pomocą algorytmu AES wzmocniony dodatkowo CBC o długości klucza 128 bitów i zamienia rozszerzenia plików dołączając do nich .encrypted. Każdy katalog zawiera dodatkowo plik README_FOR_DECRYPT.txt z żądaniem okupu.
W momencie deszyfrowania plików (po zapłaceniu okupu) wirus używa klucza prywatnego RSA dostarczonego od cyberprzestępcy, dzięki któremu możliwe jest pozyskanie klucza AES z zaszyfrowanych plików.
Jak się chronić?
Nie ma jednej skutecznej metody, jednak ważniejsze z nich to:
1. O ile to możliwe, zaktualizować rdzeń CMS-a oraz moduły do najnowszej wersji.
2. Zaktualizować serwer HTTP.
3. Ukryć serwer za siecią CDN (content delivery network), np. CloudFlare.
4. Skorzystać z płatnych web-firewalli lub darmowych rozwiązań bazujących na mod_security.
5. Korzystać z najnowszych kerneli, najlepiej już z łatką grsecurity, która chroni przed zagrożeniami 0 Day.
6. Wyłączyć logowanie na roota via hasło, które powinno być zastąpione logowaniem z wykorzystaniem kluczy.
7 W przypadku konieczności użycia konta root zalogować się na konto o niższych uprawnieniach a później przełączyć się na roota.
8. Odpowiednio skonfigurować firewall iptables lub zainstalować alternatywę CSF.
9. Do ochrony przed atakami brute-force wykorzystać fail2ban.
10. Do FTP logować się jako użytkownik, nie root.
11. W przypadku stosowania hostingu współdzielonego stosować odrębne konta FTP do każdej strony, a w przypadku VPS’a / serwera dedykowanego FTP zastąpić STP.
