قد تبدو البطاقة البنكية المنتهية قطعة بلا قيمة: تاريخ صلاحيتها انتهى، البديل وصل إلى صاحبها، والمنطق يفترض أن أي محاولة لاستخدامها ستُرفض فوراً. لكن بحثاً أمنياً حديثاً أظهر أن هذا الافتراض لا يصمد دائماً أمام التفاصيل الدقيقة لبروتوكولات الدفع اللاتلامسي.

باحثون من جامعة Massachusetts Amherst استعرضوا هجوماً أطلقوا عليه اسم Zombie Card، يستطيع في ظروف محددة إعادة استخدام بطاقة Visa لاتلامسية منتهية الصلاحية في عمليات شراء فعلية داخل المتاجر، من دون كسر مفاتيح البطاقة أو تزوير التوقيع الرقمي أو اختراق خوارزميات التشفير.

المشكلة ليست في أن التشفير ضعيف، بل في أن معلومة حاسمة — تاريخ انتهاء البطاقة الذي يعتمد عليه جهاز الدفع — لا تكون دائماً مرتبطة تشفيرياً ببقية بيانات المعاملة.

TL;DR

هجوم Zombie Card يعتمد على اعتراض الاتصال عبر NFC بين البطاقة وجهاز POS وتعديل تاريخ الانتهاء الذي يراه الجهاز، مع ترك البيانات التي يتحقق منها البنك دون تغيير. في Visa Kernel 3، لا يدخل الحقل 5F24 الخاص بتاريخ انتهاء التطبيق ضمن البيانات المحمية بتوقيع fDDA، ما يسمح — وفق نتائج البحث — بتغيير التاريخ أثناء انتقاله دون إبطال التوقيع أو الـ cryptogram. نجاح العملية فعلياً يبقى معتمداً على سياسة البنك المصدر وطريقة تعامله مع البطاقة المنتهية والبطاقة البديلة.

#بطاقة منتهية… لكنها لا تزال تحمل هوية حساب فعّالة

جوهر الهجوم يبدأ من حقيقة عملية في دورة حياة البطاقات البنكية.

عندما تنتهي صلاحية البطاقة ويصدر البنك بطاقة بديلة، قد يبقى الحساب مرتبطاً بنفس رقم الحساب الأساسي:

PAN

وهذا يعني أن البطاقة القديمة قد تكون منتهية من ناحية تاريخ الصلاحية، لكن بعض مكونات هويتها المرتبطة بالحساب لا تزال ذات صلة بالبنية الخلفية لدى البنك.

لكي ينجح سيناريو Zombie Card كما عرضه الباحثون، يجب توافر عدة شروط في الوقت نفسه:

  • امتلاك البطاقة المنتهية فعلياً أو البقاء قريباً منها بما يكفي لاستمرار اتصال NFC.
  • وجود Relay من نوع Man-in-the-Middle (MitM) بين البطاقة وجهاز الدفع.
  • بقاء الحساب نفسه مفتوحاً تحت نفس PAN.
  • عدم قيام البنك المصدر بإعادة التحقق بصورة مستقلة من تاريخ الانتهاء أثناء عملية التفويض.

الهجوم، إذاً، ليس سيناريو سحرياً يجعل أي بطاقة منتهية قابلة للاستخدام. لكنه يكشف كيف يمكن لاختلاف صغير في طريقة التحقق من بيانات EMV أن يتحول إلى فجوة بين ما يثق به جهاز الدفع وما يثق به البنك.

#أين توجد المشكلة داخل معاملة Visa Contactless؟

المفارقة الأساسية أن تاريخ انتهاء البطاقة يظهر في أكثر من موضع داخل معاملة Visa Contactless، ولا تستخدم جميع الأطراف التمثيل نفسه.

جهاز الدفع يعتمد أثناء فحوصات المعالجة على:

Application Expiration Date

والمخزن داخل حقل:

TLV Tag 5F24

أما البنك المصدر فيستمد تاريخ الانتهاء من:

Track 2 Equivalent Data

الموجود في:

Tag 57

هذه الازدواجية ليست مشكلة بحد ذاتها. المشكلة تظهر عندما لا يكون الحقلان مرتبطين ببعضهما بصورة تجعل أي اختلاف بينهما مكشوفاً تشفيرياً.

وفقاً للبحث، فإن Visa Kernel 3 لا يفرض ربطاً متسقاً بين تمثيلي تاريخ الانتهاء، كما أن توقيع:

fast Dynamic Data Authentication (fDDA)

