Implementacja cyfrowych podpisow dla binariow i bibliotek :-#

[TQM]

Hej!

Jako ze ten dzial to "Wdrażanie i optymalizacja zabezpieczeń" (przynajmniej wg opisu) dlatego pisze tutaj a nie gdzies indizej

Ostatnio kombinuje z implementacja czegos co pozowliloby mi na takie ustawienie systemu (na razie tylko Linux), aby mozna bylo uruchomic tylko binarki i biblioteki ktore maja odpowiedni podpis cyfrowy.

Chodzi o to aby system w trakcie pracy sprawdzal kazda biblioteke i program ktory uruchamia (lub probuje uruchomic) i jesli nie zostal podpisany odpowiednim kluczem to program/biblioteka sie nie uruchomi. Szukalem w google - znalazlem kilka przydatnych informacji i jeden projekt ktory to realizuje. Niektore informacje na serwerach BOINC byly tez bardzo przydatne ale jednak jest to za malo jak dla mnie.

Oto pytania ktore sobie stawiam i na ktore szukam odpowiedzi:
1. Jakie gotowe narzedzie mozna do tego zaprzac na warstwie kernela (a moze sprzetu?) itd - co jest w tej chwili dostepne?
2. Jakie sa zagrozenia ze jednak ktos to obejdzie (np. jesli sprawdzanie sygnatur bedzie przez modul jadra to teoretycznie jest mozliwosc obejscia mechanizmu)?
3. Zakladajac ze mam caly system dzialajacy, jak wygladalaby aktualizacja softu na takim systmeie (albo inaczej - jak bardzo bolesna bedzie taka operacja - i nie mowcie "bardzo" bo to juz wiem hehe)?

To tak na poczatek - moze ktos sie z tym zetknal... Generalnie sama filozofia czy tez pomysl nie jest nowy. Uzywa tego np wojsko jednego z panstw w europie i to na dodatek pod Windows (!!!) - z tym, ze maja specjalnie skonstruowane plyty glowne, gdzie za weryfikacje podpisow odpowiada osobny uklad na plycie, ktory nie pozwoli aby procesor wykonal kod ktory nie ma waznego podpisu cyfrowego. W ten sposob ktokolwiek wlezie do systemu, chocby i wgral lub nawet skompilowal rootkit'a albo cokolwiek inne, to i tak tego nie odpali... jak to wyglada w rozwiazaniu software'owym - nie wiem...

Jesli ceny nie sa jakies astronomiczne dla takiego sprzetu (moze jakas karta PCI ktora to realizuje) to bylbym nawet w stanie kupic takie cos... Generalnie szukam informacji - nawet zaslyszanych opowiastek, linkow, itd... moze podsunie mi to jakis pomysl.

Ktokolwiek ?

[dexter]

Po pierwsze też szukałem czegoś podobnego dla linucha, tylko trochę w innym kontekście. Osobiście interesowałem się czy istnieje na linuxa odpowiednik windowsowych firewalli typu BlackIce PC / Server Protection (moduł Application Protection, ktory jest częścią pakietu robi dokładnie to czego szukasz), szukałem chociaż odpowiednika funkcjonalności Sygate Personal Firewall, który aplikację łączące się gdziekolwiek poddaje weryfikacji MD5.

Niestety nie udało mi się znaleźć nic, co by mogło sprawować powyższe funkcje w linuxie.

Wydaje mi się, że w celu zabezpieczenia modyfikacji binarek, trzeba będzie je mount ro , i najlepiej, żeby leciały z nośnika z fizycznym brakiem możliwości zapisu.

Edit: przyszła mi do głowy jeszcze jedna możliwość, zakładając, że mamy do czynienia z serwerem, ruchome części (logi itp.) leżą gdzieś na zewnątrz, to można użyć czegoś takiego
http://allegro.pl/item217673078_najl..._v12_0_pl.html
Chociaż podpis cyfrowy to to nie jest, i z tego co kojarzę to ma pewne ograniczenia (poprzednie wersje miały problemy z dyskami SCSI)

[TQM]

Możesz zainstalować, ustawiać parametry i nadal używać dużych aplikacji lub gier bez różnicy. współpracuje z systemami operacyjnymi Windows9x/ME/NT/2000/XP/2003 i formatem plików typu FAT16/32/NTFS

Czyli lipa... windows only :-/

Co prawda rozpracowalem metode aktualizacji softu - zasada jest prosta - kernel musi sprawdzac poprawnosc podpisow sam - inaczej lipa... Najlepiej aby bylo to wkompilowane w kernel - cos jak TPE (Trusted Path Execution) ale idace o krok dalej Do aktualizacji calosc softu kompilujesz i pakujesz w pakiety albo rozpakowujesz, podpisujesz i ponownie pakujesz - na osobnej maszynie, odlaczonej od sieci, ktora sluzy TYLKO do tego celu. Mozesz nawet pokusic sie o ustawienia swojego wlasnego repo i np jesli pracujesz na Debianie albo czymkolwiek innym co ma pakiety, tworzysz wlasny serwer do apt-get

