روابط عمومی شرکت ایدکو (توزیع کننده محصولات کسپرسکی در ایران)؛ اخيراً متخصصين امنيت بلاك‌چينِ كسپرسکيِ ما وقتي داشتند اپ‌هاي وبي را مورد رسيدگي قرار مي‌دادند متوجه آسيب‌پذيري آن‌ها به حملات enumeration (شمارش) شدند. متخصصين ما در حقيقت دريافتند كه فرآيند ريكاوري رمزعبور اين پلت‌فرم از طريق شمارش نام كاربري به يك نوع حمله آسيب‌پذير است. توسعه‌دهندگان وبي مي‌بايست از اين نوع حمله و خطرات آن آگاه باشند. در ادامه تلاش داريم اين مشكل را شرح داده و روش مبارزه با اين حمله را خدمتتان ارائه دهيم. پس با ما همراه بمانيد.
حمله‌ي Enumeration چيست؟
اپ‌هاي وبي كه پسورد احراز لاگين دارند معمولاً شامل چندين مؤلفه مي‌شوند كه بدين‌واسطه با پايگاه اطلاعاتي كاربر در تعاملند: پنجره‌ي لاگين (به دلايل آشكاري)، فرم ثبت‌نام (براي جلوگيري از تكثير نام‌هاي كاربري) و صفحه ريست پسورد (براي تضمين اينكه اكانت مورد نظر وجود دارد). اگر توسعه‌دهندگان وبي به حد كافي اين ويژگي‌ها را در حاشيه‌ي امن خود پياده‌سازي نكنند، مهاجمين ممكن است بتوانند از آن‌ها براي تعيين اينكه نام كاربري خاصي در آن پايگاه اطلاعاتي وجود دارد يا نه استفاده كنند.
در گذشته، توسعه‌دهندگان بين‌شان رسم بود تمام آن ويژگي‌ها را بدون هيچ لايه‌ي محافظتي‌اي پياده‌سازي كنند و البته كه مهاجمين هم مي‌توانستند از فهرستي از نام‌هاي كاربري و برنامه‌اي كه آن‌ها را يكي پس از ديگري وارد مي‌كرد استفاده كنند. به مرور زمان، براي دور نگه داشتن هكرهاي احتمالي، توسعه‌دهندگان شروع كردند به بكارگيري ترفندهاي جلوگيرانه همچون کپچا، محدوديت‌هايي روي تعداد تلاش براي لاگين و استفاده از ستاره‌ها يا ساير ابزار براي پنهان كردن برخي اطلاعات خاص پاسخ.
در اپ‌هاي وبي مدرن، پنجره‌ي لاگين معمولاً از نوعي محافظت برخوردار است. با اين حال، فرم‌هاي ثبت‌نام و صفخات ريست رمزعبور برخي‌اوقات از اين محافظت محروم بودند. افزون بر اين، توسعه‌دهندگان وب هميشه هم حواسشان به اين موضوع نيست كه حضور يا عدم حضور يك كاربر در يك پايگاه اطلاعاتي مي‌تواند توسط زمان‌بنديِ پاسخ سرور تعيين شود. براي مثال، اگر نام كاربري در پايگاه اطلاعاتي ظاهر شود، پاسخ سرور 2 هزارم ثانيه طول مي‌كشد. اگر هم نه، اين پاسخ دو برابر به طور خواهد انجاميد (يعني 4 هزارم ثانيه). انسان‌ها نمي‌توانند فرق بين اين دو ميزان سرعت را متوجه شوند اما ابزارهاي خودكار شمارش خيلي راحت اين را مي‌فهمند.
خطرات حمله‌ي enumeration به نام كاربري
يك حمله‌ي enumeration به هكر اجازه مي‌دهد تا چك كند ببيند آيا نامي در پايگاه اطلاعاتي وجود دارد يا نه. اين اما به هكر اجازه نمي‌دهد تا بلافاصله بتواند لاگين كند؛ بلكه به او نيمي از اطلاعات لازم را ارائه مي‌دهد. براي مثال، به منظور راه‌اندازي حمله‌ي جست‌وجوي فراگير به جاي جست‌وجو از طريق جفت‌هاي لاگين و رمزعبور، همه‌ي آنچه نياز دارند رمزعبوري مطابق با نام‌كاربري تأييدشده است (هم انرژي كمي از آن‌ها گرفته شده و هم در وقتشان صرفه‌جويي مي‌شود). همچنين اين را هم به ياد داشته باشيد كه تقريباً هر سرويسي از آدرس‌هاي ايميل به عنوان نام‌هاي كاربري استفاده مي‌كند. بنابراين، متوسط كاربران براي بسياري وبسايت‌ها تنها يك لاگين دارند و همه‌ي سايت‌ها هم به طور مساوي بحث امنيت را جدي نمي‌گيرند. اخباري كه از تركيب لاگين و پسورد به بيرون درز مي‌كند بسيار مأيوس‌كننده است.
مجموعه داده‌‌هاي ادغام‌شده كه اين اخبارهاي درز كرده از آن خبر مي‌دهند روي صفحات پيغام هكرها موجود است. همچنين افراد بيشتر تمايل دارند براي وبسايت‌هاي مختلف از پسوردهاي يكسان استفاده كنند؛ بنابراين بعد از مطمئن شدن از اينكه يك نام كاربري روي وبسايت وجود دارد، مهاجم مي‌تواند روي مجموعه‌اي مشابه زده تا ببيند آيا پسوردهاي همان كاربر روي سايت‌هاي ديگر وجود دارد يا نه- و بعد شروع مي‌كند به امتحان كردن آن پسوردها.
علاوه بر اين، اپراتورهاي فيشينگ اغلب در طول فاز شناسايي از حملات شمارش استفاده مي‌كنند. آن‌ها وقتي مطمئن شدند كه هدف با سرويس شما اكانت دارد مي‌توانند ايميلي ارسال كنند كه ظاهراً از سمت شماست؛ ايميلي كه از كاربر تقاضا مي‌كند پسورد خود را تغيير داده و بعد هم لينكي به صفحه‌ي فيشينگ كه در ظاهر شبيه به وبسايت شماستخواهند داد. وقتي مشتري كه روحش هم از اين ماجرا خبر ندارد پسورد جديدي را وارد مي‌كند همچنين بايد پسورد قديمي را نيز تأييد كند و خوب بدين‌ترتيب هر چه اسكمر نياز داشت بدو داده مي‌شود.
چطور جلوي اين حمله را مي‌توان گرفت؟
تا به حال متوجه شديد وبسايت‌هاي مدرن چطور نسبت به ارسال فرم مجدد پسورد واكنش نشان مي‌دهند؟ آن‌ها نمي‌گويند «لينكي براي ريست كردن پسورد شما برايتان ارسال شده است» يا «ايميل تعيين‌شده در پايگاه اطلاعاتي ما وجود ندارد»- چيزي كه زماني وبسايت‌ها انجام مي‌دادند. در عوض، اينطور مي‌نويسند كه «اگر اين ايميل در پايگاه اطلاعاتي ما باشد، ما برايتان پيامي حاوي لينك ارسال خواهيم كرد». به بياني ديگر، وبسايت‌ها صراحتاً وجود نام كاربري را تأييد يا رد نمي‌كنند. آن‌ها به طور خاص براي محافظت در برابر حملات شمارش تغييرات را اعمال مي‌كنند.
در همين راستا، هيچ نيازي هم نيست كه در پنجره‌ي لاگين به تفصيل توضيح دهيد كاربر پسورد نادرست وارد كرده يا هيچ كاربري به اين نام در سيستم وجود ندارد. فقط كافيست بگوييد تركيب لاگين و رمزعبور پيدا نشده است. با اين وجود، امنيت مجازي هميشه راحتي مي‌آفريند و در مورد سرويس‌هاي احراز هويت اگر اين مسئله رعايت شود بيشتر مشكلات حل شده است. البته استفاده از كپچا و محدوديت‌هاي اقدام به لاگين هم واجب است. علاوه بر آن، براي تضمين امنيت اپ وبي خود توصيه ما اين است كه از مميزي طرف سوم كمك بگيريد. و اگر در حوزه فناوري بلاك‌چين فعاليت مي‌كنيد همكاران ما در بخش امنيت بلاك‌چين كسپرسكي مي‌توانند با تحليل امنيت اپ وبي به شما ياري رسانند.
