توضیح عمیق آسیب‌پذیری‌های JWT (بخش سوم)

مقالات آموزشی ، وبلاگ
ارسال شده توسط
1404/07/22
52 بازدید

سلام من بهروزم و با توضیح عمیق آسیب‌پذیری‌های JWT (بخش سوم) در خدمتتونم.

اگر بخش اول و دوم رو مطالعه نکردید بهتره همین الان بری و مطالعه کنی و برگردی 😉 

مشغول کار کردن روی یه سایت بودم که بعد از ورود مجدد، متوجه شدم که وب‌سایت برای احراز هویت از JWT استفاده می‌کند.

JWT شبیه این بود:

توضیح عمیق آسیب‌پذیری‌های JWT (بخش سوم)

در JWT دو فیلد مهم وجود داره:

sub : شناسه کاربری قربانی (به همراه نام‌کاربری، به‌صورت عمومی قابل‌دسترس).

sss : یک شناسه خصوصی برای جلسه (خصوصی).

پس چند ترفند JWT را امتحان کردم: alg:none، امضا با کلیدِ خالی، مقدارهای تصادفی و غیره. هیچ‌کدام کار نکرد.

بعد از آن، Hashcat را برای پیدا کردن key ضعیف اجرا کردم:

hashcat -a 0 -m 16500 "eyJ0eXAiOiJKV1QiLCJhbGciOiJIU…" /usr/share/wordlists/Passwords/scraped-JWT-secrets.txt

…و بعدش فراموشش کردم. 🙃

چند وقتی گذشت؛ وقتی در Burp می‌گشتم، یک مشکل با شدت «High» دیدم که عملاً فریاد می‌زد:

«داداش، منو از قلم انداختی!»

توضیح عمیق آسیب‌پذیری‌های JWT (بخش سوم)

کلید کلمه secret بود. 🙂 

بله. همون بود. کلید امضای JWT در محیط تولید عملاً کلمه «secret» گذاشته شده بود. 🤦‍♂️


🔑 جعل و ورود من

با داشتنِ secret، حالا می‌تونستم JWT جعل کنم. اما نکته این بود: چطوری مقدار sss قربانی رو به‌دست بیارم در حالی که عمومی نیست. این ترفندها رو امتحان کردم:

  • بدون فیلد sss: payloadِ JWT رو بدون فیلد sss ساختم.

  • فیلد sss خالی: فیلد sss را با رشته‌ای خالی فرستادم.

  • sss تصادفی: یک رشته اشتباه برای sss گذاشتم (مثلاً "random").

هیچ‌کدوم از این‌ها کار نکرد. بعد یک موضوع 💡 به ذهنم رسید: چی می‌شه اگه payload رو با فیلدهای زیر امضا کنم:

  • sub: شناسه قربانی (قابل‌دسترس عمومی)

  • sss: sss مهاجم

وقتی با این فیلدها JWT رو امضا کردم و درخواست GraphQL را برای تغییر نام‌کاربری قربانی فرستادم پاسخ 200 OK برگشت و نام‌کاربری قربانی با موفقیت تغییر کرد.


👤 تسخیر حساب (Account Takeover)

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

اما بعد متوجه شدم یک چیز زیرکانه وجود دارد: پلتفرم به کاربران اجازه می‌داد ایمیل‌شان را تغییر دهند.

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

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

POST /graphql HTTP/2
Host: target.com
Referer: https://target.com/test3/edit
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciO....  (Forged Token With victim's suid) 

{"query":"mutation UserEditFormMutation(\n  $id: ID!\n  $input: UpdateUserInput!\n) {.....}\n","variables":{"id":"AFVzZXI....LhFgIk","input":{"email":"msaadsbr+10@intigriti.me"}}}

پاسخ ۲۰۰ OK گرفتم. و ایمیلِ قربانی به ایمیلِ من تغییر کرد.

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

در اینجا بازی تموم بود: بازنشانی رمز عبور → بدون ۲FA → هیچ تأییدی به ایمیل قبلی زده نشد → تسخیر کامل حساب. 🎯

اگر به هک و امنیت علاقه داری همین الان صفحه کلوپ امنیت ۱ و پیشرفته رو ببین.

"توضیح عمیق آسیب‌پذیری‌های JWT (بخش سوم)"
برچسب ها: