مع ظهور بطاقات الائتمان والإنترنت ، أصبح التسوق أسهل بكثير ، كما يقولون ، أكثر أمانًا. فقط بضع نقرات والمنتج الذي تحتاجه بالفعل في طريقك إلى منزلك. ومع ذلك ، ليست كل الأنظمة مثالية ، أو بالأحرى لا يوجد. يمكنك دائمًا العثور على نوع من الخطأ ، فجوة تسمح للمهاجمين بفعل أعمالهم القذرة. أود اليوم أن أوجه انتباهكم إلى دراسة مبرمج موهوب للغاية يوهانيس نوغروهو ، تحدث عن نقاط الضعف في نظام MIGS.
هذا النص عبارة عن ترجمة لكلمات الباحث عن الثغرات يوهانيس نوغروهو نفسه. استمتع بوقتك.
ضعف MIGS خوارزمية التجزئةفي العام الماضي ، اكتشفت خطأً في خوارزمية التجزئة المستندة إلى MD5 التي تستخدمها MIGS (خدمة بوابة الإنترنت Mastercard). سمح لك بإجراء تغييرات على حجم المعاملة. كافأتني الشركة على اكتشاف هذه المشكلة. في نفس العام ، تحولت MIGS إلى استخدام HMAC-SHA256 ، ولكن كانت هناك بعض نقاط الضعف.
ما هي MIGS؟عندما تدفع على موقع ويب ، عادة ما يربط أصحابه نظامهم ببوابة دفع وسيطة (هناك انتقال إلى صفحة أخرى). يتم بعد ذلك توصيل بوابة الدفع هذه بالعديد من أنظمة الدفع المتاحة في بلد معين. بالنسبة لبطاقات الائتمان ، تتصل العديد من البوابات ببوابات أخرى (أحدها MIGS) ، والتي تعمل مع العديد من البنوك لتوفير 3DSecure.
كيف يعمل؟عادةً ما يبدو تسلسل الدفع ، إذا كنت تستخدم MIGS:
- قمت بتحديد منتج على الموقع.
- أدخل رقم بطاقتك الائتمانية.
- يتم توقيع رقم البطاقة وحجم الدفع والمعلمات الأخرى وإعادتها إلى المتصفح ، مما يؤدي تلقائيًا إلى إنشاء طلب POST إلى بوابة الدفع المتوسطة.
- تقوم هذه البوابة بتحويل المعلومات إلى تنسيق مدعوم بواسطة MIGS ، وتوقع بمفتاح MIGS وتعيده إلى المتصفح. وبعد ذلك يقوم المتصفح بإنشاء طلب POST آخر لخادم MIGS نفسه.
- إذا لم يتم تمكين 3DSecure ، يتم تخطي هذه الخطوة. خلاف ذلك ، تقوم MIGS بتحويل الطلب إلى البنك الذي أصدر البطاقة. يطلب البنك OTP ويولد HTML ، الذي يولد طلب POST لخادم MIGS.
- تقوم MIGS بإرجاع البيانات الموقعة إلى المستعرض وإنشاء طلب POST لبوابة الدفع المتوسطة.
- المصادقة على البيانات والتوقيع بواسطة بوابة دفع وسيطة. إذا كانت البيانات غير صحيحة ، يتم إنشاء صفحة خطأ.
- بناءً على استجابة MIGS ، تنقل بوابة الدفع حالة الدفع إلى البائع.
الضعف في خوارزمية التجزئة MD5هذا الخطأ بسيط للغاية. تستخدم طريقة التجزئة الصيغة التالية:
MD5 (سري + بيانات)ولكن لا توجد قابلية للتوسع في التجزئة (تم إجراء بعض عمليات الفحص لمنع ذلك). يتم تشكيل البيانات بهذه الطريقة: يتم فرز جميع معلمات الطلب التي تبدأ بـ vpc_ ، وبعد ذلك يتم توصيل القيم دون فصل. على سبيل المثال ، لدينا البيانات التالية:
الاسم: جو
المبلغ: 10000
البطاقة: 1234567890123456
vpc_Name = Joe & Vpc_Amount = 10000 & vpc_Card = 1234567890123456
تطبيق الفرز:
vpc_Amount = 10000
vpc_Card = 1234567890123456
vpc_Name = جو
نحن نربط القيم:
100001234567890123456
لاحظ إذا قمت بتغيير المعلمات:
vpc_Name = Joe & Vpc_Amount = 1 & vpc_Card = 1234567890123456 & vpc_B = 0000
تطبيق الفرز:
vpc_Amount = 1
vpc_B = 0000
vpc_Card = 1234567890123456
vpc_Name = جو
نحن نربط القيم:
100001234567890123456
ستكون قيمة MD5 هي نفسها. هذا ، في الواقع ، عندما يتم نقل البيانات إلى MIGS ، يمكننا إضافة معلمة إضافية بعد حجم الدفع لإزالة الرقم الأخير ، أو قبله - لإزالة الرقم الأول. ويمكنك دفع 2 دولارًا بدلاً من 2000 لجهاز MacBook.
يمكن للبوابات المتوسطة والتجار تجنب هذه الثغرة عن طريق التحقق دائمًا مما إذا كان مبلغ الدفع الذي أعادته MIGS يطابق ما تم طلبه.
كافأتني MasterCard لتعريف هذا الخطأ بعلاوة قدرها 8500 دولار.
HMAC-SHA256 نقاط الضعف في التجزئةيحتوي HMAC-SHA256 الجديد على ثغرة يمكن استغلالها إذا أدخلنا قيمًا غير صحيحة في بوابة الدفع المتوسطة. لقد تحققت من هذا الخطأ في إحدى بوابات الدفع (Fusion Payments). لقد دفعوا لي 500 دولار مكافأة لهذا. قد تؤثر هذه الثغرة الأمنية أيضًا على بوابات الدفع الأخرى المتصلة بـ MIGS.
في الإصدار الجديد ، تمت إضافة محددات (&) بين الحقول وأسماء الحقول (وليس القيم فقط) ، وبالطبع ، HMAC-SHA256. بالنسبة للبيانات نفسها كما كان من قبل ، يبدو الخط المجزأ كما يلي:
Vpc_Amount = 10000 & vpc_Card = 1234567890123456 & vpc_Name = Joe
لا يمكننا تحريك أي شيء ؛ كل شيء في هذه الخطة منظم. ولكن ماذا لو احتوت القيمة على الأحرف & أو = أو غيرها؟
بعد قراءة المستند المرجعي لتكامل عميل الدفع الظاهري MiGS ، وجدت:
"ملاحظة: يجب ألا تحتوي القيمة في جميع أزواج الأسماء / القيم ، لغرض التجزئة ، على أحرف URL"أركز على
NOT . هذا يعني إذا كان لدينا الحقول التالية:
المبلغ = 100
البطاقة = 1234
CVV = 555
التجزئة ستكون كما يلي: HMAC (Amount = 100 & Card = 1234 & CVV = 555)
وإذا كانت الحقول مثل هذا (باستخدام & و =):
المبلغ = 100 والبطاقة = 1234
CVV = 555
يبدو هذا التجزئة كما يلي: HMAC (Amount = 100 & Card = 1234 & CVV = 555)
بنفس الطريقة. ولكن حتى الآن ، ليست هذه المشكلة.
بالطبع ، اعتقدت أنه قد تكون هناك مشكلة في الوثائق الرسمية ، ربما يجب استخدام أحرف URL. لكنني تحققت من سلوك خادم MIGS ، فكل شيء كان كما هو في المستند. ربما لا يريدون العمل بترميز مختلف (مثل + بدلاً من٪ 20).
يبدو أنه لا ينبغي أن تكون هناك أي مشاكل ، سيتم التحقق من القيم غير الصحيحة بواسطة MIGS وستظهر رسالة خطأ (على سبيل المثال ، سيتم رفض حجم الدفع الخاطئ).
لكنني لاحظت أنه في بعض بوابات الدفع ، بدلاً من التحقق من البيانات المدخلة على جانب الخادم ، فإنهم ببساطة يقومون بتوقيع كل شيء وإعادة توجيهه إلى MIGS. من الأسهل بكثير اختبار جافا سكريبت على جانب العميل ، وتوقيع البيانات على جانب الخادم ، ثم السماح لـ MIGS بتحديد ما إذا كان رقم البطاقة صحيحًا ، وما إذا كان يجب أن يتكون CVV من 3 أو 4 أرقام ، وما إذا كانت البطاقة تنتهي صلاحيتها بشكل صحيح ، وما إلى ذلك. المنطق هو: سوف تقوم MIGS بالتحقق مرة أخرى من البيانات وتحسينها.
في Fusion Payments ، اكتشفت أن هذا ما يحدث: فهي تسمح لك بإدخال أي طول من رمز CVV (يتم التحقق في JavaScript فقط) ، ثم قم بتوقيع الطلب وإرساله إلى MIGS.
استغلاللاستغلال هذه الثغرة الأمنية ، نحتاج إلى إنشاء سلسلة ستكون الطلب الصحيح والحصول على الاستجابة الصحيحة من خادم MIGS. لسنا بحاجة للتواصل مع خادم MIGS ، نحن فقط نجعل العميل يوقع على البيانات الصحيحة.
طلب أساسي:
vpc_AccessCode = 9E33F6D7 & vpc_Amount = 25 & vpc_Card = Visa & vpc_CardExp = 1717 & vpc_CardNum = 4599777788889999 & vpc_CardSecurityCode = 999 & vpc_OrderInfo = vdchecfurecurecurecurecure
وستكون الاستجابة الأساسية من الخادم كما يلي:
vpc_Message = موافق عليه & vpc_OrderInfo = ORDERINFO & vpc_ReceiptNo = 722819658213 & vpc_TransactionNo = 2000834062 & vpc_TxnResponseCode = 0 & vpc_SecureHash = THEHASH & vpc_Secure25Shecpe2525ecpe2525
في حالة Fusion Fusion ، يتم تنفيذ الاستغلال من خلال تنفيذ vpc_CardSecurityCode (CVV)
vpc_AccessCode = 9E33F6D7 وvpc_Amount = 25 & vpc_Card = فيزا وvpc_CardExp = 1717 & vpc_CardNum = 4599777788889999 & vpc_CardSecurityCode = 999٪ 26vpc_Message٪ 3DApproved٪ 26vpc_OrderInfo٪ 3DORDERINFO٪ 26vpc_ReceiptNo٪ 3D722819658213٪ 26vpc_TransactionNo٪ 3D2000834062٪ 26vpc_TxnResponseCode٪ 3D0٪ 26vpc_Z٪ 3DA وvpc_OrderInfo = ORDERINFO وvpc_SecureHash = THEHASH وvpc_SecureHashType = SHA256
تقوم بوابة العميل / الدفع بإنشاء التجزئة الصحيحة لهذا الخط.
يمكننا الآن إدخال هذه البيانات في العميل نفسه (بدون التفاعل مع خادم MIGS بأي شكل من الأشكال) ، ولكننا سنغيرها قليلاً حتى يتعرف العميل على المتغيرات الضرورية (يتحقق معظم العملاء فقط من vpc_TxnResponseCode و vpc_TransactionNo):
vpc_AccessCode = 9E33F6D7٪ 26vpc_Amount٪ 3D25٪ 26vpc_Card٪ 3DVisa٪ 26vpc_CardExp٪ 3D1717٪ 26vpc_CardNum٪ 3D4599777788889999٪ 26vpc_CardSecurityCode٪ 3D999 & vpc_Message = المعتمدة وvpc_OrderInfo = ORDERINFO وvpc_ReceiptNo = 722819658213 & vpc_TransactionNo = 2000834062 & vpc_TxnResponseCode = 0 & vpc_Z = مئوية 26vpc_OrderInfo٪ 3DORDERINFO وvpc_SecureHash = THEHASH وvpc_SecureHashType = SHA256
ملحوظة:
سوف يكون التجزئة نفس البيانات السابقة.
سيتجاهل العميل vpc_AccessCode وقيمته.
سيتعامل العميل مع vpc_TxnResponseCode ، وما إلى ذلك ، بافتراض أن المعاملة صحيحة.
يمكن القول أن هذا خطأ في عميل MIGS ، لكن طريقة التجزئة التي تستخدمها MasterCard تسمح بوجود هذا الخطأ. إذا تم ترميز القيم ، لن توجد هذه الثغرة الأمنية.
رد من MIGSلم تستجب MasterCard لهذا الخطأ في HMAC-SHA256. اتصلت بالعديد من الأشخاص الذين اتصلت بهم سابقًا بشأن ثغرة أمنية سابقة. لا توجد إجابة. حتى إلغاء الاشتراك بأسلوب "نختبره". لديهم الفيسبوك الخاص بي إذا كانوا يريدون الاتصال بي (منذ المراسلات حول MD5).
يتظاهر البعض على ما يبدو أنهم لم يروا تقريري ، لكنني وضعت كلمة مرور على الرسالة. كان هناك 3 طرق عرض على الأقل من عنوان IP الخاص بـ MasterCard. في الوقت نفسه ، هذه ليست نقرات عشوائية بدون قراءة ، لأنك تحتاج إلى إدخال كلمة المرور بوعي. أكتب إليهم كل أسبوع.
توقعت أنهم سيحذرون كل من يتصل بنظامهم للتحقق من البيانات المضمنة وتصفيتها.
ثغرات في بوابات الدفعبالإضافة إلى ذلك ، أود أن أقول: على الرغم من حقيقة أن بوابات الدفع تتعامل مع المال ، فهي ليست آمنة كما تبدو. خلال اختبارات البنت الخاصة بي (اختبارات الاختراق) ، اكتشفت العديد من نقاط الضعف في بروتوكولات الدفع في عدة بوابات وسيطة. للأسف ، لا يمكنني معرفة التفاصيل (إذا قلت "pentest" ، فهذا شيء يقع ضمن اتفاقية عدم الإفشاء).
لقد وجدت أيضًا أخطاء في التنفيذ. على سبيل المثال ، هجمات امتداد التجزئة ، XML ، أخطاء التحقق من التوقيع ، إلخ. أحد أسهل الأخطاء التي وجدتها في Fusion Payments. الخطأ الأول الذي وجدته هو أنهم لا يتحققون من التوقيعات من MIGS. وهذا يعني أنه يمكننا ببساطة تعديل البيانات التي أرجعتها MIGS ووضع علامة على المعاملة على أنها ناجحة. هذا يعني فقط تغيير حرف واحد: من F (غير ناجح) إلى 0 (ناجح).
هذا ، في الواقع ، يمكننا إدخال أي رقم بطاقة ، وتلقي رد غير صحيح من MIGS ، وتغييره ، وفجأة يصبح الدفع ناجحًا. هذه شركة بميزانية 20 مليون ، وتلقيت منها 400 دولارات. هذه ليست بوابة الدفع الوحيدة التي لديها مثل هذه الثغرة ، خلال فترة مكاني وجدت هذا في بوابات أخرى. على الرغم من المكافأة الصغيرة ، تعتبر Fusion Payments حاليًا بوابة الدفع الوحيدة التي اتصلت بها ، وهي واضحة جدًا في برنامج مكافآتها للأخطاء الموجودة. لقد استجابوا بسرعة لرسائلي وأصلحوا أخطاءهم بسرعة.
الخلاصةبوابات الدفع ليست آمنة كما تظن. مع هذه المكافآت المنخفضة (وفي بعض الحالات تلقيت 0 دولارًا أمريكيًا) ، أتساءل عن عدد الأشخاص الذين استغلوا بالفعل هذه الثغرات الأمنية في بوابات الدفع.
ملاحظة من المترجممن نفسي أريد أن أضيف بضع كلمات إلى استنتاجات مؤلف الدراسة. بادئ ذي بدء ، هذه الدراسة هي تحذير ودعوة إلى الحذر للبائعين ، لأن نقاط الضعف الموجودة تجعلهم ضحايا المتسللين. ولكن هناك العديد من الأخطاء الأخرى التي يمكن أن تكون ضارة للعملاء (حاملي البطاقات ، ومستخدمي أنظمة الدفع ، وما إلى ذلك). كن حذرًا عند إدخال معلومات الفواتير الشخصية الخاصة بك على موقع لم يتم التحقق منه. والأفضل من ذلك ، أن تكون تحت تصرفك بطاقة مصرفية منفصلة ، حيث سيكون هناك بالضبط المبلغ الذي تحتاجه لإجراء عملية شراء على الإنترنت.
هل واجهت أي أخطاء في أنظمة الدفع ، أو ربما كنت ضحية لمثل هذه الأخطاء؟ شارك تجاربك وآرائك ونصائحك حول كيفية حماية نفسك في التعليقات. أتمنى لك يومًا لطيفًا وتسوقًا آمنًا.
كإعلان. الترويج! احصل الآن على
ما يصل إلى 4 أشهر فقط من الاستخدام المجاني لـ VPS (KVM) مع محركات أقراص مخصصة في هولندا والولايات المتحدة الأمريكية (تكوينات من VPS (KVM) - E5-2650v4 (6 نوى) / 10 جيجابايت DDR4 / 240 جيجابايت SSD أو 4 تيرا بايت HDD / 1Gbps 10TB - 29 دولارًا - 29 دولارًا / شهرًا وما فوق ، تتوفر خيارات مع RAID1 و RAID10) ، وهو تناظري كامل من الخوادم المخصصة ، عند الطلب لمدة تتراوح من 1 إلى 12 شهرًا ، تتوفر
شروط الإجراء هنا ، ويمكن للمشتركين الحاليين الحصول على شهرين كمكافأة!
كيفية بناء البنية التحتية للمبنى. الطبقة باستخدام خوادم Dell R730xd E5-2650 v4 بتكلفة 9000 يورو مقابل سنت واحد؟