security through obscurity

Security through obscurity (także security by obscurity) to opieranie ochrony systemu na tym, że atakujący nie zna jego szczegółów: adresu panelu, nazw tabel, algorytmu albo zaszytego klucza. MITRE opisuje tę słabość jako CWE-656: siła mechanizmu ochrony zależy w dużej mierze od jego niejawności, więc poznanie algorytmu lub kluczowych danych wystarcza, by go pokonać ^[2]. Dokumentacja WordPressa nazywa security through obscurity strategią na ogół nietrafną jako podstawową, choć dopuszcza ją w kilku miejscach jako dodatek ^[1].

Jak działa

Ukrycie szczegółu podnosi koszt ataku tylko do chwili, gdy atakujący ten szczegół pozna. MITRE zwraca uwagę, że znajomość kodu lub projektu wystarcza do złamania takiej ochrony, a inżynieria wsteczna jest skuteczna i opłacalna dla zmotywowanego przeciwnika ^[2]. Słabość pojawia się wtedy, gdy niejawność jest główną obroną, a nie jedną z warstw ochrony ^[2].

OWASP ujmuje to podobnie: security through obscurity to słaba kontrola, która niemal zawsze zawodzi, gdy jest jedyną ^[3]. Bezpieczeństwo systemu nie powinno zależeć od ukrycia szczegółów wdrożenia, tylko od silnych haseł, warstwowej obrony, limitów transakcji, projektu sieci i kontroli audytowych ^[3]. Jako przykład OWASP podaje Linuksa, którego kod źródłowy jest publiczny, a który przy właściwym zabezpieczeniu pozostaje odporny i bezpieczny ^[3].

Różnicę między ukrywaniem a zabezpieczaniem dobrze widać na prefiksie tabel. Poradnik seohost.pl zalicza zmianę prefiksu do technik, które maskują elementy systemu, a nie łatają luk ^[5]. Atakujący, który ma pełne możliwości SQL injection, odczyta nazwy tabel zapytaniem SHOW TABLES ^[5].

Przykłady technik

Ostatni wiersz to klasyczny błąd z katalogu MITRE: przykłady CWE-656 obejmują klucze kryptograficzne i hasła zaszyte w plikach wykonywalnych oraz ukryte pola formularzy, o których twórcy zakładali, że nikt ich nie zmieni ^[2]. Zob. zaszyte w kodzie hasło.

W WordPressie

Dokumentacja WordPressa wskazuje dwa miejsca, w których ukrycie informacji może pomóc ^[1]. Pierwsze to nazwa konta administracyjnego: nie należy używać łatwych do odgadnięcia nazw takich jak admin czy webmaster, bo to na nie ataki kierowane są najpierw ^[1]. Drugie to prefiks tabel: wiele opublikowanych ataków SQL injection na WordPressa zakłada domyślny prefiks wp_ ^[1]. Warto pamiętać, że nazwę konta można też poznać przez enumerację użytkowników, więc jej ukrycie nie jest trwałe.

Podobnie jest z adresem logowania. Poradnik WordPressa o atakach siłowych (brute-force) mówi wprost, że ukrycie adresu logowania może zmniejszyć szum, ale nie powinno być jedyną obroną ^[4]. Jako właściwą ochronę ta sama strona wskazuje ograniczanie liczby prób logowania na brzegu sieci albo przez wtyczkę bezpieczeństwa oraz reguły WAF dla /wp-login.php i /xmlrpc.php ^[4].

Kolejność warstw przy logowaniu pokazuje schemat poniżej: niejawność stoi na początku i odsiewa część ruchu, ale o bezpieczeństwie decydują warstwy dalsze.

RYS. 1Warstwy ochrony logowania

Znaczenie

Security through obscurity nie jest bezwartościowe. Seohost.pl zauważa, że dla prostych, zautomatyzowanych botów niestandardowy prefiks stanowi realną przeszkodę, choć nie chroni przed celowym atakiem ^[5]. Podobnie zmiana adresu logowania ogranicza liczbę prób ataku siłowego widocznych w logach ^[4].

Problem zaczyna się, gdy ukrycie zastępuje właściwe zabezpieczenia. Właściciel strony, który przeniósł formularz logowania pod inny adres, może uznać, że uwierzytelnianie wieloskładnikowe jest zbędne. Strona z ukrytą wersją WordPressa nadal jest podatna, jeśli nie została zaktualizowana; ukrycie wersji utrudnia jedynie jej odczytanie, zob. ujawnianie wersji. Dokumentacja WordPressa przypomina, że starsze wersje nie otrzymują poprawek bezpieczeństwa, więc trzeba korzystać z najnowszej ^[1].

Niektóre techniki ukrywania mają też koszt. Poradnik WordPressa o atakach siłowych zauważa, że dawne zalecenia, takie jak rozbudowane przepisywanie adresów w .htaccess, blokowanie całych krajów po adresach IP czy hasło HTTP na cały katalog /wp-admin, są dziś zawodne, psują wtyczki korzystające z AJAX albo pogarszają wygodę użytkowników ^[4]. Zamiast nich dokumentacja wskazuje rate limiting i reguły na brzegu sieci ^[4]. Zob. też zabezpieczenie katalogu hasłem.

Dobre praktyki

• Traktować niejawność jako dodatek do utwardzania (hardening), nie jako jego zamiennik.
• Projektować zabezpieczenia tak, by działały także wtedy, gdy atakujący zna kod. MITRE zaleca sprawdzenie w przeglądzie projektu, czy ujawnienie implementacji osłabi ochronę ^[2].
• Korzystać z publicznie sprawdzonych algorytmów i procedur, bo przechodzą one szerszą analizę i testy ^[2].
• Nie przechowywać haseł i kluczy w kodzie wtyczki ani motywu.
• Nadawać kontom tylko potrzebne uprawnienia, zgodnie z zasadą najmniejszych uprawnień, by odgadnięty login dawał jak najmniej.

Historia i przykłady

Zasada, że bezpieczeństwo nie może zależeć od tajności kodu, pojawia się także w decyzjach państw. W lipcu 2016 roku Sekurak opisał bułgarskie przepisy, według których oprogramowanie tworzone na zamówienie administracji ma być udostępniane na licencji open source ^[6]. Jako jeden z plusów takiego rozwiązania redakcja wskazała walkę z security by obscurity ^[6].