WSTG-ATHN-02

بررسی Default Credentials

در این بخش از دوره آموزشی OWASP-WSTG به چهارمین بخش از استاندارد WSTG با شناسه WSTG-ATHN-02 می پردازیم که مربوط به بررسی Default Credentials می باشد.

خلاصه

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

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

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

علت ریشه‌ای این مشکل را می‌توان به صورت زیر شناسایی کرد:

• پرسنل کم ‌تجربهIT، که از اهمیت تغییر گذرواژه‌های پیش‌فرض بر روی اجزای زیرساخت‌های نصب‌شده آگاه نیستند، یا گذرواژه را به عنوان پیش‌فرض برای ease of maintenance یا سهولت نگهداری باقی می‌گذارند.
• برنامه‌نویسانی که Back Door ها را برای دسترسی آسان و آزمایش برنامه رها نموده و در ادامه فراموش می‌کنند که آن‌ها را حذف نمایند. (در این جا Back Door به مفهوم بدافزار نبوده و قابلیتی برای تست برنامه توسط برنامه نویس هست و یا استفاده از موارد پیش فرض برای دسترسی آسان مد نظر می باشد)
• برنامه‌های کاربردی با حساب‌های پیش‌فرض غیر قابل حذف با نام کاربری و رمز عبور از پیش تعیین‌شده.
• برنامه‌هایی که کاربر را مجبور به تغییر اعتبار پیش‌فرض پس از ورود به سیستم نمی‌کنند.

اهداف تست

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

چگونه تست را انجام دهیم

تست برای Credentials پیش‌فرض برنامه‌های کاربردی رایج

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

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

برای انجام این کار می‌توانید مستندات مربوط به شرکت سازنده را مطالعه نموده یا به شیوه‌ای بسیار ساده‌تر، می‌توانید Credential های رایج را با استفاده از یک موتور جستجو شناسایی نموده یا با به سایت‌هایی که لیست مربوط به Credential های پیش فرض دستگاه‌ها و برنامه‌ها را منتشر می‌کنند مراجعه نمایید.

هنگام مواجهه با برنامه‌های کاربردی که در آن ما یک لیست از حساب‌های کاربری معمول و پیش‌فرض نداریم (‏برای مثال به دلیل این واقعیت که برنامه به صورت گسترده مورد استفاده قرار نمی‌گیرد)‏، می‌توانیم تلاش کنیم تا Credential های پیش‌فرض و معتبر را حدس بزنیم.

آشنایی با WSTG-ATHN-01

توجه داشته باشید که برنامه مورد آزمایش ممکن است دارای یک سیاست مسدود سازی حساب بوده و پس از تلاش برای حدس کلمات عبور، حساب کاربری مورد بررسی را مسدود نماید. در صورتی که امکان مسدود شدن حساب کاربری مدیر وجود داشته باشد، ممکن است برای مدیر سیستم مشکل‌ساز باشد که آن را مجددا تنظیم نماید. پس به این موضوع توجه داشته باشید.

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

پس از شناسایی یک نام کاربری پیش‌فرض، می‌توانید حدس زدن رمزهای عبور برای این حساب را نیز آغاز کنید.

اطلاعات بیشتر در مورد این روش را می‌توان در بخش‌های زیر یافت:

از آنجا که این نوع credential های پیش‌فرض اغلب به حساب‌های اجرایی محدود می‌شوند، می‌توانید به این ترتیب ادامه دهید:

نام‌های کاربری admin، administrator، root، system، guest، operator،super و موارد مشابه را امتحان نمایید. این‌ها در میان مدیران سیستم محبوب هستند و اغلب مورد استفاده قرار می‌گیرند. علاوه بر این می‌توانید “qa”، “test”،”test1” ، “testing” و نام‌های مشابه را نیز امتحان نمایید.

در ادامه نیز می‌توانید هر ترکیبی از موارد بالا در هر دو بخش نام کاربری و رمز عبور را تست نمایید. علاوه بر این یک کلمه عبور خالی یا یکی از عبارات “password”، “pass123″، “password123″، “admin”، یا “guest” با حساب‌های بالا یا هر حساب شناسایی شده دیگر را امتحان کنید.

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

