Wesołe przygody pentesterów

— Marek Cybul —

Dzień dobry wszystkim, dziękujemy za poświęcony nam czas. Nazywam się Marek Cybul i zajmuję się testami bezpieczeństwa w EXATEL. A to mój kolega Kamil.

— Kamil Suska —

Dzień dobry. Również pracuję jako pentester. Sądzę, że każdy z Państwa zna przynajmniej jeden z tych obrazków. To są logo znanych, popularnych podatności, które w ostatnim czasie często przewijały się w mediach. Podatności te są bardzo ciekawe. Każdy ma swoją stronę internetową oprócz tego że ma CVE swoje logo, ale są też często złożone i znane, czyli…

— Marek Cybul —

Każdy antywirus posiada na nie sygnaturę.

— Kamil Suska —

Tak. Są znane i łatwe do wykrycia.

— Marek Cybul —

O tym nie będziemy dzisiaj mówić. Nie będziemy też mówić o całej grupie podatności typu OWASP Top Ten, które zostały znalezione podczas testów – o tych łatwiejszych do wykorzystania i o tych trudniejszych – bo po prostu nie starczyłoby też nam czasu na jakąś analizę i tego typu sprawy. Po prawej stronie widzimy przykładowe wyniki jednej z web aplikacji i chociaż jest to ekstremum, to aż tak bardzo nie odbiega od rzeczywistości. O tym mówić dziś nie będziemy.

— Kamil Suska —

Będziemy mówić o tym: RCE przed kawą? Co tak naprawdę znaczy to RCE przed kawą? To jest takie hasło, które nie powstało u nas specjalnie na potrzeby prezentacji. Ono po prostu pojawiło się jakoś w trakcie pracy, w trakcie jednego z prowadzonych pentestów i to hasło symbolizuje podatność, która jest bardzo prosta w swoim założeniu, łatwo ją wykonać, ale jednocześnie trudno ją wykryć i potrafi być krytyczna w swoich skutkach.

— Marek Cybul —

I można ją wykorzystać w półśnie przed tytułową kawą.

— Kamil Suska —

Tak, stąd „przed kawą”. Zaczniemy od uwierzytelnienia. Uwierzytelnienie to chyba jeden z ważniejszych elementów każdej aplikacji. Wydaje się, że w obecnych czasach takich trywialnych błędów w uwierzytelnieniu już nigdzie nie powinno być – w produkcyjnych aplikacjach przynajmniej – bo mamy sporo rozwiązań, które załatwiają za nas, są napisane i dobrze działają, ale programiści eksperymentują, próbują swoich rozwiązań. Jak się za chwilę okaże z różnym skutkiem. Tu jest taki pierwszy dość jaskrawy przykład. Mieliśmy sobie aplikację, którą testowaliśmy– to były chyba testy grey-box – i mieliśmy się do niej zalogować. W trakcie pracy okazało się, że mamy taki ciekawy cookie: rk_administrator=0. Każdy chyba pentester w trakcie pracy od razu się zastanawia co się stanie jak zmienimy to 0 na 1. I stało się to, czyli aplikacja wpuściła nas od razu z uprawnieniami administratora. Tu mamy zmieniony parametr, a w tle mamy piękny panel. To tylko jedna zmiana cyferki i niech ktoś spróbuje to wykryć w trakcie pracy.

— Marek Cybul —

Przejęcie poprzez jeden znaczek, a pytanie tutaj jest po prostu: jak coś takiego dotarło na produkcję i żyło tam przez jakiś czas? Prawdopodobnie wywodzi się to po prostu z jakiejś wersji testowej aplikacji, służyło do ułatwienia testowania samej funkcjonalności, ale ktoś po prostu tego nie usunął i przez cały czas sobie istniało.

— Kamil Suska —

