پژوهشگران امنیتی نشان دادند که چگونه یک نقش (Role) با دسترسی محدود در پایگاه داده مدیریت‌شده PostgreSQL شرکت Snowflake، می‌تواند منجر به کنترل کامل سرور میزبان شود. این تحقیق نشان می‌دهد که چگونه ترکیب چندین قابلیت داخلی PostgreSQL می‌تواند محدودیت‌های امنیتی اعمال شده توسط ارائه‌دهنده سرویس ابری را دور بزند.
جزئیات زنجیره حمله
این زنجیره حمله از یک حساب غیر-superuser به نام snowflake_admin آغاز شد که دارای مجوز CREATEROLE بود. اگرچه این مجوز به تنهایی کنترل کامل پایگاه داده را فراهم نمی‌کند، اما پژوهشگران از آن برای ارتقای سطح دسترسی (Privilege Escalation) استفاده کردند:
- گام اول: استفاده از
CREATEROLEبرای اعطای نقش‌هایpg_read_all_dataوpg_write_all_dataبه حساب اولیه. - گام دوم: دسترسی به کاتالوگ‌های سیستم و تغییر در افزونه
pg_cronبرای اجرای وظایف زمان‌بندی شده. - گام سوم: ایجاد یک تابع
SECURITY DEFINERکه با سطح دسترسی کاربرpostgres(Superuser) اجرا می‌شود.
دور زدن محدودیت‌های سیستم‌عامل
پس از دستیابی به سطح دسترسی Superuser در پایگاه داده، پژوهشگران با استفاده از زبان داخلی PostgreSQL، نام توابع جدیدی را به توابع C موجود در نرم‌افزار سرور متصل (Bind) کردند. این کار امکان دسترسی مجدد به توابع خواندن و نوشتن فایل را که توسط Snowflake مسدود شده بود، فراهم کرد.
در نهایت، با استفاده از قابلیت Large-Object، پژوهشگران موفق شدند فایل پیکربندی را تغییر داده و دستور archive_command را دستکاری کنند. این امر منجر به اجرای دستورات سیستم‌عامل (OS Command Execution) با سطح دسترسی کاربر postgres شد.
وضعیت اصلاح و توصیه‌ها
شرکت Snowflake پیش از انتشار این گزارش، آسیب‌پذیری را در سمت سرور اصلاح کرده است و کاربران این سرویس نیازی به اقدام اضافی ندارند. با این حال، برای سازمان‌هایی که از پایگاه داده‌های PostgreSQL به صورت خود-مدیریت‌شده (Self-managed) استفاده می‌کنند، توصیه‌های زیر ارائه شده است:
- مجوز
CREATEROLEرا به عنوان یک مجوز پرخطر در نظر گرفته و از حساب‌های اپلیکیشن حذف کنید. - وظایف
pg_cronو توابعSECURITY DEFINERرا به دقت بازرسی کنید. - دسترسی به ایجاد توابع داخلی یا توابع زبان C را محدود نمایید.
- فایل‌های پیکربندی پایگاه داده را محافظت کرده و دسترسی‌های شبکه را محدود کنید.
