Analiza bezpieczeństwa

Transkrypt

1 Manager sekretów Analiza bezpieczeństwa Szymon Doroz Piotr Świgoń Tomasz Turski Przemysław Zych studenci Wydziału Matematyki, Informatyki i Mechaniki Uniwersytetu Warszawskiego Pisanie bezpiecznych programów w Javie 2008/09 16 marca

2 Spis treści 1 Wprowadzenie Cel Zakres Definicja zagadnienia Metodyka Definicje i skróty Identyfikacja stron procesu Użytkownik programu Dostarczyciel oprogramowania Konserwujący system Potencjalny atakujący Identyfikacja lokacji w procesie Mieszkanie prywatne Budynek - miejsce pracy Komputer przenośny Identyfikacja akcji w procesie 5 5 Identyfikacja i określenie wartości cennych zasobów Identyfikacja chronionych zasobów Określenie wartości zidentyfikowanych zasobów Zagrożenia i analiza zachowania komponentów oprogramowania Przekroczenie bufora (Buffer overruns) Napisy formatujące (Format strings) Przekroczenie zakresu liczb (Integer overflows) Wstawienie SQL-a (SQL injections) Wstawienie polecenia (Command injections) Brak obsługi błędów (Failing to handle errors) Używanie słabych systemów opartych na haśle (Use of weak password-based systems) Brak bezpiecznego zapisu i zabezpieczenia danych (Failing to Store and Protect Data Securely) Wyciek informacji (Information leakage) Wyścigi (Race conditions) Silne generatory liczb losowych (Cryptographically strong random numbers) Kiepska funkcjonalność (Poor usability) Zagrożenia sieciowe Drzewo ataku 10 2

3 8 Długość ważności analizy 11 3

4 1 Wprowadzenie 1.1 Cel Celem tego dokumentu jest przeanalizowanie bezpieczeństwa projektowanej aplikacji oraz identyfikacja i ocena potencjalnych ryzyk z nim związanych. Poniższy dokument ma zapewnić kompletność i spójność polityki bezpieczeństwa zastosowanej w przygotowywanej aplikacji. Wnioski w nim zawarte będą ramowymi wytycznymi dla zapewnienia jakości procesu kodowania. 1.2 Zakres Dokument składa się z następujących części: identyfikacja stron procesu, identyfikacja lokacji w procesie, identyfikacja akcji w procesie, identyfikacja i określenie wartości cennych zasobów, określenie zagrożeń i analiza zachowania komponentów oprogramowania, drzewo ataku określenie terminu ważności analizy. 1.3 Definicja zagadnienia Analiza dotyczy wolno stojącego programu z GUI, który będzie menadżerem sekretów (hasła, klucze, numery konta bankowego itp.). Aplikacja będzie przechowywała dane w formie struktury plików i katalogów, będą one zapisywane w formacie szyfrowanych plików xml. Pliki programu nie będą zawierały żadnej formy zapisu hasła, będzie ono jedynie przechowywane w czasie pracy programu. Hasło będzie wykorzystywane jako klucz w symetrycznym algorytmie szyfrowania zabezpieczanych danych. Do szyfrowania wykorzystana zostanie biblioteka JCA. 1.4 Metodyka Analiza bezpieczeństwa została wykonana w oparciu o wytyczne zawarte w materiałach definiujących metodę i zakres przeprowadzania analiz, dostępnych pod adresem: alx/secjava/index.php. 4

5 1.5 Definicje i skróty GUI - Graphical User Interface (Interfejs graficzny użytkownika), JCA - Java Cryptography Architecture, JVM - Java Virtual Machine, Key Logger - urządzenie lub program służący do zapamiętywania wprowadzanych przez użytkownika znaków, Swing - biblioteka graficzna używana w języku programowania Java, VFS - Virtual File System. 2 Identyfikacja stron procesu 2.1 Użytkownik programu Prowadzący zajęcia oraz zwykli użytkownicy programu, który będą wykorzystywać go do codziennych zastosowań. Nie przyjmuje się żadnych założeń odnośnie wiedzy i umiejętności zwykłego użytkownika programu. Użytkownik będzie posiadał stały dostęp do programu, jego danych oraz maszyny na, której jest on uruchamiany 2.2 Dostarczyciel oprogramowania Strona związana z analizą zagadnienia, zaprojektowaniem i implementacją aplikacji - zespół projektu, składający się z czterech osób. 2.3 Konserwujący system Osoba odpowiedzialna za codzienną konserwację i administrowanie systemem, na którym zainstalowana będzie aplikacja Manager sekretów. Administrator systemu będzie posiadał pełny dostęp do programu, jego danych oraz maszyny, na której jest on uruchamiany. 2.4 Potencjalny atakujący Osoba trzecia, próbująca uzyskać nieautoryzowany dostęp do ukrytych danych. Zakłada się, że osoba atakująca może dysponować najlepszą dostępną wiedzą odnośnie zabezpieczeń użytych w projektowanym oprogramowaniu. 5

