Smithery.ai’dagi konfiguratsiya xatosi — 3,000+ MCP serveri va minglab API kalitlar xavf ostida

Sun’iy intellekt (AI) ilovalari tez sur’atda qamrab olayotgan sohada, ularni tashqi vositalar va ma’lumotlar bilan bog‘lovchi infrastruktur ham ayon darajada muhim ahamiyat kasb etadi. Shu qatorda Model Context Protocol (MCP) serverlari AI ilovalari uchun ma’lumot va xizmatlarga kirishni ta’minlovchi kalit tugun hisoblanadi. Biroq 2025-yil yozida aniqlangan bir oddiy konfiguratsion xato shu hamkorlik tarmog‘ida qanday halokatli natijalar keltirib chiqarishi mumkinligini ochiq ko‘rsatdi.

Vaziyat qanday yuz berdi?

Smithery.ai — MCP serverlarini markaziy joyda qabul qiluvchi va foydalanuvchi yuborgan GitHub repolarini Docker tasvirlariga («image») aylantiruvchi registr hisoblanadi. GitGuardian tadqiqotchilarining aniqlashicha, Smithery’ning qurilish (build) jarayonida dockerBuildPath maydoniga kiritiladigan yo‘l qiymati yetarlicha tekshirilmagan. Oddiy yahni qilib aytganda, foydalanuvchi taqdim etgan smithery.yaml ichidagi dockerBuildPath parametriga kiruvchi yo‘l «..» deb ko‘rsatilsa, tizim repodan tashqari kataloglarni ham qurilish kontekstiga qo‘shib yuboradigan imkoniyat paydo bo‘lgan.

GitGuardian sinov maqsadida “test” nomli repo yaratib, unga maxsus Dockerfile joylashtiradi. Dockerfile ichidagi buyruqlar orqali qurilish mashinasining katalog daraxti hujumchiga yuboriladi — shu tariqa .docker/config.json kabi sezgir fayllar oshkor bo‘ladi. Mazkur faylda yashiringan fly.io autentifikatsiya tokeni esa nafaqat Docker registriga kirishga emas, balki hosting muhitidagi kengroq amallarni bajarishga imkon bergan.

Natija: keng ko‘lamli buzilish xavfi

Fly.io tokenidan foydalangan hujumchi tashkilotning 3,243 ta ilovasi (aksariyat MCP serverlari) joylashgan tashkilot resurslariga kira olgan. Ular:

  • ilovalarni so‘rov qilib ko‘rish,
  • mashinalarda kod bajarish (sinov uchun id buyrug‘i orqali root huquqi tasdiqlangan),
  • tarmoq trafikini ushlash va analiz qilish imkoniyatiga ega bo‘lgan.

Shu tariqa, MCP serverlari orqali xizmat ko‘rsatilgan mijoz ilovalarining yuborgan API kalitlari ham oshkor bo‘lishi aniqlandi — masalan, so‘rov satrida yuborilgan Brave kaliti singari ma’lumotlar qoldiqsiz tutib olinishi mumkin. Agar bu hujum masshtabini oshirilsa, minglab foydalanuvchilarning API kalitlari va boshqa maxfiy ma’lumotlari talon-toroj qilinishi muqarrar edi.

Muammo ildizi: noto‘g‘ri chegaralash va markazlashgan ishonch

Ushbu hodisa bir necha muhim dars beradi:

  • Markazlashgan hosting modeli (foydalanuvchi yuborgan container’larni umumiy infra’da qurish) qulaylik bilan birga katta xavfni ham keltirib chiqaradi — bitta zaiflik butun ekotizimga «epidemik» ta’sir ko‘rsatishi mumkin.
  • Statik API kalitlar ishlatilishi (OAuth o‘rniga) hujumchilarga to‘g‘ridan-to‘g‘ri ma’lumotlarga keng kirish imkonini beradi; OAuth singari tokenlar cheklangan ruxsatlar va muddat bilan xavfsizroq hisoblanadi.
  • Qurilish jarayonida kirish nazorati va path traversal tekshiruvi yo‘qligi oddiy xatolarni halokatga aylantirishi mumkin.

Smithery’ning javobi va tuzatishlar

GitGuardian tomonidan muammo 2025-yil 13-iyunda oshkor qilingach, Smithery jamoasi tezkor reaksiya bilan 15-iyun 2025-yilda path traversal zaifligini tuzatdi, mos ravishda xavfsizlik tokenlarini qayta chiqarish (key rotation) va build jarayonini qat’iyroq izolyatsiyalash choralarini ko‘rdi. Ushbu choralar muammo oqibatlarini cheklashga yordam berdi, ammo biroz kechikish butun ekotizim uchun jiddiy tahdid tug‘dirgan edi.

Oldini olish bo‘yicha tavsiyalar

Bunday supply-chain turidagi xatoliklarni minimalga tushirish uchun quyidagi amaliy choralarni tavsiya qilish mumkin:

  1. Build kontekstlarini qat’iy validatsiya qiling — yozilgan dockerBuildPath yoki shunga o‘xshash parametrlar path traversal hujumlariga qarshi tekshirilishi shart.
  2. Izo­lyatsiya va least-privilege tamoyilini qo‘llang — qurilish mashinalari va konteynerlar boshqa tizim fayllariga kira olmasligi kerak.
  3. Token va sirlarni boshqarish — doimiy/umrbod tokenlar o‘rniga vaqtinchalik va cheklangan huquqli tokenlardan foydalanish, tokenlarni minimal huquq bilan cheklash.
  4. Qo‘shimcha monitoring va detektsiya — build jarayonida g‘ayrioddiy so‘rovlar, fayl eksporti yoki tarmoq trafikidagi anomaliyalarni avtomatik aniqlash.
  5. Supply-chain auditing — uchinchi tomon xosting va CI/CD provayderlari bilan bog‘liq xavf omillarini muntazam baholash.
  6. Foydalanuvchilarni xabardor qilish — agar mijoz kalitlari yoki ma’lumotlar xavf ostida bo‘lgan bo‘lsa, ularga darhol xabar berish va kalitlarni almashtirish choralarini ko‘rish.

Smithery.ai misoli — bir oddiy konfiguratsion xatolikning butun AI ekotizimiga qanday ziyon yetkazishi mumkinligini ko‘rsatdi. AI infratuzilmasi tobora murakkablashar ekan, uning xavfsizligi ham tizimli va qat’iy yondashuvni talab qiladi: qurilish, hostlash va autentifikatsiya jarayonlarida qat’iy izolyatsiya, cheklangan huquqlar va doimiy monitoring bo‘lmasa, bir «kichik teshik» katta bo‘shliqqa aylanadi.