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

[alphamale 0]

Może kogoś zainteresuje:

[MikeJones 25]

świetnie.. kolejny idiotyczny "test" na tym forum wykonany na podstawie dziwnych kryteriów .. czyzby ktos robil to na zaliczenie na studiach?

[B0FH 3]

świetnie.. kolejny idiotyczny "test" na tym forum wykonany na podstawie dziwnych kryteriów .. czyzby ktos robil to na zaliczenie na studiach?

a co jest idiotycznego w tym tescie i czemu kryteria są dziwne skoro to test bezpieczeństwa SSL, a tylko SSL odpowiada za szyfrowanie www? do idiotycznych rzeczy jeśli już coś się zalicza to Twój post imo

[MikeJones 25]

coz, jesli elementarnymi bledami bezpieczenstwa w jakims firemkach hostingowych okreslamy ataki takie jak beast, ktore po pierwsze sa bardziej teoria niz praktyka, a po drugie nawet mbank jest podatny na nie, to dla mnie taki raport ociera sie o smiesznosc

Edytowano Grudzień 23, 2012 przez MikeJones (zobacz historię edycji)

[kafi 2425]

a co jest idiotycznego w tym tescie

Ano np. to, czy jest to, czy wspomniane podatności dotyczą konfiguracji strony firmowej, czy też strony klienta, czy też czegoś tam innego.

Ponadto autor(zy?) tego zestawienia nie pofatygowali się nawet o sprawdzenie, czy analizują rzeczywiście to, co powinni...

Ot taki przykład - w zestawieniu podany jest ADRES i NAZWA. Weźmy sobie takie regdos.com. Wejdźmy na podaną w tabelce https://regdos.com. No i co nas wita na wejściu? Ano przeglądarkowy alert SSL o niepoprawnym CN certyfikatu

[B0FH 3]

coz, jesli elementarnymi bledami bezpieczenstwa w jakims firemkach hostingowych okreslamy ataki takie jak beast, ktore po pierwsze sa bardziej teoria niz praktyka, a po drugie nawet mbank jest podatny na nie, to dla mnie taki raport ociera sie o smiesznosc

jest napisane bezpieczeństwa SSL, a nie bezpieczeństwa

Ano np. to, czy jest to, czy wspomniane podatności dotyczą konfiguracji strony firmowej, czy też strony klienta, czy też czegoś tam innego.

Ponadto autor(zy?) tego zestawienia nie pofatygowali się nawet o sprawdzenie, czy analizują rzeczywiście to, co powinni...

Ot taki przykład - w zestawieniu podany jest ADRES i NAZWA. Weźmy sobie takie regdos.com. Wejdźmy na podaną w tabelce https://regdos.com. No i co nas wita na wejściu? Ano przeglądarkowy alert SSL o niepoprawnym CN certyfikatu

a co ma bezpieczeństwo szyfrowania w tym wypadku BEAST/CRIME do braku zaufania do certyfikatu? bo nie bardzo rozumiem, bo jak jets zaufany to nie szyfruje lepiej

 

zresztą, osobiście nie chce mi się już ich bronic, bo to co piszecie świadczy, że widocznie niezbyt rozumiecie o czym jest mowa w ogóle

Edytowano Grudzień 23, 2012 przez B0FH (zobacz historię edycji)

[Edart 239]

w raporcie są uwzględnione firmy których nie ma i to np. od około 2 lat, kiedy to było robione ? bezsensu jak dla mnie taka publikacja

[MikeJones 25]

@B0FH a to co Ty piszesz wyglada tak jakbys sam ten raport napisal...

[B0FH 3]

@B0FH a to co Ty piszesz wyglada tak jakbys sam ten raport napisal...

a co mam nalezec do Waszego towarzystwa wzajemnej adoracji? wole nie

 

a moze po prostu mam pojecie o tym co jest tam napisane?

bo Ty wyraznie nie, zobacz sobie CVE jaki jest poziom dla BEAST, to samo za siebie mowi

 