الذي يتحقق منه جهاز الدفع لا يتضمن الحقل:

5F24

وهنا تظهر نافذة الهجوم.

يمكن للـ Relay تعديل تاريخ الانتهاء الذي يراه جهاز POS إلى تاريخ مستقبلي، بينما يترك بيانات Track 2 كما هي.

النتيجة المهمة أن التعديل لا يحتاج إلى كسر التوقيع؛ لأن الحقل الذي تم تغييره لم يكن داخلاً أصلاً في البيانات التي يحميها التوقيع.

#كيف تسير عملية Zombie Card؟

يمكن تبسيط مسار الهجوم إلى سلسلة من الخطوات المترابطة:

  1. يقترب المهاجم من البطاقة المنتهية أو يمتلكها فعلياً.
  2. جهاز Relay يتواصل مع البطاقة عبر NFC.
  3. جهاز آخر يتصرف أمام جهاز الدفع كما لو كان البطاقة نفسها.
  4. رسائل APDU تنتقل بين الطرفين عبر قناة وسيطة.
  5. عند ظهور الحقل 5F24، يعدّل الوسيط تاريخ الانتهاء إلى قيمة مستقبلية.
  6. تظل بيانات Tag 57 وبقية البيانات التي تعتمد عليها عملية التحقق البنكية دون تعديل.
  7. جهاز الدفع يرى تاريخاً غير منتهٍ ويمرر المعاملة.
  8. ينتقل القرار النهائي إلى البنك المصدر.
  9. إذا لم يعِد البنك التحقق بصورة مستقلة من حالة البطاقة وتاريخها، فقد تتم الموافقة على المعاملة.

المهاجم لا يحتاج حتى إلى معرفة تاريخ انتهاء البطاقة البديلة الحقيقي.

أي تاريخ لاحق لتاريخ المعاملة كان كافياً في السيناريو الذي اختبره الباحثون.

#لماذا لا يكتشف التوقيع التعديل؟

قد يبدو من غير المنطقي أن تمر معاملة تم تعديلها إذا كانت البطاقة تستخدم آليات توقيع وتحقق تشفيرية.

لكن الهجوم لا يزوّر التوقيع.

بدلاً من ذلك، يستهدف بيانات لا يغطيها التوقيع المستخدم في نقطة التحقق المعنية.

في Visa Kernel 3، يذكر البحث أن توقيع fDDA الذي يتحقق منه الطرف النهائي لا يشمل 5F24. لذلك يمكن تعديل القيمة التي يعتمد عليها جهاز الدفع لإجراء فحص انتهاء الصلاحية، بينما تظل البيانات الموقعة سليمة.

كما أن صلاحية شهادات البطاقة وشهادة الـ Integrated Circuit Card لا ترتبط مباشرة بتاريخ انتهاء التطبيق المطبوع على البطاقة، وقد تستمر لفترة أطول منه.

حتى المفتاح الخاص للبطاقة نفسه لا يحمل مفهوماً مباشراً لتاريخ الانتهاء.

بمعنى آخر، انتهاء البطاقة من منظور دورة حياة المنتج لا يعني تلقائياً أن جميع عناصر الثقة التشفيرية داخل البطاقة أصبحت غير صالحة في اللحظة نفسها.

#نقطة عمياء أخرى: ماذا يرى البنك المصدر؟

وفقاً للورقة، فإن Kernel 3 يحدد قيم:

Terminal Verification Results (TVR)

المُرسلة إلى البنك المصدر على هيئة أصفار.

هذه النقطة مهمة لأنها تعني أن البنك قد لا يستطيع معرفة ما إذا كان جهاز الدفع قد نفّذ فحص انتهاء الصلاحية محلياً أو فشل فيه.

هنا يصبح القرار موزعاً بين أكثر من طبقة:

  • البطاقة تنتج بيانات وتواقيع صحيحة.
  • جهاز الدفع ينفذ فحوصاته على بيانات يمكن تعديل بعضها.
  • البنك يتخذ القرار النهائي بناءً على المعلومات التي تصل إليه.
  • بعض إشارات التحقق المحلية لا تنتقل إليه بصورة تسمح له بإعادة بناء ما حدث على الطرف الآخر.

ومن منظور تصميم الأنظمة، هذه ليست مشكلة تشفير فقط؛ بل مشكلة اتساق في الثقة بين مكونات متعددة.

#Visa مقابل Mastercard وAmerican Express وDiscover

اختبر الباحثون التعديل نفسه على أربعة تطبيقات مختلفة من EMV Contactless Kernels.

