Bezpieczeństwo i testy penetracyjne gRPC
W dobie nowoczesnych systemów rozproszonych i architektury mikroserwisów, gRPC API staje się coraz popularniejszym rozwiązaniem dzięki swojej wydajności, szybkości i wsparciu dla wielu języków programowania. Użycie protokołu HTTP/2 oraz formatu Protocol Buffers (Protobuf) sprawia, że gRPC oferuje znaczne korzyści w porównaniu do tradycyjnych API opartych na REST. Jednak wraz z rosnącym zastosowaniem stworzonego w google protokołu, bezpieczeństwo gRCP stanowi również wyzwanie dla programistów, jak również i osób zajmujących się bezpieczeństwem aplikacji.
W artykule omówimy, dlaczego bezpieczeństwo gRPC API jest kluczowe w ochronie danych i usług, a także przedstawimy techniki testów bezpieczeństwa. Dowiesz się, jak identyfikować podatności w gRPC oraz jak przeprowadzać skuteczne testy penetracyjne.
Czym jest grpc api?
gRPC to wysokowydajny, open-source’owy framework RPC (Remote Procedure Call) opracowany przez Google. Umożliwia wydajną komunikację między systemami rozproszonymi, pozwalając klientom i serwerom na obustronną komunikację, tak jakby były lokalnymi obiektami. Jednocześnie zarządza złożonościami, takimi jak serializacja, uwierzytelnianie i równoważenie obciążenia. gRPC wykorzystuje HTTP/2 do transportu, Protocol Buffers do serializacji i obsługuje wiele języków programowania, co czyni go wydajnym i wszechstronnym rozwiązaniem do tworzenia systemów rozproszonych.
Pomimo wysokiej wydajności, gRPC pozostaje niszową technologią. Dzieje się tak, ponieważ przeglądarki nie oferują obecnie kontroli nad żądaniami sieciowymi na poziomie wymaganym do obsługi klienta gRPC. Aby korzystać z tej technologii w klasycznej komunikacji WEB klient-serwer, programiści muszą zastosować javascriptową implementację gRPC dla przeglądarek oraz gRPC Web-proxy. W takim przypadku proxy przekształca komunikację po protokole HTTP/1.1 lub HTTP/2 w natywny format binarny, na którym bazuje gRPC, i przesyła ją do backendu.
Bezpieczeństwo gRPC
gRPC wykorzystują krytyczne aplikacje, takie jak systemy IoT, aplikacje mobilne, usługi finansowe czy systemy opieki zdrowotnej objęte NIS2. Wynika to z unikatowej wydajności protokołu, co wpływa na bezpieczeństwo gRPC. Niewłaściwe zabezpieczenie API może prowadzić do wycieków danych, nieautoryzowanego dostępu lub przejęcia kontroli nad aplikacjami.
W ostatnim czasie konsekwencje naruszeń bezpieczeństwa API stają się coraz bardziej widoczne. Incydenty naruszenia bezpieczeństwa prowadzą do poważnych skutków, takich jak kradzież danych, przerwy w świadczeniu usług i znaczne straty finansowe. Przykładowo, atakujący mogą wykorzystać niezabezpieczony interfejs API gRPC, prowadząc do nieautoryzowanego dostępu do wrażliwych danych klientów, kradzieży tożsamości i oszustw. Choć o naruszeniach danych często myśli się w kontekście zagrożonych baz danych, potencjał takich ataków za pośrednictwem interfejsów API gRPC, biorąc pod uwagę ich wydajność i możliwości, jest również znaczący.
Najczęstsze zagrożenia dla gRPC API
Mimo wysokiej wydajności i zaawansowanych funkcji, takich jak HTTP/2 i Protocol Buffers, gRPC API jest podatne na różne zagrożenia bezpieczeństwa. Oto lista najczęstszych zagrożeń, które mogą wystąpić podczas korzystania z gRPC:
1. Brak uwierzytelniania i autoryzacji
Jeśli gRPC API nie wymaga od klientów uwierzytelniania, każdy może uzyskać dostęp do usług. Brak autoryzacji na poziomie metod lub zasobów może umożliwić atakującym uzyskanie nieuprawnionego dostępu i obniżyć bezpieczeństwo gRPC.
2. Podatności w Protocol Buffers (Protobuf)
Protocol Buffers to binarny format danych, co utrudnia ręczną inspekcję żądań i odpowiedzi. Jeśli nie zostanie poprawnie obsłużony, może prowadzić do błędów parsowania, które umożliwiają przeprowadzenie ataków związanych z deserializacją.
3. Niezabezpieczone strumieniowanie danych
gRPC obsługuje dwukierunkowe strumieniowanie danych, co może być wykorzystywane przez atakujących do przesyłania złośliwych danych lub przeciążania serwera (np. ataki typu DoS).
4. Ataki typu Replay i Brak Bezpieczeństwa Sesji
Jeśli gRPC API nie weryfikuje unikalności żądań, może być podatne na ataki typu Replay, gdzie atakujący wielokrotnie odtwarza przechwycone żądania.
5. Ataki typu Injection
Kiedy mówimy o atakach wstrzyknięcia własnego kodu w kontekście usług gRPC, zazwyczaj odnosimy się do scenariuszy, w których niezaufane dane są niewłaściwie obsługiwane, umożliwiając atakującym wstrzyknięcie złośliwego kodu lub nieoczekiwanych danych wejściowych do systemu. Może to prowadzić do różnych luk w zabezpieczeniach, takich jak wstrzykiwanie kodu SQL, a nawet poleceń systemowych.
6. Przestarzałe wersje bibliotek i zależności
Korzystanie z nieaktualnych bibliotek gRPC lub Protobuf może skutkować występowaniem znanych podatności.
Testy penetracyjne grpc api
Z uwagi na to, że gRPC jest dosyć nową technologią, a w dodatku niewspierana przez przeglądarki testy penetracyjne są w pewnym stopniu utrudnione. Na obecną chwilę niemal żaden skaner podatności nie wspiera testów gRPC. Jednym z nielicznych zestawów narzędzi, które mogą nam posłużyć do testów jest gRPC Web Pentest Suite. Toolkit znajduję się na tym repozytorium githuba. Projekt składa się m.in z:
- gRPC-scan – Skaner służący do przeszukiwana w plikach javascriptowych pod kątem endpointów, usług, wiadomości i rodzajów pól.
- burp-gRPC-extension – Dodatek do burpa pozwalający w prosty sposób na dekodowania oraz kodowanie paylodów gRPC w celach manipulacji wartościami.
Rekonesans
We wspomnianym wcześniej pliku javascriptowym main.js będącym implementacją gRPC dla przeglądarek możemy odnaleźć informacje na temat endpointów, czy pól. Możemy w ten sposób zidentyfikować również i ukryte endpointy i pola których nie dostrzeżemy w burpie. Mogą to być przykładowo zasoby związane z administrowaniem lub debugowaniem aplikacji, które nie zostały dostatecznie zabezpieczone. Mechanizm może niektórym przypominać introspekcje z GraphQL.
Testy z burpem
Dane w żądaniach oraz odpowiedziach przesyłanych za pomocą gRPC-Web przechowywane są w natywnym binarnym formacie gRPC. Niestety do tej pory burp podobnie jak większość skanerów nie wspiera formatu binarnego gRPC. Próba zdekodowania, a następnie zakodowania zmodyfikowanych danych przy pomocy base64 zaburzy integralność, przez co żądanie zostanie odrzucone przez backend aplikacji. Z pomocą jednak przychodzi nam gRPC Coder Burp Extension. Przy jego pomocy jesteśmy w stanie zdekodować dane binarne do formatu przypominającego JSON, zmodyfikować je, a następnie przywrócić do binarnego formatu.
Poza wspomnianymi wyżej przykładami, testy penetracyjne gRPC-Web nie różnią się wiele od testowania innych typów API jak REST. Możemy tutaj spotkać klasyczne typy podatności tj. SQL injection, Cross Site Scripting, błędy związane z kontrolą dostępu, czy brak szyfrowania danych. Z uwagi na unikalny sposób na przechowywanie danych w żądaniach i odpowiedziach, programiści często nie przywiązują zbyt wielkiej wagi do walidacji danych wejściowych jak w przypadku REST, czy SOAP API.
Dla przykładu spójrzmy jak w powyższy sposób będziemy w stanie znaleźć podatność typu Stored Cross Site Scripting.
Jak widzimy powyżej nasza testowa aplikacja wykorzystuje jakiś rodzaj walidacji, który uniemożliwia nam wykonanie naszego payloadu.
Po rozkodowaniu binarnej formy naszego payloadu widzimy, że frontend aplikacji waliduje dane pochodzące od użytkowników, kodując potencjalnie niebezpieczne znaki.
Wystarczy, jednak aby pentester przywrócił pierwotny payload, a następnie zakodował i wysłał dane do backendu, aby ominąć walidacje.
Podsumowanie
W niniejszym artykule przybliżyliśmy sobie technologię gRPC. Poznaliśmy zalety, takie jak szybkość i wysoka wydajność, jak również i wady związane z brakiem wsparcia ze strony przeglądarek. Omówiliśmy również kwestie bezpieczeństwa oraz zagrożeń dla protokołu na testowaniu kończąc. Z danych wynika, że gRPC będzie stawało się coraz popularniejszą technologią. Proporcjonalnie również będzie zwiększać się liczbę podatności oraz incydentów bezpieczeństwa. Znajomość oraz umiejętność testowania gRPC stanowić będzie dla pentesterów i architektów bezpieczeństwa już nie tylko ciekawostkę. Będzie to konieczna wiedza aby stale podnosić bezpieczeństwo wysokowydajnych aplikacji.
