افشای آسیب پذیری: دیدگاه دست اول

“در عمل، نظریه متفاوت است” – یک استاد برق و مغناطیس که من در کالج داشتم این را در طول آزمایشات آزمایشگاهی ما می گفت. اگر قوانین فیزیک تضمین می کرد که یک شخص می تواند یک جسم برق دار خاص را بدون برق گرفتگی لمس کند، او هرگز این اصل را با دست خود نشان نمی داد، زیرا در عمل شرایط غیرقابل پیش بینی ممکن است ایجاد شود.

این من را به یاد تجربه مشابهی می‌اندازد که در مورد افشای آسیب‌پذیری داشتیم. در تئوری، کل فرآیند باید کاملاً ساده باشد: notify -->fix -->disclose. در عمل ما تجربه بسیار متفاوتی داشتیم.

افشای یک آسیب پذیری؟ افشای مسئولانه؟

به نظر می رسد که ما به عنوان یک جامعه حتی نمی توانیم در مورد اصطلاحات صحیح به توافق برسیم: «خصوصی»، «عمومی»، «مسئولانه»، «کامل» و «افشای هماهنگ» اصطلاحاتی هستند که هیچ معنای مشترکی در دانشگاه یا صنعت ندارند. .

افشای آسیب پذیری هماهنگ (CVD) با توجه به اینکه “مسئول” در “افشای مسئول” متضمن یک تعهد اخلاقی برای طرف افشا کننده است – در حالی که در واقع مسئولیت بر عهده هر کسی است که باعث آسیب پذیری، نه کسی که آن را کشف کرده است.

آسیب‌پذیری tsuNAME

آسیب‌پذیری tsuNAME شامل کلاینت‌ها و/یا حل‌کننده‌های بازگشتی (حلقه در شکل زیر) بود که درخواست‌های پیوسته را به سرورهای معتبر ارسال می‌کرد. اگر با دقت استفاده شود، می توان از آن برای بارگذاری بیش از حد و خرابی سرورهای معتبر استفاده کرد و کل مناطق DNS را غیرقابل دسترس کرد. برای شروع یک حلقه، یک حل‌کننده یا کلاینت باید یک حلقه منطقه DNS را در فایل‌های ناحیه هر سرور پیدا می‌کرد.

به عنوان مثال، یک سرور معتبر برای ساختگی در نظر بگیرید dog.com منطقه:

dog.com NS ns.cat.org

اکنون به فایل منطقه cat.org نگاه کنید:

cat.org NS ns.dog.com

ما می توانیم یک چرخه را در هر دو حوزه ببینیم: cat.org <-> dog.com. با توجه به اینکه حل‌کننده‌ها چنین پاسخ‌هایی را در حافظه پنهان ذخیره نمی‌کنند، برخی از آنها به‌طور نامحدود حلقه می‌شوند – یا برخی از مشتریان این کار را انجام می‌دهند. ما در مورد آسیب پذیری به طور مفصل در مورد بحث می کنیم مقاله تحقیقاتی ما. ما نشان می‌دهیم که چگونه دامنه سطح بالای .nz نیوزلند (ccTLD) به دلیل آسیب‌پذیری، افزایش 50 درصدی ترافیک را تجربه کرد.

فرآیند افشا

وقتی برای اولین بار tsuNAME را کشف کردیم، متوجه شدیم که در ما مجموعه داده ها، 99٪ از جستجوهای حلقه ای که دیدیم از DNS عمومی Google (GDNS) بود. از آنجایی که ما برخی از اپراتورهای GDNS را شخصاً می شناسیم، تصمیم گرفتیم ابتدا آنها را از مشکل مطلع کنیم به این امید که زمان تعمیر را تسریع کند. (این کار را نکرد و معلوم شد که اشتباهی از جانب ما بوده است – بعداً در مورد آن بیشتر توضیح خواهیم داد.)

