Artykuły dotyczące tematu: SSL

dodany: 28.06.2013 | tagi: , , , , ,

Aktualizacja Ruby naprawia lukę MitM w obsłudze SSL

0

Implementacja OpenSSL w Ruby okazała się niebezpieczna. Dzięki znalezionej luce możliwe jest ominięcie sprawdzania hostname. Jeżeli w alternatywej nazwie X509 certyfikatu (thesubjectAltName) znajduje się znak pusty, przykładowo “ruby-lang.org\0example.com”, Ruby zinterpretuje to jako “ruby-lang.org”.

Luka zyskała oznaczenie CVE-2013-4073. Zalecana jest aktualizacja do najnowszych wersji poszczególnych gałęzi, tj. 1.8.7p374 (które naprawia także lukę DoS w REXML), 1.9.3p448 oraz 2.0.0p247.

dodany: 25.02.2013 | tagi: , , ,

Bezpieczne płatności elektroniczne

0
Płatności

Pisząc poprzedni artykuł byłem świadom, że nie będę w stanie jednocześnie nawiązać przekrojowo do samego tematu przesyłania danych w aplikacjach online, a także szczegółowo opisać wszystkich omawianych interfejsów. W jego podsumowaniu starałem się zachęcić do zapoznania ze sposobem działania rozwiązań płatności elektronicznych, ale pomyślałem, że może warto ten temat opisać w osobnym artykule. Takie rozwiązania nie są mocno skomplikowane, ale ich solidność i niezawodność jest bardzo ważna – w końcu poprzez takie usługi przesyłamy wirtualnie pieniądze z naszych kont i płacimy ufając, że dotrą one do odbiorców. Pomyślałem też, że warto przekazać zarys procesu – może przyda się kiedyś części z Was jako wstępny materiał, jeśli będziecie mieli wdrożyć w swojej firmie taki system.

(więcej…)

dodany: 19.02.2013 | tagi: , , ,

Przesyłanie danych w aplikacjach online

3

Udostępnianie systemów firmowych na zewnątrz sieci i umożliwianie użytkownikom dostępu do zasobów wewnętrznych to dziś praktycznie konieczność i chyba nie ma dziś organizacji, która nie posiadałaby chociaż własnej strony internetowej. Taka strona zwykle nie niesie za sobą ryzyka utraty danych i zawiera informacje, które celowo są upubliczniane, a sam serwis działa na wykupionej usłudze hostingowej gdzieś w Polsce lub poza granicami. Sytuacja się komplikuje, jeżeli tym udostępnianym rozwiązaniem jest jeden z systemów oferujący nie tylko publiczne dane, ale dedykowane dla konkretnej grupy odbiorców lub pojedynczego użytkownika, którzy mogą założyć konto, zalogować się, przejrzeć niepubliczne dane (np. listę faktur dotyczącej podpisanej przez siebie umowy z operatorem telekomunikacyjnym).

(więcej…)

dodany: 23.01.2013 | tagi: , , , , ,

MEGA-problem nowego serwisu Kima Dotcoma

1

Kim Dotcom, który zasłynął z założenia już nieistniejącego serwisu megauplod.com znów powrócił – założył on „bardziej” legalny serwis o nazwie Mega. Od zamknięcia poprzedniego serwisu minął rok. Start niestety nie był do końca dopracowany – dlaczego? Hasła nowo rejestrowanych użytkowników są zakodowane w linku aktywacyjnym!  Odkrył to badacz bezpieczeństwa z Steve Thomas znany też jako ScOObz.

Przykładowy link wygląda następująco:

Sc00bz zauważył, że link aktywacyjny jest zakodowany algorytem base64. Jeśli powyższy ciąg znaków skonwertujemy do kodowania heksdecymalnego, to otrzymamy zahaszowane hasło użytkownika!

Powyższy ciąg z linku po takiej konwersji wygląda następująco:

W ciągu tym możemy wydzielić 6 krótszych. Kolejne elementy tego ciągu są następujące:

1. 70491be7c3858d0698b282b993d5ed69 – to zaszfyrowany klucz master;

2. ba7fd1c38b5a5073ef73679eb9c7bd48 – hasło użytkownika zaszyfrowane algorytmem AES;

3. 63797275732e6661726976617240617273746563686e6963612e636f6d  – adres e-mail w kodowaniu heksadecymalnym;

4. 43797275732046617269766172 – zakodowana nazwa użytkownika.

 

Pozostałych dwóch ciągów Steve jeszcze nie zidentyfikował. Dane te wystarczyły jednak do stworzenia przez niego automatu łamiącego hasła z wspomnianego linka – narzędzie to możemy pobrać ze strony autora.

