17:09
28/1/2012

* Włamanie na CDRinfo.pl

Nastąpiło wczoraj.

“Drogi/a XXX,

dzisiaj późnym wieczorem (27 stycznia) odkryliśmy włamanie na serwer forum.cdrinfo.pl. Ze wstępnej analizy wynika, że dane nie zostały naruszone, jednak ze względów bezpieczeństwa zdecydowaliśmy się zresetować hasła wszystkim użytkownikom. Pragniemy zapewnić, że nawet gdyby baza danych wyciekła z naszego serwera, zapisane hasła są zaszyfrowane.

Twoje nowe dane dostępowe to:
Nazwa Uzytkownika: XXX
Haslo: XXX

Po zalogowaniu zalecamy zmianę hasła:
http://forum.cdrinfo.pl/profile.php?do=editpassword

Jeżeli hasło było używane również na innych serwisach dla pewności radzimy je także zmienić.

Przepraszamy za utrudnienia.

Pozdrawiamy,
Administracja Forum CDRinfo.pl”

Podesłał Ferry.

Screenshot: http://img215.imageshack.us/img215/4917/forumcdri.png by szczuru

Przeczytaj także:

Ten wpis pochodzi z naszego linkbloga *ptr, dlatego nie widać go na głównej.
*ptr możesz czytać przez RSS albo przez sidebar po prawej stronie serwisu.

26 komentarzy

