Czym jest atak LFI (local file inclusion)?
Spis treści
Spis treści
Błędy w aplikacjach internetowych mogą doprowadzić do poważnych konsekwencji dla ich użytkowników, łącznie z pobraniem plików umożliwiających np. przejęcie kontroli nad urządzeniem lub samą aplikacją. Atakiem, który wykorzystuje tego rodzaju błędy jest LFI (local file inclusion). Co warto wiedzieć o tej luce i jak się przed nią bronić? Wystarczy stosować kilka zasad bezpieczeństwa przy projektowaniu API.
Przygotowanie aplikacji to nie tylko warstwa techniczna i użytkowa. Bardzo istotna jest również warstwa zabezpieczająca przed cyberatakami, które mogą prowadzić m.in. do odczytu plików konfiguracyjnych czy logów. Z tym m.in. wiąże się LFI.
Co to jest local file inclusion LFI?
Local file inclusion jest luką w aplikacjach internetowych, umożliwiającą załadowanie załadowanie pliku umieszczonego na serwerze. W praktyce osoba atakująca może odczytać lub uruchomić poufne pliki z serwera takie jak np. formularze, ciasteczka albo parametry URL. Część plików może zawierać np. dane użytkowników (hasła, loginy, preferencje etc.).
Czym może grozić LFI?
Konsekwencją LFI jest zapoznanie się z wrażliwymi danymi lub (w skrajnych przypadkach) przejęcie kontroli nad aplikacją. W takim przypadku aplikacja może zdalnie wykonywać kod wskazany przez atakującego. Atak LFI uruchamia też złośliwe skrypty i szkodliwe oprogramowanie, zaimplementowane wcześniej na serwerze. Local file inclusion może być wstępem do wykorzystania aplikacji do przejmowania kontroli nad urządzeniami, które zainstalowały wcześniej określone oprogramowanie.
LFI to atak, który wykorzystywany jest często do celów przestępczych (nieuprawniony dostęp, zmiana danych użytkowników, przejęcie kontroli nad kontem zakupowym). Może mieć długofalowe skutki i wiązać się z utratą danych bezpieczeństwa.
W jaki sposób działa local file inclusion?
Schemat ataku local file inclusion jest podobny w każdym przypadku. W przypadku, gdy aplikacja tworzy ścieżkę do pliku na podstawie wskazanych danych należących do użytkownika, atakujący stara się wykorzystać sekwencję znaków (../; ../../../../; kodowanie URL typu %2e%2e%2f), aby opuścić katalog, który miał być obsługiwany przez aplikację.
W takim przypadku aplikacja przechodzi do katalogu nadrzędnego i odczytywania plików (które nie powinny być do wglądu z poziomu aplikacji, a wyłącznie z poziomu zabezpieczonej aplikacji FTP). Groźne dla aplikacji są m.in. pliki konfiguracyjne, logi, klucze, bazy danych ale też niektóre fragmenty kodu.
Jakie elementy mogą paść „ofiarą” LFI?
LFI to wszechstronny atak, który może dotknąć różnego rodzaju elementy aplikacji internetowej.
- Kod źródłowy – dostęp do kodu źródłowego pozwala na zlokalizowanie kolejnych luk.
- Pliki systemowe aplikacji – daje atakującemu uprawnienia do konfiguracji serwera i innych plików.
- Dane sesyjne ale też bieżące (tymczasowe) – umożliwia atakującemu dostęp np. do haseł tymczasowych czy lokalizacji użytkowników aplikacji.
- Logi aplikacji – dostęp do ścieżek, błędów, adresów IP etc.
- Konfiguracja systemu aplikacji – dostęp do baz danych, kluczy API, ustawień etc.
Tak szerokie uprawnienia sprawiają, ze autor ataku LFI ma tak naprawdę niekontrolowany dostęp do wszystkich przestrzeni funkcjonowania atakowanej aplikacji.
Czym różni się LFI, RFI i path traversal?
Do ataku LFI podobne są również ataki RFI oraz path traversal. W jaki sposób odróżnić od siebie te pojęcia?
Atak RFI (remote file inclusion) to próba dołączenia pliku z zewnętrznej lokalizacji (np. z innego serwera). Path traversal manipuluje ścieżką by wyjść poza dozwolony dla użytkownika katalog. Z kolei LFI dotyczy odczytu pliku lokalnego (na tym samym serwerze). Zdarza się, że atak LFI korzysta z możliwości path traversal, ale nie jest to konieczne.
W jaki sposób bronić się przed LFI?
Warto bronić się przed atakami LFI, które (jak widzisz) mają bardzo poważne konsekwencje. W ochronie przed local file inclusion pomoże odpowiednia konfiguracja aplikacji, poważne potraktowanie kwestii bezpieczeństwa i poprawna droga ładowania plików.
- Wskaż użytkownikom dozwoloną wartość nazw plików – nie przyjmuj nazw plików od użytkowników. Wskaż im konkretne wartości, którymi muszą się posługiwać. Dotyczy to np. wdrażanych haseł czy loginów. Zdefiniuj również wartości, które mogą wybierać użytkownicy.
- Filtrowanie danych i walidacja – zdefiniuj system tak, aby odrzucał on wszystkie znaki, funkcje czy polecenia wychodzące poza wskazany dla użytkownika katalog działań. Precyzyjne wskazanie możliwości dla użytkownika to skuteczne zabezpieczenie przed LFI.
- Wyłączenia w konfiguracji – jeżeli używasz PHP lub podobnych, wyłącz dyrektywę „allow_url_include”. Zapobiega to ładowaniu zdalnym i zminimalizować ryzyko powiązanych wektorów.
- Twarde kodowanie ścieżek – w przypadku, gdy aplikacja wczytuje pliki (np. zdjęciowe, tekstowe), na stałe dopisz bezpieczny katalog bazowy w kodzie. Powinien on być zgodny z identyfikatorem witryny (przefiltrowanym i oczekiwanym).
Pamiętaj, aby zmniejszyć uprawnienia użytkowników aplikacji pod kątem np. dostępu do plików konfiguracyjnych i kopii zapasowej. Stosuj dodatkowe warstwy ochronne jak m.in. certyfikat SSL. Zawsze aktualizuj CMS, staraj się regularnie weryfikować poprawność swojego kodu oraz aktualizuj wszelkie modyfikacje i wtyczki. W ten sposób zmniejszasz ryzyko, że ktoś wykorzysta luki w ich działaniu.
Co zrobić, jeżeli doszło do LFI i w jaki sposób rozpoznać atak?
Problemem dla właściciela aplikacji może być fakt, że nie jest on prosty w rozpoznaniu i daje nieoczywiste objawy. Niekiedy mogą to być np. problemy z przekierowaniem, błędy typu 404, blokada otwarcia poszczególnych ścieżek. Dopiero poskładanie wszystkich symptomów „w całość” może dać Ci obraz uszkodzonej struktury aplikacji i ataku LFI.
Jeżeli zauważyłeś, że parametry z sekwencją ../, znaki specjalne albo historię odczytu plików konfiguracyjnych w logach, zacznij przyglądać się sytuacji.
Przede wszystkim skontroluj wszystkie logi, w tym aplikacji, a także w serwerach. Zaktualizuj dostępne wtyczki i moduły do najnowszej wersji. Jeżeli zauważyłeś błędy w określonych częściach aplikacji – wyłącz je, jeżeli to możliwe. Pamiętaj, aby zmienić koniecznie dane dostępowe do aplikacji i zaimplementuj kopię zapasową (o ile ta oczywiście jest bezpieczna).
W przypadku ataku poinformuj o nim użytkowników (którzy powinni zmienić hasła dostępowe) i zleć pełen audyt kodu aplikacji. Dopiero naprawienie kodu i ponowne zabezpieczenie plików pozwoli Ci uchronić się przed atakiem cyberprzestępców i zabezpieczeniem danych własnych użytkowników.
swój potencjał z
polityką prywatności
