MidpSSH - analiza bezpieczeństwa Bartłomiej Bonarski Paweł Brach Gabriel Kłosiński Piotr Mikulski 18 marca 2009
Spis treści 1. Wstęp 3 2. Identyfikacja stron procesu 4 2.0.1 Użytkownicy posiadające domyślne uprawnienia.......... 4 2.0.2 Użytkownicy o uprawnieniach administratora........... 4 2.0.3 Osoby dostarczające oprogramowanie................ 4 2.0.4 Potencjalni włamywacze....................... 4 3. Identyfikacja lokacji w procesie 5 4. Identyfikacja akcji w procesie 6 5. Identyfikacja urządzeń w procesie 7 6. Identyfikacja i określenie wartości cennych zasobów 8 7. Model atakującego 9 8. Określenie zagrożeń 12 9. Działania, które można podjąć celem podniesienia poziomu bezpieczeństwa 14 9.0.5 Zdobycie dostępu do komunikacji pomiędzy klientem a serwerem SSH.................................. 14 9.0.6 Zakłócenie komunikacji........................ 15 10.Określenie jak długo analiza jest aktualna 16 2
1. Wstęp Niniejszy dokument opisuje kwestie bezpieczeństwa dotyczące użycia klienta SSH na telefony komórkowe. 3
2. Identyfikacja stron procesu 2.0.1 Użytkownicy posiadające domyślne uprawnienia 1. Użytkownicy aplikacji SSH 2. Właściciel telefonu komórkowego 2.0.2 Użytkownicy o uprawnieniach administratora 1. Administrator sieci lokalnej 2. Administrator sieci komórkowej 3. Administrator serwera SSH 4. Administrator sieci bezprzewodowej 5. Osoby, które zdobyły prawa administratora 2.0.3 Osoby dostarczające oprogramowanie 1. Operator sieci komórkowej 2. Dostarczyciele oprogramowania MidpSSH 3. Twórca systemu operacyjnego zainstalowanego na telefonie 4. Twórca serwera SSH, do którego nawiązujemy połączenie 2.0.4 Potencjalni włamywacze 1. Osoby próbujące podsłuchać wysyłane i odbierane wiadomości 2. Osoby próbujące uzyskać informacje w sposób bezpośredni 3. Złośliwe oprogramowanie blokujące działanie sieci i systemu komputerowego 4
3. Identyfikacja lokacji w procesie 1. Każda lokacja, w której jest dostęp do sieci bezprzewodowej 2. Miejsce, w którym znajduje się serwer 3. Nadajniki/odbiorniki pośredniczące w transmisji danych 5
4. Identyfikacja akcji w procesie 1. Uruchomienie aplikacji 2. Modyfikacja ustawień programu 3. Nawiązywanie połączenie 4. Logowanie do systemu 5. Transmisja pakietów 6. Wylogowywanie z systemu 7. Zakończenie połączenia 8. Wyłączenie aplikacji 6
5. Identyfikacja urządzeń w procesie 1. Telefon komórkowy 2. Nadajniki/odbiorniki sieci komórkowej 3. Łącza telefonii komórkowej 4. Serwer SSH, z którym nawiązujemy połączenie 5. Dostarczyciel źródła zasilania do powyższych urządzeń 7
6. Identyfikacja i określenie wartości cennych zasobów 1. Kontakty telefonu komórkowego (średnio istotne) 2. Baza danych dokonywanych połączeń (między mało a średnio cenne) 3. Baza danych odbieranych i wysyłanych SMS-ów/MMS-ów (między średnio a bardzo cenne) 4. Informacje przechowywane na serwerze SSH (bardzo cenne) 5. Zbiór haseł używanych w naszej aplikacji (cenne) 6. Dane przesyłane przez naszą aplikację (cenne) 7. Numery kont bankowych/kart kredytowych oraz innych cennych informacji (bardzo cenne) 8
7. Model atakującego 1. Atakujący posiadający bezpośredni dostęp do telefonu komórkowego Złodziej Znalazca telefonu (osoba, która znalazła zagubiony/porzucony telefon) Osoba, która pożyczyła telefon od właściciela Współużytkownicy telefonu (np. mąż, żona, rodzeństwo, rodzina, znajomi) Pracownicy dokonujący przeglądu/naprawy/wymiany telefonu Podglądacz 2. Atakujący mający dostęp do sieci pomiędzy telefonem a serwerem Osoby próbujący podsłuchać transmisję danych sieci bezprzewodowej (za pomocą urządzeń zewnętrznych/poprzez bezpośredni dostęp do nadajników/odbiorników) Administratorzy nadajników/odbiorników sieci komórkowej Organy bezpieczeństwa (policja, CBŚ itp.) Administrator sieci lokalnej, w której działa serwer 3. Atakujący próbujący uzyskać zdalny dostęp do telefonu komórkowego Cyberterroryści próbujący włamać się do telefonu i uzyskać cenne informacje Osoby próbujące uniemożliwić lub ograniczyć działanie telefonu Osoby próbujące uzyskać dostęp korzystając z luk w oprogramowaniu, błędów w protokołach itp. Złośliwe oprogramowanie Robaki Trojany Wirusy 4. Atakujący mający zdalny dostęp do telefonu komórkowego Osoby próbujące zainstalować podsłuch w telefonie lub inne oprogramowanie szpiegowskie 9
7. Model atakującego Osoby próbujące wykorzystać telefon do swoich potrzeb Obciążanie kosztami cudzych rozmów Wykonywanie innych płatnych usług na koszt właściciela (np. doładowanie telefonu, wysyłanie płatnych SMS-ów itp.) Osoby wykorzystujące telefon użytkownika do wykonywania różnego rodzaju ataków, włamań itp. Osoby próbujące uzyskać informacje przechowywane na telefonie komórkowym i serwerze SSH Osoby próbujące uzyskać dostęp do serwera SSH, z którymi możemy się połączyć 5. Atakujący, który wcześniej posiadał bezpośredni dostęp do urządzenia Osoba, która była poprzednim właścicielem Osoba, która miała bezpośredni dostęp przez krótki czas (znalazca, ktoś, komu chcemy się pochwalić telefonem, użyczyć itp.) Właściciel i sprzedawcy telefonu w sklepie Właściciel i pracownicy hurtowni Właściciel i pracownicy operatora sieci komórkowej Właściciel i pracownicy firmy produkującej telefony oraz podzespoły Właściciel i pracownicy projektujący telefony Osoby zajmujące się transportem i składowaniem telefonów 6. Atakujący mający dostęp do serwera Administrator serwera Zwykli użytkownicy serwera (w tym użytkownicy mający dostęp do naszego oprogramowania) Osoby nieuprawnione mające dostęp do serwera (np. osoby, które uzyskały dostęp do serwera SSH w wyniku włamania) 7. Twórcy oprogramowania mającego wpływ na działanie systemu Twórcy MidpSSH Twórcy firmware Twórcy systemu, na którym jest postawiony serwer SSH Twórcy systemu, na którym działa telefon komórkowy Twórcy systemu obsługujący transmisję danych, protokołów komunikacyjnych 8. Osoby próbujące dokonywać nieautoryzowanych zmian w kodzie źródłowym 10
7. Model atakującego Prowadzący przedmiot Twórcy Administrator serwera SVN Inne osoby, które uzyskały dostęp do serwera SVN 11
8. Określenie zagrożeń 1. Atak typu DOS / DDOS Atakujący za pomocą wielu komputerów połączonych w sieci może doprowadzić do zablokowania usług serwera SSH poprzez masowe wysyłanie pakietów. Napastnik wysyła fałszywe żądania skorzystania z usług do serwera co może spowodować wyczerpanie zasobów tj. pamięć, czas procesora, pasmo sieciowe. Efektem takiego ataku może być przerwa w działaniu serwera, bądź nawet zawieszenie systemu operacyjnego. 2. Ataki Man-in-the-middle a) Atakujący tworzy serwer pośredniczący pomiędzy klientem a serwerem. Metoda ta polega na modyfikacji wiadomości przesyłanych pomiędzy dwiema stronami bez ich wiedzy. Scenariusz takiego ataku może wyglądać następująco: - K (Klient) próbuje się połączyć z S (Serwerem), A (Atakujący) przekierowuje ruch sieciowy z komputera K do S na własny serwer - K przekazuje swój klucz publiczny do A - A łączy się z S używając własnego klucza publicznego i pobiera klucz publiczny od S - K szyfruje wiadomość używając klucza publicznego A, A dekoduje wiadomość używając własnego klucza, A używa klucza publicznego S, szyfruje wiadomość i wysyła ją do S W skutek tego działania atakujący może: - podejrzeć dane (pakiety) - zmodyfikować pakiety - wysłać nowe pakiety b) Atakujący tworzy fałszywy serwer, z którym będzie się łączył klient. Może tego dokonać poprzez podmianę serwera DNS. Po zalogowaniu klienta na fałszywy serwer, atakujący przejmuje login, hasło oraz kończy sesję. 3. Podmiana aplikacji MidpSSH-JIF Atakujący mający fizyczny dostęp do urządzenia, na którym zainstalowana jest aplikacja MidpSSH-JIF może ją podmienić. Wówczas osoba korzystająca z aplikacji nie będzie miała kontroli nad jej działaniem. 4. Social engineering Można użyć technik inżynierii społecznej, np. podszywając się pod inną osobę, by 12
wyłudzić cenne informacje. 8. Określenie zagrożeń 5. Atak Brute Force Poprzez użycie ataku siłowego, który opiera się na sukcesywnym sprawdzaniu wszystkim możliwych haseł, atakujący może uzyskać dostęp do serwera i monitorować użytkownika posługującego się tym hasłem. 6. Przechwytywanie hasła a) Analiza ruchu Atakujący podsłuchuje transmisje z serwerem i uzyskuje informacje o długości hasła poprzez zliczanie pakietów. Dzięki temu dostaje informacje o tym czy atak Brute Force ma szanse się powieść. b) Kompromitacja serwera Atakujący może wykorzystać luki serwera SSH i uzyskać do niego dostęp. 7. Zakłócenia autentyczności komunikacji Atakujący może zakłócić komunikację między klientem a serwerem, w skutek czego klient nie będzie mógł się połączyć z serwerem. Napastnik może również poprzez ingerencje w konfiguracje serwera SSH zmienić parametry transmisji danych np. na nieszyfrowane. 13
9. Działania, które można podjąć celem podniesienia poziomu bezpieczeństwa 9.0.5 Zdobycie dostępu do komunikacji pomiędzy klientem a serwerem SSH Każdy hipotetyczny atak polegający na przechwyceniu komunikacji pomiędzy klientem a serwerem może mieć na celu zdobycie cennych danych przechowywanych w telefonie komórkowym (serwerze SSH). Aby udaremnić/utrudnić dostęp do cennych dla użytkownika informacji, można wykorzystać narzędzie Jif (Java information flow). Pozwoli to na zdefiniowanie poziomów bezpieczeństwa dla wszystkich obiektów składających się na aplikację MIDPSSH-JIF. Wówczas dostęp do obiektu z poziomu o wyższym priorytecie będzie niemożliwy. Próba odczytu wszystkich niezaszyfrowanych danych przechowywanych w pamięci podczas komunikacji z serwerem będzie niedozwolona. To zapobiegnie wykradaniu cennych informacji. Zastosowanie Jifa jest nietrywialne z uwagi na ograniczenia, jakie nakłada standard Jifa. W chwili obecnej Jif nie wspiera takich mechanizmów języka Java jak: wątki klasy zagnieżdżone bloki inicjalizacyjne Wymusza to od programisty gruntowną modyfikację kodu w celu przystosowania go do zastosowania narzędzia Jif. W praktyce może się okazać, że ewentualna modyfikacja będzie wymagała większego nakładu pracy niż pierwotna implementacja MIDPSSH. Jedynym atakiem, któremu nie da się całkowicie zapobiec, jest podmiana samej aplikacji MIDPSSH-JIF. Jednym ze sposobów zabezpieczenia się przed tym atakiem jest podpisanie pakietu jar kluczem prywatnym dostawcy aplikacji. Niestety, podpis jest sprawdzany wyłącznie podczas instalacji aplikacji na telefonie komórkowym i nie jest weryfikowany później. Stanowi to potencjalną lukę w bezpieczeństwie, której nie da się w łatwy sposób zniwelować. 14
9. Działania, które można podjąć celem podniesienia poziomu bezpieczeństwa 9.0.6 Zakłócenie komunikacji Atakujący może próbować zakłócać proces uwierzytelniania z serwerem. Wówczas użytkownik nie będzie mógł uzyskać połączenia z serwerem. Niestety, nie da się wyeliminować tego typu ataku na poziomie implementacyjnym MIDPSSH-JIF. Innym sposobem ataku jest ingerencja w konfigurację serwera SSH. Wszystkie tego typu luki bezpieczeństwa powinny zostać wyeliminowane przez administratora udostępniającego usługę. Można próbować zminimalizować powyższe zagrożenia poprzez wprowadzenie ograniczenia na czas procesu negocjacji parametrów sesji. 15
10. Określenie jak długo analiza jest aktualna Analiza bezpieczeństwa jest aktualna przez trzy miesiące z uwagi na dynamicznie rozwijające się technologie. Nowe urządzenia mobilne dostępne na rynku mogą posiadać inne luki bezpieczeństwa, które nie zostały uwzględnione w powyższej analizie. 16