Dodaj komentarz
  1. Szybko, sprawnie i informatywnie… Dali rade.

    Pozdrawiam.

    Andrzej

  2. “Na szczęście” podmieniono tylko index.php forum. Reset haseł został wykonany tylko na wszelki wypadek.

  3. Skoro już zostaliśmy wywołani do tablicy, to napiszę, co zostało wykorzystane do włamania. Dziura była w skrypcie vBSEO. Wersja którą mieliśmy była najnowsza, jednak z wyjaśnień obsługi vBSEO wynika, że z jakiegoś powodu jeden z plików nie został zaktualizowany, mimo, że w poprzedniej wersji tej dziury nie było.

    Więcej szczegółów można znaleźć na forum vBSEO: http://www.vbseo.com/f5/vbseo-security-bulletin-all-supported-versions-patch-release-52783/

    • No to jedna z paru możliwych :)

    • @linc0ln.dll
      A coś więcej możesz zdradzić? :)

    • Kiedyś na Google latało kilka błędów.

  4. Z tego co pamiętam ktoś tam już dawno miał Access.

    • Twoi koledzy hakierzy mówisz? To fajnie synek ;)

    • haha :) Coś jeszcze? Czy już się spociłeś?

  5. Czy tylko ja zauważyłem “małe” kłamstwo?

    “zapisane hasła są zaszyfrowane.

    Twoje nowe dane dostępowe to:
    Nazwa Uzytkownika: XXX
    Haslo: XXX”

    Tak, widać kolejny serwis trzymający plaintext lub zaszyfrowane ale do wglądu przez adminów. Skandal! Ja się nie zgadzam, żeby KTO KOLWIEK znał moje hasło!

    • Po pierwsze, to ty powinienes mieć różne, unikalne hasło do każdego serwisu — wtedy to czy ktoś je zna, czy nie nie ma większego znaczenia.

    • To jest mail wysyłany do użytkownika. Unikalne hasło jest generowane dla każdego użytkownika i nikt poza nim samym nie ma do niego dostępu – chyba, że ktoś przechwyci maila :) Dlatego na końcu jest zdanie, że zalecamy zmianę tego hasła. Jeszcze raz powtarzam, że hasła w vBulletinie są trzymane w postaci posolonego hasha.

    • Bzdura – to żadne kłamstwo. Algorytm jest następujący:
      – generowanie jest hasło dla użytkownika
      – wysyłany jest mail z tym hasłem w treści
      – hasło jest zapisywane do bazy i szyfrowane

      Tym samym i nowe hasło jest w mailu i w bazie jest jedynie zahashowane.

      Gdyby w mailu było stare hasło to byłoby to faktycznie kłamstwo. Ale tutaj wysyłają nowe hasło. Taki algorytm kiedyś oprogramowywałem, więc wiem, że bez żadnych kłamst może to tak funkcjonować.

    • Not sure if trollin, but..
      Wygenerowali Ci nowe haslo, wyslali je w mailu a w bazie zapisali hash.

    • a zauważyłeś przy okazji słowo “nowe” umieszczone pomiędzy słowami “Twoje” oraz “dane”?

  6. Nawet nie wiedziałem że ta strona jeszcze żyje :)

  7. *cough* KeePass/KeePassX i do wszystkiego oddzielne hasło *cough*

  8. A czy można wiedzieć jakim algorytmem zahashowane są hasła? Jeśli użyto MD5 to hash zamiast plaintext jest marnym pocieszeniem…

  9. Oh, jak ja lubie tych ekspertów od “MD5 to prawie jak plaintext”.

    • @c > Jakiś czas temu trafiłem na informację o możliwości wygenerowania zadanego skrótu MD5 w czasie ok. minuty na dość słabym sprzęcie – w takiej sytuacji faktycznie nie ma _jeszcze_ mowy o odwróceniu funkcji i odzyskaniu oryginalnego hasła (co przy losowym salt’cie zabezpiecza inne skróty z tego samego hasła).
      Pytanie – czy znając salt (jak rozumiem również był przechowywany w bazie celem weryfikacji hasła) i hash, przy użyciu metody przedstawionej przez Vlastimila Klima (http://eprint.iacr.org/2006/105) odnajdywania kolizji MD5, nie jest możliwe odgadnięcie oryginalnego hasła w rozsądnym czasie (szukając kolejnych kolizji)?

    • Przy samym hashu to już wszystko zależy od użytkownika. Jeśli ustawi hasło dupa8 marcin1 czy admin1 to już właściwie jego wina, bo to nie ważne czy plaintext czy md5 to 10 minut i po haśle. Kiedyś z ciekawości wrzuciłem wszystkie hashe ze swojego forum do freerainbowtables. Miałem wtedy z 10tys. userów. Odszyfrowanych zostało 85 czy 95 procent haseł. Ale chyba 85%. Więc wszystko zależy od użytkowników i ich świadomości, jak być bezpiecznym.

    • @Marek:
      Ale przeczytałeś ten papier i zrozumiałeś o co w nim chodzi? O ile moje skromne zdolności kryptograficzne pozwalają mi to ogarnąć, to chodzi o atak w którym dla jawnego kawałka tekstu szukasz innego kawałka tekstu, który da ci taki sam skrót MD5 – papier mówi o przyśpieszeniu metody znajdowania kolizji.

      Oczywiście, MD5 nie powinno się już używać – ale to nie jest tak, że jak masz hasła z saltem w MD5 to nagle prawie plaintext i temu podobna panika.

    • @c:
      >Ale przeczytałeś ten papier
      Masz mnie :P W czasie gdy trafiłem na tę informację (i wyrobiłem sobie zdanie na temat łatwości ataków na MD5) przeczytałem tylko abstract i artykuł, który referował do niego. Pojęcie kolizji funkcji skrótu jest mi znane tylko kontekście ogólnoalgorytmicznym i algebraicznym. Stąd zresztą moje wcześniejsze pytanie (kryptografię znam w bardzo ogólnych zarysach).
      Słusznie zwróciłeś uwagę na powierzchowność mojej opinii.

      Żeby zamknąć temat – czy dobrze rozumiem, że w grę wchodzi zatem tylko atak słownikowy?

  10. Środa, 9 rano, a baza forum leży ponownie:

    Database error
    The Forum CDRinfo.pl database has encountered a problem.

    Cóż, ceniłem skrypt VB w wersji 2.x za prostotę. Trójka to jak dla mnie twór pełen zbędnych wodotrysków – i efekty tego właśnie widać.

    • To raczej wina MySQL nie vB. Drobny crash jednej z tabeli trzymającej cache postów. Wyłapany po kilku min i naprawiony. Nie ma powodów do paniki ;)

    • Bo w wersji 2.x nie robli to jeszcze tylko dla kasy. Teraz robią, i nie zwracają uwagi na błędy.

Twój komentarz

Zamieszczając komentarz akceptujesz regulamin dodawania komentarzy. Przez moderację nie przejdą: wycieczki osobiste, komentarze nie na temat, wulgaryzmy.

RSS dla komentarzy: