Bardziej szczegółowe omówienie incydentu związanego z bezpieczeństwem z maja 2019 r .: opinie na blogu
Właśnie opublikowaliśmy aktualizację incydentu związanego z bezpieczeństwem, który wydarzył się w maju 2019 r., Ze szczegółami technicznymi dotyczącymi tego, co się stało, jak to się stało, oraz środków zaradczych, które zastosowaliśmy, aby zapobiec ponownemu wystąpieniu takiego incydentu. Oto kilka fragmentów postu - pierwszy z wprowadzenia:
12 maja 2019 roku około godziny 00:00 czasu UTC zostaliśmy ostrzeżeni o nieoczekiwanej eskalacji uprawnień dla nowego konta użytkownika przez wielu członków społeczności. Użytkownik, którego nikt nie rozpoznał, uzyskał dostęp na poziomie moderatora i programisty we wszystkich witrynach sieci Stack Exchange Network. Naszą natychmiastową reakcją było odebranie uprawnień i zawieszenie tego konta, a następnie uruchomienie procesu identyfikacji i kontroli działań, które doprowadziły do zdarzenia.
Po wstępnym odkryciu stwierdziliśmy, że eskalacja uprawnień była tylko wierzchołkiem góry lodowej, a atak w rzeczywistości spowodował eksfiltrację naszego kodu źródłowego i nieumyślne ujawnienie informacji umożliwiających identyfikację (e-mail, prawdziwe imię i nazwisko, adresy IP) 184 użytkowników sieci Stack Exchange (wszyscy zostali powiadomieni). Na szczęście żadna z baz danych - ani publiczna (czytaj: zawartość Stack Exchange), ani prywatna (Teams, Talent czy Enterprise) - nie została eksfiltrowana. Ponadto nie ma dowodów na bezpośredni dostęp do naszej wewnętrznej infrastruktury sieciowej, a osoba atakująca nigdy nie miała dostępu do danych w produktach Teams, Talent lub Enterprise.
A z ostatniego akapitu:
Ten incydent przypomniał nam o kilku podstawowych praktykach bezpieczeństwa, których wszyscy powinni przestrzegać:
- Rejestruj cały ruch przychodzący. Prowadzimy dzienniki wszystkich połączeń przychodzących. Umożliwiło to wszystkie nasze dochodzenia. Nie możesz zbadać, czego nie rejestrujesz.
- Użyj 2FA. Ten pozostały system, który nadal korzysta ze starszego uwierzytelniania, może być Twoją największą luką w zabezpieczeniach.
- Lepiej strzeż tajemnic. TeamCity ma sposób na ochronę tajemnic, ale okazało się, że nie używamy go konsekwentnie. Poinformuj inżynierów, że „sekrety to nie tylko hasła”. Chroń również klucze SSH i parametry połączeń z bazą danych. W razie wątpliwości chroń je. Jeśli musisz przechowywać sekrety w repozytorium Git, chroń je za pomocą git-crypt lub Blackbox .
- Weryfikuj żądania klientów. Im bardziej niezwykłe jest żądanie klienta, tym ważniejsze jest sprawdzenie, czy żądanie jest uzasadnione.
- Traktuj raporty bezpieczeństwa poważnie. Jesteśmy wdzięczni, że nasza społeczność tak szybko zgłosiła podejrzaną aktywność. Dziękuję Ci!
W poście na blogu jest o wiele więcej - nie krępuj się zadawać pytań lub komentarzy związanych z poniższym postem, a my dołożymy wszelkich starań, aby na nie odpowiedzieć. Nie możemy komentować żadnych innych szczegółów związanych z atakiem poza tym, co jest zawarte w poście na blogu, ze względu na trwające dochodzenia.
Odpowiedzi
Czy możesz skomentować zamiary napastników?
Czy wygląda na to, że szukali określonego celu / pewnych danych (użytkowników)?
A może raczej „ciekawski nastolatek” szperający patykami, sprawdzający, jak daleko mogą się dostać?
PS dzięki za otwartość w tej sprawie, to naprawdę doceniane!
Ta linia:
Ten akt wyszukiwania rzeczy (pytań odwiedzin) w sieci Stack Exchange staje się częstym zjawiskiem i pozwala nam przewidzieć i zrozumieć metodologię atakującego w nadchodzących dniach. (podkreślenie moje)
sprawia, że brzmi to jak w czasie rzeczywistym , ponieważ atak miał miejsce, można było określić, co zrobiłby atakujący na podstawie tego, co odwiedził w Stack Overflow, zamiast tego, co zrobił, patrząc na to, co zobaczyli (po ataku). Który miałeś na myśli?
Kilka pytań związanych głównie z napastnikiem:
- Co się stało z napastnikiem?
- Czy zawiesiłeś ich konto?
- Czy SE skontaktowało się z napastnikiem w dowolnym momencie?
- Dlaczego nie ujawnisz tożsamości napastnika?
- Czy ktoś inny próbował później użyć tej samej metody ataku?
Czy po drugiej stronie wydarzeń był wykrywalny cykl snu?
Edytuj, aby wyjaśnić:
Kiedy zdałeś sobie sprawę z napastnika i śledziłeś niektóre z ich działań w miarę ich rozwoju, czy zauważyłeś coś przypominającego cykl biologiczny, zarówno codzienny, jak i retrospektywny? Np .: Jedzenie (1-2 godzinne przerwy), spanie (8-godzinny wzorzec braku aktywności), „drzemki” (90 minut), itd.?
To nie jest tak naprawdę część incydentu, ale bardziej ogólne obawy dotyczące środków bezpieczeństwa wokół kont pracowników. Incydent składał się z wielu etapów, ale ostatnim z nich było zwiększenie uprawnień konta SE. Mogę sobie wyobrazić o wiele prostsze sposoby, aby spróbować tego, niż uzyskanie dostępu administratora do serwera CI za pośrednictwem instancji deweloperskiej w celu wykonania kodu SQL w środowisku produkcyjnym, i interesuje mnie, jakie środki zaradcze i praktyki bezpieczeństwa wdrożyło SE, aby chronić się przed prostszymi próbami uzyskania dostęp do konta pracownika.
Nie możesz oczywiście umieścić głównych witryn SE za zaporą ogniową, więc zawsze będą one narażone. A wewnętrzna metoda logowania SE nie zapewnia żadnych metod 2FA, co wydaje mi się nieco niepokojące.
- czy konta pracowników 2FA są chronione za pomocą innych środków (lub innych dostawców logowania)?
- Czy są jakieś środki zapewniające, że żadne prywatne adresy e-mail ani dostawcy logowania nie są dołączani do kont pracowników, które mogłyby być mniej bezpieczne i nadal służyć do otrzymywania wiadomości pomocniczych w celu uzyskania dostępu do konta?
- czy istnieje monitorowanie prób logowania z nowych źródeł na konta pracowników?
- czy istnieją dodatkowe zabezpieczenia dla niebezpiecznych narzędzi pracowników na wypadek, gdyby ktoś uzyskał dostęp do trwającej sesji konta pracownika (np. wymaganie ponownego hasła i / lub tokena 2FA podczas uzyskiwania dostępu do narzędzi krytycznych dla bezpieczeństwa)
Coś takiego jak spear phishing jest prawdopodobnie nadal jednym z bardziej prawdopodobnych sposobów, w jakie ktoś może próbować uzyskać dostęp do konta pracownika.
Mniej więcej w tym samym czasie, gdy miał miejsce ten incydent bezpieczeństwa, kilka dni później niektórzy użytkownicy zaczęli zauważać, że połączenie na Twitterze na czacie już nie działa . Pracownik następnie potwierdził w lutym następnego roku, że rzeczywiście został celowo niepełnosprawny z powodu konieczności „wypełnienia niektórych luk” w wyniku tego incydentu związanego z bezpieczeństwem.
Czy możemy uzyskać pełne wyjaśnienie, dlaczego korzystanie z Twittera na czacie musiało zostać wyłączone w wyniku tego incydentu związanego z bezpieczeństwem? W opublikowanym wówczas poście na blogu stwierdzono, że „inne potencjalne wektory” zostały wówczas zamknięte, a wiadomość od personelu z lutego 2020 r., Do której dołączyłem powyżej, stwierdzała, że funkcja oneboxingu na Twitterze „wykorzystała jedną z luk, które zlikwidowaliśmy”. Co to było i jakie zagrożenie bezpieczeństwa stwarzało?
Wreszcie, czy jest jakiś sposób, aby ta funkcjonalność mogła zostać ponownie zaimplementowana w bezpieczny sposób? W sierpniu 2020 r., Kilka miesięcy po powyższym komunikacie personelu, zgłoszony wówczas raport o błędzie został oznaczony jako status-bydesign przez innego pracownika. Czy żądanie funkcji przywrócenia projektu (w bezpieczny sposób) byłoby rozważane, czy też nie można tego zrobić bez otwarcia wektora ataku?
Oznaczałbym, że typy parametrów „hasło” w TeamCity nie są uważane za zbyt bezpieczne:
Wartość hasła jest przechowywana w plikach konfiguracyjnych w TeamCity Data Directory. W zależności od ustawień szyfrowania serwera, wartość jest zaszyfrowana lub zaszyfrowana przy użyciu klucza niestandardowego.
Wartość dziennika kompilacji jest ukryta za pomocą prostego algorytmu wyszukiwania i zamiany, więc jeśli masz trywialne hasło „123”, wszystkie wystąpienia „123” zostaną zastąpione, potencjalnie ujawniając hasło. Ustawienie parametru na typ hasła nie gwarantuje, że nie będzie można pobrać wartości surowej. Każdy administrator projektu może go pobrać, a każdy programista, który może zmienić skrypt kompilacji, może potencjalnie napisać złośliwy kod, aby uzyskać hasło.
Dlaczego magiczne łącze w programie deweloperskim było widoczne dla CM (prawdopodobnie tylko w programie deweloperskim) było prawdziwym magicznym linkiem?
To naprawdę niesamowity raport z incydentu! Jeden z najlepszych, jakie przeczytałem.
Dziękuję Stack za upublicznienie tego i Dean za wspaniały tekst!
Ciekawi mnie tylko kilka rzeczy:
- Jaka jest wielkość zespołu reagowania na incydenty?
- Czy podczas dochodzenia przestrzegano jakichś szczegółowych protokołów?
- Jaki kluczowy czynnik był brany pod uwagę przy zaangażowaniu zewnętrznego dostawcy zabezpieczeń? Jakie punkty wzięto pod uwagę przy wyborze tego konkretnego dostawcy?
- Jakie wnioski wyciągnięto od zewnętrznego dostawcy zabezpieczeń? Czy ich proces audytu był inny (skuteczny / nieefektywny) od tego, z którego już korzystał zespół?
Artykuł daje dobry wgląd w całą architekturę Stack i procesy rozwojowe. Bardziej szczegółowa lektura lub link, jeśli istnieje już artykuł na ten temat, byłby świetny.
W sekcji „Porady dla innych”:
Rejestruj cały ruch przychodzący. Prowadzimy dzienniki wszystkich połączeń przychodzących. Umożliwiło to wszystkie nasze dochodzenia. Nie możesz zbadać, czego nie rejestrujesz.
W jaki sposób sieć tak obciążona jak Stack Exchange może rejestrować cały ruch przychodzący? Czy w tych dziennikach są wpisy serwera WWW, przepływy adresów IP czy pełne sesje TCP?
Mogę zarejestrować większość wpisów i prób połączenia w mojej małej sieci, ale nie mam pojęcia, jak robi to tak duża sieć.
Czy możesz jaśniej wyjaśnić, co oznaczają „nieruchomości dostępne publicznie” w poniższym cytacie?
mamy bazę danych zawierającą dziennik całego ruchu do naszych publicznie dostępnych właściwości