To w sumie jedyny sposób w jaki jesteśmy sobie w stanie to wytłumaczyć. Z kolejnym przykładem wiąże się taka pewna krótka opowieść, którą przytoczę. Pewnego dnia testowałem sobie pewien system – cały czas będzie się przewijało określenie „pewien system”, ponieważ staramy się to anonimizować – i na etapie rozklikiwania aplikacji, chciałem sobie uruchomić i zobaczyć o co w tej aplikacji chodzi. Zobaczyłem panel logowania, więc wpisałem sobie login admin i hasło w tym wypadku aor1=1, czyli w SQL to jest „zawsze prawda”. To taki typowy, klasyczny, dwudziestopięcioletni atak, który umożliwia zalogowanie się przez SQLi. I aplikacja zalogowała się co tutaj widać – to jest fragment tego panelu, chciałem wszystko na tym ekranie upchnąć. Aplikacja się zalogowała więc stwierdziłem, że mam SQLi w aplikacji. Chciałem ten atak pociągnąć dalej i z bazy danych aplikacji wyjąć wszystkie dane które mogą być dalej dla mnie potrzebne w trakcie prowadzenia testu: loginy, hasła użytkowników itd. Uruchomiłem narzędzie, które nazywa się SQLMap i otrzymywałem ciągle komunikat, który mówił o tym, że ten parametr nie jest podatny. SQLMap jest naprawdę dobrym narzędziem, ale czasami trochę zawodnym. Poprosiłem Marka żeby zobaczył u siebie. Marek u siebie również próbował i z takim samym skutkiem, więc stwierdził, że spróbuje te query napisać ręcznie i zaczął je rzeczywiście ręcznie wpisywać, a ja trochę poirytowany, zamiast hasła wpisałem pewne niecenzuralne słowo, kliknąłem zaloguj i aplikacja się zalogowała. Myślę sobie: o co chodzi? Może trafiłem z hasłem? Zdarza się. Wylogowałem się więc, wpisałem inne niecenzuralne słowo i aplikacja znowu się zalogowała. Co się okazało, jak wpisywałem cenzuralne słowa również się logowała, także aplikacja potrzebowała jakiegokolwiek hasła żeby się zalogować na konto administratora. Weryfikowała samo istnienie zmiennej, a nie jaką ma zawartość. Także nie wszystko jest SQLi co się świeci.

— Marek Cybul —

Tu z kolei widzimy już normalne logowanie SQLi. Warto przypomnieć właśnie, że to jest jakiś atak z lat dziewięćdziesiątych i za pomocą kilku znaczków jesteśmy w stanie zalogować się bez znajomości hasła. Warto tutaj dodać, że jest to aplikacja jednej z organizacji finansowych i jest to logowanie do panelu administratora.

— Kamil Suska —

To była na szczęście produkcyjna aplikacja wystawiona w Internecie.

— Marek Cybul —

Istniała sobie w Internecie przez jakiś czas i wrzuciliśmy to tu dla pokazania, że takie trywialne ataki nadal mają miejsce w Internecie i nie jest to egzotyczne.

— Kamil Suska —

Mimo powagi organizacji, która była właścicielem tego problemu.

— Marek Cybul —

Na dole widzimy ten sam portal i zazwyczaj po przełamaniu takiego uwierzytelnienia w panelu administracyjnym, staramy się uploadować webshell żeby wykonać kod na serwerze, ale w tym przypadku nie musieliśmy się za bardzo wysilać bo sama aplikacja posiadała skrypt, który pozwalał nam tego dokonać za pomocą jednego znaku. Tutaj słowo widoczne jest na dole screenu. A humorystycznym faktem jest, że w stronie „odpowiedzi” dostawaliśmy stronę „podziękowań” z formularzem dziękujemy.html.

— Kamil Suska —

Także miło jeżeli ktoś docenił pracę.

— Marek Cybul —

Teraz opowiemy sobie o podatnościach, które często stoją ogólnie na spornej krawędzi pomiędzy funkcjonalnością, a bugiem. Często wynikają one już w procesie samego projektowania aplikacji i są obiektem sporów pomiędzy wykonawcą aplikacji, a outtesterami, ponieważ nie da się tego prosto naprawić, nie zaburzając samej funkcjonalności aplikacji.

— Kamil Suska —

