Chainstack'in operasyon ortamına kimlik doğrulamasız MCP üzerinden sızıldı

Bir dış saldırgan, blokzincir altyapı şirketi Chainstack’in operasyon ortamının bir bölümüne 29 Ekim’de sızdı. Varsayılan yönetici parolası değiştirilmemiş bir geliştirme sunucusundan başlayan saldırı, kimlik doğrulaması olmayan bir iç Model Context Protocol (MCP) araç sunucusu ve operasyon ortamı üzerinden müşterilerin hesap bilgilerini içeren bir veritabanına ulaştı.

Chainstack, 10 Kasım’da yayımladığı olay raporuna teknik ayrıntılar ekledi. Şirket, saldırganın 26 Ekim’de geliştirme ortamına girdiğini, 31 Ekim’de saldırı yolunu kapattığını ve soruşturmayı 2 Kasım’da tamamladığını bildirdi.

İlk erişim noktası, temmuz ayında geliştirme amaçlı Kubernetes kümesine kurulan bir Grafana test sunucusuydu. Sunucu internete açıktı ve varsayılan yönetici hesap bilgileri değiştirilmemişti. Tek oturum açma (SSO) veya temel kimlik doğrulama gibi ek oturum açma korumaları da bulunmuyordu.

Saldırgan, 26 Ekim’de varsayılan yönetici hesabıyla giriş yaptıktan sonra Grafana’nın veri kaynağı proxy’sini kullanarak iç hizmetlere erişti. Proxy’de bağlantı hedefleri için izin listesi yoktu; ağ politikası da Grafana’nın bağlanabileceği yerleri kısıtlamıyordu. Chainstack, saldırganın kimlik doğrulama, veritabanı, otomasyon ve izleme alanlarında onlarca iç hizmete bağlandığını bildirdi.

Aynı gün saldırgan, yapay zekâ ajanlarına Kubernetes görevleri sunan iç MCP araç sunucusuna ulaştı. Sunucu kimlik doğrulaması istemiyordu ve sunucu hesabına geliştirme kümesinde yönetici yetkileri verilmişti. Chainstack, ağ trafiği, yetkiler ve daha sonra yapılan değişikliklere dayanarak sunucunun saldırganın komut çalıştırması için kullanıldığı sonucuna vardı; ancak tek tek araç çağrılarının kayıtlarını kurtaramadı.

Saldırgan sonraki bir buçuk saat içinde iç iş akışı motorunun yazma yetkilerini denedi ve geliştirme amaçlı kimlik doğrulama sisteminde bir yönetici kullanıcısı oluşturdu. Test amaçlı bir web sayfası dağıttı; saldırgana ait bir dosyayı Kubernetes ConfigMap birimi olarak bağlayıp geliştirme web uygulamasının sunduğu JavaScript dosyasını değiştirdi. 27 Ekim’de aynı yöntemle hazırlık ortamındaki web uygulamasını ve geliştirme Grafana’sını da değiştirdi. Chainstack, yükleyicinin işaret ettiği ikinci aşama betiğini kurtaramadığını belirtti.

29 Ekim’de saldırgan, otomasyon platformunun veritabanında kayıtlı iş akışlarını doğrudan değiştirerek kabuk komutlarının çalıştırılmasını sağladı. Geçerli bir web kancası belirteciyle iş akışını çalıştırdıktan sonra önceki duruma döndü. Platformun veritabanını doğrudan değiştirerek kendi değişiklik geçmişini atladı.

Bu süreçte saldırgan, otomasyon pod’unun ortam değişkenlerini, Kubernetes hizmet hesabı belirtecini ve altyapı erişim ağ geçidinde kullanılan makine kimliği bilgilerini ele geçirdi. Aynı gün, ele geçirilen ağ geçidi ve dağıtım otomasyonu hesabıyla üretim Kubernetes kümesindeki gizli bilgileri listeledi ve bulut ile altyapı kimlik bilgilerini okudu.

31 Ekim’de üretim ortamındaki bulut gizli bilgi deposunu çok sayıda kez sorguladı. Saldırgan, altyapı otomasyonu hesabı için ek anahtarlar oluşturdu ve uzun süre geçerli belirteci olan bir Kubernetes hesabı da açarak yeniden erişim yolu hazırlamaya çalıştı. Ele geçirdiği VPN anahtarıyla veritabanı ağına bağlandı.

Aynı VPN eş kimliğini iki istemcinin sunması, tünel bağlantı noktasının değişip durmasına ve veritabanı çoğaltma sürecinde hataya yol açtı. Chainstack, bu kesintinin ardından saldırı soruşturmasını başlattığını bildirdi.

Saldırgan, yönetici hesabıyla üretim veritabanına bağlanarak sorgu sonuçlarını dışarı aktardı. Chainstack, bir örnekte veritabanı rollerinin parola özetlerini içeren PostgreSQL pg_shadow görünümünün de sorgulandığını açıkladı.

Erişilen veritabanında kuruluş adları, hesap sahiplerinin adları, kuruluş üyelerinin e-posta adresleri ve parola özetleri bulunuyordu. Saldırgan, müşteri düğümlerinin erişim bilgilerinin saklandığı sisteme de erişti; ancak Chainstack bu bilgilerin gerçekten okunduğuna dair kanıt olmadığını belirtti. Şirket, önlem olarak düğüm erişim bilgilerini de açığa çıkmış kabul ediyor.

Chainstack, saldırganın açık kaynaklı yapay zekâ saldırı çerçevesi ARTEX’i kullanmış olma ihtimalinin yüksek olduğunu değerlendirdi. Bu değerlendirmede saldırganın oluşturduğu dosya ve hesaplarda görülen adlandırma izleri, kullanılan araçlar ve davranış biçimi etkili oldu. Aynı çerçeve farklı gruplarca da kullanılabildiğinden saldırının arkasındaki taraf belirlenmedi. Şirket, bir yazılım açığının istismar edildiğine dair kanıt da bulamadığını bildirdi.

Chainstack, olay süresince müşteri düğümleri, konsol ve API’nin normal çalıştığını ve saldırgan tarafından değiştirilmediğini açıkladı. Bu bulgu, müşteri hesap veritabanına ve düğüm kimlik bilgilerini saklayan sisteme erişilmiş olmasından ayrı bir soruşturma sonucuydu.

MCP, yapay zekâ araçlarının harici sistemlerdeki verilere ve işlevlere erişmesini sağlayan bir standarttır. Bu olayda ortaya çıkan sorun, iç araç sunucusunda kimlik doğrulaması bulunmaması ve sunucunun geniş yönetici yetkilerine sahip olmasıydı. TokenPost daha önce Radware’in şirket içindeki MCP sunucularını ve yapay zekâ ajanlarının faaliyetlerini izlemeye yönelik bir güvenlik ürünü duyurduğunu aktarmıştı.

Chainstack, müşterilerinden parolalarını değiştirmelerini, düğüm erişim bilgilerini yenilemelerini ve platform API anahtarlarını yeniden oluşturmalarını istedi. Şirket, iç MCP araçlarında kimlik doğrulamasını ve en az ayrıcalık ilkesini güçlendirmek; geliştirme ve üretim ortamlarının hesaplarıyla gizli bilgilerini birbirinden ayırmak için güvenlik önlemleri üzerinde çalıştığını bildirdi.