شکل زیر افشای ما را خلاصه می کند. اولین بار در سپتامبر 2020 به مخاطبین GDNS خود اطلاع دادیم. پس از ماه‌ها انتظار، در نوامبر 2020 با استفاده از کانال رسمی CVD به Google اطلاع دادیم. باز هم چندین ماه بدون راه حل گذشت، بنابراین تصمیم گرفتیم به صورت خصوصی گروهی از اپراتورهای DNS را که ممکن است قربانی حملات tsuNAME مانند شوند، مطلع کنید. ما با استفاده از یک جلسه افشای آنلاین برنامه ریزی کرده ایم DNS-OARC، برای ارائه یافته های خود در نشست آنلاین OARC34. برای در جریان نگه داشتن افراد در GDNS، به آنها اطلاع داده ایم که این افشای گروهی را انجام خواهیم داد.

در همین حین، همکاران ما در GDNS تماس گرفتند و به سرعت مشکل را حل کردند – یک روز قبل از رونمایی خصوصی ما از OARC34.

سپس به طور خصوصی برای چندین طرف افشا کردیم (ناحیه زرد رنگ در شکل بالا). سیسکو همچنین سرویس OpenDNS خود را در آوریل وصله کرد و در نهایت ما به صورت عمومی این موضوع را در می 2021 فاش کرد. در مجموع، از اولین تماس تا افشای عمومی 8 ماه طول کشید.

درس های آموخته شده

1. پیگیری افشای عمومی برای همه مفید است

آسیب احتمالی که می تواند توسط حملات tsuNAME ایجاد شود که یک اپراتور دامنه سطح بالا را نقض می کند، یک منبع نگرانی بود. با این حال، ما متعجب بودیم که چرا هیچ گزارش عمومی از چنین حملاتی وجود ندارد – به هر حال، این آسیب‌پذیری احتمالاً جدید نیست. آیا به این دلیل است که مهاجمان هنوز آن را کشف نکرده اند یا روش های دیگری، در دسترس تر و موثرتر وجود دارد؟ ما با یک دوراهی اخلاقی مواجه شدیم: افشای آسیب‌پذیری یا عدم افشای آن. علیرغم خطر تلقی شدن به عنوان هراس، در نهایت تصمیم گرفتیم با افشاگری گروهی و عمومی ادامه دهیم.

تصمیم ما برای افشای این آسیب‌پذیری در نهایت به اصلاح tsuNAME کمک کرد تا هیچ اپراتور دیگری نتواند قربانی حملات مشابه شود. تنها به یک طرف نیاز است تا مشکلی را کشف کند تا زنجیره ای را ایجاد کند که در نهایت به نفع همه باشد. بنابراین، ما به محققان توصیه می کنیم که آسیب پذیری ها را افشا کنند.

2. افشاگری پیامدهای اخلاقی دارد

هنگام افشای یک آسیب پذیری، محقق ممکن است بهترین نیت را داشته باشد، اما باید آگاه باشد که باید انتخاب هایی انجام شود و هر تصمیمی ممکن است عواقبی برای دیگران داشته باشد.

ما معتقدیم که در افشای tsuNAME انتخاب درستی انجام دادیم. فروشندگان توانستند این آسیب پذیری را اصلاح کنند و از استفاده از آن در حملات تقویتی جلوگیری کنند.

در نگاهی به گذشته، متوجه می‌شویم که زمانی که در ابتدا تصمیم گرفتیم فقط به GDNS به صورت خصوصی اطلاع رسانی کنیم، اشتباه کردیم. اکنون می بینیم که باید با همه ارائه دهندگان حل کننده DNS یکسان رفتار می کردیم و همزمان به آنها اطلاع می دادیم. خطای ما باعث تاخیر در کاهش آسیب‌پذیری شد. همچنین افشای خصوصی ما نتیجه مطلوبی را به همراه نداشت، بنابراین ما واقعاً نیاز به تعیین تاریخ برای افشای عمومی داشتیم و به فروشندگان اطلاع رسانی می کردیم.

3. برای سبک کردن بار کمک بخواهید

کشف tsuNAME به زمان و انرژی بیشتری از آنچه در ابتدا پیش بینی می کردیم نیاز داشت. علاوه بر آماده سازی ارائه ها، ما همچنین راهنماهایی برای اپراتورها و توسعه دهندگان ایجاد کرده ایم که مراحل مورد نیاز برای تولید مجدد tsuNAME را تشریح می کند.

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