I jako pierwszy przedstawimy taki bardzo jaskrawy przykład. To jest widok aplikacji po zalogowaniu, na szczęście na uprawnieniach administratora. Ktoś pisząc, projektując tę aplikację – bo pisząc pewnie napisał co mu kazali – wymyślił sobie, że w ten sposób będzie to zrealizowane, że na serwerze są jakieś skrypty i te skrypty po prostu będzie można sobie uruchomić. Były one nazwane Listener, Pinger i Logger. Osoba ta nie uwzględniła jednak tego, że ktoś może sobie swój skrypt pobrać i go również potem uruchomić, także mamy tak naprawdę webshell wbudowany jako funkcjonalność w aplikację. 5 minut dosłownie wystarczyło do przejęcia serwera i do kompromitacji. I to jest właśnie pytanie, bo ktoś powie, że to jest konto administratora aplikacji, ale czy administrator aplikacji musi być również administratorem serwera, na którym nie tylko ta aplikacja się znajduje?

— Marek Cybul —

Może być kilka aplikacji na tym samym serwerze, a w ten sposób mamy pełną nad nim kontrolę.

— Kamil Suska —

I tak w tym przypadku też było, z tego co pamiętam.

— Marek Cybul —

Tu z kolei mamy inny przypadek. Często niedoceniany z punktu widzenia bezpieczeństwa, czyli grube klienty, aplikacje desktopowe. Bierze się to prawdopodobnie stąd, że bilans ryzyka dla przejęcia serwera aplikacyjnego jest dużo wyższy od stacji roboczej użytkownika, ale jak się przekonamy na tym przykładzie, nie zawsze tak jest. Była to taka właśnie aplikacja, której jako funkcjonalność można było umieścić swój własny kod w języku „R” i służyła ona do obliczeń statystycznych i transformacji danych wejściowych. Pierwszym problemem było to, że aplikacja pozwalała na wykonanie dowolnego kodu bez żadnego mechanizmu whitelisty, tak że można było też umieścić złośliwy kod, który został wykonany, ale nie byłoby to dość krytyczne bo każdy użytkownik i tak posiadał uprawnienia do wykonania kodu na swojej maszynie – tak można uruchamiać dowolne programy. Problem zaczyna się tutaj, gdzie aplikacja ta synchronizuje kawałek kodu z serwerem.

— Kamil Suska —

A serwer synchronizuje potem ze wszystkimi innymi użytkownikami tej aplikacji.

— Marek Cybul —

Dokładnie. W ten sposób raz umieszczony złośliwy kod, ląduje na wszystkich stacjach roboczych posiadających ten sam software. I to jest po prostu funkcjonalność, której pewnie nie powstydziłby się twórca botnetu, ale takie było założenie twórców i ciężko było jednoznacznie naprawić, zmitygować ten fakt. Można było użyć np. Qt Scripta, który posiada taki mechanizm whitelisty w pewnym stopniu. I Sandbox z tego co pamiętam.

To jest przykład SQLi bez „i”. Dlaczego bez „i”? Dlatego że na dole widzimy że w requeście DD Boost, przesyłany jest po prostu cały query SQL, łącznie z selectem, tak więc nie trzeba tutaj niczego injectować. Jest to po prostu SQL Shell w Webie. I to też zostało wybrane jako metoda komunikacji z serwerem bazy danych, co prawdopodobnie ciężkie by było do umieszczenia w regule WAF-a, jeżeli sama aplikacja opiera się na takiej komunikacji, ale może gdyby ktoś spróbował i przynajmniej zajrzałby pod ten JavaScript, sprawdziłby co tam tak naprawdę się dzieje i że może to mieć jakieś konsekwencje. Dodatkowym faktem jest tu to, że nie tylko jest to SQL Shell, ale również normalny Shell. W MS SQL została włączona metoda xp_cmdshell, pozwala ona na wykonanie command powłoki systemowej. Także jednym requestem możemy jednocześnie uzyskać dostęp do bazy danych, do systemu i to na niskim uwierzytelnieniu, z tego co pamiętam.
BUGdoor platform. Często podczas projektowania architektury sprzętowej, musimy też myśleć o bezpieczeństwie. Przykładem jest urządzenie, które dostaliśmy w swoje ręce jakiś czas temu. Jest to jedna z bramek video, rozwiązanie podobne do Chromecasta, ale przez producenta reklamowane jako rozwiązanie typu enterprise i proponowane do wykorzystania w środowiskach biurowych. I tu już na początku możemy powiedzieć, że sama architektura fizyczna trochę pozostawia do życzenia bo na tej karcie SD widocznej na lewym zdjęciu nie znajduje się przestrzeń do zamieszczenia nowych zdjęć czy danych – znajduje się tam cały filesystem urządzenia, tak więc w łatwy sposób można ją podmienić.