نام کاربران مدیریتی کاربردی اغلب به نام برنامه یا سازمان نامگذاری می‌شوند. این به این معنی است که اگر برنامه‌ای به نام “Obscurity” را آزمایش می‌کنید، سعی کنید از obscurity / obscurity یا هر ترکیب مشابه دیگری به عنوان نام کاربری و رمز عبور استفاده نمایید.

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

توجه داشته باشید که آدرس ایمیل مشتری، قرارداد نام گذاری حساب‌های کاربری را نشان می‌دهد: اگر کارمند “John Doe” آدرس ایمیل jdoe@example.com را در اختیار داشته باشد، می‌توانید نام مدیران سیستم را در رسانه‌های اجتماعی پیدا کنید و نام کاربری آن‌ها را با استفاده از همان قرارداد نام گذاری برای نام آن‌ها حدس بزنید. همچنین گزینه بعدی، تلاش برای استفاده از تمام نام‌های کاربری بالا با رمزهای عبور خالی می‌باشد.

سورس صفحه و بخش های JavaScript را از طریق یک پروکسی و یا از طریق مشاهده سورس در مرورگر بررسی کنید. به دنبال هر گونه اشاره به کاربران و رمزهای عبور در سورس بگردید. به عنوان مثال کد زیر را در نظر بگیرید (برای لاگین موفق در برابر لاگین نا موفق):

If username=’admin’ then starturl=/admin.asp else /index.asp

همچنین ، اگر حساب کاربری معتبری دارید، با آن وارد شوید و هر درخواست و پاسخ مربوط به ورود معتبر را در مقابل ورود نامعتبر مانند پارامترهای مخفی اضافی، درخواست جالب GET (login=yes) و غیره را مشاهده کنید.

به دنبال نام حساب‌ها و گذرواژه‌های نوشته شده در کامنت‌های ایجاد شده در سورس بگردید. همچنین در دایرکتوری‌های backup برای سورس کد (یا نسخه‌های backup سورس کد)که ممکن است حاوی کامنت‌ها و کدهای جالب باشند، جستجو کنید.

آزمایش گذرواژه پیش‌فرض حساب‌های جدید

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

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

مراحل زیر را می‌توان برای تست این نوع credential های پیش‌فرض به کار برد:

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

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

اگر در هنگام استفاده از یک نام کاربری معتبر و یک رمز عبور اشتباه بتوانید پاسخ متفاوتی را از برنامه شناسایی کنید، در این صورت می‌توانید یک حمله Brute Force به نام کاربری معتبر را امتحان کنید .

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

اگر قرارداد نامگذاری صحیح برای نام کاربر را شناسایی کرده‌اید، سعی کنید گذرواژه‌های “Brute Force” را با توالی قابل‌پیش‌بینی معمول مانند تاریخ تولد، شناسایی کنید. همچنین، تلاش برای استفاده از تمام نام‌های کاربری بالا با گذرواژه‌های خالی یا استفاده از نام کاربری به عنوان گذرواژه نیز گزینه دیگری برای تست می‌باشد.

آزمایش جعبه خاکستری

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

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

از پرسنل IT بپرسید که آیا گذرواژه‌های پیش‌فرض تغییر کرده‌اند و آیا حساب‌های کاربری پیش‌فرض از غیرفعال شده اند. پایگاه‌داده کاربر را برای credential های پیش‌فرض همانطور که در بخش آزمایش جعبه سیاه توضیح داده شد، بررسی کنید. همچنین فیلدهای پسورد خالی را بررسی کنید.

کد را برای نام‌های کاربری و گذرواژه‌های hard code شده بررسی کنید.

فایل‌های پیکربندی که حاوی نام کاربری و کلمه عبور هستند را بررسی کنید. سیاست کلمه عبور را بررسی کنید و اگر برنامه کاربردی، کلمه عبور خودش را برای کاربران جدید تولید می‌کند، سیاست مورد استفاده برای این روش را بررسی کنید.

ابزاها

• Burp Intruder
• THC Hydra
• Nikto 2