Skocz do zawartości
Zaloguj się, aby obserwować  
alphamale

Raport na temat bezpieczeństwa SSL serwerów firm hosting

Polecane posty

slyszales kiedys o czyms takim jak XSS? to poczytaj... moze Ci troche orzswietli ze wystarczy XSS + LAN, znam dziesiatki sieci uczelnianych, publicznych i innych tego typu w ktorych BEAST mozna wykonac, bo zajmuje sie ich audytowaniem i przedstawianiem PoC

eh 5* tyle roboty? poprawa bezpieczenstwa ssl to 1 plik konfiguracyjny, jaka robota? podmienic cfg i zrestartowac serwer www? udowadniasz tylko jak dobrze znasz temat, za kazdym postem, jak czytalem o tych trojanach i BEAST to uhm... heh

 

Dales filmik z dupy, zaprzeczajacy temu co napisales i teraz dorabiasz sobie ideologie :). I naucz sie czytac. Napisalem, ze zastosowanie takiego ataku to 5x wiecej roboty niz przy popularnych exploitach w celu przechwycenia.. tak naprawde czego? co z tego atakujacy ma? no wlasnie, userskie haslo.. sztuka dla sztuki.

 

staru blagam Cie, poczytaj pierw a potem sie wypowiadaj, BEAST/CRIME to nie bledy apache, dzialaja tak samo na apache jak i nginx i innych bo dotycza CBC/kompresji kolejno...

 

Ten "raport bezpieczenstwa" wytyka bledy wynikajace z domyslnych konfigow Apache w roznych wersjach, ktore pozwalaja na atak. W zaleznosci czy ktos ma jeszcze antyczne 1.3, 2.2 czy moze juz 2.4 to jest na coraz mniej "bledow" podatny. A majac litespeeda nie jest podatny na zaden z listy. Ale za to na kilka innych..

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Ano to, że raport/tytuł tematu jest zatytułowany nie Podatność serwerów firm hostingowych na BEAST/CRIME tylko Bezpieczeństwo SSL serwerów firm hostingowych. A IMO na owe bezpieczeństwo SSL składa się także (szeroko pojęte) konfiguracja samego PKI.

przeciez wymienili tam punkty co zostalo sprawdzowe, przeciez nikt wszystkiego w temacie nie ujmuje, tylko ogol, a szczegoly w tresci

Ehh ;).

 

Jeśli user będzie miał milusiego szkodnika na komputerze, który będzie robił takie podstawowe rzeczy jak chociażby przechwytywanie znaków z klawiatury (o reszcie funkcji w ogóle nie wspominając) to wszystkie certyfikaty SSL są na jednoczesnej pozycji co hasła w plaintextcie. Ja rozumiem, że takie rzeczy są realnym zagrożeniem i jak najbardziej wypadałoby na nie zwrócić uwagę, ale nie stanowią bezpośredniego zagrożenia, które zagraża samej usłudze bądź serwerowi (czy jakiejś dalszej infrastrukturze). Osobiście też jestem zwolennikiem szyfrowania i używam go gdzie tylko się da, ale co byś nie wprowadził to i tak wszystko jest do przechwycenia odpowiednim softem na komputerze klienta. I na to wpływu nie masz, chyba że będziesz wymagał od klienta jakiegoś force-skanu antywirusem czy coś w ten deseń :D.

 

Sam test też uważam za taki sobie. Niby coś można z niego wyciągnąć, ale tak naprawdę nic szczegółowego nam nie mówi. Mam tu głównie na myśli wszystkie rzeczy, które zostały już wyżej wspomniane i nie ma sensu ich powtarzać. Prawda jest taka, że bez obiektywnego pentestu całej strony to takie pojedyncze testy nie mają nic wspólnego z rzeczywistymi zabezpieczeniami danej usługi. No dobra, może mają kilkuprocentowy wpływ na całość...

 