والنتيجة لم تكن موحدة.

الشبكة / Kernelنتيجة تعديل تاريخ الانتهاءالسبب التقني
Visa Kernel 3نجح التعديل في تجاوز قيود المعالجة لدى الجهازالحقل 5F24 ليس ضمن البيانات التي يغطيها التوقيع
Mastercard Kernel 2رُفضت المعاملةيتم إجراء فحص اتساق بين تمثيلي تاريخ الانتهاء أثناء READ RECORD
American Express Kernel 4رُفضت المعاملةتاريخ الانتهاء جزء إلزامي من البيانات المرتبطة بالمصادقة غير المتصلة، والتعديل يؤدي إلى hash mismatch
Discover Kernel 6رُفض التعديلآلية Combined Dynamic Data Authentication تربط كائنات TLV التي تعيدها البطاقة داخل Transaction Hash يتم التحقق منه

الفرق هنا مهم جداً.

الأنظمة الأربعة تعمل جميعها ضمن عالم الدفع اللاتلامسي، لكن الطريقة التي تربط بها بيانات المعاملة بالتوقيع أو بالـ transaction hash تغيّر بالكامل نتيجة الهجوم.

#كيف بُني Relay المستخدم في الاختبار؟

لم يستخدم الباحثون بنية مختبرية ضخمة أو أجهزة متخصصة معقدة.

الـ Relay اعتمد على هاتفين يعملان بنظام Android ويدعمان NFC:

  • هاتف يعمل كـ Card Emulator.
  • هاتف يعمل كـ POS Emulator.
  • الاتصال بين الهاتفين تم عبر Wi-Fi.

واختُبرت المنظومة ضد قارئات:

SumUp Solo

و:

SumUp Plus

كل دورة APDU أضافت زمناً تقريبياً يقدر بنحو:

20 ms

للـ Relay، وبنحو:

50 ms

عند إجراء التعديل.

ومتوسط زمن المعاملة وصل إلى قرابة:

415 ms

مقابل حد EMV البالغ:

500 ms

لكل أمر بحسب ما ورد في الدراسة.

هذه الأرقام توضح أن الاعتراض والتعديل لم يكونا بطيئين بالدرجة التي تجبر جهاز الدفع بالضرورة على إيقاف المعاملة.

#وماذا عن Relay Resistance Protocol؟

يتضمن معيار EMV آلية اختيارية تسمى:

Relay Resistance Protocol (RRP)

والهدف منها تقييد زمن الاستجابة المقبول، بما يساعد على اكتشاف التأخير الإضافي الناتج عن تمرير المعاملة عبر Relay بعيد أو وسيط.

لكن أياً من البطاقات أو أجهزة الدفع الفعلية الموجودة في بيئة الاختبار لم يكن يطبق RRP.

هذا لا يعني أن RRP يحل جميع مشكلات الهجوم، لكنه يوضح أن وجود آلية دفاعية في المواصفات لا يساوي بالضرورة تطبيقها فعلياً في الأجهزة الموجودة في السوق.

#ماذا حدث مع البنوك التي اختُبرت؟

الدراسة الأولية شملت خمس مؤسسات بنكية أمريكية كبرى، بينما نُفذت اختبارات البطاقات المنتهية والمستبدلة على ثلاث منها.

ولحماية هوية المؤسسات، أُشير إليها بالحروف.

#Bank A

سمح بتعديل تاريخ الانتهاء، وقَبِل معاملات من أكثر من بطاقة في الوقت نفسه.

نجحت البطاقة التي تمت "إعادتها للحياة" في تنفيذ معاملات بقيم:

$1.00

$100.00

$500.00

على جهاز الاختبار الخاص بالفريق، إضافة إلى عمليتي شراء فعليتين بقيمة:

$2.79

و:

$3.19

في متجر تجزئة ومتجر بقالة داخل الحرم الجامعي.

#Bank B

جهاز الدفع قَبِل تاريخ الانتهاء المعدل محلياً، لكن البنك المصدر رفض جميع معاملات المختبر، وطلب من حامل البطاقة استخدام البطاقة البديلة.

أما في الاختبارات الأساسية التي لم يُجر فيها أي تعديل، فقد تم رفض البطاقة المنتهية بصورة صحيحة في جميع الحالات.

#Bank D

استخدمت بطاقاته Discover Kernel 6.

الكيرنل اكتشف تعديل تاريخ الانتهاء، لكنه في الوقت نفسه سمح — وفق ما ورد في الدراسة — بوجود أكثر من بطاقة فعالة مرتبطة بالحساب نفسه في بعض الحالات.

