Transcription

Ja bym powiedział zboczenie Japończyków. Po pierwsze, jeżeli popatrzycie sobie na ikonki, emotki, to w japońskim emotki z kupą jest ich parę tysięcy. Jest to nieprawdopodobne, ale to także ma odwzorowanie takiej w rzeczywistości, jak się tam wchodzi. Opowiedz jak wyglądają te toalety, bo to jest coś nieprawdopodobnego. Człowiek nie wie jak się tam obsłużyć. Halo, cześć. Nie byłem przygotowany na to, żeby opowiadać o toaletach w Japonii, ale rzeczywiście jest to dosyć specyficzne. Jest sporo przycisków na desce klodotowej i należy wybrać odpowiedni. Różne są funkcje różnych przycisków. Najciekawsze, które udało mi się odkryć, to śpiew ptaków. Był to śpiew w różnych tonacjach, także można było sobie wybrać, albo odgłos spuszczanej wody. Też jest to w Japonii istotne, żeby trzy razy spuścić wodę, a ponieważ ekologia jest istotna, nie należy marnować wody, więc spuszcza się raz, a dwa razy się naciska przycisk, który wydaje głos spuszczanej wody. Jest to dosyć ciekawe i instrukcja obsługi toalety na pewno jest istotnym aspektem, jeśli się wybiera do Japonii. Cześć, jeszcze raz. Przedstawię się, nazywam się Bartłomiej Głośnicki. Dzisiaj chciałem wam opowiedzieć o sposobach omijania web application firewall i filtrowania w aplikacjach internetowych. Na początku agenda web application firewall, opowiem co to jest, typy, modele działania, ogólne sposoby omijania reguł i polityk, które są zdefiniowane w tych urządzeniach czy oprogramowaniu oraz przykłady omijania tych reguł, które będą bazowały na rzeczywistych pentestach, które wykonaliśmy i na koniec pytania, jeśli będą. Chwilka o mnie. Zajmuję się tematami ofensji, security, article hacking w Accenture Security. To są pentesty, red teaming, udział w CTF-ach, programach bug bounty. Aktualnie pracuję w konsultingu, natomiast wcześniej również pracowałem po obu stronach, zarówno jeśli chodzi o defensywne aspekty, jak i ofensywne. Więc czym jest WAF? WAF jest to dodatkowa warstwa ochrony aplikacji przed atakującym. Jest to w gruncie rzeczy filtr, który instalujemy pomiędzy przeglądarką a aplikacją. Jego cel jest dosyć prosty, oczywisty, ma zablokować znane sygnatury ataków oraz pewny ruch, który jest anomalią w stosunku do regularnego ruchu. I tutaj mamy przykład, jeżeli jest na przykład payload i CSS, to taki WAF powinien go zablokować. Jeśli jest poprawne zapytanie, to przechodzi dalej do serwera, który obsługuje to zapytanie. Podobnie jest z jakimś payloadem SQL injection. Więc zasada ogólnie znana, natomiast się przypomnę dla porządku. Przykłady produktów, które mogą realizować funkcję WAF-a, to jest najbardziej popularny open source mod security, ale także te, które znajdują się w prawym górnym rogu kwadratu Gartnera, czyli Imperwa, Akamai, F5 i cloudowe Cloudflare, AWS i też pozostałe, tak jak Barcuda czy Fortinet. Wszystkie te produkty są dojrzałe i można je spotkać w organizacjach Enterprise. I sposoby ich działania. No mogą być to skrzynki, które wstawiamy do szafy rokowej, czyli rozwiązanie on-premise lub rozwiązanie typu cloud-based, gdzie wykupujemy po prostu pośrednictwo na przykład w Cloudflare, gdzie ten ruch jest filtrowany pomiędzy aplikacją a atakującym i dodatki software'owe, takie jak na przykład mod security, który instalujemy jako moduł serwera WWW. Typy filtrowania. White box filtering. Najbardziej pożądany, najtrudniejszy we wdrożeniu z uwagi na częsty brak dokumentacji, oprogramowania. Często nie wiemy, jakie parametry, jakie wartości parametrów może aplikacja przyjmować i z tego względu jest to bardzo trudne do prawidłowego wdrożenia. Black box filtering bazuje po prostu na gotowych sygnaturach ataków. Jest najprostszy do wdrożenia, jednak najczęściej, najłatwiej się go omija. I takie, które są najbardziej popularne w rozwiązaniach właśnie enterprise'owych, czyli hybrydowe, inteligentne, gdzie mamy połączenie black box i white box. Z tym, że ten white box filtering polega na tym, że WAF dopasowuje reguły filtry do danej aplikacji na podstawie pewnego uczenia się tej aplikacji, czyli mamy okres czasu, kiedy aplikacja się uczy, czyli WAF się uczy na tej aplikacji i potem zakłada, że to są wszystkie wartości, które parametry mogą przyjmować. Ten typ często też wymaga potem obsługiwania przez administratora, operatora, WAF-a, tak żeby false positives obsługiwać, bo często się niestety pojawiają. Ok, teraz przechodząc już do samego atakowania WAF-ów. Najpierw warto wiedzieć z jakim WAF-em mamy do czynienia, czyli tak zwany WAF fingerprinting. I tutaj, no jest to dosyć proste, ponieważ WAF bardzo dużo mówi o sobie. Przede wszystkim w jakiś sposób musi ustanawiać sesję z użytkownikiem i tą sesję ustanawia poprzez ciasteczka. Nazwy ciastek typu incapsation albo dodatkowe nagłówki. Tutaj mamy w prostce pokazane nagłówek incapsula, który mówi, że mamy do czynienia z WAF-em incapsula, czyli WAF-em imperwy w chmurze. Ta sama sytuacja, tylko mniej tych ciastek. WAF F5 moduł ASM. Ciastko jest zawsze w postaci TS i jakichś numerek. Oczywiście to jest konfigurowalne, natomiast rzadko kiedy ktoś zmienia nazwę tego ciastka, więc bardzo łatwo można w ten sposób rozpoznać, z jakim WAF-em mamy do czynienia. Również z samych ciastek, również komunikaty błędów, które zwraca WAF, jeżeli zapytanie zawiera payload, który chce zablokować ten WAF, no to zawiera po prostu swoje informacje typu nazwę produktu, bo często też te komunikaty nie są personalizowane pod aplikację. Również mamy narzędzia do wykrywania, takie gotowe, które klik and play, ściągamy, podajemy URL-a i dostajemy na koniec informację, jaki to WAF. Tutaj jest informacja, że to jest Imperwa. Innym narzędziem, które jest dostępne w dystrybucji Kali Linux, WAF-WUF. Ciekawa nazwa, wykrywa 30 typów różnych WAF-ów. No i tu też mamy przykład, że to jest WAF inkapsula. I teraz jak ominąć reguły WAF-a, które są zaimplementowane jako polityki. Są takie ogólne zasady, ja ich tutaj o nich opowiem, a potem przedstawię przykłady ich wykorzystania na przykładzie rzeczywistych pendestów. I tutaj mamy, pierwsza metoda to zmiana kodowania. I tutaj są różne podejścia, jednym z nich jest zastosowanie kodowania tak zwanego Overlong UTF, czyli przedstawiania parametrów, wartości parametrów na dwóch, trzech, czterech bajtach. Z reguły współczesne dekodery UTF-a wykrywają to i zgłaszają to jako błąd, natomiast no zdarza się jeszcze, że przejdzie to w aplikację, a WAF też tego nie zauważy. URL encoding, podwójny, potrójny też się sprawdza. Stosowanie HTML-em kipis. Czyli różne kodowanie w zależności od tego, w jakim kontekście wykonujemy dany payload. I drugim sposobem jest testowanie warunków brzegowych. Każdy WAF ma pewne, ustawione pewne limity, czy to na ilość parametrów, które obsługuje, czy na wielkość komunikatu po przekroczeniu którego limitu powinien zgłosić błąd i odrzucić to zapytanie. Chyba, że jest ustawione tak, że po prostu przepuszcza komunikaty, których nie jest w stanie obsłużyć. I tutaj teraz przedstawię ciekawy przypadek, gdzie właśnie taki błąd znaleźliśmy w WAFie i MPW-y. Ok, jak już mamy informację o tym, jaki to jest WAF, skorzystajmy z dobroci internetu i wiedzy, która jest tam publikowana. Czyli warto na początku zobaczyć, czy może są jakieś znane reguły o wejście danego WAF-a. Twitter jest ciekawym źródłem wiedzy, ponieważ dużo researcherów, bounty hunterów i osób, które zajmują się bezpieczeństwem, po prostu publikuje tam w postaci one-linerów tego typu informacje, które mogą być albo natchnieniem do naszego sposobu, który będziemy stosować w omijaniu, albo po prostu wprost wykorzystamy, możemy wykorzystać to, co jest publikowane. Tutaj mamy przykład obejścia Cloudflare i podatności XSS. Cloudflare bazuje w dużej części na mod-security, więc też powinien się sprawdzić w przypadku obejścia mod-security. Kolejny XSS w Cloudflare, tylko używamy taga svg. Tu z kolei SQL injection i przedstawienie funkcji sleep w dodatkowo zakodowany sposób. To, co wspominałem wcześniej, URL encoding tutaj właśnie jest w użyciu. Okej. Ostatni przykład obejściem od security XSS, również wykorzystanie taga svg. Także tutaj chodzi mi o to, żeby tylko powiedzieć, że warto korzystać z tej wiedzy, która jest publikowana. Ona jest bardzo często tutaj aktualizowana, więc myślę, że warto z tego korzystać. Kolejnym sposobem jest modyfikacja payloadu w zależności od kontekstu, w którym jest użyty. Mamy na przykład kontekst SQLa, czyli podatności SQL injection, gdzie standardowy payload SELECT apostrof 1 apostrof możemy przedstawić w postaci również wyrażenia SELECT, tylko zapisanego w dużymi i małymi literami oraz funkcji SQL CHR 41. 41 to jest kod ASCII cyfry 1, która w ten sam sposób, ale bez użycia apostrofów przedstawi dany payload. W kontekście SHELA możemy zapytanie czy komendę BIN-ka etc.passwd, która wyświetla zawartość pliku etc.passwd przedstawić przy użyciu tak zwanych wildcards, czyli znaków zapytania i gwiazdek. I w ten sposób słowa kluczowe, których szuka WAF, takich jak passwd, etc. czy polecenie cards, no nie są uwzględnione. Natomiast dla SHELA jest to tożsama komenda. Innym przykładem jest tutaj polecenie PING, które poprzez użycie konkatenacji i pojedynczych czy podwójnych cytrusłów też potrafi w ten sposób ominąć reguły WAF-a. Okej, tu mamy przykład taki bardzo prostego kodu napisanego w PHP. To są czynniki. Pierwsza nika to jest przypisanie parametru wejściowego do dominy CMD. Przekazanie tego łańcucha echo apostrof cmd i przekazanie do funkcji system, która wykonuje dany łańcuch w powłocie systemowej. Tutaj jest klasyczna podatność command injection. Pokrótce tylko wyjaśnię o co chodzi. Jeżeli przekazujemy parametr hello, to wykonywana jest funkcja system echo hello i po prostu wypiszemy na ekranie hello. Dodamy apostrof, średnik id, średnik apostrof, to oprócz tego, że nic nie zostanie wypisane, to wykona się polecenie cut etc. passwd, to polecenie, które umieścimy pomiędzy dwoma średnikami. I to jest klasyczny payload command injection. Natomiast jeżeli taką aplikację umieścimy za web application firewall, w tym przypadku mod security, no to niestety zostanie to wykryte i się nie wykona. Zostanie to zablokowane, czyli tutaj WAF spełni swoją rolę. Natomiast w bardzo łatwy sposób można to obejść. Tutaj pokażę jeszcze, jaka, która reguła WAFA została wzbudzona. Jest to remote command execution Linux command injection. Zapytanie zostało zablokowane. Natomiast przy zastosowaniu tylko dwóch znaków zapytania w poleceniu cut i etc. wystarczyło to, żeby obejść tego WAFA i tutaj wyświetlić zawartość etc. passwd. Niektóre WAFy mają również wyłączone polityki dotyczące normalizacji łańcuchów, czyli to, co wspomniałem wcześniej, można stosować podwójne, pojedyncze cudzysłowie w poleceniach. Tutaj na przykład takie polecenie cut można też wysłać do aplikacji i zostanie to potraktowane jako komenda, która jest zrozumiała, natomiast przez WAF może być niezrozumiała. W przypadku mocy Curifil niestety ta normalizacja, niestety dla atakującego, występuje i takie coś nie przejdzie, natomiast warto też to stosować. Inny przykład, to jest przykład również w PHP, natomiast wykorzystujemy kontekst samego PHP i ciekawostek, które można zastosować. Prosty przykład, parametr cmd jest przekazywany do polecenia eval. Polecenie eval wykonuje kod PHP, który jest zdefiniowany, przypisany do tego parametru cmd. I tutaj jest próba wykonania payloadu system w apostrofie id. To polecenie id powinno wyświetlić informację, jaki użytkownik jest, aktualnie wykonuje dane polecenie. No i po przypisaniu zmiennej id 1, 2, 3, 4 tego, tego payloadu system id dostajemy oczywiście komunikat forbidden, który wskazuje, że moc security znowu zadziałał. Tym razem reguła PHP injection, high risk PHP function call, czyli funkcja, która no jest ryzykowna, powinna być ogólnie wyłączona przy hardeningu, ale no tutaj jest włączona, ale WAF zadziałał. Natomiast ciekawy sposób obejścia jest taki, że możemy funkcje systemowe w PHP przedstawić w formie łańcuchów, czyli tutaj system id możemy przedstawić jako otwarcie nawiasu, łańcuch system, zamknięcie nawiasu i parametry również. A druga, drugi ciekawy feature w PHP jest to, że można wykonywać operacje logiczne and, or, xor na stringach. Czyli tutaj mamy na przykład string wth, można go przedstawić w postaci trzech różnych stringów, które są ze sobą sksorowane. Żaden z nich nie zawiera ani w, ani t, ani h i dzięki temu można ciekawe funkcje systemowe właśnie w ten sposób przedstawić. Czyli tak, system id możemy przedstawić jako trzy różne stringi. One są oczywiście specjalnie dobrane tak, żeby operacja xor t, xor j, xor m dała literkę małą s. To, to trzeba odpowiednio oczywiście sobie przygotować, ale widzimy, że jak przekażemy taki payload do funkcji eval, to zostanie, to moc jakiegoś zostanie pokonane i można w ten sposób bardzo łatwo ominąć wafa. Okej, teraz takie przykłady już oparte na komercyjnych rozwiązaniach. Tutaj jest podatność SQL injection, którą znaleźliśmy w jednej z aplikacji. Jeden z parametrów komunikatu JSON był podatny na blind SQL injection. Tu jest taki payload dosyć skomplikowany, który eksploituje to, czyli sprawdza, czy pierwsza litera baneru, czyli informacji o wersji bazy danych zawiera literę o. Jeśli tak, no to zapytanie się wykonywało odpowiednio dłużej. I taki payload został zablokowany przez Interweb. Tu jest informacja, że request unsuccessful, numer incydentu. Jak taki filtr w Interwebie można ominąć? Okazało się, że dosyć prosto. Pierwsza rzecz, którą sprawdziliśmy, zadziałała, czyli to, co wspomniałem wcześniej, usunięcie apostrofów, ale usunięcie apostrofów tylko z tej części, która była blisko wyrażenia select. Pozostałe mogły być używane. To jest tylko taki przykład, żeby pokazać, że często najprostszy sposób pokonuje nawet te najlepsze rozwiązania, które są uznane przez Gartnera za najbardziej pożądane. Inna podatność, czyli remote code execution. To jest podatność, którą znaleźliśmy w aplikacji napisanej w Javie. Widok czy stan aplikacji był zapisywany jako obiekt Javowy. Natomiast podatność była obecna z uwagi na to, że ten obiekt Javowy nie był odpowiednio zabezpieczony, tak? Czyli nie było ani sumy kontrolnej na końcu, gdzie siłka, która była sprawdzana, nie był szyfrowany. Można było spokojnie go podmienić na dowolną treść. Tak to już zrobiliśmy. Wygenerowaliśmy payload poprzez narzędzie YSO Serial, znany gadżet Commons Collections, który jest używany najczęściej w tego typu eksploatacjach. No i też każdy warstw posiada sygnaturę na niego, więc z reguły powinien go zablokować. I tak to już tutaj się stało, został zablokowany. Natomiast sposób obejścia był też ciekawy. Jak taki sposób ominąć? To, co tutaj próbowaliśmy zrobić, to na początku zmiana kodowania. Czasem się sprawdza, tutaj się nie sprawdziło. Zmiana gadżetu na taki, który nie ma sygnatury. No, próbowaliśmy wszystkie, które były publicznie dostępne. Kolejnym krokiem byłoby spróbowanie stworzyć własnego. No, oczywiście tutaj to jest to bardzo czasochłonne i kosztowne. Z reguły klient się na to nie decyduje. Natomiast to, co spróbowaliśmy, to zrobiliśmy mały stres test tego WAFA, czyli spróbowaliśmy właśnie zastosować te warunki brzegowe. Sprawdzić, czy po wysłaniu tysięcy parametrów, które każdy z nich zawierał payload, który musiał być przetworzony. Na przykład archiwum zip, które było kilkukrotnie spakowane. Chcieliśmy jakby spowodować, żeby ten WAFA się trochę zmęczył tym działaniem. No i zobaczyć, jak zareaguje. Jak się okazało, był to dosyć dobry sposób, ponieważ po dodaniu tylko tysiąca parametrów o losowych nazwach, czyli zwiększeniu komunikatu około 250 kilobajtów i umieszczeniu tego parametru, który zawierał nasz payload, taki komunikat został przepuszczony i nie został flagowany jako niebezpieczny. Co wydało nam się dosyć ciekawe. Błąd został zgłoszony do Impery i został już naprawiony w przypadku tego klienta i tej konfiguracji. Więc takie rzeczy się zdarzają również na dużych, bardzo istotnych aplikacjach i u dużych klientów. Tutaj taka demonstracja. Czyli mamy najpierw ten payload, który wstaliśmy i nasz parametr ten na samym końcu. Aplikacja zgłosiła błąd, bo tak z reguły to działa. Natomiast w tle wykonał się payload, który nam wykonał kod, który chcieliśmy. Innym przykładem są niestandardowe nagłówki. Tutaj mamy nagłówek, który ma nazwę authentication tylko po portugalsku i jak się okazuje, WAP był tak skonfigurowany, że oczywiście sprawdzał wszystkie nagłówki, które znał i wszystkie te, które uznał jako niestandardowe, czyli na przykład X i dowolna treść. Natomiast nagłówek authentication po portugalsku był wyłączony ze sprawdzenia przez WAF i wystarczyło prosty payload SQL injection wysłać. Oczywiście była tam też podatność, SQL injection bardzo trywialna i to spowodowało, że taki WAF został umiędzy. Czyli też trzeba zwracać uwagę na to, czy na pewno cały profil, wszystkie parametry wejściowe są pod kontrolą. Bo czasem może się okazać, że no niestety część jest wyłączona ze sprawdzenia. Jeszcze odnośnie kodowania. Wspomniałem o tym overlong UTF. Każdy znak w UTF-ie można przedstawić na dwóch, trzech, czterech i więcej bajtach. Ten sposób powinien być już niedostępny w najnowszych dekoderach UTF-a, natomiast no często się zdarza, że jeszcze to działa. Czyli na przykład apostrof możemy przedstawić za pomocą trzech znaków, trzech bajtów tutaj wskazanych. Cała lista tych znaków wrażliwych, które możemy tak przedstawiać wrażliwych z punktu widzenia atakującego jest więcej, więc jest cała lista. Jest to dostępne oczywiście w internecie, można sobie swobodnie korzystać. Tutaj mamy przykład, że wysłanie w PHP właśnie takich overlong UTF jest bez problemu interpretowane. Znak otwarcia nawiasu i wykrzyknik wysłany jako overlong UTF jest interpretowany w PHP, więc może być potencjalnie przemycony przez WAFA. Okej, co się stanie jeśli poprzez nasze testy zostaniemy zablokowani przez WAFA? Najprostszy sposób to oczywiście to, co wspomniałem wcześniej, jesteśmy identyfikowani przez ciastka, więc nie musimy panikować, że już WAFA nas zablokował po IP. Wystarczy wyczyścić ciasteczka, które identyfikują naszą sesję i to z reguły pomaga, żeby mieć, rozpocząć czystą historię jeśli chodzi o eksploatację WAFA. Okej, filtrowanie danych w aplikacji. Aplikacje często implementują walidację opartą na blacklisting i te same techniki co w przypadku omijania WAFA mogą być użyte do omijania filtrów wbudowanych w aplikację. I tutaj jest taki przykład. Aplikacja, która wysyła komunikat XML-owy do backendu, do serwera. Jeden z parametrów table alias powinien zawierać alias z tabeli, natomiast był podatny na strzyknięcie SQL injection. Tutaj widzimy gwiazdka, from, sys user, dolar i komentarz. To eksploatacja tej podatności pozwoliła na wyświetlenie właśnie tej tabeli. Zgłosiliśmy to oczywiście do application ownera. Aplikacja została naprawiona i dostaliśmy ją ponownie do testów. Natomiast nie zostało to zrobione w taki sposób jak powinno, czyli nie został redesign zrobiony tego, bo ta podatność występowała we wielu miejscach. Tylko dodałem jakiś filtr, który miał nas powstrzymać przed eksploatacją, który można było bardzo łatwo obejść poprzez właśnie techniki czysto wzięte z omijania WAFA, czyli zamiana wielkości liter, zamiana kluczowych znaków takich jak spacja na na przykład otwarcie, zamknięcie nawiasu, czy też zastąpienie spacji tabulatorem. Tutaj jeszcze dodatkowo należało go przedstawić w postaci HTML entity, czyli znak ASCII 9 przedstawiony jako HTML entity. I to wystarczyło, żeby też obejść ten filtr, który został zaimplementowany. Więc dosyć trywialny sposób, ale właśnie takie sposoby się sprawdzają w przypadku omijania WAFA. Jeśli chodzi o sposoby, z których można czerpać wiedzę o tym, jak omijać WAFA, bardzo fajne materiały są dostępne po konferencjach Black Hat, Offensive.com, materiały dostępne na stronach OWASPA. Bardzo polecam właśnie śledzić to, co się dzieje na bieżąco. Właśnie Twitter czy Reddit to są miejsca, na których jest bardzo dużo treści. Często może mało nieciekawej, więc trzeba sobie odfiltrować to, ale jak już się zna odpowiednich, ma się ten fit odpowiednio dostosowany, to ciekawe rzeczy można znaleźć. Tutaj właśnie przykład z OWASPA. W jaki sposób można przedstawić script alert 1 w postaci różnych modyfikacji encodingu. Tutaj mamy standardowy payload, potem dodane HTML entities, przedstawione jako, w postaci ur-encodingu i dodatkowo jeszcze wzbogacony jako znów HTML entities, więc takie modyfikacje payloadu powodują, że można w łatwy sposób ominąć te reguły, które są w WAFie. Ok. Pokrótce chciałem przedstawić, w jaki sposób można omijać WAF. To, co chciałem jakby podkreślić, to to, że WAF nie imityguje tych podatności, które wykryjemy, on tylko wprowadza dodatkowy koszt, dodatkowe utrudnienie dla atakującego, więc oczywiście warto implementować WAFy i to każdemu zalecamy, natomiast nie jest to zamknięcie obsługi danej podatności, należy ją po prostu potem faktycznie naprawić, bo w przeciwnym wypadku bardzo zdeterminowany atakujący będzie w stanie bez problemu ją wykorzystać. Także jeśli są jakieś pytania, to... Pytania? Ręka do góry, podejdę z mikrofonem. Jak nie ma z sali, to zastanawiajcie się, natomiast pytanie, używałeś Burba, widzieliśmy sporo screenów. Czy korzystasz z jakichś jeszcze innych automatów, z jakichś innych skryptów po to, żeby wykorzystać bardziej te podatności, szczególnie te duże, duże? Tak, tak jak najbardziej. Oczywiście używamy również narzędzi, które automatyzują naszą pracę. W przypadku SQL injection jest SQL map, który ma tak zwane skrypty tamper script, które zawierają część z tych technik, które to opowiedziałem, implementują po prostu to dodatkowe enkodowanie, filtrowanie, ominięcie filtrowania, więc warto też używać oczywiście tych narzędzi, które automatyzują, tylko trzeba oczywiście dobrze wiedzieć, czego my używajemy. Jeśli włączymy wszystkie skrypty SQL mapa naraz i nie ustawimy ich w odpowiedniej kolejności, no to z reguły skończy się to tym, że aplikacja po prostu nie zrozumie tego, co wysyłamy, więc trzeba robić to z głową. Krótkie pytanie, czy mechanizmy te, które pokazywałeś też powiedzmy działają powiedzmy na środowisku chmury, na przykład ażur? Na pewno, akurat jeśli chodzi o ażura, musiałbym dokładnie sprawdzić w konkretnym przypadku, natomiast to, co pokazywałem to są przykłady. To jest oczywiście, ponieważ mamy tutaj 30-40 minut, to jest tylko zajawka, żeby pokazać, że można to robić, natomiast na każdego WAF-a i na każdą aplikację, każdą podatność z reguły się dobiera dedykowane ominięcie tego, tej podatności czy tego, tego filtrowania, więc tak, z reguły każdy WAF, który nie jest zbudowany w oparciu o white listing, taki pełny, to da się po prostu go wykorzystać, ominąć. Cześć, a słyszałeś o takiej możliwości obejścia właśnie cloudowego WAF-a, gdzie szukamy sobie w historii domeny, jakie był IP serwer, a zanim tego WAF-a wprowadzili i się okazuje, że można bezpośrednio pominąć tego WAF-a, wbijając się na IP oryginalnego serwera. Tak, tak, jak najbardziej jest to klasyczny błąd, gdzie ten serwer, który jest w back-endzie jest dopuszczony do wszystkich, a nie tylko do klasy adresowej danego, danego prowajdera WAF-a czy na przykład klausler. Takie rzeczy często wykorzystujemy wtedy, kiedy na przykład aplikacja zdradza w jakiś sposób swój rzeczywisty IP. Więc jeżeli poznamy ten IP, to potem już nie skupiamy się na WAF-ie, nie omijamy go, tylko bezpośrednio uderzamy w ten serwer. Super Bartku, bardzo dziękujemy Ci, nie mamy już więcej pytań z sali. Brawa ogromne, dla Ciebie kalendarz. Dziękuję i zarówno tą techniczną, jak i tą wyjaśnieniem tej części związanej z Japonią. Ci, którzy jeszcze nie byli, to dobrze, żeby się wybrali.