W IT Security trzeba się skupić na wszystkim równomiernie, dopiero jak wyrównamy poziom to się brać za rzeczy bardziej zaawansowane, aż dojdziemy do poziomu, w którym ciężko będzie wymyślić coś "jeszcze" :).

a gdzie wystepuje jeszcze szyfrowanie poza SSL w komunikacji klient - serwer HTTP Twoim zdaniem? skoro mowimy o szyfrowaniu

Dales filmik z dupy, zaprzeczajacy temu co napisales i teraz dorabiasz sobie ideologie :). I naucz sie czytac. Napisalem, ze zastosowanie takiego ataku to 5x wiecej roboty niz przy popularnych exploitach w celu przechwycenia.. tak naprawde czego? co z tego atakujacy ma? no wlasnie, userskie haslo.. sztuka dla sztuki.

 

 

 

Ten "raport bezpieczenstwa" wytyka bledy wynikajace z domyslnych konfigow Apache w roznych wersjach, ktore pozwalaja na atak. W zaleznosci czy ktos ma jeszcze antyczne 1.3, 2.2 czy moze juz 2.4 to jest na coraz mniej "bledow" podatny. A majac litespeeda nie jest podatny na zaden z listy. Ale za to na kilka innych..

a jakim popularnym exploitem przechwycisz transmisje SSL poza takim bledem albo sslstrip? takie cos to nawet problem przy nasluchu malware

 

dla twojej informacji to nie podatnosc samego Apache, a dotyczy kazdego demona www, co najmniej ostatnie konfigi apache/nginx ktore sa w wiekszosci dystrybucji linux

 

juz nawet Ci nie odpisuje, bo widze ze trollujesz piszac jakeis farmazony, tylko ciagle potwierdzasz ze nie znasz i nie rozumiesz tematu, swoja droga apache przed 2.2.24 nie jest w stanie sie ochronic przeciwko CRIME

 

# apt-cache show apache2 | grep Version
Version: 2.2.22-12
# cat /etc/issue.net
Debian GNU/Linux wheezy/sid

 

poniewaz nie obsluguja "SSLCompression" w konfiguracji modulu SSL

 

paradoksalnie dodam w jednym bug bounty zarobilem na BEAST

 

serio nie ma sie juz co klocic bo widze ze jestes jedna z tych osob ktore do upadlego bronia swojej racji mimo ze wiedza, ze racji nie maja... a tak niestety jest i juz pare razy udowodnilem Ci ze piszesz bzdury, to znowu probujesz w inny sposob, chyba po prostu j/w trollujesz i tyle...

Edytowano przez B0FH (zobacz historię edycji)

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Ty za to robisz sie madrzejszy w miare tego co wygoglujesz.. najpierw czytam, ze ochrona przed beastem to jedna linijka, a teraz twierdzisz, ze naprawia ja tylko apache 2.2.24, ktory jeszcze oficjalnie nie istnieje ;). Jakim popularnym exploitem przechwyce transmieje? Na cholere mi transmisja, jak chce miec login i haslo usera to mu instaluje byle jaki keylogger, o czym pisal juz Kafi.. Przyloz sie po prostu jak bedziesz robil nastepny raport i tyle, skoncz bronic cos co jest nie do obrony.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Nie ma co ukrywać, że CVE jest, więc literalnie problem występuje/istnieje.

 

Z mojego punktu widzenia, jeśli ktoś ma w sieci intruza ( MITM ) albo malware,

przy czym istnieje AFAIR tylko jeden komercyjny driver szyfrujący dane wpisywane na klawiaturze w warstwie kernela,

możliwość przeprowadzenia w.w. ataków to naprawdę *najmniejszy problem* jaki ma użytkownik.

W obu wypadkach atakujący ma pełną kontrolę nad stacją użytkownika.

 

Można się czepiać firmy hostingowe o to, jasne, ale to bardziej PR aniżeli błąd krytyczny wymagający natychmiastowej interwencji.

