أصبحَت معظم وسائل تواصلنا اليومية رقمية. في أغلب الأحيان، ولحسن الحظ، تُدرِك الشركات أهمية السرية وتحاول أن تحمي بياناتنا. سأتحدث في هذه المقالة عن كيف أن هذا ليس الحال دائمًا، بالتركيز على دراسة حالة واقعية حدثت لي في بولندا.
رسائل البريد الإلكتروني وسهولة استخدامها
يُعَدّ التواصل أحد أهم جوانب حياتنا اليومية. نظلّ على تواصل في المنزل وفي العمل، وحتى أثناء تنقُّلنا بينهما، كما جرت العادة. الفرق الوحيد هو أنَّنا اليوم، على عكس ما كان عليه الأمر قبل بضعة عقود، قد نقلْنا جزءًا كبيرًا من هذا التواصل إلى الفضاء الرقمي. لا نتحدث مع الأصدقاء والعائلة عبر مختلف التطبيقات فقط، بل غالبًا ما نتبادل الرسائل مع صاحب العمل أو الزملاء أو حتى الأطباء. وعندما نُرسِل معلومات حساسة عبر الإنترنت، علينا أن نتأكَّد أنَّها محميَّة.
البريد الإلكتروني وسيلة سهلة وشائعة لتبادل الرسائل. في الواقع، يتكل الإنترنت عمومًا على البريد الإلكتروني لإنشاء الحسابات، وشراء التذاكر، والاشتراك في النشرات الإخبارية، وغيرها. وبالنظر إلى أنّ هذه الوسيلة متاحة ويستخدمُها الجميع، فمن المفترض أن تكون آمنة أيضًا، أليس كذلك؟
ليس بالضرورة، فالبروتوكول الذي بُنِي عليه البريد الإلكتروني لم يُصمَّم آخذًا الأمن في الحسبان في بدايات الإنترنت، حين لم يكن بوسع أحد أن يتخيَّل كم سيتضخَّم في المستقبل. كان الهدف من هذه البروتوكولات أن تكون سهلة الاستخدام وأن تُمكِّن تبادل المعلومات بين أنظمة مختلفة، بافتراض أنّ بيئة الشبكة موثوقة. وبعدما تطوَّر الإنترنت، ظهرت الحاجة لإدخال تدابير أمنية، ممّا فَرَض تعديل تلك البروتوكولات. وعلى مرّ السنين، بُذِلَت جهود كبيرة من أجل زيادة الأمان. أحيانًا عبر تغييرات جذريّة، وأحيانًا بتعديلات تراكمية تُعزِّز الأمان دون إعادة بناء البروتوكول بالكامل.
أمّا الآن، تُرسَل الرسائل بصورة آمنة بين مزوِّد بريدك الإلكتروني ومزوِّد بريد المُستَلِم. ولا يمكن للأجهزة أو الموجِّهات (Routers) بينك والمُستلِم أن تقرأ محتوى الرسالة وهذا ما تضمنه القناة الآمنة التي أنشأها المزوِّدان. لكن، هل يستطيع مزوِّد الخدمة أن يقرأ الرسالة؟ فعليًّا، يمكنه أن يقرأ كل رسالة أرسَلْتها أو استلمْتَها، حتى لو كان ذاك مكروهًا في الحالات التي تطلَّب سريّة عالية.
مقدِّمة موجَزة عن التشفير
أحد الجوانب الأساسية الذي أود توضيحه هو سرية المحادثات بين الأفراد، سواء في السياقات المغلقة أو المهنية. ففي الحالة الأولى، من السهل أن تتَّفق مع صديقك أو زميلك على استخدام تطبيق أو وسيلة أكثر أمانًا، أمّا في السياقات المهنية، فالأمر ليس دومًا بهذه السهولة.
ذلك يشمل حالات مثل التواصل مع محامٍ أو طبيب، أو استلام مستندات مالية من البنك. رغم أن العديد من الشركات تستخدم تطبيقات رسائل فورية مشفَّرة تشفيرًا بين الأطراف (End-to-End)، ما يزال هناك اعتماد على قنوات أخرى مثل البريد الإلكتروني، لا سيما عند التعامل مع جهات خارجية مثل العملاء. إلّا أنّ هناك فرق هام بين تطبيقات المراسلة الفوريّة المشفّرة والبريد الإلكتروني.
فيما يخصّ البريد الإلكتروني، يمكن لمزوِّدك ومزوِّد الطرف الآخر أن يقرأ محتوى الرسائل، بما فيها الملفات المرفقة الخاصّة. أمّا في التطبيقات المشفَّرة تشفيرًا بين الأطراف مثل «سيجنال»، فلا يمكن لأي أحد أن يرى ما يُرسَل ويُستقبَل إلّا المشاركين في المحادثة. وإن كان بمقدور المزوِّد أن يصل إلى بعض البيانات الوصفية (Metadata)، مثل توقيت اتصالك الأخير أو هوية المتَّصلين بك ومدة المكالمات، فإنه لا يستطيع قراءة محتوى الرسائل نفسها.
كيف يُشفَّر البريد الإلكتروني؟
هناك طرق تشفير مثل (PGP/GPG) تسمح للمُستخدِم بأن يرسل البريد الإلكتروني مشفَّرا تشفيرًا بين الأطراف، لكن يتوجَّب على المرسل والمستلِم إعدادها يدويًا، وهذا الأمر يحتاج إلى جهد يدوي وتقني متقدم نوعًا ما، مما يجعله غير عمليّ لمعظم المستخدمين ما لم يتكفل مزود البريد به. لكن هذا ليس شائعًا بين المزودين، إذ إنّ معظم استخدامات الإنترنت تعتمد على البريد الإلكتروني الذي لا يدعم التشفير بين الأطراف. قد يختار بعض الأفراد المهتمين بالخصوصية مزوِّدًا قائمًا بالأساس على مبدأ التشفير. لكن هذا لا ينطبق إلّا على قلّة من المزوِّدين ويعمل فقط إذا استخدم الطرفان نفس المزوِّد أو قد أعدّا التشفير يدويًا.
ومع أنّ البريد نفسه غالبًا غير مشفَّر، يمكنك أن تشفِّر المرفقات بسهولة! لا يعتمد هذا على آلية تشفير البريد، كونه يحصل على مستوى الملف ذاته. على سبيل المثال، تدعم ملفات PDF التشفير، ومن السهل تعيين كلمة مرور لحماية محتواها قبل إرسال الملف. أو يمكن استخدام أرشيفات مثل Zip-7 أو Zip لتشفير وحماية الملفات النصيّة والصور ومقاطع الفيديو وغيرها من أنواع الملفات.
من المهم في هذه الحالات أن نتذكَّر أنّ الحماية الفعلية للملف تعتمد على كلمة المرور في نهاية المطاف، بدلًا من الخوارزمية. وقد سمعت بلا شكّ عن أهمية كلمات المرور وكيفية اختيارها. إليك بعض النقاط المهمة باختصار:
يفضَّل استخدام عبارات مرور بدلًا من كلمات مرور، لأنها تجمع بين الأمان وسهولة الحفظ.
ينبغي أن تتكوَّن عبارات المرور أو كلمات المرور من عدد معقول من الكلمات (٥ إلى ٦ كلمات على الأقل)، أو من عدد كافٍ من المحارف (١٤ إلى ١٦ محرف فأكثر)، ويُفضَّل أن تحتوي أيضًا على أرقام و/أو رموز مميَّزة.
يجب أن تُولَّد عبارات المرور عشوائيًا وألّا تكون سهلة التخمين – بإمكانك أن تَستعمِل تطبيقات إدارة كلمات المرور التي تُولِّد مثل هذه العبارات وتحفظها بأمان.
تبادل كلمات المرور
مؤخرًا، استلمْتُ ملف PDF يحتوي على معلومات بالغة الحساسية عبر البريد الإلكتروني. من الجيد أنّ المُرسِل أدرَك حساسية المحتوى، وبادر إلى تأمينه بكلمة مرور. كنا قد التقينا سابقًا في لقاء واقعي، ورغم أننا لم نناقش كلمات المرور، فقد كان بإمكانه إيصال المعلومة لي بأمان دون الحاجة إلى الإنترنت.
لكن ماذا لو كانت الخدمة إلكترونية بالكامل كخدمة حكومية مثلًا، حيث ينحصر التواصل على الإنترنت؟ هل يمكن أن نتبادل الملف وكلمة المرور معًا بأمان؟
في هذه الحالات، غالبًا ما يُرسَل الملف عبر قناة ما، وكلمة المرور عبر قناة أخرى. بما أنّ العديد من الخدمات تطلب بريدك ورقم هاتفك، فبإمكانك أن ترفق الملف بالبريد وكلمة المرور داخل رسالة نصية. ومع أن الرسائل النصيّة القصيرة (SMS) غير آمنة بطبيعتها١، لكن على المهاجم أن يعترض كلًّا من البريد والهاتف، أو أن يحصل على صلاحية الدخول إليهما، ليتمكن من قراءة الملف المرفق.
دراسة حالة: رقم الضمان البولندي (PESEL)
إذًا، ماذا حدث مع الملف المشفَّر الذي استلمتُه عبر البريد الإلكتروني؟ لقد كان محميًا بكلمة مرور مكوَّنة من ١١ عدد، كانت تلك الكلمة رقم PESEL البولندي. كلمة PESEL هي اختصار (Powszechny Elektroniczny System Ewidencji Ludności) وترجمتها التقريبية هي: «نظام التسجيل المدني الإلكتروني الشامل». وهو ما يشبه رقم الضمان الاجتماعي، أي أنّه مُعرِّف خاص يجب أن يبقى سريًّا. لم أكن على علم بكلمة المرور قبل أن أستلم البريد، كما أشرتُ سابقًا، ما جعلني أتساءل إلى أي درجة يُعَدّ رقم الضمان البولندي آمنًا عندما يُستخدَم كمفتاح لحماية الملفات؟ ففي النهاية، هو مُعرِّف خاص وحسّاس، أليس كذلك؟
لكن بما أنّه مُكوَّن من كل الأرقام (أي الأعداد من ٠ إلى ٩) وطوله ١١ خانة، فإن عدد التوليفات المُمكنة التي يجب على المهاجم أن يُجرِّبها حتى يكتشف كلمة المرور هو:
١٠^١١ = ١٠٠,٠٠٠,٠٠٠,٠٠٠ (١٠٠ مليار)
لو فرضنا أنّ الملف بصيغة PDF حديثة، فإن سرعة تنفيذ «هجوم القوة العمياء» (Brute-Force Attack) ستكون أبطأ نسبيًا، لأن الخوارزمية المُستخدَمة حديثًا مؤمّنة من هذا الجانب. لا تقتصر التعمية (Cryptography) على إخفاء المعلومات، بل على تعقيد سُبل الوصول إليها إلى أقصى حدّ ممكن. وبالتأكيد، لو احتوى الملف على بيانات منشودةٍ بشدة، قد يقضي المهاجم شهورًا أو سنوات ليستخرج ما بداخله، وهو ما يُعرف بمبدأ: ”احصد الآن، وفُكّ التشفير لاحقًا“.
الطريقة الصحيحة لتنفيذ هجوم القوة العمياء
أجد تنفيذ هجمات القوة العمياء ممتعًا، لكن بشرط أن تكون مدروسة لا عشوائية. ولهذا السبب، بدلًا من تجربة كل الاحتمالات، تُحاول أن نفهم الهدف، كان شخصًا أو شركة. مثلًا، يمكننا أن نجرِّب كلمات مفتاحية من موقع الشركة أو مدونتها، وأن ندمجها مع أنماط شائعة لاختيار كلمات المرور مثل: الكلمة المفتاحية + السنة الحالية، أو اسم الحيوان الأليف + تاريخ الميلاد. في الواقع، استلَم أحد معارفي ملفًّا مُشفّرًا بكلمة مرور بسيطة وهو اسم الشركة + السنة الحالية، لكن لنتجاهل هذا المثال.😄
ما يهمُّني هنا هو رقم الضمان البولندي بعينه. ما يميِّز هذه الحالة أنّ ”السرّ“ المُستخدَم لم يكن عشوائيًا بالكامل، بل استند إلى مجموعة من القواعد المحدَّدة. وهذا ما يقلِّل عدد الاحتمالات، ويزيد من قابلية تنفيذ هجمة القوة العمياء.
بنية رقم الضمان البولندي
بعدما فكّكت تشفير الملف الذي وصلني، راودني سؤال عن سهولة كسر الحماية باستخدام هجمة القوة العمياء. بحكم عشقي للأمن السيبراني، أصبحت ألاحظ الأنماط حتى في التفاصيل اليومية، وهذا تمامًا ما حدث في هذه الحالة.
كما ذكرت، رقم الضمان يتكوَّن من ١١ عددًا، لكن القواعد التي تحكم تركيبه معقدة للغاية. نقلاً عن ويكيبيديا:
أرقام PESEL تتبع الصيغة التالية: YYMMDDZZZXQ
، حيث: YYMMDD
تُمثِّل تاريخ الميلاد (مع ترميز القرن داخل خانة الشهر) ZZZ
يُمثِّل رقم تعريف فريد، بينما يشير الحرف X
إلى الجنس (الأرقام الزوجية للإناث، والفردية للذكور)، أمّا الحرف Q فهو عدد تحقُّق يُستخدم للتأكُّد من صلاحية رقم PESEL. صُمِّم نظام PESEL ليغطي خمسة قرون. ولتمييز الأشخاص الذين وُلِدوا في قرون مختلفة، تُضاف أرقام خاصة إلى خانة الشهر.
عندما دَرستُ صيغة رقم الضمان، اتضَّح أنّ كسره باستخدام القوة العمياء أسهل بكثير ممّا يبدو، بسبب قلّة عدد التوليفات المحتملة لو أخذنا بعين الاعتبار ما يلي:
سنوات الميلاد محصورة في نطاق زمني يبدأ من عام ١٩٥٠ ويصل إلى عام ٢٠٢٤ تقريبًا.
الأشهر محدودة أيضًا، إذ لا يتجاوز عدد القيم الممكنة ١٢ قيمة لكل قرن، نظرًا لأن رقم الضمان صُمِّم ليغطي فترات زمنية طويلة.
وللأيّام، ٣١ قيمة لكل شهر.
أمّا الأعداد الأربعة ”ZZZX
“ الواردة في اقتباس ويكيبيديا، فهي عشوائية.
والعدد الأخير، يُحسَب اعتمادًا على الأعداد العشرة السابقة.
بناءً على ما سبق، تستهدف هجمة القوة العمياء الأعداد الأربعة ”ZZZX
“، لأن بقية الخانات محسوبة بشكل منهجي دقيق. ما يقلِّل عدد التوليفات المحتملة إلى ٢٩٠,٧٨٠,٠٠٠ فقط، أي ما يعادل تقريبًا ٠٫٢٩٪ فقط من أصل ١٠٠ مليار احتمال، لو كان الرقم مكوّنًا من ١١ عددًا عشوائيًا بالكامل!
نصّ برمجي على ”بايثون“ لتوليد قائمة بكلمات المرور
وفقًا لبنية رقم الضمان، فإن كود «بايثون» المُستخدَم لتوليد كلمات المرور يتَّخِذ الشكل التالي:
# SPDX: GPL-3.0-or-later
year19k = [ f"{x:02d}" for x in range(50, 100) ]
year20k = [f"{x:02d}" for x in range(0, 26)]
month19k = [ f"{x:02d}" for x in range(1, 13) ]
month20k = [ f"{x:02d}" for x in range(20, 33) ]
day = [ f"{x:02d}" for x in range(1, 32) ]
unique = [ f"{x:03d}" for x in range(0, 1000) ]
gender = [ f"{x:01d}" for x in range(0, 10) ]
ولتوليد جميع التوليفات الممكنة، استخدمت مكتبة itertools
الرائعة لهذه الوظيفة.
أمّا العدد الأخير فيُحسَب اعتمادًا على الأعداد العشرة السابقة.
فور تشغيل النصّ البرمجي، أصبح من الواضح أن استخدام رقم سهل التخمين لحماية الملفات، مثل رقم الضمان، هو قرار مريع من الناحية الأمنية.
لمن يرغب في تجربة النصّ البرمجي الكامل بِلُغة «بايثون» واختباره على ملف PDF يحتوي على كلمة مرور ”عشوائية“ مُشتقَّة من رقم الضمان البولندي، يمكنكم زيارة مستودع ملفّاتي على «غيت لاب»: @randshell/
pesel-bruteforce
علمًا بأن هذا الكود يُستخدم كإثبات للمفهوم (Proof of Concept)، وبالتالي فإنّ تنفيذه قد يكون بطيئًا.
الخاتمة
مهما بدا ذلك مبتذلًا، فإن اختيار كلمة مرور قوية يظل أمرًا بالغ الأهمية في جميع الحالات، سواء كانت لحساب إلكتروني أو عند مشاركة الملفات. ويُستحسَن إنشاء كلمات المرور باستخدام برنامج مخصَّص، مثل مدير كلمات المرور، لضمان العشوائية الحقيقية وتفادي الاعتماد على اختيارات شخصية أو خوارزميات غير آمنة. في هذه الدراسة، كان رقم الضمان البولندي مثالًا حقيقيًا على استخدام خوارزمية ضعيفة لتوليد كلمة مرور. وقد أظهرت هذه التجربة أن الخصوصية لا تكفي وحدها لضمان الأمان، حتى لو بدا الأمر كذلك ظاهريًا.
الهوامش
خلال الفترة الماضية، شاركتُ في مشروع جديد يُركِّز على موضوع «هجمات القوة العمياء». من الغريب وربما من المضحك أنّ هذا المشروع أيضًا مبني على دراسة حالة حقيقية. لكن هذه الحالة مثّلت مشكلة أمنية أكثر واقعية من حالة ملف رقم الضمان البولندي، ولا تزال طي الكتمان. وعندما تصرّح الشركة المتأثِّرة عن المشكلة، سأنشر تقريرًا مفصَّلاً عن القضية.
١: خدمات الاتصال الغني (RCS)، تُعَدّ بديلًا حديثًا للرسائل النصيّة القصيرة (SMS) ورسائل الوسائط المتعدِّدة (MMS)، وتُصمَّم لتدعَم التشفير التام بين الأطراف.
تمت إعادة نشر هذا المقال وفقاً لرخصة المشاع الإبداعي - Creative Commons، للإطلاع على المقال الأصلي.