4. شما تصویر کامل را ندارید

در طول جلسه پرسش و پاسخ در افشای گروه OARC34، 2 اپراتور ccTLD تأیید کردند که قبلاً رویدادهای DNS مربوط به GDNS را داشته اند. اولین اپراتور، یک ccTLD اروپایی، با مهربانی آمار ترافیک رویداد DNS خود را به اشتراک گذاشت. بر خلاف حادثه nz که شاهد افزایش 50 درصدی ترافیک بود، این اپراتور شاهد افزایش 10 برابری بود.

شکل 3 کل ترافیک اپراتور را نشان می دهد که هر رنگ نشان دهنده ترافیک هر سرور قابل اعتمادی است که مدیریت می کند. ما می‌توانیم شاهد افزایشی در ترافیک باشیم که از ساعت 19:00 UTC شروع می‌شود و در 10 برابر ترافیک عادی خود به اوج خود می‌رسد، قبل از اینکه روز بعد از ساعت 11:00 UTC روز بعد که آنها به صورت دستی منطقه خود را از چرخه خارج کردند، کاهش شدیدی پیدا کند.

یک اپراتور دوم ccTLD در قاره آمریکا پس از ارائه از طریق ایمیل با ما تماس گرفت و گفت که او در موارد متعدد تحت تأثیر رویدادهای مشابه قرار گرفته است. آنها همچنین این موضوع را به طور خصوصی با مخاطبین خود در Google مطرح کرده بودند، اما این مشکل سال ها ادامه داشت و باعث ناامیدی شد. اگرچه ما نمی توانیم ادعاهای آنها را تأیید کنیم، اما حساب آنها این افشای شخصی را نشان می دهد ممکن است موثر نباشد.

5. برای واکنش های استرس زا آماده شوید

ما 2 نوع واکنش به افشای خود داشتیم:

• مثبت: بیشتر از فروشندگان – GDNS، Unbound/NLnet Labs، BIND/ISC، Cisco/OpenDNS. اینها افرادی بودند که قدرت داشتند ثابت نرم افزار آسیب پذیر بنابراین مخاطبان اصلی ما.
• منفی: برخی از اپراتورها ما را به ایجاد ترس متهم کردند، در حالی که برخی دیگر گفتند که مشکل از قبل شناخته شده بود. در حالی که درست است که RFC های قبلی به موضوع وابستگی های دایره ای (RFC1034، RFC1035، RFC1536) پرداخته بودند، اما آنها آن را به طور کامل پوشش ندادند، بنابراین آسیب پذیری همچنان وجود داشت. ما یک پیش‌نویس اینترنتی نوشتیم که این موضوع را پوشش می‌دهد، که بعداً در دیگری گنجانده شد یک پروژه IETF.

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

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

بهبود فرآیند افشای اطلاعات

ما می توانیم از تجربه افشای خود دو درس بگیریم:

نقش تامین کننده و جدول زمانی را روشن کنید

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

در مورد ما با Google، پس از استفاده از سیستم اعلان رسمی آنها، رسیدگی به این مشکل بیش از 60 روز طول کشید. اگرچه سیستم ردیابی باگ گوگل در هر مرحله به‌روزرسانی‌هایی را در اختیار ما قرار می‌دهد، جدول زمانی برای رفع اشکال همچنان نامشخص است. اظهارات آنها نادرست بود”[P2 issues] باید در یک زمان معقول رسیدگی شود.

ما عمیقاً نگران این بودیم که سایر اپراتورها به هدفی برای مهاجمان DDoS تبدیل شوند، در حالی که منتظر راه حلی بودیم که در صورت وقوع حملات، احتمالاً ما را شریک جرم می‌کند.

ما می‌خواهیم در هنگام رسیدگی به مسائل فروشنده، تا حدی برای کنترل خطرات (و استرس) ناشی از نشت یا تشخیص خطای موازی در طول یک پنجره تعریف‌نشده، یک بازه زمانی وضوح واضح‌تر ببینیم.

به روز رسانی و تایید دستورالعمل های CVD

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

در پیش

ما به صورت نقدی نوشتیم کار علمی در مورد تجربه ما در کشف tsuNAME آسیب پذیری