— Kamil Suska —

Do tej karty nie trzeba było tego urządzenia rozbierać, rozklejać czy jakiś twardych zatrzasków, taka klapka się odsuwała jak w pilocie i mieliśmy cały dostęp do file systemu. Także około 30 sekund mogło to zająć.

— Marek Cybul —

Później takie urządzenie służy do prezentacji ekranu, wędruje po firmie i prezentowane są najróżniejszego typu prezentacje od tych sprzedażowych produktu, po posiedzenia zarządu. Ale pomimo drobnego tutaj błędu w samym tym rozwiązaniu, nie znaleźliśmy większych błędów jeżeli chodzi o samą web aplikację zarządzania i interfejs tego urządzenia.

— Kamil Suska —

Ale tak jeszcze wtrącę. Testowaliśmy celowo na takiej wersji oprogramowania jaką dostaliśmy to. Urządzenie nie miało wtedy zainstalowanej najnowszej wersji firmware’u bo wierzyliśmy że najnowsza wersja firmware’u będzie lepsza, połatana, chcieliśmy sobie trochę błędów znaleźć najpierw na tym urządzeniu, potem zaktualizować i zobaczyć jak to będzie wyglądało po aktualizacji.

— Marek Cybul —

I po takiej aktualizacji trochę się zawiedliśmy, bo o ile istniejące wcześniej uwierzytelnienie panelu zarządzania istniało i nie pozwalało nam na wykonanie jakichś złośliwych akcji, to po upgradzie zostało ono totalnie zlikwidowane i od tej pory każdy użytkownik sieci bezprzewodowej mógł dowolnie zarządzać takim urządzeniem. Przykładem po prawej jest zmiana ekranu powitalnego, ale mogłoby to być dosłownie wszystko. Dodatkowo podczas odkręcenia firmware’u tego urządzenia i zajrzenia w środek, znaleźliśmy hardcodowane uwierzytelnienie root1234 i nie byłoby to jeszcze takie krytyczne bo zgodnie z założeniem interfejs SSH był dostępny tylko po kablu USB jako Internet gadget, ale poprzez błędną konfigurację Arpa w Linuxie, który był na tym urządzeniu, można było do tego SSH połączyć się również przez sieć wireless. Wystarczyło znać odpowiedni adres IP (tu był on z zakresu 169) i można było się połączyć na ten interfejs USB przez wireless. Także rodzi się tu scenariusz w którym ktoś na parkingu firmowym, siedząc wygodnie w samochodzie, mógłby połączyć się do takiej sieci wireless rozgłaszanej przez samo urządzenie, zalogować się na nie, podglądać całe posiedzenie zarządu, a na koniec wrzucić tam złośliwe oprogramowanie, które będzie wędrować po firmie. I z pozoru błahe urządzenie mogłoby doprowadzić do jakiegoś poważnego wycieku.

— Kamil Suska —

Tu na samym dole jest jeszcze screen z innej beczki, ale nawiązujący do tematu, tylko dotyczy po prostu innej aplikacji. Dotyczył „grubego” klienta i ten „gruby” klient działał w organizacji w której pracowało się w systemie gorącego krzesła, czyli przy jednym komputerze pracowało wielu pracowników, którzy logowali się na swoje dane uwierzytelniające, tylko problem polegał na tym, że właśnie ten screen, który tutaj widać, to jest plik log w jawnym tekście, przechowywanym na tej stacji roboczej w której są dane uwierzytelniające wszystkich użytkowników, którzy się na tej stacji roboczej logowali, także mamy keyloggera jako feature.

— Marek Cybul —