6 Atakujący może uzyskać dostęp do systemu użytkownika poprzez atak sieciowy, uzyskanie nieuprawnionego fizycznego dostępu do maszyny lub nośników danych. 3 Identyfikacja lokacji w procesie 3.1 Mieszkanie prywatne System może być używany przez osoby prywatne w miejscu ich zamieszkania. Dostęp do komputera w takim przypadku jest względnie dobrze chroniony. 3.2 Budynek - miejsce pracy System może być używana przez pracowników firm prywatnych oraz instytucji publicznych. W takim przypadku dostęp do komputera posiada znaczenie więcej osób, choć zależy również od polityki bezpieczeństwa stosowanej w budynku (pomieszczenia zamknięte na klucz, dostęp do pomieszczeń firmowych dla osób trzecich itp.). 3.3 Komputer przenośny Używanie systemu na komputerze przenośnym nie determinuje lokacji. W związku z tym utrudnione jest zabezpieczenie systemu przez zabezpieczenie lokacji uzytkowania systemu. 4 Identyfikacja akcji w procesie Aplikacja będzie pozwalała na przeprowadzenie następujących akcji: Zakładanie plików tekstowych w VFS Zakładanie katalogów w VFS Zmiana nazwy pliku lub katalogu Zmiana hasła dostępu do katalogu Przeglądanie zawartości plików i katalogów Zmiana zawartości plików tekstowych 5 Identyfikacja i określenie wartości cennych zasobów 5.1 Identyfikacja chronionych zasobów Celem projektu jest ochrona poufnych danych przed nieautoryzowanymi użytkownikami, stąd też podstawowymi zasobami chronionymi przez system będą te właśnie dane. Trzeba 6

7 mimo to mieć świadomość pojawienia się również drugiego typu zasobów, czyli haseł używanych do szyfrowania danych. 5.2 Określenie wartości zidentyfikowanych zasobów W powyższym podpunkcie zidentyfikowaliśmy dwa rodzaje zasobów, wobec których należy prowadzić skuteczną politykę bezpieczeństwa: zasoby właściwe (pliki chronione przez system), hasła użyte do szyfrowania zasobów, Pracując nad projektem należy mieć świadomość że poznanie hasła chroniącego dane przez osobę niepożądaną, może prowadzić nie tylko do wycieku informacji i zasobów chronionych przez stworzony system, ale również do istotnego zmniejszenia bezpieczeństwa związanego z danymi niebezpośrednio chronionymi. Może się tak wydarzyć w związku z zjawiskiem używania wielokrotnie przez użytkownika jednego hasła do ochrony wielu zasobów, jak również zasób właściwy chroniony przez nasz system, może być hasłem dostępu do zasobów zewnętrznych. Mając świadomość tych zjawisk, należy pamiętać o skutecznej polityce bezpieczeństwa względem haseł używanych w systemie. 6 Zagrożenia i analiza zachowania komponentów oprogramowania 6.1 Przekroczenie bufora (Buffer overruns) Projekt będzie realizowany w język, Java, w którym niebezpieczeństwa w przypadku przekroczenia bufora jest minimalne. W przypadku próby zapisu w niedozwolonym miejscu w buforze zostanie podniesiony wyjątek, ale nie dojdzie do nadpisania żadnych informacji, a tym bardziej uruchomienia niebezpiecznego kodu. 6.2 Napisy formatujące (Format strings) W projekcie nie przewidujemy funkcjonalności podawania przez użytkownika napisów formatujących. Ponadto wszystkie napisy formatujące będą stałymi napisami przez co błędne listy argumentów do funkcji formatujących napisy zwrócą wyjątki przy pierwszym użyciu, dzięki czemu prawdopodobieństwo wystąpienia nieoczekiwanego błędu tego typu jest znikome. 6.3 Przekroczenie zakresu liczb (Integer overflows) Wszystkie informacje podawane przez użytkownika będą traktowane jako tekst i nie będą w żaden sposób interpretowane przez co ryzyko wystąpienia błędu przekroczenia zakresu liczb będzie niewielkie. 7

