Kiteworks odkrywa lukę po awaryjnym shutdownie
Kiteworks po dziewięciogodzinnym wyłączeniu ujawnia krytyczną lukę i wraca do normalnej pracy. Zagrożenie nie zostało wykorzystane.
Kiteworks odkrywa krytyczną lukę po awaryjnym wyłączeniu
Kiteworks poinformowało, że podczas zaplanowanego, dziewięciogodzinnego wyłączenia systemów udało się wykryć i załatać wcześniej nieznaną, krytyczną podatność. Luka dotyczyła funkcji aktywnej u mniej niż 1% klientów i została zabezpieczona w trakcie przerwy technicznej.
Firma podkreśliła, że nie ma dowodów na wykorzystanie podatności w atakach. Dodatkową warstwę ochrony wdrożono we wszystkich środowiskach, a pozostałe produkty Kiteworks nie zostały nią objęte.
Dlaczego systemy zostały wyłączone
Kilka dni wcześniej dostawca MFT, znany dziś jako Kiteworks, rozesłał do klientów nietypowe zalecenie: na dziewięć godzin wyłączyć własne instalacje. Dotyczyło to zarówno środowisk utrzymywanych samodzielnie, jak i wdrożeń w chmurze publicznej, m.in. w AWS i Azure. Jednocześnie firma wyłączyła także systemy hostowane w imieniu klientów.
Powodem były wiarygodne informacje wywiadowcze przekazane przez federalne władze. Z komunikatu wynikało, że możliwy jest nadchodzący atak na część systemów Kiteworks. Firma zaznaczała wtedy, że działa prewencyjnie, a nie w reakcji na potwierdzony incydent bezpieczeństwa.
Co udało się ustalić podczas przerwy
To właśnie w trakcie tego okna serwisowego wykryto nową lukę. Kiteworks nie ujawniło jednak szczegółów technicznych dotyczących błędu ani sposobu jego wykorzystania. Na moment publikacji nie przypisano mu identyfikatora CVE.
Według firmy:
- podatność dotyczyła tylko jednej, rzadko używanej funkcji,
- nie znaleziono oznak jej aktywnego nadużycia,
- awaryjne wyłączenie pozwoliło wdrożyć poprawkę przed wznowieniem pracy systemów.
Systemy wracają online
Po ustąpieniu zagrożenia i braku wykrytych anomalii klienci otrzymali zielone światło do ponownego uruchomienia swoich środowisk. Jednocześnie użytkownikom zalecano pozostanie na najnowszej wersji 9.5.1, w której uwzględniono znane wcześniej podatności.
To nietypowy przypadek, bo dostawca oprogramowania poprosił klientów o wyłączenie produkcyjnych systemów bez potwierdzonego włamania. Z perspektywy bezpieczeństwa była to jednak klasyczna decyzja „na wszelki wypadek” — podjęta po to, by wyprzedzić potencjalny atak, zamiast reagować dopiero po incydencie.
MFT znów na celowniku
Sytuacja przypomina, że platformy managed file transfer (MFT) od lat są atrakcyjnym celem dla cyberprzestępców. W przeszłości atakowano już m.in. Accellion, GoAnywhere, Cleo oraz MOVEit. W głośnej kampanii przeciwko MOVEit grupa Cl0p miała przejąć dane z tysięcy firm i dziesiątek milionów użytkowników końcowych.
Kiteworks przekonuje, że tym razem szybka reakcja pozwoliła przerwać możliwy łańcuch ataku, zanim doszło do kompromitacji środowisk klientów.