حفرهٔ رمزنگاری S3 کلید پاکت را فاش می‌کند؛ راه میان‌بُر ندارد

|نویسنده: تیم تحریریه QUASA|5 دقیقه مطالعه
حفرهٔ رمزنگاری S3 کلید پاکت را فاش می‌کند؛ راه میان‌بُر ندارد

AWS در ۱۴ اکتبر ۲۰۲۶ در بولتن امنیتی خود دربارهٔ CVE-2026-110310 اعلام کرد که نقص Amazon S3 Encryption Client for .NET می‌تواند با تغییر طرح padding در فرادادهٔ شیء، به بازیابی کلید پاکت و رمزگشایی آن منجر شود؛ برای این نقص راهکار موقتی اعلام نشده است. حمله در شرایطی مطرح است که شخص بتواند شیء رمزگذاری‌شده را بخواند و مقدار مربوط به padding را در فرادادهٔ مصرفی کلاینت تغییر دهد. بنابراین مسئله به برنامه‌ای مربوط است که با این کتابخانه شیء را رمزگشایی می‌کند.

رکورد OpenCVE که همان روز منتشر شد، محدودهٔ آسیب‌پذیر را از 2.1.0 تا انتهای شاخهٔ 2.x، از 3.0.0 تا 3.2.1 و از 4.0.0 تا 4.0.2 ثبت می‌کند؛ نسخه‌های اصلاح‌شده برای دو شاخهٔ تازه‌تر 3.2.2 و 4.0.3 هستند. شاخه‌های 1.x و 2.x وصلهٔ تازه نمی‌گیرند و مصرف‌کنندگان آن‌ها باید مهاجرت کنند. قرار گرفتن 1.x در مسیر مهاجرت به معنای ثبت همهٔ نسخه‌های آن به‌عنوان نسخهٔ آسیب‌پذیر همین CVE نیست.

کدام شاخه باید ارتقا یابد و کدام شاخه مهاجرت کند؟

نقطهٔ شروع، نسخهٔ کتابخانه در برنامهٔ در حال اجراست. نام بستهٔ Amazon.Extensions.S3.Encryption در فایل پروژه یا فهرست وابستگی‌ها کمک می‌کند، اما برای تصمیم نهایی باید خروجی ساخته‌شده و نسخه‌ای که واقعاً در سرویس مستقر شده نیز معلوم باشد. در سامانه‌ای که چند سرویس یک شیء را می‌خوانند، نسخهٔ هر مصرف‌کننده جداگانه اهمیت دارد؛ به‌روزرسانی یک سرویس مسیر رمزگشایی سرویس دیگر را عوض نمی‌کند.

  • اگر سرویس روی 3.0.0 تا 3.2.1 است، مسیر همان شاخه نصب 3.2.2 یا نسخهٔ جدیدتر آن و استقرار دوبارهٔ سرویس است.
  • اگر سرویس روی 4.0.0 تا 4.0.2 است، باید به 4.0.3 یا نسخهٔ جدیدتر شاخه برسد.
  • اگر سرویس از 2.1.0 به بعد در شاخهٔ 2.x قرار دارد، وصله‌ای در همان شاخه نمی‌آید. برای 1.x نیز برنامهٔ ارتقا در همان شاخه وجود ندارد؛ هر دو به مهاجرت به شاخهٔ اصلاح‌شده نیاز دارند.

این تصمیم به نسخهٔ کلاینت وابسته است؛ نسخهٔ SDK، پیکربندی سطل و تاریخ ایجاد شیء جای آن را مشخص نمی‌کنند. اگر کد کتابخانه در انشعاب داخلی نگهداری می‌شود یا بخش‌هایی از آن در پروژه‌ای دیگر کپی شده، تنها به‌روزرسانی بستهٔ NuGet کافی نیست؛ همان منطق مشتق‌شده نیز باید اصلاح شود. حضور بستهٔ تازه در مخزن نیز به‌تنهایی نشان نمی‌دهد که فرایند در حال اجرا از همان نسخه استفاده می‌کند.

تغییر فراداده چگونه به رمزگشایی شیء می‌رسد؟

Amazon S3 Encryption Client داده را پیش از بارگذاری در سمت کاربر رمز می‌کند و هنگام دریافت نیز همان‌جا رمزگشایی را انجام می‌دهد. برای هر شیء، کلید داده‌ای که محتوا را رمز کرده زیر یک کلید پوشاننده نگهداری می‌شود و اطلاعات لازم برای باز کردن آن در دسترس کلاینت قرار می‌گیرد. در حالت ذخیره‌سازی فرادادهٔ شیء، کلاینت این اطلاعات را از سربرگ‌های همان شیء می‌خواند؛ در حالت دیگر، اطلاعات در فایل دستور جداگانه ذخیره می‌شود.