Tam wrzucasz podpisane pakiety i system moze sie aktualizowac. Jest z tym sporo pracy, bo pamietaj, ze zanim podpiszesz pakiet i uwolnisz go do serwerow produkcyjnych, musi on przejsc przez testy... a na to trzeba czasu!

Nie jest to takie proste... poza tym sprawdzanie MD5 pod windows to taka lekko sliska sprawa - mam gdzies fajna prezentacje o wywolywaniu kolizji MD5 i okazuje sie ze nie jest to az tak trudne jak sie wydaje :P
Dlatego ja podaje wszedzie MD5 i SHA1 aktualnie - SHA1 nie oszukasz tak jak MD5, bo nawet jesli suma MD5 sie zgadza to mogla zostac wyliczona dla 2 roznych ciagow (!!!) a SHA1 bedzie juz dla nich rozne.

[dexter]

O tym, że w MD5 można wywołać kolizję to wiem, jednak nie martwi mnie to aż tak bardzo, ponieważ uważam, że utworzenie zmodyfikowanego działającego exe-ca, o sumie identycznej jak oryginalny exe jest wg. mnie naprawdę mało prawdopodobne, i już szybciej spodziewałbym się ataku bezpośrednio w firewall.

Odnośnie zastosowania TPE i podpisywania własnoręcznie repozytoriów. Widzę w tym kilka słabych punktów:
1. kto miałby dokonywać audytów (komu firma by na tyle wierzyła)
2. audyty kosztują, a pakiety aktualizują się stosunkowo często
3. nie prościej by było umieścić środowisko robocze wewnątrz GSX Server, ma hoście nie uruchamiać ŻADNYCH daemonów, przecież inwestując fragment budżetu potrzebnego na uruchomienie wspomnianych przez ciebie audytów, które jak sam napisałeś zabierają czas, można stworzyć w miarę (podkreślam - W MIARĘ ) bezpieczny system. Na hosta można użyć grsec czy selinux, roboczy system to plik ładowalny do GSX, a obszar zapisu, czyli logi i pliki userów na oddzielny dysk, który nie jest podmontowany na hoście. W ten sposób otrzymujesz środowisko, które możesz podnieść w zasadzie natychmiast (skrypcik sobie można machnąć do tego). Bezpieczeństwo też jest niezłe, ale to w sumie nie czas i miejsce na wykład o security through virtualization (i tak pewnie nie napisałbym czegoś czego sam już nie wiesz )


W ramach podsumowania mojego elaboratu chciałem tylko napisać, że podczas mojej krótkiej przygody z linuxem nie udało mi się znaleźć rzeczy tak wydawałoby się banalnej jak weryfikacja sum kontrolnych odpalanych bibliotek i programów, co szczerze mówiąc zastanawia mnie głęboko. Podany przezemnie punkt 3, jest wg. mnie najbliższy cyfrowemu terminatorowi , nawet jeśli go coś przewróci to momentalnie wstaje i idzie dalej.

P.S. nie lubie debiana, i pochodnych ;p

[TQM]

Widzisz dexter - troszke inaczej rozumiemy system docelowy. Ja potrzebuje taka funkcjonalnosc dla prawde mowiac jednego clustra HA zlozonego z identycznych maszyn. Zalozenie jest takie, ze system raz postawiony nie bedzie modyfikowany czesciej niz raz na rok jesli w ogole, poniewaz i tak bedzie tak gleboko w strukturze ze dotarcie do niego bedzie praktycznie niemozliwe, tym bardziej ze kazde wejscie/wyjscie danych bedzie podpisywane cyfrowo wiec ataki na aplikacje (custom code) mijaja sie z celem.

System ma byc stabilny... raz doprowadzony do tego punktu przez dluuuugi czas nie bedzie zadnych aktualizacji - mozliwe ze nawet do czasu wycofania systemu z uzytku (przewidywany czas to 4-5 lat). Aktualizacje nie beda wiec tak wielkim problemem - co zalatwia punkty 1 i 2.

Odnosnie wirtualizacji - zastanawialem sie nawet nad czyms w rodzaju Xen'a na clustrze fizycznych maszyn (albo np taki Blade), do tego swiatlowodowy NAS (ktory i tak juz mam na wyposazeniu) i wtedy mozna by podnosci takie serwery jako wirtualki - problem tylko w tym, ze nie ufam bezpieczenstwu director'a. Jesli udaloby sie jakims cudem komus przejsc przez te wszystkie warstwy i dotrzec do serwera w sensie wejsc do tej samej sieci, to boje sie ze byloby to najslabsze ogniwo calego systemu (kontroler platformy wirtualizacji, jakakolwiek ona nie jest).