I tu mamy historię pewnego pentestu, który standardowo zaczęliśmy od skanu usług TCP i renumeracji i pośród takich wyników znalazła się usługa, której Nmap nie był w stanie zinterpretować co to może być, więc manualnie sprawdziliśmy to Netcatem. Przy każdorazowym wysyłaniu prostego żądania, jakichś losowych znaków wejściowych otrzymywaliśmy w podpowiedzi losowe znaki, tak więc próbowaliśmy modyfikować nasze żądanie, zmieniać je, ale odpowiedź za każdym razem była bardzo losowa i nie dało się z niej za dużo wyciągnąć. Po bliższym przyjrzeniu się – tutaj słabo widocznego błędu w komunikacie zwrotnym – widzimy że aplikacja tak naprawdę próbuje nam zwrócić ID wiadomości, która tutaj, w tym przypadku złego żądania, po prostu nie istnieje. I doprowadza to do klasycznego przypadku wycieku pamięci. Jak się później okazało, sam adres który był testowany jest tak naprawdę load balancerem i poprzez wystarczająco długie wysyłanie takich zapytań, powiedzmy przez pół godziny ciągłego wysyłania ich, byliśmy czasem w stanie dostać kawałek PDF-a widocznego po lewej, a czasem też pełnego dokumentu widocznego po prawej. Wydaje nam się, że przy wystarczająco długim odpytywaniu tej usługi, moglibyśmy dostać cookie, loginy, hasła i sesje użytkowników.

— Kamil Suska —

Wszystko co przechodzi przez load balancer tak naprawdę.

— Marek Cybul —

Było to o tyle krytyczne, że nawet nie trzeba było zbytnio wysyłać żadnych znaków do tej usługi – ona po prostu aż prosiła żeby zwrócić nam część tej pamięci procesu.

— Kamil Suska —

Klienci często nie chcą się decydować na testy penetracyjne, które w swoim zakresie mają również testy odporności systemów przed atakami typu DoS. Są to testy dosyć inwazyjne i potrafią tę aplikację wykoleić, ale my nie uważamy tego w sumie za słuszne podejście, szczególnie jak to jest aplikacja wystawiona w Internecie, bo lepiej naszym zdaniem tę aplikację przetestować w kontrolowanych warunkach, niż jak jakiś samozwańczy pentester ma tę aplikację sobie przetestować, co jest wysoce prawdopodobne jeżeli jest ona wystawiona w Internecie. Ale są organizacje dla których ta dostępność aplikacji jest bardzo krytyczna i na pewno jednym z takich rodzajów działalności jest prowadzenie portali aukcyjnych. I tu mamy przykład portalu aukcyjnego naszego klienta, któremu bardzo zależało właśnie na tym żeby tę wysoką dostępność aplikacji zachować, więc te testy przeprowadzaliśmy. Klient dlatego że dbał o bezpieczeństwo swoich użytkowników, do każdej praktycznie akcji, która była wymagana w aplikacji, wymagał 2FA i potwierdzenie było realizowane jako token, który przychodził sms-em. Była bramka sms, więc my tę bramkę sms wzięliśmy jako pierwszy cel i co się okazało? Okazało się, że przesyłając dużo zapytań (ale nie jakoś bardzo dużo bo około 2 tysięcy), w ciągu 5 sekund jesteśmy w stanie tę bramkę zapchać. Bramka zapychała się w ten sposób, że sms-y w ogóle nie dochodziły, aplikacja była unieruchomiona na dobre kilkadziesiąt minut i co ciekawe zapchała się najprawdopodobniej na etapie samego operatora, bo analizowaliśmy potem z klientem i sama aplikacja odpowiadająca za wysyłkę tych sms-ów jak najbardziej przeżyła. W ten oto prosty sposób mieliśmy aplikację wyłączoną z użytku przez 20 minut.

— Marek Cybul —

Po przerwaniu. A gdybyśmy to kontynuowali?

— Kamil Suska —

