اختُطف DNS لموقع Flap الرسمي: التفويض الاحتيالي أخطر من اختراق الخادم
تكمن خطورة التلاعب بترجمة النطاقات في أن المستخدم يرى النطاق الرسمي الحقيقي، لكن الصفحة التي تُفتح أمامه هي صفحة تصيّد أنشأها مخترقون.
في 31 أكتوبر، أصدر فريق Flap تحذيرًا أمنيًا أعلن فيه عن تعرض موقعه الرسمي flap.sh لاختطاف DNS. تلاعب المهاجمون بترجمة النطاق، ووجّهوا حركة المرور إلى عنوان IP 31.56.52.52، واستخدموا شهادة TLS صادرة حديثًا لانتحال الموقع، وحثّوا المستخدمين على ربط محافظهم والتوقيع، في محاولة لسرقة BNB. وأكد الفريق أن الخطر يقتصر على المستخدمين الذين زاروا الموقع ومنحوا التفويض خلال عشرات الدقائق السابقة للإعلان؛ أما من زاروه قبل ذلك، والمفاتيح الخاصة التي تحتفظ بها المنصة، فلم يتأثروا.
من الناحية التقنية، لم يُخترق الخادم مباشرة هذه المرة، بل جرى تحويل مسار الدخول إليه. لم يحصل المخترقون على المفاتيح الخاصة للمنصة؛ وتمحور الهجوم حول إقناع المستخدمين بمنح «تفويض للمحفظة» بأنفسهم على صفحة مزيفة، ما أتاح نقل الأصول. وهذا مثال نموذجي على «مخاطر الواجهة الأمامية» في Web3: لم تنهَر البنية التحتية، لكن واجهة التفاعل انتحلت بدقة.
بموضوعية، سارع فريق Flap إلى احتواء نطاق التأثير، وكان توصيفه للحادث واضحًا. لكن بالنسبة إلى مستخدمي البلوك تشين، فهذا تذكير آخر بأن التحقق من النطاق وإدارة التفويضات عند التفاعل لا يزالان من أضعف الحلقات. فإذا منحت تفويضًا على صفحة مزيفة، فستحتاج لاحقًا إلى بذل جهد إضافي لفحص الأصول وإلغاء التفويض.
عندما تتفاعل مع مشاريع البلوك تشين، هل تتحقق دائمًا من عنوان IP الذي يُترجم إليه النطاق أو من حالة الشهادة، أم تعتمد على تنبيهات إضافات الأمان؟
#Flap #Web3安全 #bnb
هذا عرض موضوعي للمعلومات المتاحة للعامة ولآلية الحادث، ولا يشكل نصيحة استثمارية. #
تكمن خطورة التلاعب بترجمة النطاقات في أن المستخدم يرى النطاق الرسمي الحقيقي، لكن الصفحة التي تُفتح أمامه هي صفحة تصيّد أنشأها مخترقون.
في 31 أكتوبر، أصدر فريق Flap تحذيرًا أمنيًا أعلن فيه عن تعرض موقعه الرسمي flap.sh لاختطاف DNS. تلاعب المهاجمون بترجمة النطاق، ووجّهوا حركة المرور إلى عنوان IP 31.56.52.52، واستخدموا شهادة TLS صادرة حديثًا لانتحال الموقع، وحثّوا المستخدمين على ربط محافظهم والتوقيع، في محاولة لسرقة BNB. وأكد الفريق أن الخطر يقتصر على المستخدمين الذين زاروا الموقع ومنحوا التفويض خلال عشرات الدقائق السابقة للإعلان؛ أما من زاروه قبل ذلك، والمفاتيح الخاصة التي تحتفظ بها المنصة، فلم يتأثروا.
من الناحية التقنية، لم يُخترق الخادم مباشرة هذه المرة، بل جرى تحويل مسار الدخول إليه. لم يحصل المخترقون على المفاتيح الخاصة للمنصة؛ وتمحور الهجوم حول إقناع المستخدمين بمنح «تفويض للمحفظة» بأنفسهم على صفحة مزيفة، ما أتاح نقل الأصول. وهذا مثال نموذجي على «مخاطر الواجهة الأمامية» في Web3: لم تنهَر البنية التحتية، لكن واجهة التفاعل انتحلت بدقة.
بموضوعية، سارع فريق Flap إلى احتواء نطاق التأثير، وكان توصيفه للحادث واضحًا. لكن بالنسبة إلى مستخدمي البلوك تشين، فهذا تذكير آخر بأن التحقق من النطاق وإدارة التفويضات عند التفاعل لا يزالان من أضعف الحلقات. فإذا منحت تفويضًا على صفحة مزيفة، فستحتاج لاحقًا إلى بذل جهد إضافي لفحص الأصول وإلغاء التفويض.
عندما تتفاعل مع مشاريع البلوك تشين، هل تتحقق دائمًا من عنوان IP الذي يُترجم إليه النطاق أو من حالة الشهادة، أم تعتمد على تنبيهات إضافات الأمان؟
#Flap #Web3安全 #bnb
هذا عرض موضوعي للمعلومات المتاحة للعامة ولآلية الحادث، ولا يشكل نصيحة استثمارية. #