Wyobraz sobie teraz rootkit dzialajacy w kontrolerze, wtedy jest on ponad kazdym systemem wirtualnym i do tego zachowuje sie jak kernel-mode sniffing rootkit. Niezla zabawka - nie ma mowy o tym by go wykryc z systemu goscia! Sprawa z GSX ma sie identycznie (a nawet jeszcze gorzej moim zdaniem).

Wyglada na to ze chyba utknalem

Jesli masz jeszcze jakies pomysly to wal smialo... kazdy punkt zaczepienia jest dobry!

[dexter]

(szybkie przemyślenie przed wyjściem do pracy )

Czy nie uważasz, że w sytuacji, w której atakujący pokona hypervisor-a , to będzie działać najwyżej z uprawnieniem, bądź ralą (grsec) usera z odpalającego gsx server, xen. Ja bym nie korzystał z dołączonego ostatnio do mainstream-a wirtualizacji właśnie z opisanych przez ciebie powodów.
A jak ktoś się NAWET przebije powyżej logicznych kompów i działa w kontekście hypervisora (szczerze mówiąc nie wyobrażam sobie co by to mogło dać skoro user odpalający wirtualizację nie ma uprawnień) to :
1. zapewne tak poważna luka będzie szybko załatana
2. zastanawiam się na użyciem wrappera, ale to chyba odsłoni naszego hosta, bo sens używania wrappera w wirtualnym kliencie mija się z celem, jeśli zawiedzie obsługa wirtualnych kart sieciowych

P.S. naskrobałem maila do ISS czy nie mają czegoś podobnego do Application Protection pod linucha, może któraś z odsłon proventii będzie miała coś ciekawego do zaproponowania

edit: wlaśnie sobie uświadomiłem, że poczyniłem pewne założenie, które może nie być prawdą - otóż założyłem, że proces hypervisora to user space daemon, i nie wymaga modułów w kernelu.
Trzeba by sprawdzić konkretne implementacje maszyn wirtualnych

[markossx]

nie wiem czy powiem coś czego nie znacie ale przyłączę się do ciekawego tematu i opiszę swoje przemyślenia:
może dobrze by było umieścić sygnatury plików i bibliotek w bazie danych i zautomatyzować to w ten sposób, że po aktualizacji lub instalacji nowego softu odpalany by był przygotowany wcześniej skrypt, który wyciągnąłby z logów informacje o zaktualizowanych plikach i tylko dla tych plików wyliczyłby nowe sygnatury kładąc je do bazy. I oczywiście dla nowych. A kernel przed odpaleniem czegokolwiek sprawdzałby te informacje właśnie w bazie. Interfejs, który by komunikował kernel z bazą to dla mnie jeszcze zbyt wysoka poprzeczka dlatego sie nie wypowiadam. Skrypt można uczynić w bash i awk na przykład lub w perlu.
Odszukałem jeszcze narzędzie na stronie Amira Alsbiha (kernel-guard), oczywiście spełnia inaczej funkcje ochronne od tego czego poszukujesz ale myślę, że warto o nim wiedzieć
warto również przyjrzeć się projektowi rsback.

[TQM]

Jesli Kernel-Guard dziala tak jak podaje autor to nie trzeba bedzie sie gimnastykowac z kompilacja monolitycznego kernela - tak jak to robie do tej pory. Po prostu jak nie ma modulow to nie ma co ladowac do pamieci - rootkit jest wiec user-space Nie wiem czy grsec nie ma podobnej funkcji gdzies w stosie swoich opcji

[markossx]

no tak. nie wiem czy pamiętasz jak kiedyś poruszyliśmy temat rbash'a.
często wykorzystuję te rozwiązanie ponieważ w pewnych środowiskach dobrze ogranicza poczynania uzyszkodnika
można ustawić, że user może jedynie odpalić aplikacje, na które ty mu jawnie zezwolisz. jeśli będziesz potrzebował to mam gotowy skrypt, który mogę ci przesłać (każdy oczywiście może sie zgłosić ). można zaoszczędzić czas nie absorbując go na jakieś poszukiwania.
off top:
uważam że jesli ktoś wystarczająco długo drąży, to znajdzie źródło problemu i go rozwiąże ale jeśli jest już rozwiązanie to warto go użyć. ewentualnie zoptymalizować według swojego pomysłu
oczywiście ktoś może mieć inne zdanie, czyli własne rozwiązania najlepsze, ale z drugiej strony po co wyważać drzwi już otwarte..
end of top.
jeśli będziesz miał nowe spostrzeżenia w kwestii podpisów plików wykonywalnych i bibliotek to pisz proszę na forum

[dexter]

w sumie gdyby udało się połączyc weryfikację odpalanych plików i posadzic z wirtualizacją można by otrzymac dosyc twarde srodowisko - jak znajde troche czasu to chetnie poczytam glebiej