Tak, po przerwaniu, bo tylko wysłaliśmy dla testu. Nie mówiąc o kosztach, bo każdy wysłany sms generuje koszt (SMSy w takich usługach nie są darmowe). Dalej mamy portal aukcyjny i tutaj jest taki bardzo prosty atak (aż atak tego nazywać nie wypada), a mianowicie aplikacja w ten sposób wylosowywała użytkowników, że metodą http delete usuwała po prostu dane sesyjne aplikacji. I wszystko byłoby w porządku gdyby nie to, że aplikacja nie weryfikowała tego kto usuwa i czyje usuwa dane sesyjne, więc mogliśmy usunąć dane sesyjne dowolnego użytkownika, a sprawę jeszcze pogarszało to, że te ID użytkownika to są po prostu kolejne cyferki, także możemy znumerować wszystkich użytkowników poza sobą i tych użytkowników najzwyczajniej w świecie wylogować. Ale jak już mamy użytkowników wylogowanych, aukcja się kończy, no to też byśmy nie chcieli żeby się zalogowali z powrotem i tu klient zastosował rozwiązanie, które blokowało możliwość zalogowania się po określonej ilości wpisania błędnego hasła i blokowało również możliwość resetu hasła jeśli za dużo razy próbowało się te hasło zresetować. Zrealizował to po adresie IP, czyli aplikacja identyfikowała użytkownika po adresie IP, tylko że tu mamy ciekawy przypadek, bo klient zastosował urządzenie, które znacznie podnosi bezpieczeństwo aplikacji czyli Reverse Proxy, ale w związku z tym że zastosował Reverse Proxy, to każdy klient, który się logował do aplikacji był dla nich widziany jako ten sam użytkownik, czyli jako adres serwera Reverse Proxy i blokując możliwość zalogowania się z jakiegokolwiek adresu IP, blokowaliśmy możliwość zalogowania się tak naprawdę wszystkim użytkownikom tej aplikacji.

— Marek Cybul —

I tu przykład następnego oprogramowania dla którego dostępność jest krytyczna. Jest to jedno z rozwiązań też dobrze znanych i istniejących na rynku już jakiś czas. Jest to jeden z systemów do backupów, kopii zapasowych i zarządzania nimi. Podczas jednego z testów z takim systemem, przyszło nam się zmierzyć i o ile nie znaleźliśmy w samym interfejsie zarządzania jakichś krytycznych błędów, to wystarczyło nam pół godziny wysyłania losowych znaków widocznych po prawej stronie, żeby znaleźć jeden pakiet, który taki system wyłączał na stałe. Tak więc można sobie wyobrazić, że było to dość trywialne, a w prawidłowym wykorzystaniu np. w złośliwym oprogramowaniu typu ransomware, takie wyłączenie backupów przed zaczęciem szyfrowania dysków, znacznie powiększyłoby szkody wyrządzane przez takie oprogramowanie.

Na koniec opowiemy krótką historię z ostatnimi czasy przeprowadzonych testów. Były to testy, które zakończyły się totalną kompromitacją sieci biurowej klienta – przejęcie kontrolera domeny itp. Ale były to testy typu grey-box czyli mieliśmy częściowy dostęp, powiedzmy na tej zasadzie, że zapora sieciowa została wyłączona na czas testów, tylko po to żeby znaleźć jak najwięcej podatności w aplikacji.

— Kamil Suska —

Tak, chcieliśmy znaleźć błędy w aplikacjach, a nie testować zaporę.

— Marek Cybul —

Ale po włączeniu tego firewalla okazało się, że nasza ścieżka ataku została przełamana i nie możemy go powtórzyć drugi raz i zapora sieciowa działa tak jak powinna. W zakresie testu znajdował się też infokiosk, który tu widzimy i pomyśleliśmy że spróbujemy swoich sił i sprawdzimy czy może do czegoś nas to doprowadzi.

— Kamil Suska —

Kiosk, trzeba powiedzieć wprost, był całkiem nieźle zrobiony. Próbowaliśmy na wszelkie znane nam sposoby odpuścić tego dodatkowego sortboxa w tym kiosku. Usługi swoje dostarczał w ten sposób, że miał zaprojektowaną dla siebie przeglądarkę internetową i ta przeglądarka miała zwhitelistowane tylko trzy zaufane strony internetowe dla klienta, gdzie te usługi były udostępniane. Jedyne co nam się udawało zrobić to scrashować tę aplikację, staliśmy przy tym kiosku, klikaliśmy na dwie ręce żeby ją wycrashować, ale aplikacja od razu ładnie wstawała, wskakiwała na samą górę, nic się nie dało w międzyczasie zrobić i tak ze dwie godziny się męczyliśmy dotykając ten kiosk na wszystkie możliwe sposoby i zaczęliśmy w końcu przeglądać udostępnione tam strony internetowe.

