آسیب پذیری هایی که در یک ماه تست نفوذ GitHub پیدا کردیم

آسیب پذیری هایی که در یک ماه تست نفوذ GitHub پیدا کردیم

مقدمه

دراین برنامه باگ بانتی تصمیم گرفتیم روی npmjs.com، یکی از شرکت های تابعه GitHub تمرکز کنیم. با وجود این واقعیت که GitHub یک شرکت بزرگ بود و برنامه باگ بانتی در HackerOne عمومی بود، ما احساس کردیم که ارزش یک بار امتحان کردن را دارد.

شناسایی (ریکان)

در پیگیری ما برای یافتن آسیب‌پذیری‌ها در npmjs.com،  محققان امنیتی Th3Pr0xyB0y (وانش دوگان) و آقای راجپوت هاکر (شیوام سینگ) با انجام یک عملیات ریکان را شروع کردند. ما از محصول داخلی خود، X (بخشی از مجموعه CyberXplore) برای جمع‌آوری هرچه بیشتر اطلاعات، از جمله آدرس‌های IP، پورت‌های باز، اسکرین‌شات‌ها و اندپوینت ها استفاده کردیم. با استفاده از قدرت محاسبات ابری، فرآیند شناسایی بسیار سریع و کارآمد پیش رفت.

پس از بررسی اطلاعات جمع آوری شده، متوجه شدیم برای حمله به هدف npmjs.com و npmjs.org به اسکوپ محدودی دسترسی داریم.

تمرکز برروی منطق کسب و کار (پروژه)

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

آسیب‌پذیری های کشف شده

Id H1 عنوان گزارش هدف تاریخ گزارش  (DD/MM/YY) شدت پاداش
1 تصاحب حساب کاربری، نام کاربری حذف شده قبل از 90 روز که موجب بروز مشکلات عدیده ای می‌شود. https://github.com/ 11/12/22 آگاه‌گر NA
2 Sessionهای حساب کاربری بعد از تغییر نام کاربری هنوز فعال و به حساب کاربری متصل است. https://education.github.com/ 11/12/22 پایین $2000
3 فریب دادن اعضای سازمان قربانی با استفاده از آسیب‌پذیری گمراهی نام در تابع دعوت‌نامه اعضا سازمان https://npmjs.com/ 07/12/22 متوسط تکراری
4 قربانی می‌تواند ادعا کند که صاحب نام کاربری حذف شده است که این اتفاق منجربه تصاحب حساب کاربری مبنی بر کنترل Session حساب کاربری حذف شده می شود https://npmjs.com/ 02/12/22 متوسط $4000
5 حذف کردن حساب کاربری افراد با سواستفاده از پیکربندی اشتباه سیستم پشتیبانی https://npmjs/com/ 11/12/22 کم تکراری ($200)
6 دور زدن تایید ورود به حساب در NPMJS.com https://npmjs.com/ 16/11/22 متوسط $4000
کل پاداش $10000

آسیب‌پذیری به برنامه امنیتی GitHub گزارش شد.

در مقاله به 9 آسیب‌پذیری که از GitHub کشف و گزارش کرده ایم اشاره کردیم، در ادامه به 3 آسیب پذیری از این لیست پرداخته ایم:

1. دور زدن تاییدیه ورود در npmjs.com

2. تصاحب ازقبل حساب کاربری (Pre-Account Takeover) در npmjs.com

3. مشکل کنترل دسترسی در education.github.com

دور زدن تاییدیه ورود در NPMJS

شرح آسیب‌پذیری –

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

برای تمام این توابع چه بازیابی رمز عبور باشد، یا تایید ایمیل یا هر لینک xyz که در این وب سایت وجود دراد و برای هر منظوری استفاده می‌شود، لینک ها به فرمت https://npmjs.com/verify/{some_random_token_here} هستند. در مرحله بعد مشاهده کردیم که هر بار که وارد برنامه شدیم، یک کد تایید به آدرس ایمیل ثبت شده ارسال می کند که شما باید آن را به عنوان بخشی از ویژگی تایید ورود به سیستم (نوعی کد 2FA/MFA در ایمیل) وارد کنید تا با موفقیت وارد حساب شوید. سپس سعی کردیم این عملکرد را دور بزنیم که موفق شدیم آن را دور بزنیم، زیرا در 2 ساعت گذشته از اپلیکیشن به طور کامل استفاده کردیم و با تمام توابع آن آشنا بودیم، بنابراین توانستیم به خوبی با اپلیکیشن و توابع به خوبی ارتباط برقرار کنیم. در ادامه مراحل بازتولید دور زدن را مطالعه کنید تا ببینید چگونه این کار را انجام دادیم.

درطول مدت زمانی که فرایند احراز هویت و توابع عمومی npmjs.com مثل، به روزرسانی آدرس ایمیل ها و پروفایل‌ها را تست می‌کردیم، متوجه رفتار عجیبی در فرمت لینک‌های تایید، لینک های بازیابی رمزها و لینک های ارسال شده برای به روزرسانی آدرس های ایمیل شدیم. این لینک‌ها در قالب https://npmjs.com/verify/{random_token} بودند، و برای توابعی ازجمله بازیابی رمزعبور، تایید ایمیل و … مورد استفاده قرار گرفته بود.

