Podatności typu Command Injection i zagrożenia z nimi związane

Dzisiaj omówimy podatności typu Command Injection w systemach operacyjnych. Jak duże jest zagrożenie z ich strony? Jak można zapobiec tym podatnościom? Jak NexDAST pomaga im zaradzić? Na wszystkie te pytania odpowiemy szczegółowo poniżej!

Co to jest Operating System Command Injections?

Nie należy mylić command injection z code injection. Złośliwy kod wstrzykiwany do języka programowania jest podatnością typu code injection. Wstrzyknięcia poleceń systemu operacyjnego są rodzajem ładunku, który haker wstrzykuje. Ładunek ten jest następnie wykonywany jako polecenie systemu operacyjnego.

Haker wykonuje tymczasowe polecenie systemu operacyjnego na serwerze aplikacji, co powoduje ryzyko naruszenia aplikacji i danych. Błędy polegające na wstrzykiwaniu poleceń do systemu operacyjnego są często wykorzystywane przez hakerów. Jest to najgorszy scenariusz w przypadku wstrzykiwania poleceń systemu operacyjnego, ponieważ zaczyna się od wstrzykiwania poleceń systemu operacyjnego i prowadzi do wykorzystania innych części infrastruktury hostingowej, co skutkuje narażeniem całego szeregu innych systemów.

Python, Ruby, Perl, Java, C, PHP. Wszystkie te języki programowania umożliwiają użytkownikom wywoływanie poleceń powłoki systemowej. To czyni je podatnymi na wstrzyknięcia poleceń do systemu operacyjnego. Jednak wykonanie wstrzykniętej komendy tymczasowej zależy od uprawnień serwera WWW. Dlatego właśnie podatności typu command injection same w sobie nie są tak niebezpieczne. Ale haker może wykorzystać eskalację przywilejów i uzyskać dostęp do większej ilości informacji. Mając te informacje, można znaleźć i wykorzystać więcej luk.

Przykłady luk typu OS Command Injection

Powiedzmy, że chcesz kupić klawiaturę na stronie internetowej. Aplikacja musi najpierw pozwolić Ci sprawdzić, czy klawiatura, którą chcesz kupić, jest dostępna w magazynie. Użytkownicy otrzymują te informacje za pośrednictwem adresów URL takich jak ten:

https://Keyboard-website.com/StockStatus?ProductID=111&StoreID=22

Aplikacja prosi starsze systemy o dostarczenie użytkownikowi informacji o stanie magazynowym. Wywołanie do polecenia powłoki reprezentuje tę funkcjonalność. Identyfikatory produktów i sklepów są argumentami, więc polecenie powłoki wygląda mniej więcej tak:

Keyboards.py 111 22

Użytkownicy widzą teraz, czy ich preferowana klawiatura jest dostępna w magazynie. Tu jednak pojawia się pewien problem. Aplikacja nie jest zabezpieczona przed wstrzyknięciami komend do systemu operacyjnego. Hakerzy mogą teraz przesłać dane wejściowe, które wykonają tymczasową komendę. Wygląda to coś w stylu „& echo randomstring &” w parametrze storeID. Aplikacja następnie wykonuje to polecenie:

Keyboards.py & echo randomstring & 22

Co robi to polecenie? Powoduje, że podany ciąg znaków zostanie wyświetlony jako echo na wyjściu. Efektywny sposób na testowanie typów wstrzyknięć poleceń systemu operacyjnego. Separator poleceń powłoki ( & ) zamienia jedno polecenie w trzy. Użytkownicy widzą wtedy trzy wyniki:

Error - productID was not provided
Randomstring
22: command not found

Oryginalne polecenie Keyboard.py wykonało się, ale brakowało oczekiwanych argumentów. Z tego powodu otrzymaliśmy komunikat o błędzie. Dostarczony łańcuch (Randomstring) pojawił się na wyjściu. Taki jest cel wstrzykniętego polecenia echo. Ale pokazuje się 22: command not found. Dlaczego? Ponieważ oryginalny argument 22 został wykonany jako polecenie, powodując błąd.

