Jak włamano się do BrowserStack, czyli uczmy się na cudzych błędach

Kilka dni temu doszło do włamania do serwerów firmy BrowserStack. Włamywacz uzyskał kontrolę nad bazą danych klientów i rozesłał do nich złośliwego emaila. Firma stanęła na wysokości zadania i opublikowała szczegółową analizę wartą lektury.

Testowanie tworzonych stron WWW od zawsze było poważnym problemem z uwagi na mnogość przeglądarek, ich wersji oraz  platform, na których mogą zostać one użyte. BrowserStack rozwiązuje ten problem, oferując dostęp do wirtualnej maszyny, w której czeka na użytkownika większość przeglądarek gotowych do rozpoczęcia testów. Zaufanie klientów firmy zostało jednak nadszarpnięte po tym, jak ich część otrzymała niepokojącego emaila.

Zamykamy działalność a oto nasze hasła

Cztery dni temu grupa klientów firmy otrzymała wiadomość pod tytułem „BrowserStack kończy działalność”. W treści znajdowały się przeprosiny oraz informacja o zamknięciu firmy ze względu na katastrofalne błędy bezpieczeństwa. Według wiadomości wszystkie serwery klientów oferowały dostęp przez VNC z publicznych adresów IP, zabezpieczony jedynie hasłem nakula, a dodatkowo każdy z nich posiadał dostępne zdalnie konto root z hasłem c0stac0ff33. Email informował również, że jest praktycznie pewne, że wszystkie serwery zostały już dawno spenetrowane przez włamywaczy.

Wiadomość dla klientów BrowserStack

Jak doszło do włamania

Firma szybko poinformowała, ze doszło do włamania do jej sieci a wczoraj opublikowała szczegółowe wyjaśnienia. Omówimy je krok po kroku.

BrowserStack działa w oparciu o usługi Amazon Web Services. Posiada tysiące serwerów, z których jeden padł ofiarą włamania. Jak się okazuje jeden serwer czasem wystarcza, by skutki mogły być katastrofalne. Była to maszyna „prototypowa”, stworzona w roku 2012 i już od jakiegoś czasu nieużywana. Okazało się, że była ona podatna na błąd Shellshock, a firma jej nie załatała, bo… nikt jej już nie używał.

To był jednak tylko początek i jeszcze nie oznaczał katastrofy, która nadchodzi w kolejnym paragrafie. Na tej nieużywanej, ale ciągle aktywnej maszynie, włamywacz znalazł klucze AWS API, które umożliwiły mu kontrolę nad środowiskiem firmy. Włamywacz stworzył sobie zatem własnego użytkownika, nadał mu odpowiednie uprawnienia, dodał swój IP do białej listy, podłączył kopię bezpieczeństwa, odzyskał z niej hasła do bazy danych i zaczął kopiować tablicę z danymi użytkowników. Duża operacja bazodanowa zapaliła czerwone światełka, dostęp został zablokowany, ale włamywacz zdążył jeszcze rozesłać do ok. 5000 klientów firmy wiadomość cytowaną powyżej.

Firma sprawdziła za pomocą usługi AWS CloudTrail, że pobranie fragmentu bazy danych i rozesłanie wiadomości były jedynymi szkodliwymi operacjami wykonanymi przez włamywacza. Co jednak z hasłami przez niego ujawnionymi? Firma twierdzi, że faktycznie takie hasła były używane na serwerze testowym, jednak firma już dawno przeszła na uwierzytelnienie za pomocą kluczy a dla każdej sesji VNC są generowane nowe hasła jednorazowe.

Wnioski z włamania

Firma oczywiście oprócz przeprowadzenia analizy logów w celu ustalenia skali włamania podjęła także dalsze kroki takie jak:

• wymiana wszystkich haseł i kluczy
• wdrożenie szyfrowania kopii bezpieczeństwa
• dodanie dodatkowych mechanizmów monitoringu podejrzanych zachowań
• odtworzenie wszystkich klienckich maszyn wirtualnych z zaufanych obrazów
• zlecenie pełnego audytu bezpieczeństwa infrastruktury.

Lekcje dla tych, którzy nie musieli się tłumaczyć z tego włamania:

• każda działająca maszyna musi być objęta programem aktualizacji
• jeżeli jakąś maszyna jest niepotrzebna, to trzeba ją wyłączyć
• klucze i hasła nie powinny leżeć tam, gdzie nie są potrzebne
• nie używaj jako hasła imienia założyciela firmy i nazwy jego ulubionej kawiarni
• kopie bezpieczeństwa trzeba szyfrować
• na maszynach testowych też trzeba trzymać się standardów bezpieczeństwa.

Nie życzymy nikomu wyjaśniania swoim przełożonym lub klientom przyczyn podobnego incydentu we własnej firmie.