CERT Polska, czyli krajowy zespół ekspertów zatrudnionych do reagowania na incydenty, przeprowadził badanie dotyczące bezpieczeństwa stron internetowych placówek oświaty. Analizę wykonano między 19 czerwca a 15 sierpnia 2020 roku. W wykazie znajduje się 34920 podmiotów, z czego tak naprawdę 22396 posiadało podaną stronę internetową. Finalnie badaniu zostały poddane 20464 adresy internetowe, stanowiące 17911 unikalnych domen oraz 6602 unikalne adresy IP, na które te domeny wskazywały.
Część placówek nie posiada lub nie zgłosiła swojej strony internetowej, dodatkowo w momencie prowadzenia badania 1932 stron placówek nie było osiągalnych. Rozkład typów podmiotów oświatowych, których strony zostały poddane badaniu, przedstawiono na rysunku poniżej (72% z nich stanowiły placówki publiczne).
Raport ujawnia wykryte nieprawidłowości
Zbyt dużo otwartych portów
Skanowanie otwartych portów ujawniło dużą skalę nieprawidłowości w zabezpieczeniach. Otwartymi portami, na których najczęściej nasłuchiwały usługi, to:
- FTP (21) aż na 4795 hostach
- SSH (22) na 1892 hostach
- MSQL (3306) na 3927 hostach
- SMTP (587) na 4368 hostach i SMTP (25) na 4355 hostach
- IMAP (993 SSL) na 4329 hostach
- POSTGRESQL (5432) 3057
- Inne (wyszczególniono na stronie 6 raportu)
WordPress czy Joomla?
Najczęściej stosowanym silnikiem do zarządzania treści (CMS) były:
- WordPress (59,2%)
- Joomla (34,1%)
- Drupal (2%)
- WIX Website Builder (0,9%)
- Inne (3,4%)
Podatności dla stron opartych o Joomla
Na stronach napędzanych Joomla znaleziono 5157 podatności na 2873 stronach. Na 827 z nich znajdowała się przynajmniej jedna podatność o klasyfikacji wysokiej, które dotyczyły podatności typu SQL Injection, Directory Traversal, czy pozwalających na zdalne wykonanie kodu na serwerze (RCE). Występowanie takich podatności pozwala atakującemu na wykradanie danych z bazy (w tym danych logowania do panelu administracyjnego), przeglądania wewnętrznych plików witryny czy nawet przejęcia całkowitej kontroli nad serwerem.
Należy zauważyć, że prawie połowa stron (49,2%) korzystała z najnowszej dostępnej wersji 3.9, co świadczy o regularnie dokonywanych aktualizacjach. Jednak część ze sprawdzonych instancji posiadała bardzo starą wersję systemu, co może stanowić łatwy cel dla atakujących.
Bezpieczeństwo WordPressa zależy od aktualizacji
Do analizy użyto narzędzia „wpscan”. Niemal połowa z 6602 stron korzystała z CMS-a w najnowszej wersji, co świadczy o regularnych aktualizacjach. Spośród tych 6602 sprawdzonych stron, 1134 strony miały co najmniej jedną podatność oraz 264 podatności o klasyfikacji wysokiej. Zazwyczaj było to związane z wykorzystaniem starej wersji WordPressa. Krytyczne luki zostały zaklasyfikowane jako RCE, SQLI, XSS.
Dostęp do poufnych danych
W kilkudziesięciu przypadkach znaleziono katalogi, które posiadały włączony listing plików, tzw. open directory. W większości foldery te zawierały wewnętrzne pliki serwisu, lecz dostęp do nich nie powodował negatywnych konsekwencji dla placówki oświatowej (np. galeria zdjęć i tak wyświetlana na stronie głównej).
W pojedynczych przypadkach udało się jednak trafić na dane wrażliwe, jak kopie zapasowe czy logi, które powinny być niejawne. W 6 przypadkach znaleziono archiwa zawierające kopie całej strony wraz z plikami konfiguracyjnymi, a w 11 kopie bazy danych. Pliki te były dostępne do pobrania bez żadnych zabezpieczeń, a jedynym utrudnieniem było poznanie odpowiedniego adresu. Najczęściej były to pliki o oczywistym nazewnictwie jak backup.sql czy web.tar.gz.
Podatności CVE
Na 3137 hostach (47%) znaleziono przynajmniej jedną podatność. Łącznie hosty te posiadały 63311 podatności zawierających się w 1081 różnych CVE.
Bezpieczeństwo połączenia – certyfikaty TLS
W trakcie badania zespół CERT Polska sprawdził czy strony posiadają dobrze skonfigurowany, ważny certyfikat TLS oraz wymuszone przekierowanie z http na https. Na 17911 przebadanych domen aż 16835 zwróciło jakiś certyfikat. Niestety ogromna część z nich była źle skonfigurowana. Wynika to głównie z tego, że często w domyślnej konfiguracji pod portem 443 strona zwraca certyfikat hostingodawcy. Świadczy o tym fakt, że niezgodność badanej domeny i nazwy CN w certyfikacie miała miejsce aż w 8438 przypadkach. Bardzo często CN skonfigurowany był np. dla *.home.pl czy *.nazwa.pl. W 866 przypadkach zwracany certyfikat był wygasły.
Poprawność konfiguracji FTP
Podczas badania sprawdzono 4795 serwerów FTP dostępnych na serwerach hostujących strony placówek oświatowych. Z tego aż 999 pozwalało na dostęp anonimowy albo za pomocą kombinacji ftp:ftp.
Poprawność konfiguracji serwerów poczty
Z 13522 szkół i jednostek oświatowych, aż 12771, tj. 94% nie posiada poprawnie skonfigurowanych mechanizmów pozwalających na ochronę przed podszywaniem się pod adresy email w ich domenach.
Badanie poprawności konfiguracji serwerów poczty dotyczyło możliwości ewentualnego podszywania się przez atakujących pod adresy pocztowe w domenie szkół i jednostek oświatowych. Podstawowymi mechanizmami obrony przed podszywaniem się są: Sender Policy Framework (SPF), Domain Keys Identified Mail (DKIM) oraz Domain-based Message Authenti-cation (DMARC). Tutaj więcej o tych technologiach.
Aż 3593 domen z rekordem MX w ogóle nie posiada rekordu TXT z polityką SPF, co pozwala dowolnym serwerom podszywać się pod domenę nadawcy w wartości “MAIL FROM”. 233 domeny posiadają politykę SPF z kwalifikatorem neutralnym dla każdego ad-resu (“?all”), a 108 domen nie posiada w ogóle mechanizmu “all”, “redirect” ani “include”, co w obu przypadkach efektywnie oznacza brak polityki.
Natomiast z 9929 domen posiadających politykę SPF tylko 1297 posiada również politykę DMARC. Spośród nich, 546 nie posiada polityki “reject” lub “quarantine”, co sprawia, że jest ona nieefektywna. Brak efektywnej polityki DMARC oznacza, że z dużym prawdopodobieństwem można podszyć się pod nadawcę nawet, gdy poprawnie skonfigurowany jest rekord SPF (ponieważ ten sprawdza wartość “MAIL FROM”, a nie nagłówek “From” wyświetlany w klientach pocztowych).
Placówkom oświatowym zaleca się
- Regularnie aktualizować systemy zarządzania treścią, ich wtyczki oraz skórki. Jeśli strona nie jest oparta o tego typu system, aktualizować jej komponenty, jak np. biblioteki javascript.
- Sprawdzić konfigurację i aktualność wykorzystywanych usług, w szczególności serwerów pocztowych i DNS.
- Zadbać o poprawne wystawienie i ważność certyfikatów. Konfigurować automatyczne przekierowanie strony z protokołu http na https.
- Zwracać szczególną uwagę na pliki wystawione publicznie (przez serwer HTTP czy FTP), zwłaszcza na to, czy nie zawierają wrażliwych informacji, takich jak dane osobowe czy dane logowania.
- Uczulić wszystkie osoby, mające dostęp do wprowadzania zmian na stronie, na używanie silnych haseł.
- Zapewnić odpowiednią izolację usług od Internetu i nie pozwalać na dostęp z zewnątrz do usług, do których nie jest to niezbędne (np. baz danych).
- Zadbać o poprawną konfigurację mechanizmów chroniących przed podszywaniem się pod domenę przy wysyłce maili (SPF, DMARC, DKIM).
- Zadbać o poprawność i aktualność danych w rejestrze domen.