Inna sprawa, że ja nie jestem przekonany ( poprawcie mnie jeśli się mylę ),

że w obliczu tych wszystkich osób, które korzystają z antycznego softu - można tak sobie dowolnie

żonglować wymuszaniem wersji SSL'a, cipher'a etc.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Ty za to robisz sie madrzejszy w miare tego co wygoglujesz.. najpierw czytam, ze ochrona przed beastem to jedna linijka, a teraz twierdzisz, ze naprawia ja tylko apache 2.2.24, ktory jeszcze oficjalnie nie istnieje ;). Jakim popularnym exploitem przechwyce transmieje? Na cholere mi transmisja, jak chce miec login i haslo usera to mu instaluje byle jaki keylogger, o czym pisal juz Kafi.. Przyloz sie po prostu jak bedziesz robil nastepny raport i tyle, skoncz bronic cos co jest nie do obrony.

koles... nie potrzebujesz trojana zeby javascript odpalic, wystarczy 1 lepszy XSS, a takich to od groma jest, nawet w produktach Google...

Nie ma co ukrywać, że CVE jest, więc literalnie problem występuje/istnieje.

 

Z mojego punktu widzenia, jeśli ktoś ma w sieci intruza ( MITM ) albo malware,

przy czym istnieje AFAIR tylko jeden komercyjny driver szyfrujący dane wpisywane na klawiaturze w warstwie kernela,

możliwość przeprowadzenia w.w. ataków to naprawdę *najmniejszy problem* jaki ma użytkownik.

W obu wypadkach atakujący ma pełną kontrolę nad stacją użytkownika.

 

Można się czepiać firmy hostingowe o to, jasne, ale to bardziej PR aniżeli błąd krytyczny wymagający natychmiastowej interwencji.

Inna sprawa, że ja nie jestem przekonany ( poprawcie mnie jeśli się mylę ),

że w obliczu tych wszystkich osób, które korzystają z antycznego softu - można tak sobie dowolnie

żonglować wymuszaniem wersji SSL'a, cipher'a etc.

DNSSEC i inne? a co jesli jest hotspot/sieci uczelniane/sieci blokowe itd, a nie koneicznie intruz w jakeis sieci domowej? MITM wykryje kazdy IDS/IPS w takiej sieci jesli istnieje, swoja droga polowa jesl inie wiekszosc tych mniejszych ISP pozwala Ci na zabawy w 2giej warstwie ISO/OSI

 

pomijajac juz fakt, ze mowisz o MITM, a BEAST i CRIME są atakami MITM...

 

wlasnie w przypadku antycznych userow to jest najwieksze niebezpieczenstwo, bo nowsze wersje same priorytetyzuja RC4 nad CBC

Edytowano przez B0FH (zobacz historię edycji)

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

DNSSEC i inne?

Piszemy o przeciętnym Kowalskim, który "robi internety", a Ty mi tutaj z DNSSEC'iem wyskakujesz? :rolleyes:

Inna sprawa, przed czym ma ten DNSSEC go uchronić jeśli w sytuacji którą zakładamy

na drodze od niego do resolver'a może ten pakiet przechwycić X osób,

zmodyfikować i odesłać cokolwiek?

Czy jesteś w stanie znaleźć szybko choć 10 popularnych stron komercyjnych,

które są zabezpieczone DNSSEC'iem ?

Kiedyś poświęciłem temu kilka godzin. Tych stron praktycznie nie ma. DNSSEC to mit.

a co jesli jest hotspot/sieci uczelniane/sieci blokowe itd, a nie koneicznie intruz w jakeis sieci domowej? MITM wykryje kazdy IDS/IPS w takiej sieci jesli istnieje, swoja droga polowa jesl inie wiekszosc tych mniejszych ISP pozwala Ci na zabawy w 2giej warstwie ISO/OSI