در مسیر توصیف‌شده برای این آسیب‌پذیری، مقدار ثبت‌شده برای طرح padding به PKCS#1 v1.5 قدیمی تغییر می‌کند. وقتی کلاینت رمزگشایی را بر پایهٔ آن مقدار دنبال کند، تفاوت پاسخ‌های مربوط به درستی padding می‌تواند نقش اوراکل را در حملهٔ Bleichenbacher بازی کند. نتیجهٔ ممکن، بازیابی کلید دادهٔ پوشانده‌شده با RSA و سپس گشودن محتوای همان شیء است. کلید دادهٔ مربوط به شیء با کلید خصوصی RSA تفاوت دارد.

تفاوت میان رمزگذاری سمت کاربر و تنظیمات رمزگذاری سمت سرور در اینجا تعیین‌کننده است. حتی اگر سطل برای ذخیره‌سازی، رمزگذاری سمت سرور داشته باشد، نقصی که هنگام خواندن فراداده و باز کردن کلید در کتابخانهٔ .NET رخ می‌دهد با تغییر آن تنظیمات برطرف نمی‌شود. پرسش اصلی این است که کدام برنامه‌ها با نسخهٔ آسیب‌پذیر شیء را می‌خوانند و آیا در همان مسیر، امکان دست‌کاری فرادادهٔ رمزنگاری وجود دارد.

دسترسی خواندن و امکان تغییر فراداده را با هم بسنجید

شرح حمله به دو توانایی وابسته است: خواندن شیء رمزگذاری‌شده و تغییر طرح padding ثبت‌شده در فراداده‌ای که کلاینت مصرف می‌کند. از این رو فهرست هویت‌هایی که به اشیای مورد استفادهٔ کلاینت دسترسی خواندن دارند باید کنار مجوزهای کپی، جایگزینی یا نوشتن همان اشیا قرار گیرد. این بررسی برای هر شیء و هر مسیر خواندن انجام می‌شود، زیرا دسترسی یک برنامه به داده لزوماً دسترسی برنامهٔ دیگر را نشان نمی‌دهد.

سیاست سطل، مجوزهای نقش برنامه و مسیرهای خودکار بازنویسی ممکن است برای یک شیء نتیجه‌های متفاوتی داشته باشند. اگر چند برنامه با هویت‌های جداگانه از دادهٔ مشترک استفاده می‌کنند، باید روشن شود هر کدام کدام شیء را می‌خواند، با چه نسخه‌ای رمزگشایی می‌کند و کدام فرایند می‌تواند فرادادهٔ همان شیء را عوض کند. محدود کردن این دسترسی‌ها هنگام استقرار اصلاحیه می‌تواند فرصت سوءاستفاده را کم کند، اما جای نسخهٔ اصلاح‌شده را نمی‌گیرد.

مهاجرت قدیمی‌ها با سازگاری اشیای موجود گره خورده است

برای برنامه‌های قدیمی، انتخاب 4.0.3 فقط تغییر شمارهٔ بسته نیست. راهنمای مهاجرت .NET در AWS توضیح می‌دهد که کلاینت V4 با سیاست پیش‌فرض RequireEncryptRequireDecrypt اشیای رمزگذاری‌شده با V1 یا V2 را باز نمی‌کند؛ در دورهٔ گذار، پیکربندی سازگار با قالب قدیمی باید سیاست تعهد کلید و SecurityProfile مناسب را با هم داشته باشد. برای سامانه‌ای که دادهٔ قدیمی نگه می‌دارد، این تفاوت باید پیش از تغییر رفتار نوشتن و خواندن همهٔ مصرف‌کنندگان بررسی شود.

ترتیب مهاجرت در محیطی با چند خوانندهٔ مشترک مهم است. ابتدا باید معلوم شود کدام نسخه‌ها و تنظیمات می‌توانند قالب شیء موجود و شیء تازه را بخوانند؛ سپس برنامه‌ها در ترتیبی مستقر شوند که خوانندهٔ قدیمی با قالبی روبه‌رو نشود که نمی‌فهمد. بعد از آن می‌توان سیاست رمزگذاری اشیای تازه و بازرمزگذاری دادهٔ قدیمی را به شکل برنامه‌ریزی‌شده تغییر داد. آزمون خواندن نمونه‌ای از اشیای واقعاً موجود، همراه با کنترل خروجی استقرار هر سرویس، این سازگاری را در همان سامانه روشن می‌کند.

برای شاخه‌های 3.x و 4.x نیز پایان کار، ثبت نسخهٔ تازه در فایل وابستگی نیست؛ نسخهٔ مستقرشده، انشعاب‌های داخلی و مسیرهای واقعی خواندن باید با اصلاحیه همسو باشند. در شاخه‌های قدیمی، تصمیم باز همان مهاجرت است و تا تکمیل آن، دسترسی به اشیای رمزگذاری‌شده و امکان جایگزینی فراداده در ارزیابی خطر باقی می‌ماند. حفاظت داده در نهایت به کلاینتی بستگی دارد که در لحظهٔ خواندن اجرا می‌شود.

بیشتر بخوانید:

اشتراک‌گذاری:

مقالات مرتبط

عضویت در خبرنامه

تازه‌ترین اخبار Web3، هوش مصنوعی و رمزارز را مستقیم در صندوق ایمیل خود دریافت کنید.

0