همچنین متوجه شدیم که هرموقع که یک کاربر وارد اپلیکیشن می‌شود، یک کد تایید به آدرس ایمیل ثبت شده ارسال می‌شود. این کد تایید از ملزومات کامل شدن فرایند ورود بود، که یک نوع ورود دو مرحله ای بود. دومین موردی که نظر ما را به خود جلب کرد، متوجه شدیم که زمانیکه میخواهیم آدرس ایمیل را روی npmjs به روزرسانی کنیم،فرایند به روزرسانی بدون نیاز به تایید رمزعبور انجام می‌شود. یک ایمیل هم به آدرس ایمیل جدید و هم به آدرس ایمیل قدیمی ارسال می‌شود. ایمیلی که به آدرس قدیمی ارسال شده به گیرنده اطلاع می‌دهد که اگر تغییر از سمت آنها نبوده، می توانند با کلیک روی لینک (https://npmjs.com/verify/{some_random_token_here}) تغییر را لغو کنند و آدرس ایمیل را به همان آدرس ایمیل فعلی بازگردانند. ایمیل ارسال شده به آدرس جدید حاوی پیوندی برای تأیید ایمیل جدید و پیوند آن به حسابی است که به تازگی به روز شده است.

در زمان تلاش برای ورود به یک حساب کاربری بعد از به روزرسانی آدرس ایمیل در صفحه پروفایل، با یک مورد جالب مواجه شدیم. علی رغم اینکه ایمیل را تایید نکرده بودیم یا روی تمام لینک هایی که برای مان در آدرس جدید و قدیم ارسال شده بود کلیک نکرده بودیم، سیستم پیامی را نمایش می‌دهد که نشان می‌دهد کد تایید به آدرس ایمیل جدیدی که هنوز تایید نکرده‌ایم ارسال شده است. درنگاه اول اینگونه به نظر می‌رسد که قادر به لاگین کردن نیستیم. با این حال، پس از بررسی دقیق‌تر، ایمیلی را کشف کردیم که به آدرس قدیمی ما ارسال شده بود و از ما می‌خواست برای جلوگیری از قفل شدن حساب، تغییر را لغو کنیم. با کلیک روی لینک (https://npmjs.com/verify/{random_token}) برای بازگرداندن آدرس ایمیل قدیمی به صفحه ورود هدایت شدیم. در کمال تعجب، زمانی که ما اطلاعات کاربری خود را وارد کردیم، سیستم کد تایید درخواست نکرد و در عوض به ما اجازه داد وارد سیستم شده و تغییر ایمیل را لغو کنیم.

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

مراحل باز تولید –

1. ثبت حساب کاربری بااستفاده از ایمیل [email protected] (با نام حساب کاربری attacker1)

2. ورود به حساب کاربری با نام attacker1 از طریق وارد کردن نام کاربری و رمز عبور (چون ورود به سیستم npmjs فقط با استفاده از نام کاربری و رمز عبور امکان پذیر است.)

3. وارد حساب کاربری شوید > آدرس ایمیل را به روزرسانی کنید> [email protected]

4. صندوق پیام های دریافتی ایمیل [email protected] را بررسی کنید و ایمیلی که از سمت npmjs.com آمده را مشاهده کنید.

GitHub

5. لینک https://www.npmjs.com/verify/{some_random_token_here} را بازکنید. این لینک شما را به آدرس صفحه ورود راهنمایی می‌کند > با استفاده از نام کاربری و رمز عبور قربانی وارد شوید.

6. بدون نیاز به کد تایید به صفحه 404 هدایت می‌شوید و وارد حساب کاربری می‌شوید! (حتی باوجوداینکه صفحه پیامی به شما نشان می دهد که به شما می گوید به حساب کاربری درست وارد نشده اید)

مثال عملی (POC) –

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

اثرات –

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

نتیجه گیری ما –

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

معیارهای آسیب‌پذیری های بحرانی ذکر شده در صفحه قوانین GitHub در HackerOne

• اجرای کد/فرمان دلخواه در یکی از سرورهای موجود در شبکه محصول GitHub

• اجرای کوئری های دلخواه SQL روی پایگاه داده محصول

• دور زدن فرایند ورود به سیستم، با رمز عبور یا 2FA

• دسترسی به داده‌های حساس کاربران محصول یا دسترسی به سیستم‌های محصول داخلی

• دسترسی به داده های سایر کاربران در سرویس عملیاتی GitHub

اسکرین شات قوانین GitHub
اسکرین شات قوانین GitHub

درخواست بازخورد از تیم GitHub: اگر یکی از اعضای تیم GitHub توجیهی برای طبقه بندی آسیب پذیری در دسته متوسط داشته باشد، از پاسخ به گزارش یا با تماس با حساب های کاربری @th3pr0xyb0y و @mrrajputhacker2 در H1 سپاسگزاریم.

تصاحب ازقبل حساب کاربری (Pre-Account Takeover) روی npmjs.com

شرح آسیب‌پذیری –

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

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

1. آیا اگر از یک مرورگر دیگر برای ورود به حساب کاربری استفاده کنیم، قادر به دسترسی داشتن به آن هستیم یا نه؟ ما متوجه شدیم که حذف حساب از یک مرورگر بلافاصله کاربر را از تمام session های دیگر خارج می کند.

2. آیا دوباره بااستفاده از همان نام کاربری‌ای که اخیرا حذف شده می‌توانیم دوباره ثبت نام کنیم؟ این بررسی به ما نشان داد که ثبت نام با استفاده از نام کاربری ای که قبلا حذف شده یا هنوز از آن استفاده می‌شود امکان پذیر نیست.

3. آیا راهی برای تغییر نام کاربری یا ادعای نام کاربری جدید/حذف شده وجود دارد؟ ما متوجه یک آپشن برای ادعا یا تغییر یک نام کاربری در اپلیکیشن شدیم، و آن ایجاد یک سازمان در حساب کاربری npmjs است. این آپشن به ما اجازه داد تا یک نام کاربری جدید برای سازمان انتخاب کنیم یا حساب کاربری خود را به حساب کاربری یک سازمان تبدیل کنیم و اساسا نام سازمان را به نام کاربری دلخواه تغییر دهیم. هرچند با این آپشن هم قادر به تغییر نام کاربری سازمان به نام کاربری ای که قبلا حذف کرده بودیم هم نشدیم.

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

مشاهدات جدید در تحقیقات ما –

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

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

اگر این توضیحات برایتان گیج کننده بود ، لطفاً برای درک بهتر این آسیب پذیری، به مراحل بازتولید و اثبات مفهوم با مثال عملی مراجعه کنید.

مراحل بازتولید –

1. با استفاده از گوگل کروم، با یک نام کاربری رایج به عنوان مهاجم ثبت نام کنید (برای مثال، commonusername123)

2. از پشتیبانی درخواست کنید تا حساب کاربری را حذف کنند.

3. به محض اینکه حساب کاربری از سمت پشتیبانی حذف شد، همانطور که داخل حساب کاربری هستید، مرورگر را رفرش کنید. متوجه خواهید شد که به غیر از صفحه پروفایل ، بقیه صفحات نام کاربری حذف شده را هنوز نمایش می دهند. (لینک صفحه به اینصورت خواهد بود https://npmjs.com/~username )

4. به لینک https://www.npmjs.com/settings/commonusername123/profile بروید. صفحه 404 برای شما نمایش داده خواهد شد.

5. به عنوان یک قربانی با یک نام کاربری متفاوت ثبت نام کنید (مثلا victimusername123)

6. حساب کاربری قربانی را به یک سازمان تبدیل کنید. با این کار نام کاربری سازمان victimusername123 خواهد بود و از شما درخواست می شود که یک نام کاربری جدید انتخاب کنید. از نام commonusername123 را به عنوان نام کاربری جدید استفاده کنید.

7. صفحه session مهاجم (https://npmjs.com/~username ) را با استفاده از مرورگر گوگل کروم رفرش کنید.

8. به لینک https://www.npmjs.com/settings/commonusername123/profile بروید. اکنون شما ایمیل قربانی (مثلا [email protected]) را مشاهده خواهید کرد و به حساب کاربری قربانی و سازمانی که ایجاد کرده دسترسی خواهید داشت.

مثال عملی (POC )–

لینک یوتیوب ویدیو POC

اثرات–

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

نتیجه گیری ما –

در پایان، در حالی که ما برای کشف یک آسیب‌پذیری در GitHub هیجان‌زده بودیم،پاداشی که در برابر آن گرفتیم مایوس کننده بود. این باگ یک آسیب پذیری تصاحب حساب کاربری پیچیده بود که ممکن بود یک سازمان بزرگ را تحت تاثیر قرار دهد. برای شفاف تر شدن میزان اثر این آسیب پذیری، ما یک حساب کاربری با کوکی های ذخیره شده و session های فعال را به مدت 3 ماه نگه داشتیم، تا ثابت کنیم session یک حساب کاربری حذف شده هیچ وقت روی npmjs منقضی نمی‌شود. با این حال، GitHub این آسیب پذیری را یک آسیب پذیری سطح “متوسط” شناسایی کرد و فقط 4000$ پاداش به آن تخصیص داد.

مشکل کنترل دسترسی در education.github.com

توضیحات –

پس از احساس نارضایتی از پاسخ و پاداش GitHub به گزارش آسیب‌پذیری قبلی ما روی npmjs ، تصمیم گرفتیم که روی سایر زیردامنه‌های GitHub متمرکز شویم. متوجه شدیم که education.github.com برای فرایند ورود خود از GitHub Single Sign-On (SSO) استفاده می‌کند. باالهام گرفتن از باگ‌هایی که در npmjs پیدا کرده بودیم، همان رویکرد استفاده از نام کاربری حساب پاک شده را دوباره مورد بررسی قرار دادیم.

با کمال تعجب متوجه شدیم که با پاک کردن یک حساب کاربری از GitHub، قسمت session آن در education.github.com منقضی نمی شود و تمام صفحات پیام خطای 404 را نمایش می‌دهند، حتی اگر هنوز داخل سیستم باشید (Logged in). در یک مرورگر دیگر، سعی کردیم تا با استفاده از همان نام کاربری حساب حذف شده یک حساب کاربری جدید در GitHub ایجاد کنیم، که براساس قوانین و سیاست های GitHub تا 90 پس از حذف یک نام کاربری، قادر به ایجاد حساب با همان نام کاربری حذف شده نبودیم.

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

Bypassing The Access Control (دور زدن کنترل دسترسی) –

مشاهده کردیم با وجود اینکه در GitHub یک نام‌کاربری را تغییر دادیم و session خود را در Education.github.com رفرش کردیم، باوجوداینکه نام کاربری را در نمایه GitHub تغییر دادیم، نام کاربری همان بود، به این دلیل که توکن session به نام کاربری متصل است و SSO تنها زمانی رفرش می‌شود که دوباره از اول وارد GitHub شویم. بنابراین ما به سرعت مدعی حساب کاربری GitHub حذف شده شدیم و سپس مدعی نام کاربری قدیمی که هنوز در https://education.github.com با آن حساب مرتبط بود شدیم، و با استفاده از حساب جدید github در مرورگرهای مختلف و در مرورگر جدید وارد https://education.github.com شدیم. اکنون مشاهده کردیم که هر دو حساب نام کاربری یکسانی دارند، ولیکن ایمیل‌های متفاوتی با آنها مرتبط است که کاملا کاربردی هستند، پس اگر فرم آموزشی ارسال کنیم یا هر عملکردی را راه‌اندازی کنیم، می‌تواند باعث آسیب به یکپارچگی داده‌ها در هر دو طرف شود، بنابراین ما این موضوع را به عنوان یک مشکل گزارش کردیم و به عنوان یک مشکل معتبر پذیرفته شد.

ما متوجه شدیم که حتی پس از تغییر نام کاربری GitHub، در Education.github.com بخش session بدون تغییر باقی ماند. این به این دلیل بود که توکن session به نام کاربری گره خورده بود و SSO پس از ورود فقط از طریق GitHub آن را به‌روزرسانی می‌شود. برای بهره برداری از این مشکل، ما به سرعت یک حساب GitHub حذف شده را انتخاب کردیم و سپس مدعی نام کاربری قدیمی شدیم که هنوز با یک حساب کاربری Education.github.com مرتبط بود. سپس با استفاده از یک مرورگر جدید با یک حساب GitHub جدید به Education.github.com وارد شدیم و متوجه شدیم که هر دو حساب اکنون نام کاربری مشابهی دارند اما آدرس‌های ایمیل متفاوتی دارند که هردو به درستی کار می‌کردند.

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

مراحل بازتولید آسیب‌پذیری –

1. وارد حساب کاربری GitHub تان شوید.

2. به https://education.github.com/schools بروید.

3. نام کاربری حساب GitHub تان را تغییر دهید.

4. صفحه را رفرش کنید یا دوباره به صفحه https://education.github.com/schools و نام کاربری را از قسمت آیکن پروفایل در سمت راست بررسی کنید.

5. متوجه می‌شوید که نام کاربری قدیمی هنوز روی education.github.com فعال است.

6. از آنجایی که نام کاربری قدیمی قابل ادعا است، به نظر می رسد که با ادعای آن امکان تصاحب حساب کاربری در Education.github.com وجود دارد.

7. اگر ایمیل دانشگاه ندارید، نمی‌توانید تأیید کنید که اقدامات انجام شده در session قبلی روی حساب جدیدی که با نام کاربری قدیمی ثبت‌شده است تأثیر می‌گذارد یا خیر.

8. با یک حساب کاربری جدید که همان نام کاربری session قبلی را دارد، در یک پنجره جدید کروم به Education.github.com وارد شوید.

9. خواهید دید که اکنون دو session فعال با نام کاربری مشابه دارید.

اثرات–

تاثیر این مشکل بایستی توسط تیم GitHub ارزیابی شود. این آسیب‌پذیری این پتانسیل را دارد که اطلاعات حساس کاربران جدید مانند آدرس مدرسه یا ایمیل و اطلاعات شناسایی شخصی (PII) را در صورت ثبت نام با نام کاربری که یک session فعال برای آن وجود دارد، به خطر می اندازد. این آسیب‌پذیری می‌تواند منجر به تصاحب حساب و نشت PII شود.

نتیجه گیری –

ما خوشحالیم که توانستیم این آسیب‌پذیری را در GitHub پیدا کردیم، حتی باوجوداینکه شبیه چیزی بود که در npmjs پیدا کردیم. این بار، ما نتوانستیم تأثیر کامل این موضوع را ارزیابی کنیم.بااین وجود از پاداش بانتی ای که شکار کردیم راضی بودیم.

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *