Serwer MCP Verify firmy Kluster naraża użytkowników na wyczerpanie kredytów
Serwer verify-mcp firmy Kluster AI ufa każdej sesji przeglądarki, która może dotrzeć do jego punktu końcowego /stream.
Gdy usługa jest udostępniona przez HTTP i powiązana z 0.0.0.0, atak DNS rebinding może przekształcić przeglądarkę ofiary w serwer proxy sterujący API z otwartego internetu.
Podczas naszych testów ta technika pozwoliła nam zdalnie wywołać narzędzie verify i zużyć kredyty Kluster bez zgody użytkownika.
Podsumowanie
- Wektor ataku: DNS rebinding nadużywa modelu zaufania przeglądarki, aby przekierować nazwę domeny z hosta atakującego na
127.0.0.1, omijając zabezpieczenia polityki tego samego pochodzenia (Same-Origin Policy). - Udostępniony komponent: serwer
verify-mcpfirmy Kluster udostępnia/streamprzez zwykły HTTP i akceptuje żądania wyłącznie na podstawie nagłówków Host dostarczonych przez klienta. - Zaobserwowany rezultat: po rebindingu JavaScript kontrolowany przez atakującego mógł sterować narzędziem verify tak, jakby był lokalnym użytkownikiem, zużywając płatne kredyty.
Inne narzędzia opisane na tej stronie zawodzą w ten sam sposób: Podatność DNS rebinding w transporcie SSE serwera Vet MCP i Neo4j MCP Cypher Server podatny na przejęcie bazy danych za pomocą DNS rebinding.
Analiza techniczna
Atak przebiega w dwóch fazach DNS, w połączeniu z lekkim ładunkiem HTML/JavaScript:
- Początkowe powiązanie z infrastrukturą atakującego. Ofiara odwiedza witrynę kontrolowaną przez atakującego. Pierwsze zapytanie DNS rozwiązuje się na publiczny adres IP atakującego, co pozwala nam dostarczyć skrypt odpytujący punkt końcowy Kluster.
- Rebinding na localhost. Po załadowaniu strony serwer DNS atakującego odpowiada na kolejne zapytania dotyczące tego samego hosta wartością
127.0.0.1. Przeglądarki ponownie wykorzystują nazwę z pamięci podręcznej, więc kolejne wywołaniafetchpo cichu przełączają się na interfejs pętli zwrotnej (loopback) ofiary, zachowując pierwotny ciąg origin. - Sterowanie API verify. Ponieważ
verify-mcpzezwala na żądania HTTP z dowolnego pochodzenia i nie weryfikuje nagłówków Host ani Origin, nasz skrypt z powodzeniem wysyłał (POST) zadania do/stream, uruchamiając przebiegi weryfikacji zużywające kredyty.
Ten wzorzec nie jest unikalny dla Kluster, ale połączenie transportu HTTP i braku walidacji nagłówków sprawiło, że wykorzystanie było trywialne.
Wpływ
- Nadużycie usługi: zdalni aktorzy mogą zużywać kredyty weryfikacyjne Kluster lub zasypywać API żądaniami, powodując straty finansowe lub ograniczanie liczby żądań (rate limiting) dla legalnych użytkowników.
Zalecenia
Dla Kluster AI
- Rygorystycznie weryfikuj nagłówki
HostiOrigin, odrzucając żądania, które nie pasują do jawnej listy dozwolonych (localhost,127.0.0.1). - Wprowadź uwierzytelnianie lub tokeny API nawet dla sesji lokalnych, aby zapewnić, że akcje zużywające kredyty mogą wywoływać wyłącznie zaufani wywołujący.
Dla operatorów i użytkowników MCP
- Zakładaj, że usługi localhost są osiągalne przez przeglądarkę w obecności DNS rebinding; monitoruj logi pod kątem nieoczekiwanych nazw pochodzenia.
- Preferuj HTTPS (z prawidłowymi certyfikatami) i jawną walidację nagłówków dla każdego narzędzia udostępnianego poza interfejsem pętli zwrotnej.
- Edukuj programistów, aby zamykali lokalne agenty podczas przeglądania niezaufanych witryn, lub stosuj segmentację sieci w celu odizolowania usług agentów od domyślnego profilu przeglądarki.
Uwagi końcowe
DNS rebinding nadal zaciera granicę między “lokalnym” a “zdalnym” w przypadku narzędzi MCP.
Poprzez wzmacnianie kanałów transportowych, walidację metadanych żądań i wymaganie uwierzytelniania dostawcy platform mogą pomóc programistom działać bezpieczniej.
Oś czasu
- 2025-07-17: wstępne zgłoszenie przesłane do zespołu bezpieczeństwa Kluster AI.
- 2025-07-17: Kluster potwierdził odbiór tego samego dnia.
- 2025-08-29: zapytanie uzupełniające wysłane do Kluster AI z prośbą o status naprawy.
- 2025-10-16: techniczny biuletyn bezpieczeństwa opublikowany na mcpsec.dev.