Program doczekał się już wydania drugiej wersji, która jest oznaczona numerem 0.2a – w porównaniu do pierwszego wydania działa szybciej i ma poprawione kilka małych błędów. Wydajność najnowszej wersji wynosi 4820 znaków/sekundę na procesorze i7-2600.

megacracek02a

Dla pikanterii autor zamieścił w samym serwisie MEGA ważącą 25MB listę wstępnie zdekodowanych haszów, a konkretnie zawierającą same hasła. Dzięki niej prędkość obliczeń wzrasta do 4.59 mega-znaków/sekundę podczas dekodowania jednego hasza.

 

Co na to właściciele serwisu?

Oczywiście Kim nie pozostawił tego faktu w ukryciu – właściciel zajął stosowne stanowisko w tej sprawie na swoim blogu.

Mało tego MegaCrackera opisał jako bardzo przydatne narzędzie do odzyskania swojego klucza, na wypadek zagubienia  z zastrzeżeniem, że narzędzie to nie spisuje się dobrze, jako „odgadywacz” haseł…

Informacja ta wynikła częściowo przez ciśnienie, które wywarł portal ArsTechnica odnośnie słabego szyfrowania, podczas gdy reklama  serwisu mówi o „megabezpieczeństwie”.

Poznając hasło do konta użytkownika, możemy zmienić master key, który jest odpowiedzialny za szyfrowanie naszych danych na serwerze. Klucz ten jest zaszyfrowany 128-bitowym algorytmem AES .

Serwis broni się tym, że nie ma możliwości odzyskania tego klucza, nawet jeśli zapomnimy nasze hasło i nie będzie można uzyskać dostępu do wcześniej zgromadzonych danych. Zapowiedział jednak, że ma to zostać zmienione, poprzez wprowadzenie możliwości zmiany hasła oraz ponownego zaszyfrowania nim głównego klucza.

Serwis odpowiedział, że reset hasła nie będzie umożliwiał wcześniej zgromadzonych danych, aczkolwiek będzie istnieć możliwość importu naszego klucza – wtedy nawet bez znajomości poprzedniego hasła, będziemy mogli je odczytać .

Zaskakującą linią obrony jest stwierdzenie właściciela:

jeśli potrafimy złamać komunikację SSL, to możemy zająć się ciekawszymi rzeczami, niż te zgromadzone w serwisie MEGA

– powiedział Dotcom.

Jednak to, co jest główną przyczyną braku zaufania w bezpieczeństwie nowej usługi, to fakt zastosowania po stronie serwera SSL szyfrowania za pomocą 1024-bitowego klucza, podczas gdy obecnie rozsądne minimum zapewnia klucz 2048-bitowy. Mało tego, serwis podaje, że mechanizm ten zastosował, tylko z tego względu, że przeglądarki nie lubią połączeń HTTP wywołanych z HTTPS!

Dłuższy klucz wykorzystuje co prawda główna domena https://mega.co.nz/, ale sama https://*.static.co.nz/ używa już krótszej wersji – Kim Dotcom broni się zbyt dużym zużyciem zasobów CPU.  Weryfikacja kluczy odbywa się przez JavaScript, które są generowane przez słabiej zabezpieczony serwer i wg twórców nie pozwala na atak człowiek-po-środku.

Wg niezależnych badaczy weryfikacja ta jest po prostu bezsensowna, bo nie chroni przed niczym.

Po tych oskarżeniach współtwórca serwisu Van der Kolk, dodał, że autoryzacja odbywa się w oparciu o dodatkowe dane, wygenerowane w oparciu o aktualne ruchy myszką i naciśnięcia klawiszy klawiatury u użytkownika serwisu.

Wygląda, że faktycznie tak jest, gdyż podczas generowania naszego klucza RSA, pasek postępu przyspiesza, gdy poruszamy kursorem myszy.

Cóż, start czegoś nowego zwykle przyciąga potencjalnych atakujących – tym bardziej, że nowa usługa w chmurze została zbudowana przed dobrze znane nazwisko… Ruch na serwisie szybko wzrósł i dognił usługę DropBox, o czym Kim nie omieszkał pochwalić się na swoim Twitterze.

traffic rank mega

 

Jedyne sensowne usprawiedliwienie autorów, to takie, że serwis jest w fazie beta.

dodany: 08.11.2012 | tagi: , ,

Giełda na zielono – czyli jak polskie spółki giełdowe dbają o bezpieczeństwo serwisów internetowych

1

Unizeto Technologies przeprowadziło badania zabezpieczeń serwisów internetowych polskich spółek giełdowych. Okazało się, że jedynie 11% spółek należycie dba o bezpieczeństwo użytkowników swojej witryny.

