در این بخش از دوره آموزشی SEC542 به مبحث احراز هویت به روش OAuth و همچنین مبحث Username Harvesting می پردازیم.
OAuth
OAuth برای حل مشکل برنامه های وب برای اتصال به ارائه دهندگان خدمات ایجاد شده است. اما این کار بدون ارائه Credential به ارائه دهنده خدمات صورت می گیرد. این روش برای برنامه های تحت موبایل و دسکتاپ به شدت کاربرد دارد ولی در برنامه های تحت وب نیز مورد استفاده قرار می گیرد.
نحوه عملکرد OAuth
یکی از مصارف این نوع احراز هویت برای شبکه های اجتماعی مانند توییتر است.
فرض کنید که فردی با نام باب می خواهد از برنامه توییتری SA.NS برای ارسال پست به Twitter Feed های خود استفاده کند. او از برنامه SA.NS استفاده نموده و می گوید که قصد دارد تا با حساب توییتر خود ارتباط برقرار کند.
برنامه SA.NS یک Request Token را به باب ارسال می کند و به او می گوید که به Twitter برو و دسترسی را برای برنامه SA.NS تایید (Approve) کن. برنامه SA.NS سپس باب را برای تایید دسترسی به Twitter هدایت می کند.
در ادامه باب به Twitter می گوید که قصد دارد دسترسی را برای برنامه SA.NS تایید نماید. Twitter در ادامه تایید می کند که باب می خواهد برنامه SA.NS برخی فعالیت ها را از طرف او انجام دهد. هنگامی که باب مجوز دسترسی به حساب خود را تایید می کند، Twitter به باب می گوید که او باید به برنامه SA.NS اطلاع دهد که آن هم اکنون می تواند از Request Token استفاده نماید.
در ادامه باب به برنامه SA.NS می گوید که Request Token آماده است.
سپس برنامه SA.NS از Twitter درخواست می کند که Request Token را به یک Access Token اصطلاحا Exchange نماید.
Twitter کنترل می کند تا مطمئن شود Request Token توسط باب تایید مجوز (Authorized) شده باشد. اگر چنین باشد، Twitter یک Access Token و یک Secret را برای برنامه SA.NS ارسال می کند تا از آن هنگام ارسال پست های توییتری باب استفاده نماید.
در ادامه برنامه SA.NS یک درخواست برای توییتر ارسال می کند تا مطالب باب پست شود و برای صحت و اثبات خود، Access Token را نیز به همراه درخواست ارسال نموده و آن را با Secret اصطلاحات Sign می کند.
در انتها نیز توییتر تایید می کند که امضایی که بر روی Access Token قرار گرفته است معتبر بوده و داده های درخواست شده ای که مربوط به باب می باشد را پست می کند.
برای کسب اطلاعات بیشتر در خصوص احرازهویت OAuth می توانید به لینک های زیر نیز مراجعه نمایید:
https://www.roxo.ir/oauth
https://virgool.io/@mohebbisadegh/oauth2-lbwjnljyorgr
احرازهویت OAuth نسخه یک، وابسته به تایید یکپارچگی Secret بود تا اطمینان حاصل نماید پیام ها جعلی نیستند. در این نسخه نیازی به رمزنگاری در انتقال (SSL) وجود نداشت و همچنین Token ها نیز منقضی نمی شدند. بنابراین اولویت اصلی در این نسخه محافظت از Secret بود.
اما در احراز هویت OAuth نسخه دو، ویژگی های امنیتی ارتقاء یافته و Token ها منقضی می شدند و برای محافظت از آن ها، پروتکل SSL به کار گرفته شد. در تصویر زیر تفاوت درخواست های نسخه یک و دو از احرازهویت OAuth به تصویر کشیده شده است.
مقدار اطلاعاتی که باید در درخواست نسخه یک احرازهویت OAuth بررسی می شود بسیار بیشتر از نسخه دو می باشد. در نسخه یک، امضاها باید بر روی سرور محاسبه شده و تایید شوند تا اطمینان حاصل شود که درخواست ها جعلی نیستند.
اما درخواست ها در نسخه دو، ساختار ساده تری دارند ولی زمانی که توکن ها منقضی شوند، ایجاد مجدد Access Token ها باید به صورت ایمنی مدیریت شوند.
نفوذگران در احراز هویت OAuth نسخه یک، به دنبال کلید ذخیره شده نا امن، رهگیری ایجاد درخواست و Access Token ها می باشند. همچنین آسیب پذیری در برنامه ارائه دهنده خدمات نیز ممکن است Secret را افشا نماید.
توجه داشته باشید که ممکن است برخی از اطلاعات مانند Secret هم در کدهای جاواسکریپت افشا شوند.
Username Harvesting
در تست نفوذ وب، یکی از مراحلی که در استاندارد OWASP هم به آن اشاره شده است، جمع آوری اطلاعات حساب های کاربری می باشد که با عنوان OTG-IDENT-004:Testing for Account Enumeration در استاندارد OWASP شناخته می شود. در این بخش از تست سعی می شود که تا جای ممکن کلیه اطلاعات مربوط به نام های کاربری با روش های مختلف استخراج شود.
معمولا با تعامل با ساختار احرازهویت سایت و پیام های خطای تولید شده در آن می توان به برخی از کلمات عبور موجود در سایت پی برد. پس از انجام این مرحله و شناسایی نام های کاربری، می توان از آن ها برای حملات آتی مانند حملات Brute Force استفاده نمود.
یکی از راه های به دست آوردن نام های کاربری، صفحات احرازهویت می باشند. به عنوان نمونه ممکن است شما با وارد کردن نام کاربری صحیح با کلمه عبور نادرست یک پیام خطا دریافت کنید و با وارد کردن نام کاربری نادرست و کلمه عبور نادرست، یک پیام خطای متفاوت با پیام قبلی را مشاهده نمایید. در این صورت شما می توانید نام های کاربری مختلف را حدس زده و از وجود آن ها اطمینان حاصل نمایید.
مشکلی که در اکثر وب سرورها وجود دارد، عدم کنترل منظم لاگ های آن ها و همچنین عدم وجود سیستم مسدود سازی حساب های کاربری پس از تکرار کلمات عبور اشتباه است. که نفوذگر می تواند از این مشکل سوء استفاده نموده و اقدام به جمع آوری اطلاعات حساب های کاربری نماید.
قطعا ایجاد پیام های خطای متفاوت که در این بخش به آن اشاره گردید جزء طراحی امنیتی نامناسب محسوب می شوند اما در برخی از مواقع این موضوع به صورت عمدی در سایت قرار داده می شود. ممکن است کاربران، نام کاربری خود را فراموش کرده باشند و با نمایش این پیام که نام کاربری اشتباه است، تماس های گرفته شده با بخش پشتیبانی یا Help Desk کاهش پیدا می کند.
علاوه بر صفحات احرازهویت، صفحات مربوط به فراموشی کلمات عبور هم باید مورد بررسی قرار گیرد، زیرا این صفحات با وارد کردن نام کاربری یا ایمیل نادرست، با پیامی به شما اعلام می کند که نام کاربری در پایگاه داده ثبت نشده است یا برای نام کاربری وارد شده ایمیلی ثبت نشده است. بدین صورت نیز شما می توانید نام های کاربری معتبر را شناسایی نمایید.
علاوه بر موارد مذکور، برخی از نشانه های مربوط به صحیح یا نادرست بودن کلمات عبور به صورت مشخص نمایش داده نمی شوند و باید با بررسی پاسخ دریافتی آن ها را تشخیص داد. در برخی موارد هم با استفاده از بخش Comparer در ابزار Burp می توان، تفاوت میان دو درخواست را به منظور کشف نام کاربری معتبر، مشاهده نمود.
به عنوان مورد دیگر هم می توان با بررسی زمان پاسخ و تاخیر ایجاد شده در آن نیز به وجود یا عدم وجود یک نام کاربری در برنامه تحت وب پی برد.
Side Channel Attack
در حملات کانال جانبی از اطلاعات فیزیکی مانند گرما، صدا و EMI یا Electromagnetic Interference برای شکستن یک سیستم استفاده می شود. به عنوان مثال مانیتور کردن CPU یا اندازه گیری شدت گرمای آن می تواند نشان دهنده این موضوع باشد که CPU در حال انجام فرآیند رمزنگاری است و از این اطلاعات می توان در شکستن رمزنگاری استفاده نمود.
بروس اشنایر (Bruce Schneier) یک متخصص رمزنگاری و امنیت سیستم است. وی می گوید:
برخی از محققان ادعا می کنند که این موضوع (حملات کانال جانبی) یک تفلب است. درست است، اما در دنیای واقعی، نفوذگران تقلب می کنند. شغل آن ها این است که کلیدها را استخراج کنند. البته نه از راه قانونی، بلکه آن ها از طرق نامعمول این کار را انجام خواهند داد. اعتقاد ما این است که بییشتر عملیات های Cryptanalysis با استفاده از اطلاعات مربوط به حملات Side Channel انجام می شود.
نکته: توسعه دهندگان وب در ساختار برنامه نویسی خود، در صورتی اقدام به هش رمز عبور دریافت شده از کاربر می نمایند که نام کاربری به درستی وارد شده باشد. بدین معنی که ابتدا نام کاربری و کلمه عبور از کاربر دریافت شده و سپس وجود نام کاربری کنترل می گردد. در صورت عدم وجود نام کاربری، کلمه عبور وارد شده نیز تبدیل به هش نخواهد شد. این مورد کارایی و عملکرد برنامه تحت وب را تاحدی ارتقا می دهد.
با توجه به نکته مذکور، یکی از بهترین روش ها برای شناسایی نام های کاربری در این مورد استفاده از side-channel timing attack می باشد.
Timing Attacks
اغلب از الگوریتم های هش برای ذخیره سازی کلمات عبور و کنترل یکپارچگی استفاده می گردد. در این ساختار ما می خواهیم که هر دو روش دارای رمزنگاری قوی باشند. ولی از نظر سرعت محاسباتی، ساختار هش برای کنترل یکپارچگی باید دارای هزینه محاسباتی پایین تری بوده و ساختار هش برای کنترل کلمه عبور باید دارای هزینه محاسبه بالاتری باشد.
• Integrity hashes should be fast and cryptographically strong
• Password hashes should be slow and cryptographically strong
البته بیشتر الگوریتم های هش رایج مانند SHA1، MD5 و NTLM از ساختار هش با هزینه محاسباتی پایین استفاده می کنند. شما ممکن است تصور کنید که اگر الگوریتم استفاده شده در هش با هزینه محاسباتی بالا (Slow) باشد، این ممکن در هر بار تلاش برای ورود به برنامه تحت وب، بر کاربران بار محاسباتی در CPU داشته باشد ولی این بار محاسباتی برای نفوذگران نیز چالش برانگیز است.
توجه داشته باشید در یک مقایسه کوچک، حدود 180 میلیارد کلمه عبور هش شده با الگوریتم MD5 در ثانیه شکشته می شوند و این در حالی است که تنها 71 هزار کلمه عبور هش شده با الگوریتم Bcrypt در ثانیه شکسته می شوند.
الگوریتم Bcrypt در نسخه 5.5 از PHP به صورت پیش فرض انجام عملیات هش را بر عهده داشته و به صورت Slow فعالیت می کند.
Practical Side Channel Timing Attack
استفاده از الگوریتم های کلمه عبور با هزینه محاسباتی بالا (Slow) به طور قابل ملاحظه ای خطر شکسته شدن کلمات عبور را کاهش می دهد و در واقع استفاده از Slow Password Hash ها یک راه کار مناسب برای مقابله با شکسته شدن کلمات عبور و کاستن از سرعت این نوع حملات است.
البته یک خطای اجرایی در پیاده سازی این روش وجود دارد و آن نمایش یک خطای فوری برای زمانی است که نام کاربری و کلمه عبور نادرست می باشد و ایجاد یک تاخیر کوچک ولی قابل اندازه گیری هنگامی که نام کاربری صحیح بوده و کلمه عبور اشتباه است. لازم به ذکر است که این تاخیر با استفاده از ابزارهایی مانند ZAP و Burp Suite قابل مشاهده می باشد.
برای حل این مشکل باید رمز عبور را در هر دور مورد یعنی هم زمانی که نام کاربری صحیح بوده و هم اشتباه است، هش نمود.