#النتيجة الأهم ليست "أي بنك تم اختراقه"

الباحثون أنفسهم لفتوا إلى أن الاختلاف بين سياسات المؤسسات أهم من تصنيفها ببساطة إلى "آمنة" و"غير آمنة".

التجارب أظهرت ثلاث سياسات مختلفة للتعامل مع البطاقات المنتهية والبطاقات البديلة.

وهذا يعكس مشكلة أوسع: لا يوجد سلوك موحد عبر الصناعة في كيفية التعامل مع حالة البطاقة عند اقترابها من انتهاء الصلاحية أو بعد استبدالها.

حتى عندما يكون بروتوكول الدفع واحداً، تختلف طريقة تطبيق دورة حياة البطاقة بين الشبكة، والكيرنل، وجهاز الدفع، والبنك المصدر.

#حالة منفصلة: بطاقتان فعالتان للحساب نفسه

أثناء الاختبارات، عثر الباحثون على حالة لا تعتمد على تعديل تاريخ الانتهاء.

إحدى البطاقات لم تكن قد انتهت صلاحيتها بعد، لكن البنك استبدلها تلقائياً لأن المتبقي من عمرها كان أقل من ثلاثة أشهر.

خلال الفترة السابقة لانتهاء البطاقة القديمة فعلياً، استطاعت البطاقة القديمة والبطاقة البديلة إجراء معاملات على الحساب نفسه دون أي تعديل، وذلك على Kernel 6 الذي فشل فيه هجوم تعديل تاريخ الانتهاء نفسه.

هذه النتيجة تعزز الفكرة المركزية للدراسة: جزء كبير من المخاطر لا يأتي من خوارزمية واحدة، بل من طريقة إدارة حالة الاعتماد Credential Lifecycle عبر عدة أنظمة مستقلة.

#من زاوية GRC: أين تكمن المخاطرة الحقيقية؟

من منظور Governance, Risk, and Compliance (GRC)، القضية تتجاوز ثغرة في حقل داخل معاملة EMV.

المشكلة تكمن في توزيع المسؤولية.

البطاقة، وجهاز الدفع، والشبكة، والكيرنل، والبنك المصدر كلها تشارك في قرار واحد، لكن كل طرف يرى جزءاً مختلفاً من الصورة.

يمكن تلخيص مناطق الخطر في أربع نقاط:

المجالالإشكالية التي تكشفها الدراسة
Governanceاختلاف سياسات دورة حياة البطاقات بين البنوك وشبكات الدفع
Riskإمكانية بقاء بطاقة قديمة قابلة للاستخدام عندما لا تتطابق ضوابط الجهاز والبنك
Control Designالاعتماد على بيانات محلية لا تكون دائماً مرتبطة تشفيرياً أو مرئية للبنك
Assuranceنجاح التحقق التشفيري لا يعني بالضرورة أن جميع البيانات الحساسة في المعاملة لم يتم تعديلها

هذه النقطة الأخيرة شديدة الأهمية.

وجود توقيع صحيح لا يثبت أن كل معلومة في المعاملة محمية. ما يثبته التوقيع هو سلامة البيانات التي شملها بالفعل.

#التدابير المقترحة في الورقة

قدمت الدراسة مجموعة من الإجراءات موزعة بين الـ Kernels وأجهزة الدفع والبنوك المصدرة.

#1. ربط بيانات انتهاء الصلاحية تشفيرياً

يجب أن تدخل بيانات مثل:

Application Expiration Date

وحقول التحقق من حامل البطاقة ضمن آلية يمكن للبنك أو جهاز الدفع التحقق منها تشفيرياً، سواء من خلال signature أو offline authentication أو transaction hash معرف على مستوى الـ Kernel.

الهدف هو أن يؤدي أي تعديل أثناء انتقال البيانات إلى فشل واضح في التحقق.

#2. مقارنة تمثيلي تاريخ الانتهاء

عندما توجد أكثر من قيمة تمثل تاريخ الانتهاء، يجب ألا يتعامل النظام مع كل قيمة بمعزل عن الأخرى.

ينبغي مقارنة القيمة التي يعتمد عليها جهاز الدفع مع القيمة التي تُرسل إلى البنك، مع توفير إشارة يمكن للبنك رؤيتها عندما يحدث اختلاف.

#3. ربط التفويض بالـ PAN وتاريخ الانتهاء

تقترح الورقة أن يتعامل البنك المصدر مع الزوج:

PAN + Expiry

كجزء من هوية الاعتماد نفسه.

إذا لم يتطابق تاريخ الانتهاء المقدم مع البطاقة الحالية الصالحة لذلك الحساب، ينبغي رفض العملية.

#4. الحفاظ على إشارات التحقق الصادرة من جهاز الدفع

يجب ألا تضيع نتيجة فحوصات الطرف النهائي أثناء انتقال المعاملة إلى البنك.

تقترح الدراسة تمرير القيم الفعلية لـ:

Terminal Verification Results

أو توفير مؤشر مكافئ يمكن للبنك الاعتماد عليه لمعرفة نتيجة التحقق من انتهاء الصلاحية.

#ماذا عن المستخدم النهائي؟

التوجيه الوارد في الدراسة لحاملي البطاقات مباشر: لا تتخلص من البطاقة المنتهية وهي سليمة.

ينبغي إتلاف الشريحة والشريط المغناطيسي قبل التخلص منها.

كما تشير الورقة إلى أهمية الاستمرار في مراقبة الحساب حتى بعد إغلاقه.

السبب أن البطاقة القديمة ليست مجرد قطعة بلاستيكية تحمل تاريخاً قديماً؛ فقد تظل تحتوي على مفاتيح وبيانات وشهادات يمكن أن تبقى صالحة تقنياً لفترة تتجاوز تاريخ الانتهاء المطبوع.

#هل استُغلت Zombie Card فعلياً؟

حتى وقت نشر المادة، لم يُبلّغ عن استغلال هجوم Zombie Card في العالم الحقيقي.

كما لم يتم تخصيص:

CVE

للمشكلة.

عُرض العمل في الدورة الخامسة والثلاثين من:

USENIX Security Symposium

في بالتيمور خلال الفترة من 12 إلى 14 أغسطس 2026.

وكان الباحثون قد أبلغوا Visa والبنوك المتأثرة بالنتائج في مايو 2025، ثم أعادوا التواصل في ديسمبر 2025.

وحتى 20 أغسطس 2026، لم ترصد المادة إرشادات تخفيف أو نشرات مواصفات عامة مرتبطة بالمشكلة من Visa أو EMVCo أو Mastercard أو Discover أو American Express أو مزود أجهزة الدفع SumUp.

كما لم يُنشر تنفيذ الـ Relay أو كود الـ MitM المستخدم في الدراسة، واكتفى الباحثون بنشر سجلات معاملات منقحة.

#Zombie Card وWindRelay: الفكرة نفسها تظهر في سياق آخر

تزامنت نتائج البحث مع تقارير عن عائلة برمجيات خبيثة لنظام Android تحمل اسم:

WindRelay

استخدمت أيضاً مفهوم تمرير اتصالات NFC بين جهازين.

لكن الفرق أساسي.

WindRelay لا تعدّل تاريخ انتهاء البطاقة؛ بل تمرر بطاقة فعالة في الزمن الحقيقي.

أما Zombie Card فيستخدم Relay مشابهاً كوسيط، ثم يستغل قابلية تعديل حقل انتهاء الصلاحية في مسار محدد من معاملة Visa.

التشابه هنا في primitive الهجوم:

NFC Relay

وليس في الهدف أو الثغرة نفسها.

#الخلاصة

قصة Zombie Card لا تقول إن تشفير بطاقات Visa قد تم كسره.

الرسالة أكثر دقة — وربما أكثر أهمية.

يمكن لنظام أن يستخدم مفاتيح قوية وتواقيع سليمة وعمليات مصادقة ناجحة، ثم يبقى معرضاً للتلاعب إذا كانت هناك معلومة حساسة تقع خارج الحدود التي يحميها ذلك التشفير.

في هذه الحالة، كان تاريخ الانتهاء الذي يعتمد عليه جهاز الدفع قابلاً للتعديل في Visa Kernel 3 دون أن يؤدي ذلك إلى إبطال التوقيع الذي يتحقق منه الجهاز، بينما بقي نجاح المعاملة النهائية معتمداً على سياسة البنك المصدر وطريقة إدارته لحالة البطاقة القديمة والبديلة.

وهنا تكمن قيمة البحث: الثغرات في الأنظمة المالية لا تأتي دائماً من كسر الخوارزمية. أحياناً تظهر في المسافة الصغيرة بين ما يتم توقيعه، وما يتم التحقق منه، وما يفترض كل طرف أن الطرف الآخر قد تحقّق منه.