15/11/2014
Wczoraj informowaliśmy o kilku podatnościach, które w kodzie forum zostały znalezione przez naszego rodaka, Smasha_ — okazuje się jednak, że w tym samym czasie ktoś włamał się na konto GitHuba jednego z developerów MyBB, dzięki czemu udało mu się zmodyfikować projekt tak, że został do niego wstrzyknięty złośliwy kod (wykonujący kopię bazy danych forum).
Jeśli od wczoraj (14.11 od godz. 23:00) do dziś (15.11 do 16:30) logowaliście się do panelu administracyjnego swojego forum, to najprawdopodobniej zostaliście zaatakowani (uruchomiliście kod JavaScript odpowiedzialny za kradzież bazy danych) — aby się upewnić ponad wszelką wątpliwość, sprawdźcie logi backupowe (Tools & Maintenance -> Database Backups) — backup wykonany w czasie wskazanym powyżej oznacza udany atak.
W przypadku udanego ataku należy powiadomić swoich użytkowników aby zmienili hasła. Ty też zmień hasło do forum i wyczyść ciasteczka.
Weź udział z kolegami w jednym z naszych 8 cyberwykładów. Wiedzę podajemy z humorem i w przystępny dla każdego pracownika sposób. Zdalnie lub u Ciebie w firmie. Kliknij tu i zobacz opisy wykładów!
Każdy powinien zobaczyć te webinary! Praktyczna wiedza i zrozumiały język. 6 topowych tematów — kliknij tutaj i zobacz szczegółowe opisy oraz darmowy webinar.
No jasne. Podstawowy błąd usability.
Kto robi sprawdzanie update’ów na zdalnym serwerze po stronie klienta i to w wersji pozwalającej wstawić tam xss’a? Takie rzeczy robi się via XML i to ze sprawdzeniem zarówno sumy kontrolnej, jak i czy numer wersji na pewno ma postać X.Y.Z. Nie mówiąc o tym, że po stronie serwera.
@Lukasz032
Tyle tylko, że sprawdzanie aktualizacji jest robione po stronie serwera i via XML, a do tego MyBB ma funkcje do weryfikacji sum kontrolnych plików (tylko post factum i nie ma żadnej obsługi błędów poza przekazaniem informacji do admina, ale zawsze coś). Z Twoich świetnych porad, tylko ta dotycząca weryfikacji postaci numeru wersji cokolwiek wprowadza do tematu. Ale nie oszukujmy się — podmiana numeru wersji nie jest standardowym wektorem ataku i nie jest omawiana w ramach ITsec 101.
Nie określiłbym błędu programistów MyBB słowem „podstawowy” (nie jest to również błąd usability, ale to tak na marginesie). Skrypt PHP wykonywany w ramach konstrukcji panelu administracyjnego (czyli z założenia strony o ograniczonym dostępie) pobiera plik z oficjalnej strony internetowej programu (z założenia w pełni kontrolowanej przez zaufane osoby) i wyświetla informacje w nim zawarte. Można się czepiać, że komunikacja nie odbywa się bezpiecznym kanałem a odebrane dane nie są sprawdzane pod kątem potencjalnie szkodliwych fragmentów, ale to jest byle silnik forum dyskusyjnego a nie panel kontrolny rakiet z ładunkiem nuklearnym. Wszystkie PODSTAWOWE zabezpieczenia zostały zaimplementowane.
Tylko, jak widać, podstawowe zabezpieczenia to czasem za mało i dla dobra użytkowników warto wzbić się na wyżyny paranoi i weryfikować poprawność danych wysyłanych przez samego siebie.
Akurat często piszę webaplikacje, więc wiem, o czym mówię. Weryfikacja danych wysyłanych przez “samego siebie” to w tym przypadku (sprawdzanie aktualizacji, klucza produktu, a już absolutnie przy autoupdate) nawet konieczność. Załóżmy, że byłaby to aplikacja komercyjna aktywowana internetowo. Cracker podstawiając w dns-ie własny serwer za serwer aktywacji może – przy tak zbudowanym “algorytmie” walidacji tego co program dostaje – w prosty sposób ominąć aktywację i okresowe sprawdzanie licencji i zrobić po prostu nulleda. To samo z autoupdate – przejmując kontrolę nad tym, co w dns-ie serwera jest serwerem producenta i mając całkowity brak sprawdzania sumy kontrolnej wersji aktualizacji, albo algorytm jawny (np. crc32 bez ziarna), potencjalny włamywacz może podsunąć do zainstalowania aktualkę będącą po prostu trojanem.
No dobra, ale gdzie znajduje się złośliwy kod?
Czy to tyczy się wszystkich wersji MyBB czy tylko 1.8.x? Wciąż z pewnych powodów używam MyBB 1.6.15 i w kopiach bazy danych nie mam kopi z podanego wyżej okresu.
PS. mybboard.pl nie działa.
“Z pewnych powodów”. Ta. Możliwość usunięcia hashowania bez przekopywania tysiąca linijek kodu.
Wszystkich.
@dsadsadas
może się nie znam, ale w takim wypadku chyba łatwiej zapisać hasło przed hashowaniem?
@kamil – można sobie wysłać login i hasło na mail przy logowaniu się użytkowników. Nawet było kilka takich przypadków.