Jednocześnie jakoś bez większego echa przeszła informacja o luce we wszystkich wersjach IE (Internet Explorera) - luce umożliwiającej instalację złośliwego oprogramowania. Wystarczy, że użytkownik IE wejdzie na odpowiednio spreparowaną stronę WWW... Lukę znaleźli ludzie z www.fireeye.com.
Ciekawe czy zostanie wydana poprawka do Windows XP?
Wystarczy wykorzystać mechanizmy zabezpieczające dostęp do pamięci serwera: usługi uruchomione z prawami różnych użytkowników nie maja dostępu do swoich obszarów panięciu. Czyli prawidłowo wykonana praca administratora zabezpiecza serwer przed heartbeat, ponieważ nie da się odczytać obszarów pamięci np.: z hasłami. Przypominam, że SSL zabezpiecza transmisję, a hasła do aplikacji (lub inne metody potwierdzenia praw) stanowią oddzielny mechanizm.
Pojawiały się enigmatyczne teksty o tym, że błąd dotyczy też poczty elektronicznej. Klienta na pewno nie! Klient (oprogramowanie) nie jest usługą serwerową, nie nasłuchuje na danym porcie i do tego najczęściej i tak jest ukryty za firewallem. Co z serwerem? Wystarczy stosować odpowiednie oprogramowanie (patrz wiekowy qmail), a bramki email-http potraktować tak samo jak inne serwisy http - obsłużyć ssl na osobnej usłudze/maszynie.
Zresztą jak na razie najlepszym zabezpieczeniem dostępu np.: do poczty jest VPN, ale nie łatwe w konfiguracji wynalazki oparte o SSL, tylko prawdziwe VPN oparte o IPSec. Z tym, że i tu w przypadku nieprawidłowej konfiguracji (i posiadania np.: szybkiej karty grafiki) można znaleźć pewne luki. Dlatego trzeba zatrudniać doświadczonych specjalistów :-)
Jeszcze lepsze rezultaty można uzyskać, wprowadzając w firmie pocztę szyfrowaną technikami asymetrycznymi. Przecież dowolnie zabezpieczona poczta SSL, czy nawet i VPN'em chroniona jest tylko na drodze komputerA-serwer i serwer-komputerB - czyli przed podsłuchem gdzieś na łączach. Mając dostęp na prawach administratora do serwera poczty mamy dostęp do niezaszyfrowanej poczty. Gdy zastosujemy podpisywanie i szyfrowanie poczty technikami asymetrycznymi zyskujemy:
- Nawet gdy ktoś ukradnie nasze hasło do poczty, lub w inny sposób spróbuje wykorzystać słabość systemu pocztowego, to i tak nie jest w stanie podpisać wiadomości naszym podpisem cyfrowym. Od razu będzie wiadomo, że ktoś próbuje wysłać fałszywą wiadomość.
- Wiadomość odszyfrowana (jawna) będzie dopiero dla odbiorcy i nikt po drodze, w żadnym punkcie, nie będzie mieć dostępu do jej jawnej (nie zaszyfrowanej) treści.
Co do przetrzymywania haseł (i loginów) w pamięci operacyjnej w postaci jawnej. Problem ten już pojawiał się przy okazji użytkowników z prawami administratorów, który to mogli robić zrzuty pamięci serwera i szukać ciągów znaków mogących być hasłami (problem złej administracji serwerem lub nieuczciwych administratorów).
Nic jednak nie stoi na przeszkodzie, by programy trzymały hasła w pamięci operacyjnej zaszyfrowane kluczem aktualnym na czas uruchomienia danej instancji programu. Program uruchamia się, generuje losowy klucz i za jego pomocą szyfruje i deszyfruje hasła pobierane od użytkownika, z bazy danych, itp. Skoro hasło przypominało by inne dane binarne to nie ma można go trywialnie odnaleźć.
Tu oprogramowanie z jawnym kodem ma olbrzymią zaletę - od razu widać, czy ktoś zaimplementował techniki ochrony i czy zrobił to poprawnie.
Ciekawe czy zostanie wydana poprawka do Windows XP?
Wracając do meritum: błąd nazwany "heartbeat" CVE-2014-0160 znalazł się w implementacji rozszerzenia RFC6520 protokołów TLS/DTLS. Co to oznacza? W ten sposób powinna zostać zabezpieczona transmisja pomiędzy serwerem a klientem. Czyli nie dane przechowywane na serwerach, tylko sama transmisja.
Błąd jednak pozwalał na kradzież innych danych, niż tylko tych, które ktoś mógłby podsłuchać podłączając się gdzieś pomiędzy nami a np.: bankiem. Lecz kiedy ta kradzież może nastąpić? Tylko wtedy, gdy nie rozdzielamy usług.
Jeśli wykorzystujemy np. akceleratory SSL, czy to w postaci osobnych maszyn, serwerów proxy na innych maszynach, lub usług obsługujących SSL, ale jako osobne procesy to problem przestaje być ważny, prawda? Szczególnie, jeżeli hasła szyfrujemy i w takiej postaci przesyłamy.
Wystarczy wykorzystać mechanizmy zabezpieczające dostęp do pamięci serwera: usługi uruchomione z prawami różnych użytkowników nie maja dostępu do swoich obszarów panięciu. Czyli prawidłowo wykonana praca administratora zabezpiecza serwer przed heartbeat, ponieważ nie da się odczytać obszarów pamięci np.: z hasłami. Przypominam, że SSL zabezpiecza transmisję, a hasła do aplikacji (lub inne metody potwierdzenia praw) stanowią oddzielny mechanizm.
Pojawiały się enigmatyczne teksty o tym, że błąd dotyczy też poczty elektronicznej. Klienta na pewno nie! Klient (oprogramowanie) nie jest usługą serwerową, nie nasłuchuje na danym porcie i do tego najczęściej i tak jest ukryty za firewallem. Co z serwerem? Wystarczy stosować odpowiednie oprogramowanie (patrz wiekowy qmail), a bramki email-http potraktować tak samo jak inne serwisy http - obsłużyć ssl na osobnej usłudze/maszynie.
Zresztą jak na razie najlepszym zabezpieczeniem dostępu np.: do poczty jest VPN, ale nie łatwe w konfiguracji wynalazki oparte o SSL, tylko prawdziwe VPN oparte o IPSec. Z tym, że i tu w przypadku nieprawidłowej konfiguracji (i posiadania np.: szybkiej karty grafiki) można znaleźć pewne luki. Dlatego trzeba zatrudniać doświadczonych specjalistów :-)
Jeszcze lepsze rezultaty można uzyskać, wprowadzając w firmie pocztę szyfrowaną technikami asymetrycznymi. Przecież dowolnie zabezpieczona poczta SSL, czy nawet i VPN'em chroniona jest tylko na drodze komputerA-serwer i serwer-komputerB - czyli przed podsłuchem gdzieś na łączach. Mając dostęp na prawach administratora do serwera poczty mamy dostęp do niezaszyfrowanej poczty. Gdy zastosujemy podpisywanie i szyfrowanie poczty technikami asymetrycznymi zyskujemy:
- Nawet gdy ktoś ukradnie nasze hasło do poczty, lub w inny sposób spróbuje wykorzystać słabość systemu pocztowego, to i tak nie jest w stanie podpisać wiadomości naszym podpisem cyfrowym. Od razu będzie wiadomo, że ktoś próbuje wysłać fałszywą wiadomość.
- Wiadomość odszyfrowana (jawna) będzie dopiero dla odbiorcy i nikt po drodze, w żadnym punkcie, nie będzie mieć dostępu do jej jawnej (nie zaszyfrowanej) treści.
Co do przetrzymywania haseł (i loginów) w pamięci operacyjnej w postaci jawnej. Problem ten już pojawiał się przy okazji użytkowników z prawami administratorów, który to mogli robić zrzuty pamięci serwera i szukać ciągów znaków mogących być hasłami (problem złej administracji serwerem lub nieuczciwych administratorów).
Nic jednak nie stoi na przeszkodzie, by programy trzymały hasła w pamięci operacyjnej zaszyfrowane kluczem aktualnym na czas uruchomienia danej instancji programu. Program uruchamia się, generuje losowy klucz i za jego pomocą szyfruje i deszyfruje hasła pobierane od użytkownika, z bazy danych, itp. Skoro hasło przypominało by inne dane binarne to nie ma można go trywialnie odnaleźć.
Tu oprogramowanie z jawnym kodem ma olbrzymią zaletę - od razu widać, czy ktoś zaimplementował techniki ochrony i czy zrobił to poprawnie.
Brak komentarzy:
Prześlij komentarz