Teraz zajmiemy się lukami typu blind OS command injection. Dzieje się tak, gdy aplikacja nie zwraca danych wyjściowych z polecenia w swojej odpowiedzi. Pomimo tego, hakerzy nadal dysponują różnymi technikami wykorzystywania tych luk:

  • opóźnienia czasowe
  • przekierowanie wyjścia

Użycie wstrzykniętej komendy do wywołania opóźnienia czasowego umożliwia hakerowi potwierdzenie, czy komenda została wykonana. Czas potrzebny na odpowiedź aplikacji jest tym, co mówi, czy polecenie zostało wykonane, czy nie. Jedną z najbardziej efektywnych komend do wykorzystania tej ślepej luki jest ping. To polecenie pozwala wybrać dokładną liczbę pakietów ICMP do wysłania. Liczba ta będzie czasem potrzebnym na wykonanie polecenia.

Przekierowanie wyjścia jest kolejnym exploitem wykorzystującym wstrzyknięcie polecenia do systemu operacyjnego. Przekierowujesz wyjście wstrzykniętej komendy bezpośrednio do pliku. Plik ten znajduje się w webroot, który jest pobierany przez przeglądarkę.

Zapobieganie wstrzykiwaniu poleceń systemu operacyjnego

Jak można zapobiec wstrzykiwaniu poleceń systemu operacyjnego? Najprostszym i najbardziej skutecznym sposobem jest nieużywanie shell_exec lub podobnych wywołań dla poleceń systemu operacyjnego hosta. Zamiast tego zastosuj te same komendy w języku programowania, którego używasz. Problem pojawia się, gdy twój język programowania nie posiada odpowiedniej komendy do tej, której potrzebujesz. W takich przypadkach powinieneś użyć sanityzacji danych wejściowych. Pomocne będzie, jeśli zrobisz to przed przypisaniem wartości do polecenia powłoki. Użycie białej listy jest zawsze najbezpieczniejszą opcją, jeśli chodzi o iniekcje.

Inne opcje potężnego sprawdzania poprawności danych wejściowych obejmują:

  • Walidacja znaków alfanumerycznych (Potwierdź włączenie tylko znaków alfanumerycznych bez spacji lub składni w danych wejściowych)
  • Walidacja liczb (Potwierdź, że dane wejściowe są liczbami)
  • Dozwolone wartości białej listy (Potwierdź przeciwko białej liście dozwolonych wartości)

Nigdy nie powinieneś unikać metaznaków powłoki i próbować sanityzować dane wejściowe w ten sposób. Ponieważ czyni to dane wejściowe podatnymi na ataki hakerów, które mogą oni łatwo obejść.

Jak NexDAST może pomóc w zapobieganiu wstrzyknięciom poleceń do systemu operacyjnego

Najprostszym i najbardziej efektywnym sposobem zapobiegania wstrzyknięciom poleceń do systemu operacyjnego jest wykorzystanie NexDAST. Nasze rozwiązanie do testowania bezpieczeństwa typu black-box automatycznie bada Twoją aplikację. W przypadku wykrycia OS Command Injection, wytyczne naprawcze są wysyłane do dewelopera lub zespołu SecOps. Z NexDAST nie ma potrzeby długotrwałego i powolnego testowania ręcznego.

Przykład NexDAST identyfikujący OS Command Injection:

vulnerable.com/site/ping?ip=8.8.8.8%3B+%2Fbin%2Fcat+%2Fetc%2Fpasswd

Część %3B+%2Fbin%2Fcat+%2Fetc%2Fpasswd jest podatnością. NexDAST dostarcza również wskazówki zaradcze, które pomagają usunąć tę lukę tak skutecznie, jak to możliwe.

Chcesz dowiedzieć się więcej o NexDAST? Omówiliśmy go dogłębnie w jednym z naszych blogów, a jeśli masz problem, z którym NexDAST może pomóc, poproś o demo tutaj!

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany.