MikeJones 25 Zgłoś post Napisano Grudzień 24, 2012 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
B0FH 3 Zgłoś post Napisano Grudzień 24, 2012 (edytowany) 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ń . 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 Grudzień 24, 2012 przez B0FH (zobacz historię edycji) Udostępnij ten post Link to postu Udostępnij na innych stronach
MikeJones 25 Zgłoś post Napisano Grudzień 24, 2012 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
beliq 442 Zgłoś post Napisano Grudzień 24, 2012 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
B0FH 3 Zgłoś post Napisano Grudzień 24, 2012 (edytowany) 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 Grudzień 24, 2012 przez B0FH (zobacz historię edycji) Udostępnij ten post Link to postu Udostępnij na innych stronach
Pan Kot 1535 Zgłoś post Napisano Grudzień 24, 2012 Co jak co, ale ja z publicznych sieci ZAWSZE łączę się przez własny VPN, nigdy 100% gwarancji nie masz . Udostępnij ten post Link to postu Udostępnij na innych stronach
alphamale 0 Zgłoś post Napisano Grudzień 24, 2012 Co jak co, ale błędy wskazane w raporcie powinny zostać załatane, to nie ulega wątpliwości?! Udostępnij ten post Link to postu Udostępnij na innych stronach
Pan Kot 1535 Zgłoś post Napisano Grudzień 24, 2012 Wszystkie błędy bezpieczeństwa powinny być załatane, co nie znaczy że są same w sobie niebezpieczne. Udostępnij ten post Link to postu Udostępnij na innych stronach
kujawiq 0 Zgłoś post Napisano Grudzień 25, 2012 A że tak się spytam, ktoś te firmy może łaskawie poinformował, że są podatne na ataki czy inne działania? Udostępnij ten post Link to postu Udostępnij na innych stronach
beliq 442 Zgłoś post Napisano Grudzień 25, 2012 DNSSEC i inne? Piszemy o przeciętnym Kowalskim, który "robi internety", a Ty mi tutaj z DNSSEC'iem wyskakujesz? 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
B0FH 3 Zgłoś post Napisano Grudzień 25, 2012 (edytowany) Piszemy o przeciętnym Kowalskim, który "robi internety", a Ty mi tutaj z DNSSEC'iem wyskakujesz? 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 ? 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 Grudzień 25, 2012 przez B0FH (zobacz historię edycji) Udostępnij ten post Link to postu Udostępnij na innych stronach
Artur Pajkert 39 Zgłoś post Napisano Grudzień 27, 2012 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