السلام عليكم ورحمة الله وبركاته، متابعينا الأعزاء في قناة ومدونة Shadow Hacker. كالعادة راجعلكم اليوم بمقال مختلف، بتوضح كيف أحيانًا الثقة الزايدة بين أنظمة الشركات الكبيرة ممكن تكون هي نقطة الضعف الأكبر. إحنا اليوم راح نحكي عن ثغرة أمنية حقيقية تم اكتشافها في أنظمة شركة ميتا، الشركة الأم لكل من فيسبوك وانستقرام، ثغرة خطيرة جدًا بتسمح للمهاجم إنه يسيطر على حساب انستقرام أي ضحية بدون ما يحتاج كلمة مرور، بدون ما يدخل على إيميلها، وبدون ما حتى الضحية تحس إنه في شي غريب عم يصير.
ثغرة اختراق Instagram عبر استغلال Meta Pixel Script
القصة اللي راح أحكيها اليوم موثقة وتم الإبلاغ عنها في يناير 2026، والباحث الأمني اللي اكتشفها وثقها بتفاصيل دقيقة جدًا. وأنا جاي أحكيلكم إياها اليوم لأنها مهمة جدًا لكل واحد منكم، خصوصًا اللي بيعتمد على انستقرام في شغله أو اللي عنده متابعين كتير أو حتى اللي بده يحمي خصوصيته. اللي مش سامع عن هيك ثغرات قبل هيك، أقولك إنك فوت على حالك قصة من أندر أنواع الثغرات الأمنية، ثغرة ما بتعتمد على اختراق كلمة المرور ولا على فيروسات، لا، ثغرة بتعتمد على فهم عميق لكيفية عمل المتصفحات وكيف الشركات الكبيرة بتبني أنظمتها.
أنا بعرف إنه في كتير منكم متابعيني مهتمين بأمان حسابات التواصل الاجتماعي، خصوصًا انستقرام، لأنه بطل مجرد تطبيق للصور، صار مصدر رزق لكثير من الناس، صار فيه أصول رقمية بتمثل سنوات من الشغل والتعب. فطبيعي إنك تحب تحمي هالأصول. في 2026، صارت أدوات القراصنة والأساليب المستخدمة في الاختراق متطورة بشكل غير طبيعي. صرنا نشوف ثغرات قبل كم سنة كانت تعتبر مستحيلة، صارت حقيقة واقعية. ولهيك فهم طريقة عمل هذه الثغرات هو أقوى سلاح عندك لحماية حالك. اليوم راح نغوص مع بعض في تفاصيل هذي الثغرة بالتفصيل الممل. راح نشرح إزاي بتشتغل من الداخل، وشو السيناريو اللي المهاجم بستخدمه عشان يسرق حسابك، وشو الأسباب اللي خلت الثغرة تكون بهذي الخطورة، وأهم شي، كيف تحمي نفسك من ثغرات مشابهة في المستقبل.
ما هي ثغرة Meta Pixel Script Abuse؟ الحكاية من البداية
قبل ما ندخل في التفاصيل التقنية، خليني أحكيلك قصة مختصرة عن كيف كل شي بدأ. شركة ميتا عندها نظام بيئي ضخم جدًا من المواقع والخدمات. عندك موقع فيسبوك الرئيسي، عندك انستقرام، عندك موقع مطوري فيسبوك developers.facebook.com، عندك موقع الأعمال business.facebook.com، وعندك العشرات بل المئات من النطاقات الفرعية والخدمات المختلفة. كل هذي المواقع تحتاج تتواصل مع بعضها البعض، وبتستخدم المتصفح عشان تسوي هالتواصل.
طريقة التواصل بين المواقع في المتصفح اسمها postMessage. تخيل إنه عندك نافذتين مفتوحتين في المتصفح، وحدة منهم بدها تبعت رسالة للتانية. عشان هالرسالة تكون آمنة، المتصفح بيمنع أي موقع يبعت رسالة لأي موقع ثاني إلا إذا كان الموقع المستقبل متأكد إن الرسالة جاية من مصدر موثوق. هالتأكد بنسميه فحص المصدر origin check. ميتا، مثلها مثل أي شركة كبيرة، عملت هالفحص. هي قررت إنها راح تثق بأي رسالة جاية من facebook.com أو أي نطاق فرعي تابع لها. وللوهلة الأولى، هالقرار منطقي. ليش؟ لأنه لو الرسالة جاية من فيسبوك نفسه، معناتها هي رسالة آمنة، صح؟
الباحث الأمني اللي اكتشف الثغرة لاحظ إن في سكريبت اسمه fbevents.js، واللي هو نفسه سكريبت Meta Pixel المعروف، اللي ملايين المواقع حول العالم بتحطه عشان تتتبع الزوار وتحلل البيانات. هالسكريبت، لما ينحمل في أي صفحة، بعمل listener، يعني بيستنى أي رسالة postMessage توصل للصفحة، وكل ما يجيه رسالة مصدرها facebook.com، بيتفاعل معها فورًا بدون ما يراجع محتواها بشكل أعمق.
وهنا المعلومة الخطيرة: هالسكريبت بيقبل رسائل فيها access_token (رمز الدخول)، وبعد ما يستقبلها، بستخدم هالرمز عشان يروح يطلب بيانات من واجهة برمجة التطبيقات (API) الخاصة بفيسبوك، يعني من graph.facebook.com. وأثناء إرسال الطلبات هذي، السكريبت بيرسل معها معلومات عن الصفحة الحالية، زي عنوان الصفحة (location.href) والصفحة اللي قبلها (document.referrer).
تخيل معي هالسيناريو: لو المهاجم قدر يبعت رسالة لهالسكريبت، وحط فيها رمز دخول خاص فيه، فالمعلومات اللي راح تتبعت مع الطلبات راح توصل المهاجم عن طريق تاريخ الرمز الخاص فيه. وهون، لو هالمعلومات تحتوي على أكواد OAuth خاصة بالضحية، فالمهاجم راح يقدر يسرقها بسهولة. هذي هي الثغرة باختصار: ثغرة بتعتمد على ثقة عمياء من سكريبت Meta Pixel بأي رسالة جاية من فيسبوك، بتسمح للمهاجم إنه يستخدم رمز دخول خاص فيه عشان يسرق بيانات حساسة من الصفحة الضعيفة.
كيف بتشتغل الثغرة بالتفصيل؟ سيناريو الاختراق خطوة بخطوة
هسا خلينا ندخل في صلب الموضوع. راح أحكيلك كيف المهاجم المحترف بيقدر يستغل هذي الثغرة عشان يسرق حساب انستقرام. السيناريو راح يكون مقسم لخمس خطوات رئيسية، وكل خطوة راح أوضحها بالتفصيل عشان تفهم الصورة كاملة.
الخطوة الأولى: تجهيز بيئة الهجوم
أول شي المهاجم بحتاجه هو موقع يقدر يتحكم بمحتواه بالكامل. يعني مهاجم بقدر يجهز صفحة HTML بسيطة على سيرفر خاص فيه، أو حتى على خدمة استضافة مجانية. مش مهم الموقع، المهم إنه المهاجم يكون مسيطر على الكود اللي فيه. المهمة الأساسية لهالصفحة هي إنها تفتح نافذة جديدة باستخدام window.open، وتوجه هالنافذة لصفحة معينة. بس في شرط مهم جدًا: لما تفتح النافذة الجديدة، لازم يكون عندها علاقة مع النافذة الأم، يعني النافذة الجديدة لازم تعرف مين فتحها. هالعلاقة بنسميها opener relationship. المتصفحات بتحافظ على هالعلاقة عشان النوافذ تقدر تتواصل مع بعضها. المهاجم بيستغل هذي العلاقة عشان يكون جسر تواصل بين الصفحات المختلفة.
الخطوة الثانية: إرسال الضحية لصفحة OAuth معدلة
هسا بعد ما المهاجم جهز صفحته، بحتاج يوقع الضحية في الفخ. كيف؟ عن طريق رابط خاص جدًا. الرابط اللي المهاجم بيستخدمه هو رابط تفويض OAuth لانستقرام. OAuth هي الطريقة اللي التطبيقات بتستخدمها عشان تخليك تسجل دخولك بحسابك بدون ما تعطيها كلمة المرور. لما تضغط على "تسجيل الدخول بانستقرام" في أي تطبيق ثالث، أنت عم تستخدم OAuth. المهاجم بيعمل رابط OAuth، لكنه بيملأه بطريقة معينة. خليني أعطيك مثال على شكل الرابط:
https://www.instagram.com/oauth/authorize/third_party? &app_id=200289238967899 &redirect_uri=https://developers.facebook.com/instagram/token_generator/oauth/ &response_type=code &scope=user_profile,user_media &state={"app_id":"200289238967899","nonce":"WRONG_NONCE","user_id":"1"}
شو الغريب بهالرابط؟ فيه كم نقطة مهمة جدًا: أولاً، redirect_uri (رابط إعادة التوجيه) موجه لموقع developers.facebook.com، تحديدًا لصفحة بتستخدم لتوليد التوكنات. ثانيًا، في حقل state، المهاجم حط nonce غلط عمدًا. يعني حط قيمة مش متطابقة مع اللي متوقع.
لما الضحية تفتح هالرابط وتسجل دخولها بانستقرام بشكل طبيعي، راح يتم إصدار كود OAuth خاص فيها. لكن بدل ما الكود يروح للتطبيق الشرعي، راح يروح لصفحة developers.facebook.com. ولأن المهاجم حط nonce غلط، الصفحة راح تعطيه رسالة خطأ. يعني الضحية راح تشوف صفحة خطأ طبيعية في فيسبوك وتفكر إنه في مشكلة بسيطة وتسكرها. لكن المهم إن هالصفحة (صفحة الخطأ) بتحمل سكريبت Meta Pixel. والسكريبت هاد صار عنده مستمع للرسائل. وعلاقة opener ما زالت موجودة بين صفحة الخطأ والنافذة اللي فتحتها.
الخطوة الثالثة: استغلال صفحة فيسبوك المخترقة
هسا بعد ما الضحية صارت عندها صفحة الخطأ مفتوحة، المهاجم برجع لصفحته الأصلية ويعمل إعادة توجيه للنافذة اللي فتحها (وهي نفسها النافذة اللي فتحت صفحة الخطأ) إلى رابط خاص جدًا داخل facebook.com. هالرابط الخاص هو نقطة ضعف في فيسبوك نفسه. الرابط بستقبل باراميترات من المستخدم وبتبعثها عبر postMessage للنافذة الأم. يعني الرابط بيسمح للمهاجم إنه يحدد شو الرسالة اللي راح تتبعت، وشو محتواها، وإلى مين راح تتبعت. المهاجم بيضبط الرابط عشان يبعت رسالة فيها:
- رمز دخول خاص فيه (access_token تابع لحساب المهاجم نفسه)
- نوع الرسالة (msg_type) يكون FACEBOOK_IWL_BOOTSTRAP
- معرّف البيكسل (pixelID) ومعرّف الجلسة (sessionStartTime)
لما النافذة تروح لهالرابط، صفحة فيسبوك بتقوم بإرسال الرسالة باستخدام postMessage. المصدر (origin) لهذي الرسالة هو facebook.com. النافذة المستقبلة هي صفحة developers.facebook.com (صفحة الخطأ اللي عند الضحية). وهنا بيجي دور السكريبت fbevents.js. السكريبت بيشوف إنه في رسالة جاية، ويتأكد من المصدر: المصدر facebook.com، تمام، هذا مصدر موثوق. السكريبت بيقبل الرسالة بدون أي تدقيق إضافي.
الخطوة الرابعة: سرقة كود OAuth من الضحية
السكريبت لما يستقبل الرسالة، بيشوف إنه في access_token جاي مع الرسالة. هالرمز هو رمز المهاجم، مش رمز الضحية. لكن السكريبت ما بيدقق، بياخذ الرمز وبستخدمه عشان يروح يطلب من graph.facebook.com. أثناء إرسال الطلبات، السكريبت بيرسل معها معلومات عن الصفحة الحالية. وهون بتصير القصة. الصفحة الحالية هي صفحة developers.facebook.com اللي فيها رسالة الخطأ. وهالصفحة، لأنها كانت ناتجة عن عملية OAuth فاشلة، في عنوانها (location.href) موجود كود OAuth الخاص بالضحية! الكود اللي كان المفروض يستخدم لتسجيل الدخول.
لما الطلبات تروح لـ graph.facebook.com، بتوصل معها هالمعلومات. ولأن الطلبات صارت باستخدام رمز المهاجم، كل هالطلبات بتنحفظ في تاريخ الرمز الخاص بالمهاجم. المهاجم ببساطة بفتح أداة Graph Explorer (أداة رسمية من فيسبوك بتسمحلك تشوف تاريخ الطلبات لأي رمز دخول)، ويشوف كل الطلبات اللي صارت باستخدام رمزه. وبين هالطلبات، راح يلاقي الطلبات اللي أرسلها سكريبت Meta Pixel، وفيها كود OAuth الخاص بالضحية واضح وصريح.
الخطوة الخامسة: استبدال الكود بتوكن انستقرام حقيقي
آخر خطوة، المهاجم معه كود OAuth الخاص بالضحية. هالكود هو مفتاح سحري: إذا قدرت تستبدله بتوكن وصول، تقدر تتحكم بحساب الضحية. المهاجم بيروح على رابط تابع لميتا، وتحديدًا:
https://developers.facebook.com/instagram/short_lived_access_token/oauth/? &code=VICTIM_CODE &state={"app_id":"FIRST_PARTY_APP","nonce":"YOUR_NONCE","user_id":"1"}
هالرابط هو نقطة ضعف ثانية. المفروض إنه ما يقبل أي كود OAuth، المفروض يتأكد إن الكود صادر من تطبيق معين، لكنه في وقت الثغرة كان يقبل أي كود، بغض النظر عن التطبيق اللي أصدره. المهاجم بحط الكود اللي سرقه في الرابط، ويضغط عليه، والنتيجة؟ راح ياخذ توكن انستقرام حقيقي من الدرجة الأولى. توكن بيديه صلاحيات كاملة على حساب الضحية: يقدر ينشر صور، يحذف منشورات، يشوف الرسائل الخاصة، يغير الإعدادات، وحتى يغير كلمة المرور.
وكل هالعملية صارت بدون ما الضحية تحس. الضحية بس فتحت رابط، وسجلت دخولها بانستقرام بشكل طبيعي، وشافت صفحة خطأ في فيسبوك وسكرتها. وحسابها صار في أيدي المهاجم.
ليش الثغرة بهذي الخطورة؟
اللي قرأ السيناريو اللي فوق راح يسأل سؤال: ليه هالثغرة بهذي الخطورة؟ طيب في ثغرات ثانية بتخلي المهاجم يسرق الحساب مباشرة، شو الميزة بهذي الثغرة؟ الخطورة مش بس في إن الثغرة موجودة، الخطورة في مجموعة عوامل بتخليها قاتلة.
انتشار الهدف بشكل غير طبيعي سكريبت Meta Pixel موجود على ملايين المواقع حول العالم. أي موقع بيستخدمه عشان يحلل زواره هو موقع ممكن يكون نقطة استغلال. لكن الأخطر إن صفحات ميتا نفسها، زي developers.facebook.com و business.facebook.com و حتى facebook.com نفسه في بعض الصفحات، بتحمل هالسكريبت. يعني الضحية راح تكون داخل نطاق ميتا نفسه، وهذا بيزيد المصداقية ويقلل شكوك المستخدم.
كيف تحمي حسابك من ثغرات مشابهة
الخبر السار إن هالثغرة تم إصلاحها بشكل كبير. بس الخبر السيء هو إن المنطق الأمني اللي أدى لهالثغرة موجود في أنظمة كثيرة غير ميتا. الشركات الكبيرة كلها عندها أنظمة معقدة بتتواصل مع بعضها، والثغرات زي هيك ممكن تتكرر. لهيك، أنا حأعطيك مجموعة خطوات عملية تحمي فيها حسابك، ليس بس من هالثغرة، لكن من ثغرات مشابهة ممكن تظهر مستقبلًا.
أولاً: قلل من استخدام OAuth مع تطبيقات غير موثوقة كل مرة بتوافق على تسجيل الدخول بانستقرام عبر تطبيق خارجي، أنت بتصدر كود OAuth. الكود هذا، حتى لو كان آمن في الظروف الطبيعية، ممكن يتم استغلاله إذا في ثغرة مشابهة. حاول تقلل عدد التطبيقات المرتبطة بحسابك، وراجع باستمرار قائمة التطبيقات من إعدادات انستقرام. أي تطبيق ما بتستخدمه، اقطعه فورًا.
ثانياً: فعّل المصادقة بخطوتين بشكل إلزامي حتى لو المهاجم قدر يسرق توكن، المصادقة بخطوتين ممكن توقف الضرر. لكن لازم تعرف إن في أنواع من التوكنات بتتجاوز 2FA في بعض الحالات. لهيك، استخدم تطبيق مصادقة زي Google Authenticator أو Authy، وما تعتمد على الرسائل النصية لأنها أقل أمانًا.
هل حسابك آمن على منصات ميتا؟
بعد ما حللنا هالثغرة بالتفصيل، بدي أحكيكم رأيي الصريح. ميتا عندها فريق أمني ممتاز. في ناس شاطرة جدًا بشتغلو هناك. بس حجم التعقيد في أنظمتها الهائلة بيخلق ثغرات لا مفر منها. أنظمة ميتا فيها مليارات السطور البرمجية، وفيها مئات الآلاف من المكونات اللي بتتفاعل مع بعضها. أي تفاعل بين أي مكونين ممكن يكون نقطة ضعف.
الأهم هو إنه لما تكتشف ثغرة، يتم التعامل معها بجدية. في قصة اليوم، ميتا في البداية ما أخذت الثغرة بجدية كافية، لكنها في النهاية أصلحت أخطر جزء منها. هالشي إيجابي، بس برضه بيدل على إنه في ضغط على فرق الأمان، وإنه بعض الثغرات ممكن تتأخر معالجتها. بالنسبة للمستخدم العادي، حسابك آمن طالما تلتزم بممارسات الأمان الأساسية. الشركات الكبيرة بتستثمر مليارات الدولارات في الأمان، والثغرات الخطيرة جدًا اللي بتأثر على المستخدمين العاديين نادرة.
