Timing attacks

[eshpilen]

راجع به این حمله ها و روش جلوگیری ازش کسی چیزی میدونه؟
یکسری منابع که خوندم:
http://rdist.root.org/2010/01/07/timing-independent-array-comparison/
http://rdist.root.org/2009/05/28/timing-attack-in-google-keyczar-library/
http://codahale.com/a-lesson-in-timing-attacks/
http://en.wikipedia.org/wiki/Timing_attack

[eshpilen]

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

بنظرم میشه گفت بیشتر برنامه نویسها از این حمله اطلاع ندارن یا اطلاع و مهارت کافی ندارن نسبت بهش و میشه گفت خیلی از برنامه های شبکه و وب دربرابر این حمله ضعف دارن.

در این حمله نفوذگر با استفاده از زمانی که اجرای برنامه طول میکشه اطلاعاتی رو بدست میاره.

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

منابع میگن که این حمله حتی در محیط اینترنت و نسبت به وبسایت ها قابل اجراست، ولی طبیعتا اجراش در LAN ساده تر و سریعتره و در موارد بیشتری عملی خواهد بود.

احتمالا میتونیم بگیم نوع خیلی متداول و مهم این حمله با استفاده از طرز کار الگوریتم های استاندارد مقایسهء رشته ای عمل میکنه. ولی مسلما تنها به این عملیات و این الگوریتم ها محدود نمیشه.

از مقایسهء رشته ای یه مثال میزنم:
فرض کنید شما یک کلید رمز گذاشتید برای عملیات خاصی.
کلیدتون مثلا 390212456 است. البته من کلید کوتاه و ساده و در نتیجه ضعیفی رو انتخاب کردم بخاطر ساده بودن مثال و راحت شدن توضیح.
حالا نفوذگر میاد و برنامه ای مینویسه که درخواستهایی رو با حداکثر سرعت ممکن به سرور شما ارسال میکنه. در درخواست اول کلید به این صورت ارسال میشه: 000000000.
الگوریتمهای استاندارد مقایسهء رشته به این صورت عمل میکنن که در یک حلقه از اولین کاراکتر دو رشته شروع به مقایسه میکنن و به محض اینکه به اولین مورد اختلاف برسن مقایسه خاتمه پیدا میکنه و از حلقه خارج میشه، ولی اگر در مقایسه تا آخرین کاراکتر اختلافی پیدا نشه دو رشته یکسان هستند.
بنابراین اگر شما یک رشته رو با رشتهء دیگری مقایسه کنید و تعداد کاراکترهای مشترک اونها از ابتدای رشته تا جایی که اولین مورد اختلاف پیدا میشه 5 تا باشه، این عملیات مقایسه دورهای حلقه و عملیات و در نتیجه زمان بیشتری صرف میکنه نسبت به مقایسهء دو رشته که 2 کاراکتر اول اونها با هم یکسانه.
نفوذگر با استفاده از همین اختلاف زمانها میتونه متوجه بشه که آیا یکی دو کاراکتر اول رو درست انتخاب کرده یا نه، و به همین شکل یکی بعد از دیگری کاراکترهای بعدی رو هم کشف میکنه.
یعنی مثلا در درخواست های بعدی حالتهای ممکن برای دو رقم اول رو تست میکنه و هر وقت زمان اجرا افزایش پیدا کرد متوجه میشه که دو رقم اول رو بدست آورده، بعد دو رقم اول کشف شده رو در رشته ثابت میکنه و سراغ تغییر یک یا دو رقم بعدی میره و همینطور دست آخر کل ارقام کلید ما رو به همین راحتی کشف میکنه.

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

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