W badaniu zrealizowanym w sierpniu br. wzięto pod uwagę serwisy internetowe 440 spółek notowanych na Giełdzie Papierów Wartościowych w Warszawie (GPW). Zagrożenie cyberprzestępczością i ustawowe wymogi ochrony danych osobowych przemawiają za wprowadzeniem odpowiedniej ochrony serwisów internetowych. Weryfikacja zabezpieczeń pokazała, że aż 89% spółek na swoich serwisach internetowych nie posiada podstawowego zabezpieczenia transmisji danych w postaci certyfikatu SSL. Wynika z tego, że jedynie co dziewiąta spółka daje gwarancje bezpieczeństwa przesyłanych informacji i buduje zaufany wizerunek wśród użytkowników serwisu.

Z drugiej strony na uwagę zasługuje fakt, że wśród spółek, które zdecydowały się na zabezpieczenie witryny certyfikatem SSL, większość, bo aż 58% wybrała rozwiązanie najwyższego poziomu należące do klasy EV (Extended Validation). Certyfikat SSL typu EV wymaga kilkuetapowej weryfikacji, dzięki której potwierdzana jest m.in. tożsamość nabywcy, adres e-mail i dostęp do domeny. Co więcej klasa EV pozwala na uzyskanie zielonego paska adresu, który jest jasnym znakiem dla użytkowników przeglądarki internetowej, że ma on do czynienia z zaufaną witryną.

– Aktualnie zapewnienie bezpieczeństwa przesyłanych danych nie jest już tylko celem samym w sobie. Obecnie jest to również element szerszego budowania wizerunku firmy. Dobrze zrozumiały to spółki stawiające na bezpieczeństwo własnych witryn i decydując się w większości na certyfikaty SSL typu EV, które zapewnią maksymalny poziom weryfikacji i widoczny symbol bezpieczeństwa dla użytkowników – mówi Tomasz Litarowicz, Dyrektor CERTUM Powszechnego Centrum Certyfikacji należącego do Unizeto Technologies.

Z certyfikatów SSL typu EV najczęściej korzystały banki. Rozwiązanie średniej klasy typu OV wybrało 21% spółek, głównie z branż ubezpieczeniowej, budowlanej i telekomunikacyjnej. Taki sam odsetek badanych firm (21%) zdecydował się na podstawowe zabezpieczenie typu DV. W tym gronie przeważała branża deweloperska, informatyczna, handlowa i energetyczna.

Spółki akcyjne badane były pod kątem zabezpieczania danych przesyłanych przy wypełnianiu formularza kontaktowego, logowaniu do systemu oraz przesyłaniu danych z prośbą o newsletter. Najlepiej zabezpieczoną spółka giełdową okazał się jeden z banków, który jako jedyny zabezpiecza dane najwyższym certyfikatem SSL typu EV na wszystkich stronach przetwarzających dane swoich klientów.

Partnerem medialnym raportu Giełda na zielono jest Bankier.pl, a partnerami merytorycznymi są CERTUM i WebSecurity.pl.

Raport można pobrać pod tym adresem: Raport: Giełda na zielono

dodany: 19.10.2012 | tagi: ,

Rok później serwery SSL wciąż kulą się ze strachu przed BEAST’ią

0

W najnowszym comiesięcznym badaniu SSL Labs odkryło, że wiele witryn SSL zostaje podatnych na atak BEAST, ponad rok po znalezieniu luki przez badaczy bezpieczeństwa.

BEAST jest skrótem od Browser Exploit Against SSL / TLS. Potajemny fragment kodu JavaScript działa ze sniffera sieciowego w celu odszyfrowania zaszyfrowanych plików cookie, których używa obrana za cel strona do przyznania dostępu do zastrzeżonych kont użytkowników.

W październiku z sondażu SSL Pulse liczba witryn zabezpieczonych wszechobecnym SSL wynosi 179 000. Ok. 71 % z nich (127 000) nadal jest narażonych na atak BEAST.

Najnowsze statystyki pokazują minimalne zmiany z danych z września: o jeden punkt procentowy mniej stron podatnych na atak BEAST, niż miało to miejsce miesiąc temu.

Źródłem przyczyny ataku BEAST jest podatny cipher suite na serwerach, który został znaleziony we wrześniu 2011 przez badaczy bezpieczeństwa.

Sondaż SSL Pulse przeanalizował również kompletność łańcuchów certyfikatów oraz siły szyfrów. Ze 179 000 miejsc przebadanych tylko 24 400 zasłużyło na miano „bezpiecznych miejsc”.

Radzimy ostrożność, bo ten ciasteczkowy potwór nie jest na tyle przemiły, zabawny i futrzany jak ten z Ulicy Sezamkowej i nie tylko ciasteczka może Wam zwędzić.