Od tego jest poprawna konfiguracja sieci. Przez poprawna mam na myśli

zastosowanie mechanizmów zgodnie z planowanym wykorzystaniem danego segmentu.

Jeśli ktokolwiek pozwala na swawolne buszowanie w swojej sieci każdemu jak leci,

to kwestia ustawień połączeń SSL jest *najmniejszym problemem*.

Klient takiej sieci zawsze będzie podatny na atak - taki czy inny.

Jeśli jestem pomiędzy Tobą, a urządzeniem L3, a Ty nie masz PKI - mogę wszystko i nic tego nie zmieni.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Piszemy o przeciętnym Kowalskim, który "robi internety", a Ty mi tutaj z DNSSEC'iem wyskakujesz? :rolleyes:

Inna sprawa, przed czym ma ten DNSSEC go uchronić jeśli w sytuacji którą zakładamy

na drodze od niego do resolver'a może ten pakiet przechwycić X osób,

zmodyfikować i odesłać cokolwiek?

Czy jesteś w stanie znaleźć szybko choć 10 popularnych stron komercyjnych,

które są zabezpieczone DNSSEC'iem ?

Kiedyś poświęciłem temu kilka godzin. Tych stron praktycznie nie ma. DNSSEC to mit.

 

Od tego jest poprawna konfiguracja sieci. Przez poprawna mam na myśli

zastosowanie mechanizmów zgodnie z planowanym wykorzystaniem danego segmentu.

Jeśli ktokolwiek pozwala na swawolne buszowanie w swojej sieci każdemu jak leci,

to kwestia ustawień połączeń SSL jest *najmniejszym problemem*.

Klient takiej sieci zawsze będzie podatny na atak - taki czy inny.

Jeśli jestem pomiędzy Tobą, a urządzeniem L3, a Ty nie masz PKI - mogę wszystko i nic tego nie zmieni.

to ja moze adekwatne pytanie, a ktory chaker w ogole w Polsce rozumie co to DNSSEC :D? ide o zaklad ze 99% osob ktore takie cos beda przechwytywac nawet nie wie co to DNSSEC, a co dopiero jak to zrobic, ja rowniez nie wiem, postawic DNSSEC potrafie ale juz atak wykonac nie

 

zdecydowanie wiekszosc jeszcze nie korzysta z DNSSEC i to jest troche glupie, bo zawsze dodatkowe zabezpieczenie "tanim kosztem" jest dobre, niestety ja korzystam prywatnie z takich DNS, ktore nie wspieraja DNSSEC, DNSSEC jest po prostu malo powszechny jeszcze, to tak samo jak z IPv4 i IPv6

 

co do ostanich linii Twojej wypowiedzi to jeszcze j/w dochodzi XSS i wtedy mozesz wykorzystac atak BEAST i nie musisz byc w tej samej sieci, a XSS wszedzie sie znajdzie praktycznie

Edytowano przez B0FH (zobacz historię edycji)

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Abstrahując od wartości metodycznych i co za tym idzie merytorycznych - myślę, że dobrze, iż taki raport się pojawił, bo po prostu "zapala lampkę" pod tytułem "Uwaga - zastanów się, czy robisz wszystko jak należy". Na pewno raportowi nie przydaje wiarygodności sposób jego podpisania, być może to pierwsza przymiarka Autora lub Autorów do tego rodzaju publikacji i następnym razem pójdzie lepiej. Na pewno konkretny wysiłek został podjęty i ja kibicuję temu, kto stworzył ten raport, aby na tym nie poprzestawać.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Bądź aktywny! Zaloguj się lub utwórz konto

Tylko zarejestrowani użytkownicy mogą komentować zawartość tej strony

Utwórz konto

Zarejestruj nowe konto, to proste!

Zarejestruj nowe konto

Zaloguj się

Posiadasz własne konto? Użyj go!

Zaloguj się

Zaloguj się, aby obserwować  

×