Na jednej ze stron internetowych była możliwość wysłania wiadomości, skontaktowania się po prostu, a cały problem polegał na tym, że do wiadomości można było dodać załącznik. Skoro można było dodać załącznik, to otworzyło się nam okno file systemu i dalej sprawa była już prosta – po prostu uruchomiliśmy sobie dla wygody tylko klawiaturę ekranową, normalną przeglądarkę (tu Firefoxa) i postanowiliśmy zobaczyć czy jest ruch sieciowy i przeprowadzić tę ścieżkę ataku, którą wcześniej nam się udało przeprowadzić z wyłączonym firewallem. Co się okazało, kiosk był w sieci serwerowej, bo był uważany przez klienta za tak bezpieczne rozwiązanie, że po prostu tam się znajdował. Tak więc powtórzyliśmy naszą ścieżkę. Przedstawimy ją w skrócie, bo była w sumie dosyć ciekawa. Był wystawiony panel do zarządzania UPS-em do którego login i hasło było admin/admin (bo przecież był w sieci wewnętrznej, prawda?). Panel miał też swoją funkcjonalność, która polegała na tym, że umożliwiał wykonanie kodu na maszynie. Wykonując ten kod, dla ułatwienia jeszcze pracowała aplikacja na uprawnieniach NT Authority System na jednym z serwerów sieci więc założyliśmy tam sobie użytkownika, dodaliśmy do grupy administratorów, żeby było wygodniej dodaliśmy do grupy remote desktop i potem prostą mimikacją wyciągnęliśmy sobie hasło administratora domeny, zalogowaliśmy się na hosta Hyper-V i wszystko – wyżej się nie da. Aplikacja przejęta w 7 minut za pośrednictwem kiosku. Raczej organizacja. I mógłby ktoś powiedzieć że „Ale kto tam będzie stał, recepcja jest obok, ludzie się kręcą, kamery i robią jakieś dziwne rzeczy na tym kiosku”, trochę by to było podejrzane, prawda? Tylko że gniazdko Ethernet było tak idealne, czyli było schowane za kioskiem, ale łatwo dostępne. Wiążąc buta dosłownie można było wpiąć tam sobie Access pointa na baterie, obok była knajpa i siedzieć sobie pod parasolem i zrobić to wygodnie.

Podsumowując – ufam ale sprawdzam. Chcieliśmy przede wszystkim tak w skrócie pokazać, że nie możemy bezgranicznie ufać temu, co nam dostarczają producenci, niezależnie od tego czy jest to rozwiązanie pisane tylko dla nas, czy jest to rozwiązanie dużego producenta rozwiązań Enterprise. To rozwiązanie dba i nam zagraża, naszemu bezpieczeństwu więc musimy to sprawdzać.

— Marek Cybul —

Części podatności tutaj pokazanych można by uniknąć całkowicie w procesie samego projektowania aplikacji. Nie tylko projektowania web aplikacji, ale również całych systemów.

— Kamil Suska —

Często w bardzo prosty sposób, bo w przypadku tego Reverse Proxy, wystarczyło dodać nagłówek.

— Marek Cybul —

Tutaj była sprawa bardziej taka, że nie wystarczy zaimplementować rozwiązanie, trzeba je jeszcze dobrze skonfigurować.

— Kamil Suska —

I dobrze wdrożyć. W przypadku naszej, to też jest ciekawe rozwiązanie, „ufam ale sprawdzam”, czyli w przypadku tej naszej bramki video okazało się, że niekoniecznie najnowsza wersja oprogramowania musi być tą najlepszą, a trudno skarcić pracownika za to, że dba o aktualność oprogramowania w urządzeniach.

— Marek Cybul —

Podobna sytuacja jest z tym kioskiem, a jak się później dowiedzieliśmy, sytuacja wynikła tak, że ten kiosk był wcześniej testowany, był dobrze shardenowany, był wcześniej testowany, tyle że podczas jego pracy dokonano małego upgrade’u, czyli dodano trzecią domenę do tej whitelisty. Wcześniej były tylko dwie i tylko one podlegały testom. Później dodano trzecią domenę, ale już testów nie powtórzono, a tak jak widzieliśmy jedna domena pozwoliła nam na przejęcie tego urządzenia.