دن کامینسکی را میتوان از مسیر یکی از زیرساختهای کمپیدای اینترنت شناخت: سامانه نام دامنه یا DNS. کاربر نام یک وبسایت را وارد میکند، اما پیش از برقراری ارتباط، رایانه باید نشانی مناسب را پیدا کند. اگر این مرحله پاسخ نادرست بگیرد، بسیاری از فرضهای مراحل بعدی نیز زیر سؤال میروند. پژوهش کامینسکی در سال ۲۰۰۸ نشان داد که مسئله امنیت همیشه در برنامهای که کاربر میبیند قرار ندارد؛ گاهی یک خدمت مشترک، شمار زیادی محصول و سازمان را همزمان در معرض خطر میگذارد.
مسئلهای در اعتماد به پاسخ
کامینسکی در آن دوره پژوهشگر IOActive بود. اطلاعیه فنی ISC درباره CVE-2008-1447 صریحاً کار او را منشأ شناسایی مسیر تازه سوءاستفاده از ضعفهای پروتکل معرفی میکند. موضوع، مسمومسازی حافظه نهان حلکنندههای بازگشتی DNS بود. این سرورها پاسخ پرسشهای قبلی را برای استفاده مجدد نگه میدارند؛ بنابراین پذیرفتن یک پاسخ جعلی میتواند اثری فراتر از یک درخواست منفرد داشته باشد. ارزش کشف او در این بود که یک خطر شناختهشده را به شکلی عملیتر و فراگیرتر نشان داد و اهمیت اصلاح آن را برای عرضهکنندگان مختلف روشن کرد.
برای درک سهم فنی او، باید میان جعل یک پاسخ و شکستن رمزنگاری تفاوت گذاشت. DNS سنتی برای همه پاسخها اصالت رمزنگاریشده فراهم نمیکرد. حلکننده از ویژگیهای درخواست و پاسخ برای تشخیص ارتباط آنها استفاده میکرد و مهاجم میکوشید پاسخ نامعتبر را معتبر جلوه دهد. این مسئله به طراحی و رفتار مجموعهای از پیادهسازیها مربوط میشد، نه صرفاً یک خط اشتباه در یک مرورگر. به همین دلیل، خبر آن برای مدیران شبکه و توسعهدهندگان نرمافزار زیرساختی اهمیت ویژه داشت.
کشف تا اصلاح هماهنگ
شرح رسمی Black Hat از این رخداد بر همکاری میان عرضهکنندگان تأکید دارد. پیش از انتشار جزئیات کامل، گروهی از شرکتها و پروژهها روی اصلاح کار کردند و در ۸ ژوئیه ۲۰۰۸ وصلههایی بهصورت هماهنگ منتشر شد. این فاصله زمانی بخشی از ارزش حرفهای کار بود: پژوهشگر باید شواهد کافی برای جدیگرفتن خطر ارائه میکرد، اما انتشار عمومی جزئیات نیز باید با فرصت دفاع هماهنگ میشد. هماهنگی در چنین مقیاسی تنها با توانایی پیدا کردن باگ تمام نمیشود؛ توضیح دقیق، اعتماد میان طرفها و شناخت وابستگی محصولات نیز لازم است.
نباید این رویداد را به روایت نجات اینترنت توسط یک نفر تقلیل داد. تشخیص کامینسکی نقطه آغاز مهمی بود، ولی ساخت وصله، آزمون سازگاری، توزیع نسخه و نصب آن به کار تیمهای متعدد وابسته بود. خود ماهیت چندعرضهکنندهای رخداد نشان میدهد که امنیت زیرساخت یک مسئولیت توزیعشده است. پژوهشگر میتواند مسیر خطر را آشکار کند؛ اثر واقعی زمانی پدید میآید که نگهدارندگان و بهرهبرداران نیز آن یافته را به تغییر عملی تبدیل کنند.
تفاوت کاهش خطر و حل بنیادی
در اطلاعیه ISC، افزایش مقاومت نسخههای اصلاحشده BIND از راهحل بنیادی مبتنی بر DNSSEC جدا شده است. این تمایز برای خواننده امروز نیز آموزنده است. یک وصله ممکن است احتمال موفقیت جعل را بسیار کاهش دهد، اما لزوماً همان تضمینی را ندهد که اعتبارسنجی رمزنگاریشده پاسخ فراهم میکند. ارزیابی امنیت باید روشن کند اقدام انجامشده کدام فرض را تغییر داده و کدام محدودیت را باقی گذاشته است. استفاده از واژه امن بدون توضیح مدل تهدید، چنین تفاوتی را پنهان میکند.
از سوی دیگر، DNSSEC نیز مترادف رمزگذاری همه پرسوجوها نیست. مسئله اصالت داده با محرمانگی ارتباط تفاوت دارد. مرور پرونده کامینسکی فرصت خوبی است تا این لایهها از هم جدا شوند: پیدا کردن نشانی، اعتبارسنجی پاسخ، برقراری ارتباط و بررسی هویت سرویس هر کدام وظیفه خود را دارند. نتیجه آموزشی این ماجرا توصیه به جایگزینی یک فناوری خاص در همه موقعیتها نیست؛ تأکید بر این است که مرز هر ضمانت امنیتی باید دقیق توصیف شود.
میراثی برای پژوهشگر و مدیر شبکه
برای یک پژوهشگر تازهکار، کار کامینسکی یادآور اهمیت پرسیدن سؤال از فرضهای قدیمی است. پروتکلی ممکن است سالها کار کرده باشد، اما ترکیب تازهای از رفتارهای آن پیامدی نشان دهد که پیشتر جدی گرفته نشده است. آزمایش منظم، بازتولیدپذیری و توانایی تبدیل مشاهده به گزارش قابل بررسی، فاصله میان یک حدس و یافته مؤثر را میسازند. شهرت یک کشف نباید جای این فرایند را در روایت حرفهای بگیرد.
برای مدیر شبکه نیز این پرونده یک درس اجرایی دارد: دانستن نام آسیبپذیری کافی نیست. باید مشخص باشد کدام حلکنندهها در اختیار سازماناند، چه نسخهای اجرا میکنند و مشتریان واقعاً از کدام مسیر نامها را حل میکنند. اینها برداشتهای مهندسی از رخدادند، نه ادعای اینکه کامینسکی شخصاً همه رویههای امروزی مدیریت دارایی را طراحی کرده است. جایگاه او در تاریخ امنیت، پیوند دادن تحلیل عمیق پروتکل با اقدامی جمعی است که یک ضعف زیرساختی را به موضوعی قابل اصلاح تبدیل کرد.