بازم میگم که این ضعف و حمله فقط به مقایسهء رشته ها و کشف کلید و اینها محدود نمیشه. من با اینکه قبلا راجع به این حمله چیزی نخونده بودم (تاجاییکه یادم میاد) اما با یکی از موارد مشابه در پروژهء خودم برخورد داشتم. اون مورد کاملا متفاوت بود و با اینکه اهمیتش به اندازهء کشف یک کلید نبود اما بازم اهمیت داشت. مورد من این بود که اگر کسی تلاش میکرد با یک نام کاربری خاص لاگین کنه، اگر نام کاربری در دیتابیس وجود داشت طبیعتا یکسری عملیات اضافه و بخصوص عمل هش کردن و مقایسهء هش پسورد کاربر با هش ثبت شده در دیتابیس انجام میشد. خب ولی اگر نام کاربری در دیتابیس وجود نداشته باشه دیگه این عملیات انجام نمیشه و نفوذگر با استفاده از همین اختلاف زمان میتونه براحتی نامهای کاربری معتبر و غیرمعتبر در سایت رو از هم تشخیص بده. ضمنا چون از هش bcrypt استفاده کردم که عمدا با الگوریتم سنگین و زمانبری طراحی شده، بنظرم این حمله خیلی راحتتر و سریعتر هم میشه.
خب بنابراین کاری که من کردم این بود که حتی اگر نام کاربری در دیتابیس وجود نداشته باشه بازهم یک عملیات مقایسهء هش که هیچ کار خاصی جز صرف زمان نمیکنه انجام میدم.
حالا باوجود این کار بازم جای پرسش داره که آیا تمام تفاوت عملیات و زمان همین بوده و آیا عملیات دیگر باعث اختلاف زمان قابل تشخیص نمیشن؟ مثلا همینکه درصورت وجود کاربر تابع mysql_fetch_row رو هم اجرا میکنیم باعث ایجاد اختلاف زمانی قابل تشخیص نمیشه؟ بنظرم میشه! همینطور درمورد هر بخش از کد و شرطها و بلاک هایی که اجرا میشن. پس میبینید که قضیهء کشف و برطرف کردن ضعفهای این حمله چقدر گسترده و پردردسر است.
البته احتمالا فیکس کردن تمام این نوع ضعف ها در بیشتر برنامه ها اصلا ممکن نیست یا خیلی دشوار و هزینه بره و صرف نمیکنه، ولی حداقل موارد واقعا مهم رو باید سعی کرد تا فیکس کرد.

[eshpilen]

8. CONCLUSION
This article studied the scope and potential of performing a remote timing attack,
both on a LAN and across the Internet.
...
We have shown that, even though the Internet
induces significant timing jitter, we can reliably distinguish remote timing differences
as low as 20μs. A LAN environment has lower timing jitter, allowing
us to reliably distinguish remote timing differences as small as 100ns (possibly
even smaller). These precise timing differences can be distinguished with only
hundreds or possibly thousands of measurements.
...
We also observed, generally, that the round trip time or network hop count
did not significantly contribute to the network jitter, and thus network distance
may not confer immunity to remote timing attacks.
...
If an attacker can accurately perform timing measurements, then a number
of cryptographic or algorithmic weaknesses in a server might leak critical
information to the attacker. As a consequence, we recommend that the
algorithms used inside web and other Internet servers that process important
secrets be carefully audited and, where necessary, be modified to limit observable
differences in execution times to at most a few microseconds.


ترجمه:

8. نتیجه گیری
این مقاله محدوده و پتانسیل انجام یک حملهء زمانبندی راه دور را بر روی هردوی شبکهء محلی و اینترنت مطالعه کرد.
...
ما نشان داده ایم که، گرچه اینترنت میزان قابل توجهی نوسان زمان ایجاد میکند، ما میتوانیم بصورت قابل اتکایی تفاوتهای زمانی راه دور به کوچکی 20 میکروثانیه (م: 20 میلیونیم ثانیه) را تشخیص دهیم. یک محیط شبکهء محلی نوسان زمان کمتری ایجاد میکند، که به ما اجازه میدهد تفاوتهای زمانی به کوچکی 100 نانوثانیه (م: 100 میلیاردیم ثانیه) را تشخیص دهیم. این اختلافهای زمانی دقیق میتوانند تنها با صدها یا هزاران اندازه گیری مشخص شوند.
...
ما همچنین مشاهده کردیم، عموما، که زمان رفت و برگشت یا تعداد گره های شبکه باعث مقدار قابل توجهی نوسان شبکه نمیشود، و بنابراین فاصلهء شبکه میتواند به معنای ایمن بودن دربرابر حمله های زمانبندی راه دور نباشد.
...
اگر یک نفوذگر بتواند اندازه گیری های زمانبندی را بطور دقیقی انجام دهد، سپس تعدادی از ضعف های رمزنگاری یا الگوریتمی در یک سرور ممکن است اطلاعات بسیار مهمی را به نفوذگر نشت دهند. بعنوان یک نتیجه، ما توصیه میکنیم که الگوریتمهای استفاده شده در داخل وب و دیگر سرورهای اینترنت که اطلاعات محرمانهء مهمی را پردازش میکنند با دقت مورد بازبینی قرار گرفته، و هرجا که لازم است، جهت محدود کردن تفاوتهای قابل مشاهده در زمانهای اجرا به حداکثر چند میکروثانیه اصلاح شوند.

==============

منبع: http://www.cs.rice.edu/~dwallach/pub/crosby-timing2009.pdf (http://www.cs.rice.edu/%7Edwallach/pub/crosby-timing2009.pdf)
موقعیت ها و محدودیت های حمله های زمانبندی راه دور
SCOTT A. CROSBY, DAN S. WALLACH و RUDOLF H. RIEDI
دانشگاه Rice

[eshpilen]

