JetBrainstwórca A ciągła integracja I dostawa (CI/CD) o nazwie TeamCity i firma zajmująca się bezpieczeństwem cybernetycznym Szybki7to wymiana zdań w związku z obsługą dwóch poważnych luk w zabezpieczeniach usługi, gdy klienci spieszą się z łataniem w obliczu potwierdzonego wykorzystania.
Obydwa problemy, o których mowa, są oznaczone jako CVE-2024-27198 i CVE-2024-27199. Pierwsza to błąd polegający na obejściu uwierzytelniania w komponencie sieciowym TeamCity poprzez alternatywny problem z przejściem, z bazowym wynikiem CVSS wynoszącym 9,8, co oznacza, iż jest to problem krytyczny. Drugi ma ten sam efekt, ale jego podstawowy wynik CVSS wynosi 7,3.
W poście na blogu Rapid7 szczegółowo opisującym problemygłówny badacz Rapid7, Stephen Fewer, który odkrył luki, napisał: „Złamanie zabezpieczeń serwera TeamCity pozwala atakującemu na pełną kontrolę nad wszystkimi projektami, kompilacjami, agentami i artefaktami TeamCity i jako taki jest odpowiednim wektorem do ustawienia atakującego w celu wykonania dostawy atak łańcuchowy.”
U podstaw nieporozumienia leży różnica w podejściu do ujawniania luk w zabezpieczeniach i łatania ich.
Luki zostały ujawnione firmie JetBrains w ramach skoordynowanej polityki ujawniania informacji w czwartek 15 lutego 2024 r. JetBrains potwierdziło to w poniedziałek 19 lutego i powtórzyło problemy we wtorek 20 lutego po otrzymaniu analizy technicznej od Rapid7.
W wersji narracji Rapid7 JetBrains zasugerował następnie prywatne udostępnianie poprawek przed publicznym ujawnieniem. W odpowiedzi podkreśliła znaczenie skoordynowanego ujawniania informacji i przedstawiła swoje stanowisko przeciwko tzw. cichym łataniom.
Następnie na kilka dni było cicho, aż do piątku 1 marca, kiedy Rapid7 wrócił do JetBrains i ponownie poprosił o więcej informacji na temat wersji TeamCity, których dotyczy problem, oraz wskazówek dotyczących łagodzenia skutków dla dostawców. Poinformowano ją o przyznanych numerach CVE, ale poza tym powiedziano, iż sprawa jest przez cały czas badana.
Następnie, w poniedziałek 4 marca, bez komunikacji z Rapid7, JetBrains opublikował blog ogłaszający wydanie nowej wersji TeamCity, która załatała luki. Rapid7 stwierdziło, iż wyraziło zaniepokojenie faktem, iż łatka została wydana bez powiadomienia i koordynacji oraz bez opublikowanych porad.
Zgodnie z własną polityką ujawniania luk w zabezpieczeniach, jeżeli Rapid7 dowie się, iż wydano cichą łatę, „będzie dążyć do opublikowania” szczegółów luki w ciągu 24 godzin, co teraz uczyniło.
Od tego czasu JetBrains opublikował blog na ten tematoraz poradę i stwierdził, iż CVE uwzględniono w informacjach o wydaniu nowej wersji TeamCity, ale nie odpowiedział bezpośrednio na obawy Rapid7 dotyczące nieskoordynowanego ujawnienia.
W wersji historii JetBrainsnie kwestionuje, iż zaproponowała coś, co Rapid7 określiłaby jako cichą łatkę, utrzymując jednak, iż zastosowano tę metodę ujawniania jego skoordynowana polityka ujawniania informacji.
Oznajmiła, iż chce podążać tą ścieżką, aby umożliwić klientom podjęcie świadomej decyzji co do poziomu ryzyka, dać im czas na aktualizację i w międzyczasie powstrzymać mniej wykwalifikowanych atakujących przed wykorzystaniem luk.
Firma JetBrains podała, iż podjęła decyzję o nieujawnianiu skoordynowanego ujawnienia po tym, jak dowiedziała się, iż będzie to oznaczać, iż Rapid7 opublikuje pełne szczegóły techniczne luk w tym samym czasie, gdy wypuszczą łaty.
„Powstając, nigdy nie mieliśmy zamiaru wypuszczać poprawki po cichu, bez upublicznienia wszystkich szczegółów. Jako organ numerujący CVE (CNA) przypisaliśmy identyfikatory CVE obu problemom następnego dnia po otrzymaniu raportu” – napisał Daniel Gallo, inżynier ds. rozwiązań TeamCity w JetBrains.
„Zaproponowaliśmy ujawnienie szczegółów luk w zabezpieczeniach w taki sam sposób, jak postępowaliśmy w przeszłości, z opóźnieniem czasowym pomiędzy wydaniem poprawki a dokonaniem pełnego ujawnienia, co umożliwia naszym klientom aktualizację instancji TeamCity.
„Ta sugestia została odrzucona przez zespół Rapid7, który opublikował szczegółowe informacje na temat luk i sposobów ich wykorzystania kilka godzin po udostępnieniu poprawki klientom TeamCity”.
Ciche łatanie: zły pomysł
Podejście do skoordynowanego ujawniania informacji przyjęte przez Rapid7 jest powszechnie akceptowane i całkowicie normalne w świecie bezpieczeństwa cybernetycznego, chociaż JetBrains nie stwierdził wyraźnie, dlaczego odrzuca takie podejście, napiszę w 2022rgłówny menedżer ds. badań nad bezpieczeństwem Rapid7, Tod Beardsley, przedstawił możliwe wyjaśnienie, stwierdzając, iż na pierwszy rzut oka ciche łatanie może wydawać się niektórym odpowiednie, ponieważ wydaje się ograniczać grupę osób, które rozumieją problem i potrafią z niego skorzystać .
Wyjaśniając, dlaczego tak się nie dzieje, Beardsley napisał: „Kiedy firma produkująca oprogramowanie wypuszcza łatkę… w pewnym momencie musi zmodyfikować kod działającego oprogramowania, co oznacza, iż wszystko jest dostępne dla wszystkich, kto ma uruchomioną instancję poprawionego systemu i wie, jak używać debugera i dezasemblera. A kto używa debugerów do sprawdzania efektów poprawek? Programiści wykorzystujący exploity, prawie wyłącznie.”
Mając to na uwadze, stwierdził Beardsley, ciche łatanie w rzeczywistości ogranicza wiedzę o załatanych lukach do wykwalifikowanych twórców exploitów, czyli aktorów zagrożeń, więc chociaż prawdą jest, iż ciche łatanie eliminuje przypadkowych, nisko wykwalifikowanych hakerów i dzieciaków zajmujących się skryptami, wyklucza to również dobrych ludzi, legalnych testerów pióra, twórców technologii defensywnych, osoby reagujące na incydenty i całą społeczność cybernetyczną, która mogłaby skorzystać na lepszym zrozumieniu problemu i skutecznym zakomunikowaniu go.
„Co najważniejsze, wykluczasz najważniejszą grupę odbiorców swojej poprawki: zwykłych administratorów i menedżerów IT, którzy muszą sortować przychodzący przepływ poprawek w oparciu o pewne kryteria ryzyka i ważności oraz wzywać do przestojów i planowania aktualizacji w oparciu o to kryterium. Nie wszystkie luki w zabezpieczeniach są sobie równe i chociaż obrońcy chcą obejść je wszystkie, muszą dowiedzieć się, które z nich zastosować już dziś, a które mogą poczekać do następnego cyklu konserwacji” – napisał.
Podsumowując argumentację Rapid7, Beardsley powiedział, iż ciche łatanie przekazuje szczegóły luk w zabezpieczeniach „wyłącznie” wykwalifikowanym cyberprzestępcom i aktorom z państw narodowych, którzy już obierają za cel produkt podatny na ataki.
„To wszystko oznacza, iż ciche łatanie jest równoznaczne z pełnym ujawnieniem informacji bardzo małej grupie odbiorców, która przede wszystkim chce skrzywdzić Ciebie i Twoich użytkowników” – podsumował.
W przypadku nowych luk w TeamCity znaczenie skoordynowanego ujawniania nabiera dodatkowego znaczenia, biorąc pod uwagę, iż poprzednie błędy w usłudze były intensywnie wykorzystywane przez nikogo innego jak APT29, znanego również jako Cozy Bearjednostka cybernetyczna rosyjskiego wywiadu zagranicznego (SVR).
Dla użytkowników TeamCity on-premise, którzy znaleźli się w krzyżowym ogniu – wersje chmurowe są w pełni załatane – wskazówki są proste; nieudane ujawnienie oznacza, iż odebrano możliwość oceny czynników ryzyka i jedynym rozwiązaniem jest natychmiastowe załatanie.
