مرحبا! لقد قمنا مؤخرًا بدور نشط في The Standoff مع معالجة RBK.money - وهذا عندما يصنعون نموذجًا افتراضيًا لمدينة بأكملها بكل بنيتها التحتية ومحطات الطاقة والمتاجر والعناصر المهمة الأخرى. ثم سمحوا للفريق الأزرق (6 فرق هذا العام) والفريق الأحمر (29 فريقًا هذا العام ، على التوالي) بالانضمام إلى هذا التوأم الرقمي للمدينة ، الأول يحمي هذه البنية التحتية بأكملها ، والثاني يحاول بنشاط كسر شيء ما.
من فيلم "Blade Runner 2049"
بالطبع ، جلبنا معالجتنا إلى الحدث ، والتي يمكنك أن تقرأ عنها في التدوينات السابقة على مدونتنا. كانت المعالجة جزءًا من البنكوقدمت الخدمات المالية وخدمات الدفع لسكان المدينة الإلكترونية ، وخدمة إصدار بطاقات الدفع ، وجعلت من الممكن بيع السلع والخدمات.
في هذا المنشور ، أريد أن أخبرك كيف قام المتسللون بإفسادنا (تنبيه المفسد: ولم يفعلوا) ، وكذلك كيف أطلقنا أنفسنا على أنفسنا عدة مرات في عملية التحضير ونشر حلنا. ونعم ، الشيء الرئيسي هو أنه بالنسبة لنا كان موقفًا مربحًا للجميع: لن يكسرونا ، مما يعني أنه ليس عبثًا أننا واثقون جدًا في معالجتنا لدرجة أننا نضعها في مصدر مفتوح والآن نعطيها للمتسللين سوف يكسرونها - بشكل عام عظيم ، سنرى أين كانت نقاط الضعف ، وسنصبح أكثر حماية من حيث الأمن لعملائنا.
لقد تسللنا إلى المدينة الإلكترونية بسرعة ملموسة: هذه واحدة من أولى عمليات النشر التي قمنا بها في Kubernetes (قبل ذلك نشرنا كل شيء مع حالات Salt) ، وكان علينا استخدام أساليب تثبيت جديدة. ولم تكن عواقب هذا الاندفاع طويلة في الظهور.
نصائح للقراصنة
حتى قبل بدء المعالجة في مدينة إلكترونية ، تركنا عمدًا نقطتين ضعيفتين هناك.
الأول هو الثغرة الأمنية المرتبطة بأساليب ترميز البطاقة. كانت هذه الأساليب عرضة للثغرات الأمنية في شكل هجمات إعادة التشغيل ، أي أنه يمكن تحويل البطاقة إلى رمز مميز بنجاح في أحد المتاجر ، ثم يأتي هذا الرمز إلى متجر آخر ويعيد استخدامه هناك. كنا نأمل بخجل أن يتم اكتشاف الثغرة الأمنية ، ولكن للأسف.
والثاني هو محاسبة بسيطة للتاجر الرئيسي. أنشأنا تاجرًا واحدًا فقط لحكم القلة ، كان كيانًا قانونيًا يمتلك متاجر عبر الإنترنت في المدينة الإلكترونية. وكانت حقيبة النقود هذه تحتوي على بيانات اعتماد بسيطة إلى حد ما ، أي كلمة مرور مثل Parolec0 ، من حيث المبدأ ، يمكن أن تكون مصابة بكدمات . لكنها لم تقلع أيضًا.
لكن عضاداتنا ظهرت.
في عجلة من أمرك - لا يمكنك حماية كل شيء
سينتهي القارئ اليقظ من النقطة المتعلقة بالتاجر الرئيسي - انتظر دقيقة ، لديك أوليغارش واحد فقط يمتلك جميع المتاجر عبر الإنترنت ، يكفي اختراق أحد هذه المتاجر عبر الإنترنت ، ويمكنك الوصول إلى الباقي. حسنًا ، نعم ، لم يفكروا في هذه اللحظة في عجلة من أمرهم ..
وفي الواقع ، بعد اختراق هذا التاجر ، كان من الممكن الحصول على مفتاح API الخاص به لمعالجتنا وإدارة هذه المعالجة بالكامل. في الواقع ، هذا ما حدث - اخترق المهاجمون حلًا تابعًا لجهة خارجية ، ومتجرًا ترفيهيًا عبر الإنترنت في المدينة ، وحصلوا على مفتاح واجهة برمجة التطبيقات الخاص بتاجرنا من هناك ، وأتوا معه إلى معالجتنا وأطلقوا عليه الطريقة التي تتيح لك تشغيل / إيقاف متجرك عبر الإنترنت. ونظرًا لأن كيانًا قانونيًا واحدًا يمتلك جميع منافذ البيع بالتجزئة في جميع أنحاء المدينة ، فقد تم إيقاف تشغيلها جميعًا.
من حيث المبدأ ، هذا صحيح ، إذا كنت أوليغارشيًا جشعًا ضخمًا استولى على كل شيء لنفسه - يعاني. لقد توصلنا إلى استنتاجات وقررنا نزع ملكية كيس النقود على الفور من خلال إنشاء 5 كيانات قانونية مستقلة أخرى ، ولكل أزواج منفصلة من "كلمة مرور تسجيل الدخول" وأزواج مفتاح واجهة برمجة التطبيقات. أعتقد أنه في المسابقات التالية من هذا القبيل سنحاول جعل الوضع أقرب إلى الواقع في جزء الأعمال.
وأيضًا "طار" بسبب خصوصيات الكوبر.
في Kubernetes ، المستودع الرئيسي لحالة الكتلة هو ETCD ، وهو نظام موزع مفيد يمكنك بناء أشياء موثوقة للغاية عليه. لكنها حرجة للغاية من زمن انتقال محركات الأقراص الثابتة.
كما كتبت ، نشرنا المعالجة في بيئة مدينة إلكترونية افتراضية. كانت هناك هجمات نشطة للغاية على الأشياء المجاورة لنا ، وبمجرد أن تم نقل أحد هذه الكائنات "المزعجة" إلى مخزن البيانات الخاص بنا ، البنية التحتية لأحد المشاركين ، والتي تم كسرها لفترة طويلة وباستمرار. وعلى الرغم من أننا في الواقع لم نكن هدفًا في هذه الحالة ، وفي تلك اللحظة لم يكسر أحد المعالجة ، فقد استمرت في العمل بشكل طبيعي ، لكن المجموعة نفسها بدأت في التباطؤ بشكل كبير ، ولم تتمكن محركات الأقراص الثابتة ببساطة من التأقلم (تمكنوا من ملاحظة أن إخراج الأمر ls -l استغرق حوالي 19 ثواني). اتضح أن نوعًا من DoS ظهر ، وفي ليلة واحدة أرسلنا قططنا القياسية لجميع الطلبات.
بعد هذا الموقف ، نقلنا منظمو The Standoff إلى أقراص أخرى ، أي قاموا بإيقاف تشغيل جهاز افتراضي وتشغيل جهاز آخر في موقع مختلف. بعد ذلك ، اكتشف نظام إدارة قواعد البيانات الموزع لدينا بسعادة دماغًا منقسمًا ، واحتوت نصف العقد على معلومة واحدة ، ونصف - أخرى ، ولا يمكن أن تتفق حقًا مع نفسها. في المعركة ، بالطبع ، كنا سنشوش أكثر مع الهجرة ولن نسمح بذلك. وفي بيئة الاختبار ، كان من الأسهل بكثير تعطل كل ما هو متاح وإعادة تثبيته ، وهو ما فعلناه ، بالمناسبة ، قضينا ساعتين. لماذا أؤكد هذا - لأننا نشرنا سير عمل كامل مع جميع المكونات في ساعتين ، ويمكنك القيام بذلك من خلال معالجتنا في المعركة في شركتك. عادة ما يتم نشر المعالجة التقليدية في شركات مدتها 3 أشهر.
لذا ، حول الدماغ المنقسمة ، كل هذا اندفاع. لقد أزلنا / tmp على إحدى العقد الموجودة أسفل الجذر . من كان يعلم أن وحدة CSI LVM ، التي توزع وحدات التخزين المحلية من الأجهزة إلى البودات ، (!) تقوم بتركيب وحدة تخزين Kuber ثابتة في / tmp . وهكذا ، اتضح أننا بأيدينا هدمنا البيانات الموجودة تحت أقدام نظام إدارة قواعد البيانات (DBMS) الذي كان يدور عليه. علاوة على ذلك ، على الرغم من حقيقة أننا هدمنا التخزين لبعض العقد في المجموعات الأساسية ، استمر كل شيء في العمل من أجلنا حتى إعادة التشغيل الأولى للجهاز الافتراضي ، والذي حدث عندما بدأوا في نقلنا إلى جوانب جديدة.
الفريق الأزرق يوقف دفاعاته ببطء ...
في أحد الأيام ، قرر الفريق الأزرق إيقاف الحماية الخارجية (جدار الحماية ، إلخ). بمعنى ، حاول المتسللون في اليومين الأولين كسر الأنظمة مع تمكين هذا النوع من الحماية ، وبعد ذلك - بدون. كان لدينا أيضًا WAF تابعًا لجهة خارجية ، والذي تم تحميله وحماية حركة المرور الخاصة بنا في الدخول باستخدام njinks كوحدة نمطية.
ثم جاء اليوم ، ذهبنا لإيقاف تشغيل WAF وأدركنا أنه قد تم إيقاف تشغيله بالفعل. قبل يومين. نظرًا لأننا رائعون وفي عجلة من أمرنا (نعم ، نعم) ، قمنا بإعداد Ingress kubernetes ، والذي كان له مثيل WAF. وسيكون كل شيء على ما يرام ، لكن WAF ببساطة لم يصل إلى خادم التحكم ، ولم يتمكن من تنزيل ملف الترخيص منه ، وتجاهل كتفيه وببساطة توقف عن الخطيئة. واتضح أن كل هذين اليومين "قطعنا الحماية المشمولة" كنا جالسين ، في الواقع ، بدون هذه الحماية.
لكن ما زلنا لم نكسر.
تأكيد آخر للأطروحة القائلة بأن الإسراع ضار (إذا لم يكن لديك ما يكفي من الأفكار السابقة) - الموقف مع مكافحة الاحتيال لدينا. لقد وصفته في مشاركات المدونة السابقة ، هناك صندوق سحري به مجموعة من القواعد. Antifraud يحمي من خرق البطاقات المصرفية ، ومحاولات الدفع في وقت ما من مواقع مختلفة / IP / بريد إلكتروني ، وغيرها من الإجراءات غير الودية. أخبرنا فريق الدفاع أننا سنضع كل هذه القواعد بعناية لأنفسنا. وقد فعلنا ذلك - وضعنا بعناية جميع قواعد مكافحة الاحتيال. على خادم الإنتاج الخاص بنا RBK.money بدلاً من التثبيت لـ The Standoff. عناوين URL لواجهة المستخدم في شريط عنوان المتصفح مبتذلة. أي أن مضاد الاحتيال في هذا الوقت كان عبارة عن صندوق به فراغ غامض صامت. أصبح هذا أحد النواقل الناجحة للمحررين:
على سبيل المثال ، قاموا سابقًا باختراق بنك إنترنت تابع لجهة خارجية عن طريق سرقة رمز PAN الخاص بالبطاقة (الأرقام نفسها ، رقم الحساب الأساسي) ، واسم حامل البطاقة واختيار تاريخ الصلاحية. بعد ذلك ، أثناء معالجتنا على PAN هذا ، بدأوا في فرز CVVs. وسيكون كل شيء على ما يرام ، بعد 3 محاولات لخرق البطاقات ، سيتم حظرها بواسطة مكافحة الاحتيال لدينا. فقط إذا ... انظر أعلاه.
بشكل عام ، كان هناك العديد من هذه القصص المضحكة. في مرحلة ما ، توقفت خدماتنا عن حلها وتوقفت مزامنة الوقت على العقد ، وبشكل عشوائي إلى حد ما ، من بعض المضيفين.
بالطبع ، كان أول شيء فعلوه هو إلقاء اللوم على الخطأ في التكوين ، والعمل غير المفهوم للمجموعة.
مع DNS ، تم حل المشكلة بسرعة عن طريق نقل وحدات CoreDNS مباشرة إلى العقد حيث لم يتم إطلاق حركة المرور هذه ، ولكن مع NTP كنا محظوظين - لحسن الحظ ، لم نلاحظ انحرافًا كبيرًا على مدار الساعة ، وعند إنشاء مجموعة ، لا تزال العقد قادرة على المزامنة.
اتضح أنه في مرحلة ما على مستوى جدار الحماية ، تم تعطيل طلبات NTP و DNS الصادرة لبعض العقد. على ما يبدو ، قام أحدهم بشد صواميل الترشيح كثيرًا.
هجمات أخرى
كما نجحت الهجمات على أهداف أخرى قريبة من المدن السيبرانية في بعض الأحيان ، بما في ذلك الهجمات المماثلة لنا في النظام المالي للمدينة الإلكترونية.
من الجيد أننا لم نخلط بين عناوين url للتنبيه أعلى الشريط المطاطي وفي المراقبة ، ورأيناها بدقة تامة وبسرعة كافية.
على سبيل المثال ، كما في حالة قرصنة الأوليغارشية ومفتاح واجهة برمجة التطبيقات الذي تم سحبه. تم اختراقه الساعة 22.17 بتوقيت موسكو. في 22.22 لاحظنا ذلك من جانبنا وأبلغنا المدافعين والمنظمين به على الفور. بالمناسبة ، لاحظنا ، بفضل الاستخدام الملتوي لواجهة برمجة التطبيقات (API) - مر المتسللون برأس نوع محتوى غريب في الطلب الأول ، يُطلق عليه طريقة نادرة لواجهة برمجة التطبيقات الخاصة بنا ، وبعض الفروق الدقيقة الأخرى - كان هذا هو سبب تشغيل التنبيه.
عندما يعمل النظام بشكل طبيعي وتلقائي ، نادرًا ما يتزامن كل ذلك في نفس الوقت. ولكن إذا حدث شيء من هذا القبيل ، فهذا يعني أن شخصًا ما يلعب مع API بأيديهم. ها هو التنبيه وقد نجح.
إذا كنا لا نتحدث عن مدينة إلكترونية ، بل عن مواقف حقيقية من هذا النوع ، فكل شيء يحدث بشكل أسرع ، وفي مثل هذه الحالات يقوم النظام تلقائيًا بحظر تصرفات التاجر حتى لا يتم سحب أي شيء من حسابه ، ومن حيث المبدأ ، لا يضر العمل والأعمال بأي شكل من الأشكال ، ويثير الذعر و يربط الموظفين الأحياء بالفعل
للمستقبل
إن تنسيق القرصنة الإلكترونية للمدن ، ليس مزحة ، هو مستقبل أمن المعلومات. بالتأكيد سوف نأتي إلى هنا مرة أخرى ، ونأخذ في الاعتبار جميع الأخطاء ونفكر في البنية التحتية ومخططات الأعمال بحيث تكون أقرب إلى الواقع قدر الإمكان. من الناحية المثالية ، أريد عمومًا أن يتوصل الأشخاص من البنك المركزي أو خدمات الدولة إلى نفس الاستنتاجات - لاختبار بنيتهم التحتية في المعركة ، وتوفير فرصة لاكتشاف نقاط الضعف ، وحتى يصبحوا أفضل وأكثر موثوقية للمستخدمين والشركات.
وكان في الواقع رائعًا وممتعًا جدًا. في الواقع ، تلقينا مجموعة كبيرة من حالات Chaos Monkey - التي لن يتم إعادة إنتاجها بالضرورة في الإنتاج ، لقد اختبرنا معالجة الهجمات ، بعد أن تلقينا عددًا أكبر من الهجمات في يومين مما نتلقاه بانتظام في ستة أشهر.
لقد تعلمنا الكثير ، والأهم من ذلك ، رأينا أن منتجنا ، الذي نكتبه لأنفسنا ولكم ، يحظى بشعبية بين المشاركين في المدينة الإلكترونية ، لأن تكنولوجيا المعلومات لدينا كانت حافزًا قويًا - بعد كل شيء ، من الجيد أن يستخدم الأشخاص نتيجة عملك ، حتى لو كان في هذا ولأغراض محددة للغاية.
لقد أحببنا ذلك حقًا ونريد المزيد.
في المواجهة التالية ، انتظر منا مخططات أكثر إثارة للاهتمام ، والمزيد من وظائف الدفع وناقلات الهجوم الجديدة!