Co Alladyn2 zarzuca rządowym informatykom

Zapytaliśmy Alladyna2 o listę napotkanych w trakcie ataku podatności, które najbardziej go zaskoczyły. Jest to:

   * Trzymanie haseł do serwerów i aplikacji w formie jawnej  (txt) na pulpicie lub dyskach sieciowych

   * Używanie konta admina domeny do monitorowania stacji roboczych (dzięki temu miało się udać podnieść uprawnienia w sieci KPRM)

   *Brak reakcji systemów bezpiezeństwa (AV/IPS/SIEM-u) na przeprowadzane przez kilka dni ataki słownikowe

   Rekomendacje po atakach w 2013:
 
1. Monitorować:
   a. próby logowania się na OWA na konta z wysokimi uprawnieniami,
   b. próby logowania się na wysokie konta na stacjach roboczych,
   c. próby wyłączenia procesu AV lub jego odinstalowanie na serwerach i stacjach roboczych,
   d. dodanie/usunięcie/zatrzymanie usługi na kluczowych serwerach,
   e. próby wyłączenia FW lub dodania nowej reguły na serwerach.
 
 2. Wdrożyć HIPS-y na kluczowych serwerach (np. monitorowanie nowych plików wykonywalnych w %TEMP%).

   3. Wdrożyć czujki sieciowe wykrywające skanowanie portów i próby logowania się na share/ftp/ssh/web (honeypot).

   4. Usunąć z grupy „local admins” grupę „domain admins”. Nigdy nie używać wysokich kont w domenie do logowania się na stacje robocze.

   5. Ograniczyć/wyłączyć możliwości uruchomienia skryptów powershell dla kont zwykłych użytkowników (tylko nt_service może).

   6. Wyłączyć możliwość wykonywania niepodpisanych plików z folderów %TEMP%.

   7. Wyłączyć możliwość dodania plików do startup lub reg_run dla kont zwykłych użytkowników.

   8. Konta serwisowe logują się tylko na stacjach na których mają się logować (ograniczyć to w AD).

   9. Wdrożyć skaner monitorujący minimum 2 razy dziennie porty na kluczowych serwerach.

   10. Odinstalować Javę

   Oczywiście rekomendacje z poprzedniego roku dalej aktualne:  ( atak na CUW)

   1. Wszelkie zdalne dostępy powinny składać się z podwójnego uwierzytelnienia (hasło + token/sms/certyfikat).

  2. Wykrywanie błędnych prób logowania nie per konto, tylko globalnie (np. ilość błędnych logowań na rożne konta z różnych IP w zadanym przedziale czasu tworzy alert).

   3. Brak uprawnień admina lokalnego dla wszystkich użytkowników (nawet adminów). I nie mówcie, że się nie da, bo się da, tylko trzeba chcieć coś takiego poprawnie skonfigurować.

   4. Zablokowane konta lokalnych adminów na każdej stacji, w środowisku domenowym są one nie potrzebne. W razie problemów z siecią, można się zalogować w trybie awaryjnym na te zablokowane konto lokalnie, a przy działającej sieci są konta domenowe helpdesku.

   5. Wykrywanie wyłączonych/odinstalowanych AV jako poważny incydent oraz poważne traktowanie logów z AV (nie na zasadzie przeglądania ich raz na pół roku).

   6. Admini domeny pracujący na kontach zwykłego usera w domenie. Do prac administracyjnych posiadają oddzielne konto na wysokich prawach, które do zalogowania się wymaga podwójnego uwierzytelnienia.

   7. Korzystanie z menadżerów haseł. Niedopuszczalne jest zapisywanie haseł w formie jawnej (w plikach na dysku, w poczcie email, itp.)

   8. Separacja za pomocą FW sieci IT i serwerowych od zwykłych użytkowników. Bo czy „Pani Hania” z księgowości potrzebuje się logować przez RDP na kontroler domeny?

   9. Dla kont serwisowych i administracyjnych hasło powinno być nie słownikowe i zawierać minimum 15 znaków (co automatycznie likwiduje hash LM, zresztą przechowywanie LM’ów powinno być wyłączone globalnie).

   10. Zalogowane sesje na serwerach powinny być automatycznie wylogowywane (nie blokowane) po 10 minutach bezczynności, a użytkownicy nie powinni zostawiać włączonych komputerów po godzinach pracy.

Lotem błyskawicy obiegła Polskę informacja o włamaniach do Kancelarii Prezydenta, Kancelarii Premiera, Ministerstwa Obrony Narodowej czy Ministerstwa Spraw Zagranicznych. Człowiek, który to zrobił, nie korzystał z bardzo skomplikowanych narzędzi, wykorzystał jedynie niedopatrzenia i niedostatki, jakich pełno w firmach, nie tylko w Polsce.
Admini, zróbcie rachunek sumienia:

   * Kto trzyma hasła na pulpicie w pliku tekstowym?
   * Kto nie wyłączył przechowywania LM i nie zablokował lokalnego administratora na stacjach roboczych?
   * U kogo administrator domeny jest administratorem stacji roboczej? Kto nie przeznaczył do tego celu osobnych kont helpdeskowych?
   * Kto nie włączył blokowania konta po kilku nieudanych logowaniach?
   * Kto pracuje codziennie cały czas na uprawnieniach administratora domeny?
   * Kto nie ustawił ograniczeń na wykonywanie skryptów PowerShell?
   * Kto nie ograniczył logowania kont usługowych oraz tych o wysokich przywilejach?
   * Kto nie wprowadził separacji podsieci stacji roboczych od serwerów za pomocą dobrze ustawionego firewalla?
   * Kto nadal nie posiada oprogramowanie HIPS na wszystkich serwerach Windows?
   * Kto nie poblokował praw wykonania niepodpisanych binarek i nie monitoruje %TEMP% (Windows), a partycje /tmp i /home nadal nie są montowane z opcją nosuid, noexec, nodev (Linux)?
   * Kto nie kontroluje logowań użytkowników o wysokich uprawnieniach do narzędzi webowych (OWA, Sharepoint)?
   * Kto nadal nie może lub nie chce wdrożyć dwuskładnikowego uwierzytelnienia np. za pomocą kart chipowych lub tokenów?
   * Kto nie pilnuje logowania do usług takich jak FTP?
   * Kto nie monitoruje nieudanych logowań per organizacja?

A właśnie powyższe podatności systemu IT jako całości zostały wykorzystane do ataku. Jestem przekonany, że w większości polskich firm, w tym także tych analitycznych, wręcz ociekających wiedzą, podobny test penetracyjny zakończyłby się porównywalnym sukcesem.

Jak zachęcić kogoś do otwarcia załącznika? Przejąć konto jednego z pracowników, poszukać w „wysłanych” odpowiedniej wiadomości, przekazać dalej podmieniwszy załącznik. Dodać przy tym komentarz. Nie zdarzyło się jeszcze, by ktoś miał wątpliwości, bo przecież z tą osobą wymieniał maile „jeszcze wczoraj”, wiadomość jest w tej samej sprawie i tak dalej.

Socjotechnika jest jedynie pomocą, zresztą ona prawie zawsze działa. To tylko kwestia „odrobienia lekcji” przez włamywacza. Luka w Excelu, Javie, Flashu czy Readerze jest tylko jednym z narzędzi, czasami niezwykle skutecznych.

Niestety taka jest smutna prawda...
Dlaczego informatyzacja w Polsce jest na tak niskim poziomie?
- informatykami kierują osoby, które nie mają zielonego pojęcia o standardach IT