گپوگفتی با پردرآمدترین شکارچی راورو در سال ۱۴۰۰؛ مهدی مرادلو (moradlooo)
در این بلاگپست، به سراغ پردرآمدترین شکارچی راورو در سال ۱۴۰۰ رفتیم تا با او گپوگفت کوتاهی داشته باشیم؛ مهدی مرادلو (@moradlooo)
مهدی یه هکر کلاهسفید و اهل زنجان است. از حدود شش ماه پیش با راورو همراه شده، تا تاریخ این مصاحبه، ۸۹ گزارش آسیبپذیری در راورو ثبت و ۳۵۹ امتیاز کسب کرده است. بیشتر گزارشهای مهدی، دربارهی آسیبپذیریهای درگاههای پرداخت هستند.. مهدی در بین شکارچیهای آسیب پذیری در راورو، بیشترین تعداد گزارش را با موضوع آسیب پذیریهای درگاههای پرداخت ثبت کرده است.
- مهدی جان، خودت را برایمان معرفی میکنی؟
مهدی مرادلو هستم، ساکن زنجان. مدت زیادی در موقعیتهاش شغلی مختلفی کار کردهام و نزدیک به یک سال است که وارد فیلد امنیت شدهام. کار گرافیک کار کردهام، Back End کار کردهام، طراحی وب، UI و UX انجام دادهام، کارهای مارکتینگ و سئو انجام دادهام. از برنامه نویسی Back End که یک سری چیزهایی دستگیرم شد، بهمرور امنیت سایبری برایم پررنگتر شد. اما مشکل این بود که همزمان در همهی حیطهها نمیشد Top شد، پس تصمیم گرفتم فیلد تخصصی خودم را انتخاب کنم.
- گفتی یک سال است که وارد حوزهی امنیت شدهای؟
بله، تقریبا یک سال شده. قبلا برنامه نویسی میکردم و وقتی برنامه نویسی میکنی، بهمرور تفکر امنیتی هم پیدا میکنی. همین باعث شده که سریعتر بتوانم خودم را در این حوزه پیدا کنم.
- بهطور کلی یعنی شما وسعتی را تجربه کردهای و بعدش تصمیم گرفتهای در بخشی از آن، عمیق شوی.
- مهدی جان، شما جزو پردرآمدترین شکارچیهای راورو در سال گذشته بودهای. به نظر شما، باگ بانتی میتواند بهعنوان یک شغل تماموقت برای یک شکارچی محسوب شود؟
به نظر من قطعا امکانپذیر است. کسانی که باگبانتی کار میکنند، چه در پلتفرمهای باگ بانتی و چه در خارج از آنها، درآمد خوبی دارند. به نظرم باگ بانتی میتواند بهعنوان یک شغل تماموقت باشد. ولی قطعا به میزان تخصص شکارچی هم بستگی دارد. علاوهبر برنامههای باگبانتی داخل پلتفرمها، خیلی کسبوکارها هم باگبانتی را در زیرساخت خود راهاندازی کردهاند. که شکارچیهای آسیب پذیری روی آنها هم میتوانند کار کنند. حتی بعضی کسبوکارها که برنامهی باگ بانتی ندارند هم، وقتی گزارش را بهشان میدهی، قبول میکنند. شرایط دریافت گزارش آسیب پذیری و نگاه به باگ بانتی در سمت کسبوکارها، نسبت به قبل درحال بهبود است. الان شرایط مثل ۴،۳ سال قبل نیست و از گزارشهای آسیب پذیری بیشتر استقبال میشود.
- آره، جو بهتری الان برقرار است. سالهای قبل اگر شکارچی آسیب پذیری گزارشی داشت، کسبوکارها بانتی که نمیدادند، هیچ! حتی گاهی کار به شکایت و زندان هم میرسید!
آره، الان خیلی بهتر شده.
امنیت سایبری قبلا یک موضوع لاکچری محسوب میشد که فقط سازمانهای بزرگ داشتند. اما الان اینطور نیست و بهتر شده است. قبلا پوزیشنهای شغلی کمتری هم در حوزهی امنیت سایبری وجود داشتند که بهرسمیت شناخته میشدند. به همین دلیل خیلی از افراد، شکارچی آسیب پذیری شدن یا کلا فعالیت در حوزهی امنیت را انتخاب نمیکردند و سراغ شغلهای دیگر میرفتند.
- دراین ۸۷ گزارشی که ثبت کردی، آیا آسیب پذیری های نوع خاصی بیشتر بودهاند؟
بیشتر گزارشهای من مربوط به آسیب پذیری های درگاههای پرداخت بوده. اغلب هم آسیب پذیری Race Condition بودهاند. چون سامانههای میدانها و اهداف متفاوت بودند، حملات و شیوههایشان هم متنوع بودند. برای یک حمله، هوش و ابتکار بیشتری لازم بوده برای بعضی هم اینطور نبود. مثلا آسیب پذیریای که برای شاتل ثبت شده، با آسیب پذیریای که برای مدیانا ثبت کردهام، فرق میکرد. من قبل از اینکه سامانهی هدف را باز کنم، با خودم فکر میکنم که "این سامانه، باتوجه به نوع کسبوکار و نوع سامانهاش، چه آسیب پذیریهایی ممکن است داشته باشد؟" این سوال خیلی مهم است. وقتی جوابی برای این سوال داشته باشم، قطعا راحتتر میتوانم آسیب پذیری را پیدا و گزارش کنم. مثلا روی سامانهای مثل نماوا، با خودم فکر کنم که یکی از آسیب پذیری های منطقیای که ممکن است وجود داشته باشد، این است که ویدئو منتشرشده باشد و تو مثلا با استاتوس بیایی و در UI جلویش را بگیری که نگذاری نمایش دهد. در Response سرور هم جواب را داشته باشی. این آسیب پذیری الان در نماوا وجود ندارد. ولی بهطور کلی از نوع آسیب پذیری هایی ست که ممکن است در یک سامانه مثل نماوا وجود داشه باشد. از این ممکنها خیلی هست، وقتی از نوع کسبوکار و سامانه شناخت داشته باشی و منطقش (Logic) دستت آمده باشد، این ممکنها را که کنارهم بچینی ، دستت برای شکار آسیب پذیری، بازتر است.
- دقیقا، باید بهخوبی بشناسی؛ ساختار (Structure) سایت را بشناسی، موردتوجه داشته باشی خدمتی سایت ارائه میدهد، چگونه خدمتی ست؟ از چه End Pointهایی استفاده میکند؟ تکنولوژیهایش چیست؟ چه کار دارد میکند؟ چند تا IP درگیره در این فرآیند اند؟ و … . اینها همه از مکانیزمهای Recon هستند. تو برای جمعآوری اطلاعات (Information Gathering) و Recon از چه ابزارهایی بیشتر استفاده میکنی؟
من بیشتر از DNSRecon استفاده میکنم. روی دامنه میزنم و ... . مرحله بعدیام این است که در خود سایت میروم و امکاناتی که دارد را استفاده میکنم تا بتوانم End Pointها را به دست بیاورم. یک ابزار دیگر هم که استفاده میکنم، که روی Burp نصب میشود، JSFinder هست که مزیتش این است که خروجیهای مرتبی میدهد؛ فایلهای جاوااسکریپت و لینکهایش را میشود جداسازی کرد.
- به نظر تو، گزارش آسیب پذیری، چقدر در مقدار بانتی دریافتی تاثیر دارد؟ سناریویی که هکر و هانتر مینویسد، چه تاثیری در میزان بانتی دریافتی میتواند داشته باشد؟
به نظر من خیلی تاثیر دارد! من یک آسیب پذیریهایی پیدا کردم، و duplicate خورد. برایم عجیب بود که گزارشی که به آن ارجاع داده شده بود، ۵۰۰ هزار تومان گرفته است! با وجود اینکه با این آسیب پذیری میتوانستی به مدیریت سایت دسترسی پیدا کنی، ۵۰۰ هزار تومن بانتی گرفته بود! مشکلش چه بود؟ هم گزارش تکمیل نبوده، هم سناریو تکمیل نبوده و هم … .
پیشنهاد خواندنی: چرا گزارشهای آسیب پذیری رد میشوند؟ یا به بانتی کمی منجر میشوند؟
در کل، این مورد خیلی پیش میآید که آسیب پذیری خوب و مهمی وجود دارد، ولی میبینی که گزارشش سناریوی ناقصی داشته. مثلا وقتی XSS میزنند یا وقتی میآیند و یک tag را XSS Stored میزنند ، خب تو میاتونی اینجا بیایی و tag گوگل را بذاری... من مشابه همچین چیزی را داشتم تکمیل میکردم که در صفحهی اولش میشد tagهای HTML گذاشت. اگر به جای این، بیایی و tagی که گوگل میدهد برای Verify کردن سرچکنسول بذاری، حتی بیشتر از Account Takeover ارزش دارد. چون اینطوری میتوانی به سرچ کنسول و کل سایت دسترسی داشته باشی! کل مارکتینگش در دست توست! اما چون اکثریت، با سئو آشنایی ندارند و نمیدانند که سرچ کنسول چقدر اهمیت دارد، خیلیها به همان Account Takeoverش بسنده میکنند.
پیشنهاد خواندنی: توصیههایی برای ارتقای امنیت وبسایتهای خبری
- غیر از درگاههای پرداخت که بهعبارتی میتوان گفت که حوزهی تخصصی توست، دیگر آسیبپذیر بودن چه نقاطی از سامانهها توجهت را جلب کرده است؟
یکی از مسئلههای مهمی که به نظرم هست، این است که در کمپینها روی امنیت لندینگ پیجها زیاد کار نمیشود. لندینگ پیجهایی که مثلا برای کمپینهای نوروز یا شب یلدا میگذارند را من میتوانم بگویم که، به احتمال بالای ۹۰٪ آسیب پذیری روی آنها وجود دارد! چون برنامهنویس باید سریع هندل کند؛ در تایم کوتاهی قرار است کدش را بنویسد، دیپلوی کند و بالا بیاورد! این سرعتی که معمولا در فرآیند اجرا پیش میآید، و اینکه تایم کوتاهی هم قرار است مورد استفاده قرار بگیرند، باعث میشود که حساسیتهای امنیتی لازم در آنها رعایت نشود و اکثرا آسیبپذیر باشند.
مثلا من وقتی میخواهم رو هدفی کار کنم، گاهی میروم و کمپینهای قدیمیشان را چک میکنم تا ببینم آسیب پذیریای وجود دارد که به من دسترسی بدهد؟ یادم است که یک بار آسیبپذیری Account Takeoverی گزارش کردم که مربوط به همین کمپینها میشد. یادم است که از داخل کمپینها که میرفتی و توکنی که بهت میداد روی سایت اصلی هم کار میکرد. در واقع مشکلی که وجود داشت این بود که در کمپین یک کد چهاررقمی وجود داشت که نسبت به Rate Limit هم آسیبپذیر بود و میتوانستی توکن را به دست بیاوری.
روی هدف دیگری هم این آسیب پذیری را بررسی کردهام، مربوط به لندینگ پیجش بود. ولی قبول نکردند، چون پروکسی لیست باید استفاده می شد که طبق قوانین میدان قابلقبول نبود .ولی خب در حالت عادی فقط می شد سه تا چهار بار درخواست برای ورود به حساب کاربری را فرستاد ولی در لندینگ پیچ می شد نزدیک به ۵۰۰ درخواست را فرستاد بدون اینکه WAF آروان IP را بلاک کند.
- خودت هم اشاره کردی که اغلب گزارشهای آسیب پذیریای که ثبت کردهای، مربوط به درگاههای پرداخت بودهاند. نگاه دقیقی به درگاههای پرداخت داری و سناریوها و گزارشهای کامل و جذابی مینویسی.
یک نکتهی مهم راجع به درگاههای پرداخت نقش مهمشان در اکثر کسبوکارهاست. در اکثریت سایتها، درگاه پرداخت وجود دارد و استفاده میشود. و وقتی زیاد رویش کار میکنی به آسیب پذیریهایش مسلط میشوی و در همه جا میشود آن را اجرا کرد و ازش استفاده کرد. کاربردهای زیادی دارد و بر روی اکثر سایتها میشود پیدا کرد.
- آره، این نکته را میشود به سایر آسیب پذیریهای بقیهی نقاط سامانه هم تعمیم داد. وقتیکه روی یه باگ مسلط شوی، و همان باگ را بیایی و روی بقیهی سایتها هم امتحان کنی، مطمئنا به نتیجه میرسی. همین Race Condition را اگه روی چندین جا بزنی، احتمالا به بانتیهای خوبی منجر شود.
- در بین باگهایی که روی درگاههای پرداخت کشف کردهی، باگی بوده است که دسترسی خیلی خوبی برایت مهیا کند؟ مثلا به دیتاهایی دسترسی داشته باشی، بتوانی دیتا بیرون بکشی، باگ RCE داشته باشد یا ...؟
آره، پیش آمده که توانسته باشم به دیتا دسترسی داشته باشم و آن را بیرون بکشم. باگ RCE نبوده و تاحالا در سمت درگاهها ندیدهام. ولی data خیلی دیدم. نکتهی دیگهای که وجود دارد و باز به آن توجه نمیشود، این است که پاسخی که از در گاه پرداخت که برمیگردد، عموما data را برمیگرداند. روی بیشتر سایتها این آسیب پذیری وجود دارد که میشود از طریق درگاه data را بیرون کشید.
- حساسیت این دیتاها در چه حدی بوده؟
مثلا شما Order ID را درنظر بگیرید که اطلاعات فاکتور و سفارش ما را نگهداری میکند. در خیلی از سایتها، همراه این Order Id آدرس هم Match یا منطبق شده، شماره همراه هم Match شده و بسیاری دیتای دیگر هم Match شده. حالا مشکلی که هست این است که در اکثر سامانهها، وقتی که پاسخ از درگاه پرداخت برمیگردد، اکثرا نسبت به آسیب پذیری IDOR آسیبپذیرند. و با عوضکردن Order ID میتوانی سفارش بقیه را ببینی. من خودم در اکثر سایتها این آسیب پذیری را دیدهام، ولی خب معمولا خیلی از سمت کسبوکار بهش توجه نمیشود.
**- آره، متاسفانه ما هم شاهد این بودهایم که کسبوکارهایی چنین آسیب پذیریهایی دارند و بهشان گزارش هم شده، اما یک سال گذشته و همچنان آن آسیب پذیری را فیکس نکردهاند!
بگذریم. بیشترین بانتیت را از چه میدانی گرفتهای؟**
من بیشترین بانتیم را بابت یک گزارش از فلایتیو گرفتم؛ حدود ۲۰ میلیون تومن
فلایتیو در بین میدانها، سریعتر گزارشهاش رو بررسی و فیکس میکند.
- در طول مدتی که در حوزهی امنیت سایبری، هک و باگبانتی فعالیت کردهای، فرهنگ موجود در این حوزه را چطور دیدی؟ رفتار کسبوکارها، رفتار جامعه و مردم، رفتار نزدیکان و …؟ در مورد قوانینی که در این حوزه وجود داره، چه نظری داری؟
قطعا خلا قانونی زیادی وجود دارد. گاهی در سامانههای خیلی بزرگ، آسیب پذیریهایی میبینم. مثلا سورسکدی که در یکی از بانک ها درکنار API، برای استفادهی فروشگاه ها قرارداده بودند ، آسیب پذیر بود ولی خب منی که این آسیب پذیری را میبینم، نمیتوانم گزارش دهم و اعلام کنم. چرا؟ چون ممکن است برایم مشکل قانونی پیش بیاید.
البته الان اوضاع نسبت به قبل بهتر شده. ولی امثال این داستان خیلی اتفاق میافتد. اینکه شکارچیان آسیب پذیری از وجود باگهای جدی و مهمی در سامانههای بزرگ آگاه میشوند، ولی باگ را گزارش نمیکنند. چرا؟ به خاطر ترس از رفتار و واکنش طرف مقابل یا بهخاطر عدم درکش از باگ بانتی. گاهی وقتی به کسبوکار گزارش میدهی، ازت باجخواهی هم میکنند! میگویند که اگر آسیب پذیری را ندهی، ما ازت شکایت میکنیم. آن حمایت لازم از شکارچیهای آسیب پذیری قانونی فعلا وجود ندارد!
- آره، بقیهی شکارچیهایی که ما آنها گپوگفتهایی داشتهایم، هم به تجربیاتی مشابه تجربیات شما اشاره میکردند. در سایتها و سامانههای مهم و مختلفی مثل آموزشوپرورش، دانشگاهها و ... آسیب پذیریها و حفرههای امنیتی مهمی را کشف کرده بودند، اما بهدلیل ترس از رفتار نهاد یا سازمان روبهرو، مایل به گزارشدادن آسیب پذیری نبودند.
برخوردی که دارند، متناسب با ارزش کاری که داری میکنی، نیست. بانتی هم نمیدهند! بههرحال تو وقت گذاشتی و آسیب پذیری را پیدا کردهای! یک خاطره در این باره دارم؛ فکر کنم سال پیش بود که روی سامانهی استانی امتحان دانشگاه آزاد یک آسیب پذیری وجود داشت که وقتیکه سوالها چند ساعت قبل از امتحان بارگزاری میشدند، میشد در سایت به آنها دسترسی داشت و آنها را دید. من وجود این آسیب پذیری را گزارش دادم، Patch هم کردند، اما حتی یه تقدیر خشک و خالی هم نشد.
پیشنهاد خواندنی: قوانین و فرهنگ باگ بانتی در ایران
- بهطور کلی وضعیت امنیت سایبری و اهمیتی که کسبوکارها به آن اختصاص میدهند را چطور ارزیابی میکنی؟
احتمالا من نمیتوانم نظر جامعی در این باره بدهم، اما براساس مشاهدات و تجربهی خودم این طور فکر میکنم که وضعیت امنیت سایبری نسبت به گذشته در ایران بهتر شده و بیشتر جدی گرفته شده است.
- بهعنوان کسی که کارت هک کردن است، اگر بخواهی هک را از دیدگاه خودت تعریف و توصیف کنی، چه میگویی؟
به نظر من "هک" ، متفاوت نگاه کردن است؛ یعنی جوری که بقیه نگاه میکنند و میگذرند، به داستان نگاه نمیکنی، راه دیگری را میبینی.
- وقتی مسیرهای مختلف را رفتی، و ناگهان باگ را پیدا میکنی، چه حسو حالی داری؟ لحظهی کشف آسیب پذیری برایت چطوری است؟
حس خیلی خوبی ست. میدانید بعد از یک مدت، هیجان و اهمیت کشف آسیب پذیری و دریافت بانتی کمرنگتر میشود. و سناریویی که داری اجرا میکنی، از بانتی و باگ برایت جذابتر میشود. من به مرور در کارهایم متوجه میشوم که این سناریوها، راههای مختلف و ... هی دارند تکمیلتر میشوند... مثلا داری سناریوی قبلی را انجام میدهی و به جایی میرسی که قبلا انجامش ندادهای و باید سناریوی جدیدی را امتحان کنی. من گاهی برای تست یک آسیب پذیری، ۴۰،۳۰ تا سناریو را امتحان کردهام!
- یعنی چالش و مسیر جذابتر از آن لحظهی رسیدن به مقصد است؟
آره، دقیقا. گاهی من سناریویی را کشف و اجرا میکنم که روی سایت جواب نمیدهد. ولی همین که این سناریو به ذهنم رسیده، برایم خیلی لذتبخش است.
- کلا سناریو نوشتن هم خیلی لذتبخش است؛ خودت رو بهجای یه هکر کلاهسیاه میگذاری و باخودت میگویی:" با این سناریو چهکار میتوانم بکنم تا بیشترین ضربه را به این سازمان بزنم؟ ولی به جای ضربه زدن، گزارشش را بدهم و بانتی بگیرم." این مایندست از جنس حمله است که همهی هکرها دارند و نیاز هم هست که داشته باشند. چون گزارشهای شکار اینطوری ارزش بیشتری پیدا میکنند. مثلا الان یک XSS بهتنهایی را شکارچی میتواند گزارش دهد و ۵۰۰ دلار بانتی بگیرد. ولی یک XSS تبدیلشده به SSRF را میتواند گزارش کند و ۱۰ هزار دلار یا ۲۰ میلیون تومان بانتی بگیرد.
آره، خیلی فرق میکند.
- تا حالا روی درگاه پرداخت آسیب پذیری IDOR پیدا کردهای؟
آره.
- بیشتر در چه درخواستهایی این آسیب پذیری IDOR اتفاق میافتد؟
در درخواستهایی که از بانک برمیگردد. شما وارد بانک میشوی، پرداخت را انجام میدهی، وقتی برمیگردی بالاخره یک سری آیتم برمیگردد. در آنجا با تغییر Order ID میتوانی سفارش بقیه را ببینی. در یکی از اهداف هم یک IDOR بود. چطور بود؟ اینطور بود که شما وقتی سفارش را میخواستی بفرستی درگاه، RFID که همان توکن بانک مربوطش بود، بعدش شماره موبایل بود که از کارتهایی که داری استفاده کنی. آسیبپذیر بودن هدف نسبت به IDOR به این صورت بود که شما ID سفارش را عوض میکردی، وقتی ID سفارش را عوض میکردی، شمارهی انتهایی میرفت روی سفارشی که الان هست. حالا چیز خیلی خاصی نبود اما به این روش میتوانستی شمارهی کاربرها را به دست بیاوری. بیشتر به درد کسی میخورد که رقیب پلتفرم باشد، یا برای Data Mining و ...
- در بین همهی گزارشهایی که ثبت کردهای و سناریوهایی که نوشتهای، تا حالا شده که مثلا چندتا آسیبپذیری را با هم زنجیر (Chain) کنی تا به یک چیز دیگر برسی؟
آره، روی یکی از اهداف، همچین چیزی بود. خب یک Mass Assignment بود که User ID را اضافه میکردی، شمارهکارت را بهش میدادی، بعد پست که میکردی آن سمت User ID را ازت میگرفت و سیو میکرد. User ID در دادهای که ارسال میکردی، نبود ولی وقتی اضافه میکردی، برنامه آسیب پذیر بود و میگرفت. بعدش که میآمدی ا از طرف کاربر نسبت به IDOR آسیب پذیر بود، از طرف کاربر برداشت میزدی و یک آسیب پذیری دیگر هم کنارش بود.
- ما هم این گزارشت را به خاطر داریم. بابتش 5 تومان بانتی گرفتی. ما سر این گزارش ماجراهایی داشتیم با میدانش. چون در گزارش Brute Force استفاده شده بود، میدان نمیپذیرفت! درحالیکه IDOR از روی Brute Force پیدا شده بود.
آره، بعضی سازمانها و کسبوکارها دید امنیتی کمتری دارند. نه در مثالی که گفتی، ولی در کل، کاملبودن گزارشها خیلی به اینکه میدان منظور را دقیقتر متوجه شود، کمک میکند. ولی بعضی شرکتهای کوچک هم هستند، که خیلی حرفهای برخورد میکنند. من به کسبوکار کوچکی گزارش آسیب پذیری دادم، حتی چند ساعت هم طول نکشید که آسیب پذیریای که بهشان دادم را رفع کردند و بانتی هم پرداخت کردند. من لذت بردم از رفتار حرفهایشان. یا سایتی بود که وقتی من آسیب پذیری را بهشان اعلام کردم، همانجا رفعش کردند. با باگ بانتی آشنایی نداشتند، ولی وقتی برایشان توضیحی دادم، بانتی هم دادند.
- گاهی این نگاه موجود به امنیت سایبری در سامانهها، شکلگرفته از میزان نیاز و درخواست مردم کاربر در رابطه با امنیت است. گاهی برای کاربران و مردم، امنیت سایبری اهمیت چندانی ندارد. بارها دیدهایم که سامانهای هک شده و دیتای زیادی هم از کاربرانش نشت کرده، کسبوکار هم حتی بعدش دست به اقدام برای ارتقای امنیتش نزده! اما مردم باز هم بهراحتی، سراغ آن سامانه میروند.
آره، این به خاطر این است که کاربرها اطلاعات و آگاهی چندانی ندارند و نمیدانند که چه خطری تهدیدشان میکند و چه آسیبی بهشان میرسد! گاهی وقتی کسبوکار میداند که برای کاربرش امنیت چندان اهمیتی نداره، خب کسبوکار هم کنار میکشد...
یکی از تهدیداتی که کاربر را تهدید میکند این است که وقتی که کاربر عضو سایتی هست، وقتی که آن سایت هک میشود و اطلاعاتش نشت پیدا میکند، اطلاعات و پسورد کاربر هم لو میرود. اگر آن کاربر از یک پسورد واحد برای چندین جا استفاده کرده باشد، مثلا پسوردش در این سایت با پسورد حساب کاربریش در سایتهای دیگر، اینستاگرام، ایمیل و ...ش یکی باشد، فرد نفوذکننده با سوءاستفاده از اطلاعات نشتپیداکرده به راحتی میتواند به تکتک اکانتهای آن کاربر دسترسی پیدا کند. کسبوکار این مسئولیت را دارد که از این پسورد و اطلاعات کاربر مراقبت کند و امانتدارش باشد. وقتی دیتای آن کسبوکار هک میشود، فقط سایت خودش هک نشده... حسابها و اطلاعات کلیهی آن کاربرهایی که عضوش بودهاند، هم هک شده و کسبوکار نسبت به تمام آنها مسئول است. یکی از اقدامهای امنیتیای که کسبوکار برام محکمکاری قبل از هکشدن میتواند بکند، این است که پسورد کاربران را رمزنگاری، Hash و بعدش سیو کند. ولی خب بعضی سامانهها پسورد را رمزنگاری نمیکنند و مستقیم در دیتابیس سیو میکنند. اینطوری برای فرد نفوذکننده لقمهی آمادهتری را مهیا میکنند. اکثریت کاربران هم نمیدانند که بعد از هکشدن وبسایتی که عضوش بودهاند، اگر رمز حسابهای کاربری دیگرشان هم همان رمز است، باید سریع رمزهایشان را سریع عوض کنند.
پیشنهاد خواندنی: چکلیست مراقبت از گذرواژه؛ گاهی زود، دیر میشود...
البته یه نگاه و قوانین حداقلی نسبت به امنیت هست که خب اینها هم قطعا اثر گذارند. مثلا ظاهرا قانونی برای کسبوکارها وجود دارد که وقتی جایی هک میشود، پلیس فتا تعهد میگیرد که اگر اطلاعات شخصی کاربر از طریق سایت من نشت پیدا کرد، باید سریع اطلاعرسانی کنم و اگر آسیب مالی هم بخورد، به عهدهی کسبوکار من است. ما که فروشگاه اینترنتی داشتیم، رفتیم فتا و این تعهد را از ما گرفتند. ولی خب کاربر و فرد عادی چندان از حق و حقوقش آگاه نیست. همچنین آگاهی چندانی راجع به اینکه هک شدن سایتی که عضوش بوده، چه خطراتی برایش دارد، ندارد.
خیلی از کسبوکارها هنوز به آن بلوغ امنیتی نرسیدهاند. بعضی کسبوکارها امنیت سایبری را فهمیدهاند و وقتی گزارشی دریافت میکنند، آسیب پذیری را رفع میکنند و بانتی هم میدهند. ولی برخی کسبوکارها، وقتی گزارش آسیب پذیری را تحویلشان میدهی، پرداخت بانتی به کنار، حتی دوست ندارند که آسیب پذیری را روی سامانهی خود رفع کنند! میگویند:" سیستم دارد کار میکند دیگر، سیستمی که دارد کار میکند را دست نزنیم، بهتر است." خب اگر هم از سمت کاربرها و هم از سمت نهادها و مراجع قانونی، سختگیریهایی وجود داشته باشه برای سایتهایی که هک میشوند، طبیعتا بعدش سایتها موضوع امنیت سایبری را جدیتر میگیرند. چون خیلی از سامانههای ایرانی اطلاعات زیادی از کاربر میگیرند، اطلاعاتی که گاهی اصلا لزومی ندارد و لازم هم ندارند! و در قبال این اطلاعاتی که دریافت میکنند، هیچ مسئولیتی هم نمیپذیرند! متعهد نمیشوند که از این اطلاعات حفاظت و مراقبت کنند!
پیشنهاد خواندنی: چرا کسبوکارهای ایران امنیت اطلاعات را جدی نمیگیرند؟
- آره، نسبت به مسئولیتی که در قبال کاربر و اطلاعاتش دارند، خیلی مسئولیتپذیرانه رفتار نمیکنند...
دقیقا همینطور است! حتی بعضی از سایتهایی که بانتی میدهند، وقتی به ارزشگذاری باگهایشان نگاه میکنی، میبینی که بابت آسیب پذیری مربوط به درگاه پرداخت، ۱۰ میلیون تومن بانتی میدهند. ولی بابت آسیب پذیریای که اطلاعات مشتریهایش به خاطرش درخطر است، 1 میلیون تومان بانتی میدهند! خب این نشان میدهد که برای این کسبوکار اطلاعات کاربر در درجهی سوم و چهارم اهمیت قرار دارد! درست است که به منطق حریم خصوصی هم ربط دارد، بعضی سایتها اطلاعات زیادی از کاربر سیو نمیکنند. ولی خب من سامانهای را دیدهام که یکی از بزرگترین پلتفرمها هم بود. این سامانه بابت آسیبپذیریای که مربوط به فرآیند پرداخت بود، 5 میلیون تومان بانتی پرداخت کرد و و بابت آسیب پذیریای که بهوسیلهاش حجم زیادی از اطلاعات کاربر قابلدسترسی و سیو بوده،1میلیون.
پیشنهاد خواندنی: حریم خصوصی دادهها؛ سرمایهای حساس + گپی با یاشار شاهین زاده
- نمونهی جالبی مثال زدی.
آره، به نظرم از نمونهی این ارزشگذاریها میشود فهمید که یک کسبوکار، چقدر به دیتای کاربرش اهمیت میدهد و چقدر به خودش. البته ناگفته نماند که این نکته هم هست که در بعضی کسبوکارها، سامانهها اطلاعات کمتری از کاربر دارند و سیو میکنند، طبیعی است که در این سایتها در مقایسه با سایتهایی که اطلاعات بیشتری از کاربر دارند، مبلغ بانتی کمتری در ازای آسیبپذیریهای مشابه پرداخت شود. مثلا؛ نماوا از کاربرش فقط اسم و فامیل و یک شمارهتماس داره که میتواند فیک هم باشد. خب اطلاعات کاربر در اینجا درجهی حساسیت کمتری دارد! اما در سامانهای مثل تپسی، اطلاعات کاربر خیلی بیشتر اهمیت دارد. چونکه تپسی باتوجه به نوع کسبوکارش اطلاعات کاربر بیشتری را سیو میکند؛ کلیهی سفرهای مسافر و ... .
_ بله، و این این حق غیرقابلانکار هر کاربر است که از کسبوکاری که اطلاعاتش را دارد، انتظار فراهمآوری امنیت برای اطلاعاتش را داشته باشد.
ممنون که زمانت را در اختیار ما گذاشتی مهدی جان. امیدواریم که باگهای بیشتری شکار کنی و باعث امنتر شدن درگاههای پرداخت بیشتری برای کاربران و کسبوکارها شوی. ؛)
بلاگپستهای مرتبط:
گپوگفتی با شکارچی فعال راورو؛ سیدرضا فاطمی (Checkmate)
گپوگفتی با متخصص امنیت دنیای صفرویکها؛ علی امینی