ataki takie jak beast, ktore po pierwsze sa bardziej teoria niz praktyka

 

Exploitability Subscore: 8.6
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-3389
Exploitability   = case Exploitability of
					unproven:			 0.85
					proof-of-concept:	 0.9
					functional:		   0.95
					high:				 1.00
		   		 not defined	 1.00

 

dalej chcesz sie wypowiadac w temacie o ktorym nie masz pojecia?

Edytowano Grudzień 23, 2012 przez B0FH (zobacz historię edycji)

[alphamale 0]

Raport jest ogólny i w sumie tylko kilka wylistowanych tam firm hostingowych nie istnieje (co nie umniejsza wartości całości). Konfiguracja SSL ogólnie chyba jest zaniedbywana. Raport może zwróci na to uwagę i polepszy stan bezpieczeństwa tych firm.

Edytowano Grudzień 23, 2012 przez alphamale (zobacz historię edycji)

[MikeJones 25]

@BOFH nie popusc w gacie.. zrob sobie https://www.ssllabs.com/ssltest/ dla mbnaku albo np. inteligo i zobacz co wyjdzie . "elementarne" bledy ssla w bankach? to z pewnoscia spisek. Albo autor raportu porwal sie z bazooka na muchy .

 

SSL Report: mbank.com.pl (193.41.230.81): "This server is vulnerable to the BEAST attack (more info)"

Edytowano Grudzień 23, 2012 przez MikeJones (zobacz historię edycji)

[B0FH 3]

@BOFH nie popusc w gacie.. zrob sobie https://www.ssllabs.com/ssltest/ dla mbnaku albo np. inteligo i zobacz co wyjdzie . "elementarne" bledy ssla w bankach? to z pewnoscia spisek. Albo autor raportu porwal sie z bazooka na muchy .

i gdzie tu nawiazanie do mojej wypowiedzi? zmieniasz temat bo nie potrafisz merytorycznie sie wypowiedziec? typowe dla ignorantow ktorzy sie popisuja na forum

[alphamale 0]

@BOFH nie popusc w gacie.. zrob sobie https://www.ssllabs.com/ssltest/ dla mbnaku albo np. inteligo i zobacz co wyjdzie . "elementarne" bledy ssla w bankach? to z pewnoscia spisek. Albo autor raportu porwal sie z bazooka na muchy .

 

No popatrz, a www.webhostingtalk.pl potrafił skonfigurować prawidłowo i włożyć w to pewnie z kwadrans

[B0FH 3]

No popatrz, a www.webhostingtalk.pl potrafił skonfigurować prawidłowo i włożyć w to pewnie z kwadrans

zycie, mnie po prostu slabi jak kolega MikeJones bagatelizuje blad bezpeiczenstwa, bo go nie rozumie i nie potrafi wykorzystac, widocznie nie jest dla pierwszego lepszego script kiddie, samo CVE mowi za siebie jak wysoko stoi exploitowalnosc BEAST i dlatego wole bronic tego "raportu" (lol), nizeli z wami stac po tej samej stronie

 

czekam MikeJones az sie merytorycznie ustosunkujesz do mojej wypowiedzi, jesli potrafisz , ciekawe jak bardzo znasz temat, ze tak doglebnie sie w nim wypowiadasz

Edytowano Grudzień 24, 2012 przez B0FH (zobacz historię edycji)

[MikeJones 25]

@BOFH Nawiazanie jest takie, ze atak beast to zaden wyznacznik elementarnego braku zabezpieczenia po stronie serwera, bo do jego wykonania jest potrzebny trojan u usera, podatna przegladarka www i podatne sa na niego nawet banki. rownie dobrze autor tego wspanialego raportu moglby oceniac bezpieczenstwo hostingow po tym, ze nie wysylaja jednorazowych hasel do logowania smsem.. juz rozumiesz czy jeszcze bedziesz zgrywal takiego co pozjadal wszysrtkie rozumy co potrafi przeczytac ale juz nie zinterpretowac rating danego buga? a "ustosunkowac" to wole sie z ladna dziewczyna.

[kafi 2425]

bo nie bardzo rozumiem, bo jak jets zaufany to nie szyfruje lepiej

Ano to, że w opisywanym przeze mnie przypadku CN certyfikatu wskazuje na domenę ok.com.pl.

Czemu więc w owym raporcie jest wpisany ADRES https://regdos.com?

Ano pewnie dlatego, że owy raport robiony był na odpierdziel

 

 

PS: Dla mnie untrusted issuer* albo tym bardziej błąd weryfikacji CN w środowisku internetowym

jest bardziej krytyczny niż podatności na wspomniane ataki. Bo skoro użytkownik ma w manualu do aplikacji

informację w stylu (wejdź na stronę, kliknij AKCEPTUJ w okienku ostrzeżenia przeglądarki i dalej się baw)

to jest to znacznie bardziej narażone na różnorakie ataki MITM niż jakieś specyficzne zaburzenia szyfrowania,

przy których większość klienckich browserów będzie także alertować.

 

PS2: Bezpieczeństwo SSL to nie tylko bezpieczeństwo samego szyfrowania. To także cała otoczka związana m.in. z bezpieczeństwem PKI.

 

* - untrusted issuer != selfsigned. Bo jeśli np. via zasady grupy rozprowadzi się certyfikat CA na stacje klienckie,

to nie ma nic złego w certyfikatach selfsigned. A nie będą z punktu widzenia klientów untrusted issuer.

Edytowano Grudzień 24, 2012 przez kafi (zobacz historię edycji)

[B0FH 3]

@BOFH Nawiazanie jest takie, ze atak beast to zaden wyznacznik elementarnego braku zabezpieczenia po stronie serwera, bo do jego wykonania jest potrzebny trojan u usera, podatna przegladarka www i podatne sa na niego nawet banki. rownie dobrze autor tego wspanialego raportu moglby oceniac bezpieczenstwo hostingow po tym, ze nie wysylaja jednorazowych hasel do logowania smsem.. juz rozumiesz czy jeszcze bedziesz zgrywal takiego co pozjadal wszysrtkie rozumy co potrafi przeczytac ale juz nie zinterpretowac rating danego buga? a "ustosunkowac" to wole sie z ladna dziewczyna.

umiesz czytac? przeczytaj nazwe tego dokumentu, ciagle dajesz do zrozumienia, ze nie potrafisz czytac, chyba ze to taka taktyka na brak argumentow

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

 

lol trojan i podatna przegladarka u usera potrzebna, stary poczytaj jeszcze o tym , forma obrazkowa http://www.youtube.com/watch?v=BTqAIDVUvrU

no tak, LAN czy trojan, co za roznica, pare literek zmienic i dodac

 

nie mam sily sie juz wypowiadac w tym temacie, bo nie masz zadncyh argumentow, nie rozumiesz bledu i albo udajesz jakiegos nie ten teges albo no coz... bo jest wyraznie napisane "bezpieczenstwa SSL" a nie "bezpieczenstwa", a co innego po stronie serwera jak SSL odpowiada za bezpieczenstwo transmisji np. logowania? no wiec, daj se siana... ja tez juz j/w nie pisze bo wszystko juz napisalem, a Ty niestety nic sensownego

Edytowano Grudzień 24, 2012 przez B0FH (zobacz historię edycji)

[Prohost 345]

MikeJones ma rację. Proponuję sprawdzić co to za atak i jak działa.

[MikeJones 25]

@BOFH no w 33 sekundzie Twojego filmiku stoi "beast attacks SSL in your browsers".. w 1:05 "beast consists of a network sniffer and Javascript/applet".. i jest on uruchamiany na komputerze usera. Pytasz co odpowiada za bezpieczenstwo logowania? no na pewno nie to, ze hosting ma dziurawego mysqla, php i apache podatne na 100 exploitow. najwazniejsze, ze jego SSL podatny jest na atak, do ktorego potrzeba zaangazowac 5x tyle roboty i gowno on Ci w przeliczeniu da . Dobrze Ci radze, daruj sobie juz te polemiki .

 

@#13 alphamale jakbyś się przyłozył do sprawy to byś zauwazyl, ze webhostingtalk.pl ma jako serwer http litespeeda.. a on sila rzeczy nie jest podatny na to co apache..

[alphamale 0]

@BOFH Nawiazanie jest takie, ze atak beast to zaden wyznacznik elementarnego braku zabezpieczenia ...

 

Otóż jest elementarnym brakiem zabezpieczenia SSL po stronie serwera. Konfiguracja SSL zajmuje nie więcej niż kwadrans, wliczając w to czas na poszukiwanie gotowych rozwiązań.

Trudno jest się nie zgodzić z raportem, że są to podatności, można je wykorzystać, a zabezpieczyć jest się bardzo łatwo, więc takie dyskutowanie jak mocne jest to uchybienie oraz jak trudne do wykorzystania nie ma sensu, skoro można w chwilę się zabezpieczyć. Sam sobie odpowiedziałeś - skoro można było się zabezpieczyć w parę chwil, to nic tylko teraz zakasać rękawy i poświęcić tą chwilę na to.

 

 

@BOFH no w 33 sekundzie Twojego filmiku stoi "beast attacks SSL in your browsers".. w 1:05 "beast consists of a network sniffer and Javascript/applet".. i jest on uruchamiany na komputerze usera. Pytasz co odpowiada za bezpieczenstwo logowania? no na pewno nie to, ze hosting ma dziurawego mysqla, php i apache podatne na 100 exploitow. najwazniejsze, ze jego SSL podatny jest na atak, do ktorego potrzeba zaangazowac 5x tyle roboty i gowno on Ci w przeliczeniu da . Dobrze Ci radze, daruj sobie juz te polemiki .

 

Toż to ignorancja i niezrozumienie celu raportu

 

@#13 alphamale jakbyś się przyłozył do sprawy to byś zauwazyl, ze webhostingtalk.pl ma jako serwer http litespeeda.. a on sila rzeczy nie jest podatny na to co apache..

 

Próbujesz w ten sposób kogoś zdyskredytować? Zadaj sobie inne pytanie, dlaczego inni nie mogli zainstalować serwera webowego, którego domyślna konfiguracja modułu SSL jest bezpieczna?

A co do błędów Apache, to nie błędy zw. tylko Apache ;]

 

Chciałbym w tym miejscu coś podsumować, według mnie raport fajny, bo pozwala dostrzec błędy bezpieczeństwa i to ewidentne! SSL2.0 - miazga, BEAST/CRIME trochę roboty przy ataku ale warto i można praktycznie wykorzystać, słabe szyfry - miazga.

Zamiast zauważyć, że raport z pewnością poprawi stan bezpieczeństwa klientów firm hostingowych, czyli coś jednak zmieni na lepsze, to po co wytykać nieistotne mankamenty publikacji?... a może koledzy pracują w którejś z firm z listy i próbują w ten sposób podważyć wiarygodność raportu... to by miało sens... aye

Edytowano Grudzień 24, 2012 przez alphamale (zobacz historię edycji)

[B0FH 3]

@BOFH no w 33 sekundzie Twojego filmiku stoi "beast attacks SSL in your browsers".. w 1:05 "beast consists of a network sniffer and Javascript/applet".. i jest on uruchamiany na komputerze usera. Pytasz co odpowiada za bezpieczenstwo logowania? no na pewno nie to, ze hosting ma dziurawego mysqla, php i apache podatne na 100 exploitow. najwazniejsze, ze jego SSL podatny jest na atak, do ktorego potrzeba zaangazowac 5x tyle roboty i gowno on Ci w przeliczeniu da . Dobrze Ci radze, daruj sobie juz te polemiki .

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

@#13 alphamale jakbyś się przyłozył do sprawy to byś zauwazyl, ze webhostingtalk.pl ma jako serwer http litespeeda.. a on sila rzeczy nie jest podatny na to co apache..

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...

 

dalej chcesz dyskutowac w tym temacie? bo ciagle sie kompromitujesz, a probujesz popisac i to jest wlasnie denerwujace, bo ewidentnie brak Ci podstaw

 

moze i do tego raportu dali jakas liste stron z chgw skad, ale co do bledow to sie ewidentnie czepiasz, co wynika z Twojej ignorancji, ja temat znam przypadkowo bo kolega pracuje z gosciem ktory jest autorem tego CVE, juz samo to ze BEAST ma medium CVE to powinno Ci dac do myslenia, ze bagatelizowanie to wiesz

 

polecam Ci poczytac przed kolejna wypowiedzia http://pl.wikipedia....rough_obscurity bo to ewidentny przyklad, ktory pokazuje ze nie masz nic wspolnego z bezpieczenstwem IT i slepo bronisz siebie i kolegow odpowiedzialnych za te hostingi

Edytowano Grudzień 24, 2012 przez B0FH (zobacz historię edycji)

[kafi 2425]

Zamiast zauważyć, że raport z pewnością poprawi stan bezpieczeństwa klientów firm hostingowych, czyli coś jednak zmieni na lepsze

Optymizm wręcz porażający. Na jakiej podstawie twierdzisz, że owy raport coś poprawi?

Pierwsza sprawa - napisany przez niewiadomo-kogo tak naprawdę. Imienia i nazwiska jakiegokolwiek brak. Ot po prostu brak jakiegokolwiek autorytetu znanego w branży albo środowisku nauki. Dla przeciętnego Kowalskiego informacja, że wspomniane ataki są niebezpieczne jest równie prawdziwa jak wymysły wikipediowych profesurów. Sorry Winnetou. Świata tym się nie zawojuje.

 

Tym bardziej, że na owej liście istnieją firmy, które już nie istnieją, niektóre mają błędy w stylu umieszczenia w tabeli adresu wywołującego alert o błędnym CN (czyli autor się nie wysilił nawet, aby takie błahostki zrobić poprawnie, to co dopiero jakość wykonania innych bardziej skomplikowanych rzeczy/analiz?)

 

a może koledzy pracują w którejś z firm z listy i próbują w ten sposób podważyć wiarygodność raportu... to by miało sens... aye

Cóż. Jak brakuje merytorycznych argumentów obalających krytykę, to zaczynają się pomówienia...

 

 

 

PS: Ja wcale nie neguję, że znaczna część wspomnianych serwisów ma ustawienia SSL zgodne ze stockową konfiguracją Apache. Nie neguję też tego, że podanych dziur nie da się jakoś wykorzystać.

Ale pisanie o elementarnym bezpieczeństwie SSL robiąc błędy w weryfikacji PKI będącej tak naprawdę fundamentem mechanizmu SSL i uznając, że to drobnostki to takie trochę dziwnawe...

Edytowano Grudzień 24, 2012 przez kafi (zobacz historię edycji)

[B0FH 3]

niektóre mają błędy w stylu umieszczenia w tabeli adresu wywołującego alert o błędnym CN (czyli autor się nie wysilił nawet, aby takie błahostki zrobić poprawnie, to co dopiero jakość wykonania innych bardziej skomplikowanych rzeczy/analiz?)

nie rozumiem Twojego toku rozumowania chyba, to inny url z ta sama domena by to zmienil Twoim zdaniem? i co ma zaufanie certu do BEAST/CRIME? nie ogarniam chyba... bo tak troche ja o kozie, Ty o wozie

Edytowano Grudzień 24, 2012 przez B0FH (zobacz historię edycji)

[kafi 2425]

i co ma zaufanie certu do BEAST/CRIME

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.

[Pan Kot 1535]

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" .