یکی از کاربران تقاضای نمونه های واقعی این حمله رو کرده بود.
من چند روز پیش به 3 نفر اعضای تیم دانشگاهی که مقالهء معرفی شده در بالا رو تهیه کردن ایمیل زدم.
همینطور به یکی دو نفر دیگه که مقاله های اینترنتی در این مورد دادن.
الان دو نفر جواب دادن. البته نزدیک بود ایمیل ها رو قاطی اسپم ها/تبلیغات و بعضی ایمیل های دیگه دلیت کنم! (درواقع دلیت کردم و موقتا رفت توی سطل زباله که خوشبختانه متوجه شدم و نجاتش دادم) پس شاید قبلا کس دیگری هم جواب داده و اشتباها ایمیلش رو دلیت کرده باشم :لبخند:

یکی از ایمیل ها میگه:

PHP uses C for its comparison operator, which is likely impossible to attack remotely on common server platforms. We were able to observe timing differences in Java frameworks.

See the talk we gave at Blackhat:

http://www.youtube.com/watch?v=idjDiBtu93Y

And here's a good blog post overview:

http://blog.astrumfutura.com/2010/10/nanosecond-scale-remote-timing-attacks-on-php-applications-time-to-take-them-seriously/


ترجمه: « PHP از C برای عملگر مقایسه استفاده میکند که احتمالا نمیتوان از راه دور بر روی سرورهای متداول به آن حمله کرد. ما توانستیم اختلافهای زمانی را در فریمورک های جاوا مشاهده کنیم.
گفتگویی را که ما در Blackhat انجام دادیم ببینید: (لینک یوتیوب بالا)
و یک پست وبلاگ بررسی کلی وجود دارد: (لینک بالا) »

اینطور هم که خودم یخورده دیگه مطالعه کردم، عملگر مقایسهء جاوا به این نوع حمله خوب جواب میده. ظاهرا بخاطر کندتر بودنش (شاید پارامترهای دیگری هم درکار باشه).

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

بعد تازه نرم افزارهای متعدد حرفه ای وجود دارن که به این مسئله بی توجه نبودن و یکسری باگها و ضعفهای خودشون رو در این زمینه برطرف کردن. در بین این نرم افزارها حتی فریمورک Zend دیده میشه. البته اینطور باگها درمورد زند یحتمل خیلی جدی نبودن، اما بهرحال اونا تصمیم گرفتن ریسک نکنن و بنظرشون مسئلهء امنیت چیزی نیست که بشه سبک شمرد؛ حتی اگر این فقط یک احتمال ضعیف باشه. ضمنا همیشه باید پیشرفت ها و اتفاقات آینده رو هم تاحدی که میشه درنظر داشت. حمله های زمانبندی و حتی امکانات سخت افزاری برای انجام اونها درحال پیشرفت بوده. اینکه ما بخوایم به یک فرضهای کلی و مبهم و اثبات نشده برای حال و آینده اتکا کنیم در مورد نرم افزارهای حرفه ای و بخشهای حساس قابل قبول نیست.

یکی دیگه از ایمیل ها هم گفته:

We don't give away our code for this, but it's not hard to write your own.

So far as I know, nobody does these sorts of attacks in the real world.

ترجمه: « ما کدمان را برای این به کسی نمیدهیم، اما نوشتن کد خودتان کار سختی نیست.
تاجاییکه من میدانم، هیچکس این نوع از حملات را در دنیای واقعی انجام نمیدهد. »

[eshpilen]

میشه این مورد رو با مثال بگی. نرم افزار زند فریم ورک توی چه مسئله ای بی توجه بوده یا نبوده؟ منظورتون رو خوب متوجه نشدم همون منابعی که دادم رو خب یه نگاهی بکن. یه سرچ زدن توی صفحه برای کلمهء Zend که کار سختی نیست!

در اون مقالهء وبلاگ میگه:

As of version 1.11 which has been released as a beta, Zend Framework has been patched to remove several timing leaks primarily as a countermeasure against any future exploitation attempts of this nature. This is not considered a critical security vulnerability in the framework given the paucity of evidence that exploits are actively being pursued. Implementing it now, before exploits are widely in use, is simply an act of prudence that offers a measure of forward looking protection for Zend Framework users. I would encourage other frameworks and libraries to take similar steps

ترجمه: « از نسخهء 1.11 که بعنوان بتا منتشر شده است، فریمورک زند برای برطرف کردن چند نشت زمانی عمدتا بعنوان عمل متقابل دربرابر هر اکسپلویت آینده از این نوع پچ شده است. این یک آسیب پذیری امنیتی وخیم تلقی نمیشود، زیرا مدارک بسیار کمی وجود دارند که اکسپلویت ها درحال توسعه هستند. پیاده سازی آن درحال حاضر، قبل از اینکه اکسپلویت ها درحال استفاده باشند، به سادگی یک عمل احتیاطی است که یک دفاع برای آیندهء کاربران فریمورک زند ارائه میکند. من سایر فریمورک ها و کتابخانه ها را هم به برداشتن گامهای مشابه تشویق میکنم. »