8 6.4 Wstawienie SQL-a (SQL injections) W projekcie nie planujemy korzystania z bazy danych dzięki czemu unikamy niebezpieczeństw związanych z wstawieniem SQL-a. 6.5 Wstawienie polecenia (Command injections) Projekt będzie zrealizowany jako pojedynczy plik wykonywalny, nie korzystający z zewnętrznych narzędzi uruchamianych z polecenia. Także, projekt nie będzie korzystal z żadnego interpretera poleceń więc zagrożenie wstawiania polecenia nie występuje. 6.6 Brak obsługi błędów (Failing to handle errors) W związku z oparciem systemu o technologię Java, z konieczności musimy obsługiwać wszelkie wyjątki deklarowane (ang. checked exeptions). Jednakże z punktu widzenia bezpieczeństwa, każdy wyjątek (także RuntimeException) stanowi zagrożenie i w szczególności nie można kontynuować pracy z systemem po napotkaniu takowego. W systemie, zostanie zaimplementowana metoda sprzątająca, która zamaże ślad w pamięci po wrażliwych danych. Taka funkcja zostanie wywołana przy kończeniu pracy i po przechwyceniu dowolnego wyjątku (po czym i tak nastąpi terminacja programu). 6.7 Używanie słabych systemów opartych na haśle (Use of weak password-based systems) W celu zniwelowania zagrożenia przechwycenia hasła w projekcie zostną zastosowane następujące mechanizmy: Podczas wpisywania hasła pole tekstowe będzie wypełniane losową ilością gwiazdek uniemożliwiając w ten sposób odgadniecię długości hasła Hasła krótsze niż 8 znaków nie będą akceptowane przez system W przypadku podejrzenia, że w systemie znajduje się programowy lub sprzętowy keylogger użytkownik będzie mógł użyć klawiatury ekranowej Hasła nigdy nie będą przechowywane po wyłączeniu aplikacji Hasła nigdy nie będą przechowywane w spójnym obszarze pamięci 6.8 Brak bezpiecznego zapisu i zabezpieczenia danych (Failing to Store and Protect Data Securely) Do zapisu i zabezpieczenia danych zostaną zastosowane następujące mechanizmy: 8

9 Hasło w pamięci będzie przechowywane w specjalnej strukturze zapewniającej możliwość zamazania po użyciu Hasło w pamięci będzie przechowywane w specjalnej strukturze zapewniającej rozrzucenie kolejnych znaków hasła w pamięci Hasła będą wyrzucane z pamięci kiedy nie będą już używane przez program Hasła nigdy nie będą przechowywane po wyjściu z programu Przechowywane sekrety użytkownika będą zapisywane na dysku w postaci zaszyfrowanej 128-bitowym kluczem 6.9 Wyciek informacji (Information leakage) Ze względu na szyfrowanie przechowywanych plików, do wycieku informacji mogłoby dojść w sytuacji złamania szyfru, co przy uwzględnieniu, tego że klucz jest 128-bitowy, jest mało prawdopodobne Wyścigi (Race conditions) Pomimo tego, że system będzie korzystał z 2 wątków, nie wystąpi problem Race conditions. Wynika to z samej natury owych wątków - 1 właściwy (ang. worker thread) oraz jeden wątek do odśmieacania (w którym w odstępie czasu będzie wykonywany System.gc() ) 6.11 Silne generatory liczb losowych (Cryptographically strong random numbers) Wszędzie tam, gdzie będzie potrzebne skorzystanie z liczb losowych, użyty zostanie generator z biblioteki JCA. Aplikacja nie będzie się opierała w istotny sposób na losowości, nie uważamy zatem tego zagrożenia za łatwe do zmaterializowania Kiepska funkcjonalność (Poor usability) Główny celem systemu jest przechowywanie poufnych danych, poza tym aplikacja nie będzie udostępniała innych usług. Rozwiązuje to problem kiepskiej funkcjonalności - wszak przechowywanie haseł jest głównym i w zasadzie jedynym powodem, dla którego ktoś mógły chcieć używać tej aplikacji Zagrożenia sieciowe Ze względu na niesieciowy charakter aplikacji poniższe zagrożenia nie występują w opisywanym projekcie: 9

10 Skrypty wieloserwerowe (Cross-site sripting) Brak zabezpieczenia ruchu sieciowego (Failing to protect network traffic) Używanie magicznych URL-i i niewidocznych pól w formularzach (Use of magic URLs and hidden form fields) Nieodpowiednie użycie SSL i TLS (Improper use of SSL and TLS) Ufanie DNS-owi (Trusting DNS) Nieautentyfikowana wymiana kluczy (Unauthenticated key exchange) 10

11 7 Drzewo ataku Rysunek 1: Processes Diagram 11

12 8 Długość ważności analizy Najistotniejszym elementem, mającym negatywny wpływ na bezpieczeństwo systemu, będzie możliwość złamania kluczy symetrycznych, którym szyfrowane będą katalogi. Projekt będzie używał Java Cryptography Architecture, który dostacza standardowo szyfrowania 128-bitowego. Obecnie, 128-bitowy klucz, przy założeniu wzrostu wydajności zgodnie z prawem Moora i nie dokonaniu się rewolucji w kryptografii, wydaje się wystarczający na co najmniej 10 lat. Podany okres nie wydaje się dużym ograniczeniem, gdyż typowo oprogramowanie dla użytkowników końcowych, wymieniane jest znacznie częściej (np. system operacyjny), więc w szczególności aktualizacja oprogramowania do przechowywania danych poufnych, nie powinna stanowić problemu. Opieranie się na standardowej, powszechnej technologii do szyfrowania, daje nadzieję na to, że wszelkie błędy zostają w miarę szybko wykrywane i poprawki będą dołączane do koleknych dystrybucji Javy. Z punktu widzenia tworzonego systemu, silnie rekomendujemy używanie zawsze najnowszej JVM. 12