تأثر TanStack وحزم برمجية أخرى كثيرة - تحليل وتعمق في التفاصيل
MMaximilian Schwarzmüller
컴퓨터/소프트웨어경제 뉴스AI/미래기술
Transcript
00:00:00لدينا هجوم كبير آخر، هجوم كبير حقًا على سلاسل التوريد يحدث الآن ولا يزال مستمرًا
00:00:06وقد انتقل من نظام NPM ليشمل نظام Python البيئي أيضًا، لذا ربما من الأفضل الآن عدم تثبيت أي
00:00:12حزم NPM أو Python. وتأكد من إعداد نظامك بشكل آمن بشكل عام. لدي فيديو آخر
00:00:19حول ذلك، سأشارك الرابط أدناه وسأعود للتطرق إليه هنا في هذا الفيديو أيضًا، ولكن أولاً أريد
00:00:23أن أعطيكم بعض التفاصيل حول ما تأثر وكيف تعرفون إذا كنتم متأثرين. بدأ الأمر بـ
00:00:30حزم TanStack، مثل TanStack query وTanStack router وTanStack start وما إلى ذلك. بالأمس، 11 مايو،
00:00:36وفي إطار زمني قصير جدًا، تم نشر مجموعة من الحزم الخبيثة، أو في الواقع تم نشر جميع حزم TanStack
00:00:43بإصدارات خبيثة، وتم احتواء الأمر بسرعة خلال 20 دقيقة. في النهاية
00:00:50تم اكتشافه واحتواؤه بسرعة، ولكن كل هذه الحزم الخبيثة نُشرت في ذلك
00:00:57الإطار الزمني أو في هذا الإطار الزمني القصير هنا. ثم استمر في الانتشار ولا يزال
00:01:03ينتشر. لقد وصل إلى حزم Mistral التي (ها ها) ليس لديها سوى أربعة مستخدمين، ولكن مع ذلك
00:01:09تأثرت لأن هذه البرمجيات الخبيثة تعمل كدودة وتقوم بسرقة البيانات، وبيانات الاعتماد، وربما
00:01:16بياناتك أنت أيضًا إذا كانت مثبتة على نظامك. سأعود لكيفية معرفة ما إذا كنت متأثرًا في غضون
00:01:20ثانية، لكنه استمر في الانتشار إلى المزيد من حزم NPM لأن هذه هي الفكرة وراءه،
00:01:26ثم حتى إلى نظام Python البيئي وهذا ما يحدث الآن. هذا الأمر عمره بضع ساعات فقط
00:01:32هنا، ساعتان في اللحظة التي أسجل فيها هذا. الآن، كيف تكتشف إذا كنت
00:01:39متأثرًا؟ إذا قمت بتثبيت أي حزمة TanStack مساء أمس، في حالتي هنا بتوقيت ألمانيا،
00:01:45يجب أن تعتبر نفسك متأثرًا. إذا قمت بتثبيتها في ذلك الوقت تقريبًا، ضع في اعتبارك
00:01:54أن هذا هو توقيت UTC لذا عليك تحويله إلى منطقتك الزمنية، في ذلك الوقت يجب أن تعتبر
00:02:00نفسك متأثرًا. وبما أنه ينتشر إلى حزم Mistral، وإلى العديد من حزم JavaScript الأخرى،
00:02:06أكثر مما يمكنني سرده هنا، فيجب عليك أيضًا اعتبار نفسك أو جهازك متأثرًا ومخترقًا.
00:02:13وسأشارك روابط لهذه المنشورات أدناه لتتمكن من التعمق ورؤية القائمة الكاملة
00:02:18لكل هذه الحزم المتأثرة كما نُشرت. ولكن كما ذكرت، الأمر لا يزال مستمرًا،
00:02:22لذا ربما لا تثبت أي شيء الآن. هناك أيضًا مؤشرات على الاختراق. ستحتاج
00:02:31للبحث عن بصمات ملفات معينة، SHA hashes، للموجه (router) في ملف JS. سأضع رابط هذا المنشور أيضًا أدناه.
00:02:38وإذا كانت لديك طريقة لمراقبة طلبات الشبكة التي حدثت على جهازك،
00:02:42فستبحث عن حركة مرور خارجة إلى هذا الرابط، والذي سيكون مؤشرًا واضحًا آخر
00:02:48على أن البيانات قد تم تسريبها من نظامك. ماذا يعني الاختراق بالتفصيل؟ يعني أن
00:02:55هذه البرمجيات الخبيثة تقوم بأمرين أساسيين. الأمر المهم الأول هو جمع البيانات. فهي
00:03:03تبحث عن رموز NPM، ورموز GitHub، وبيانات اعتماد AWS، وأي أسرار أخرى. لذا تمسح نظامك بحثًا عن
00:03:12المواقع المعتادة التي تخزن فيها بيانات الاعتماد والأسرار، وتجمعها وترسلها إلى
00:03:18هذا الرابط الذي عرضته لكم. إذًا هي تسرق هذه الأسرار. لكنها لا تكتفي بذلك فحسب. فكما ذكرت،
00:03:26هي تعمل كدودة، لذا تستخدم أيضًا رموز GitHub التي تمت سرقتها. على سبيل المثال،
00:03:33تستخدمها مع رموز NPM لنشر المزيد من الحزم المخترقة. إذا كنت مطورًا مسؤولاً
00:03:40عن حزمة أخرى، أو ربما كان لديك سير عمل CI/CD تم تشغيله في ذلك الإطار الزمني وكان
00:03:46يعتمد على بعض حزم TanStack، فعندها في سير عمل CI/CD هذا، تم سحب حزم TanStack
00:03:53الخبيثة والمخترقة. وربما تم تنفيذ الكود الخبيث هناك. وبعد ذلك في سير العمل هذا،
00:04:00وليس بالضرورة على جهازك، بل في سير العمل، يمكنه أيضًا سرقة بيانات اعتماد معينة
00:04:06لنشر إصدار خبيث ومخترق من الحزمة التي كان سير عمل CI/CD الخاص بك يحاول
00:04:14بناءها. هكذا ينتشر الأمر إذًا. فكما ذكرت، هي تعمل كدودة. تستخدم هذه
00:04:20البيانات المسروقة والرموز لنشر المزيد من الحزم المخترقة. وهكذا انتشرت
00:04:26إلى Mistral ومن ثم إلى حزم JavaScript الأخرى، وحتى إلى نظام Python البيئي. وهذا
00:04:32هو الوضع الذي نحن فيه الآن. ولا يزال ينتشر حسب علمي. الآن، كيف يمكنك الحماية
00:04:39من ذلك؟ لقد أنشأت فيديو حول ذلك على قناتي الأخرى، AkataMind. وسأضع رابطه أدناه أيضًا.
00:04:44الخلاصة هي أنك تريد التأكد من تشغيل الكود الخاص بك أو القيام بالتطوير،
00:04:51ليس مباشرة على نظامك الأساسي (root) إذا كان ذلك ممكنًا، بل في جهاز افتراضي أو في حاوية تطوير (dev container)،
00:04:57أو شيء من هذا القبيل. لا ترغب في تخزين الأسرار بشكل مكشوف على جهازك. أعني، بالنسبة لـ AWS،
00:05:03على سبيل المثال، يفضل استخدام نهج تسجيل الدخول الموحد (single sign on) بدلاً من تخزين بيانات IAM على
00:05:10جهازك، على سبيل المثال، واستخدام تقنيات مماثلة للخدمات الأخرى التي قد تستخدمها. بالإضافة إلى ذلك،
00:05:16قد ترغب أيضًا في التفكير في استخدام خدمات مثل InPhysical أو Doppler لتخزين أسرارك
00:05:25في السحابة وليس على قرصك الصلب، وليس في ملفات .env. هذا شيء قد تود القيام به.
00:05:30ومرة أخرى، أتحدث عن مثل هذه الأمور في ذلك الفيديو. وتريد أيضًا استخدام مديري الحزم
00:05:38وعليك أيضًا استخدام مديري الحزم والتكوينات التي تسمح لك بضبط أشياء مثل الحد الأدنى لعمر الإصدار، كما يتيح لك Bun
00:05:44القيام بذلك. ففي ملف bunfig.toml، يمكنك تحديد الحد الأدنى لعمر الإصدار، مما يضمن أنه حتى لو
00:05:49قمت بتشغيل bun install، فإنك لا تثبت إلا الحزم التي مضى على إصدارها X ثانية، أو X يوم في
00:05:56هذا المثال هنا. الآن، pnpm لديه ميزة مماثلة. أحدث إصدارات npm لديها ميزة مماثلة.
00:06:02مرة أخرى، غطيت ذلك في الفيديو الآخر. وإذا كنت تستخدم شيئًا مثل Bun أو كان لديك
00:06:09التكوين الصحيح لـ npm، لكن Bun يفعل ذلك بشكل افتراضي مثلاً، فإنه يحظر أيضًا
00:06:15تنفيذ سكريبتات ما بعد التثبيت (post install)، أي سكريبتات دورة حياة تلك الحزم التي
00:06:21تقوم بتثبيتها، مما يمنحك آلية أمان أخرى لأن تلك البرمجيات الخبيثة تعتمد عادةً
00:06:28على تنفيذ مثل هذه السكريبتات على نظامك. لذا فإن استخدام مدير حزم آمن و/أو
00:06:36تكوين آمن لمدير الحزم، وتشغيل الكود الخاص بك في جهاز افتراضي أو حاوية تطوير،
00:06:41وعدم تخزين أسرار واضحة على نظامك؛ هذا ما يجب عليك فعله بشكل عام، ولكن الآن ربما
00:06:46أكثر من أي وقت مضى لأن هذه الهجمات، مثل هذه الهجمات هنا، ستصبح أكثر خطورة وسنتعمق
00:06:52في كيفية عمل هذا الهجوم لأنه مثير للاهتمام حقًا. ولكن بالطبع، سنواجه المزيد من
00:06:58هذه الهجمات. أنشئ فيديو كهذا كل شهر تقريبًا الآن أو ربما بشكل متكرر أكثر، لأنه لسبب ما،
00:07:04أعتقد أنها أصبحت أسهل في التنفيذ. الآن في عصر الذكاء الاصطناعي، أصبح من الأسهل تحليل الحزم أو
00:07:12التبعيات التي تريد التأثير عليها وتحليل شفرتها المصدرية أو إعداد CICD الخاص بها بحثًا عن
00:07:22نواقل هجوم محتملة. وهذا ما حدث هنا لـ TanStack. لم يكن الأمر وكأن جهاز أحد المطورين
00:07:28تأثر، ولكن بدلاً من ذلك كان سير عمل TanStack CICD هو الذي تعرض للهجوم. وسأعود
00:07:34إلى ذلك. إذًا من الأسهل البحث عن الثغرات باستخدام الذكاء الاصطناعي. ومن الأسهل كتابة التعليمات البرمجية،
00:07:40بما في ذلك التعليمات الخبيثة بالطبع. وفي الوقت نفسه، لدينا انفجار في البرمجيات. لدينا
00:07:45برمجيات تُكتب أكثر من أي وقت مضى. لذا هناك المزيد من الأهداف المتاحة، بما في ذلك العديد من الأهداف
00:07:51التي ربما لا تهتم كثيرًا بالأمان. وهذا يجعل هذه الهجمات أكثر إثارة للاهتمام أيضًا.
00:07:57الآن، كيف بدأ كل هذا؟ إنه أمر مثير للاهتمام حقًا. كما ذكرت، ليس نهجًا جديدًا،
00:08:03وليس نهجًا لم نره من قبل، ولكنه لا يزال متطورًا للغاية. نشر فريق TanStack منشورًا
00:08:09تحليليًا (post mortem)، مقالاً يشرحون فيه كيف حدث الهجوم. وسأضع رابط ذلك أدناه أيضًا.
00:08:15ولكن بالطبع، سأعطيكم الملخص هنا لأنه في النهاية، اعتمد هذا الهجوم هنا على
00:08:22ثلاث خطوات رئيسية، سأشرحها بالتفصيل. نمط طلب سحب مستهدف (pull request target pawn). سأشرح
00:08:30ما هو ذلك. ثم تسميم ذاكرة التخزين المؤقت لـ GitHub actions عبر حدود الثقة القائمة على التفريع (fork)
00:08:38واستخراج رمز OIDC من ذاكرة وقت التشغيل. حسنًا، ماذا يعني كل هذا؟ مرة أخرى،
00:08:45يمكنكم قراءة المقال لمعرفة كافة التفاصيل، ولكن دعوني أعطيكم الملخص. ولنبدأ بـ
00:08:50نمط طلب سحب مستهدف (pull request pawn). ما هو ذلك؟ لكي نفهم ذلك علينا أن نفهم
00:08:58أن GitHub actions هو بالطبع حل CI/CD، منتج CI/CD من GitHub. ولدي
00:09:05دورة تدريبية حول GitHub actions أيضًا، بالمناسبة، إذا كنتم ترغبون في تعلم كيفية إعداد GitHub actions،
00:09:10وكيفية استخدام المنتج لمهام CI/CD، وكيفية نشر حزمكم أو موقعكم الإلكتروني وما إلى ذلك.
00:09:16الآن، مثل جميع أدوات سير عمل CI/CD، يعتمد GitHub actions على الأحداث التي تطلق سير العمل، لأن
00:09:24بالطبع CI/CD يدور حول القيام بشيء ما بطريقة آلية. على سبيل المثال، إصدار موقعك،
00:09:29نشر موقعك وتوزيعه بطريقة آلية عند الدفع (push) إلى الفرع الرئيسي، على سبيل المثال.
00:09:34لذا لديك أحداث متنوعة يمكن أن تطلق سير العمل، والدفع هو حدث واحد، على سبيل المثال،
00:09:40بحيث يمكنك القول، حسنًا، إذا قمت بالدفع إلى الفرع الرئيسي، مثلاً، يمكنك التصفية حسب
00:09:44فروع مختلفة. ثم أريد تنفيذ مهام معينة. أريد تثبيت التبعيات. أريد
00:09:49بناء المشروع. أريد رفعه إلى الخادم الخاص بي. هذا ما يمكنك فعله. الآن، هناك محفز آخر
00:09:56هو pull request target (هدف طلب السحب). ينشط هذا المحفز إذا تم فتح طلب سحب لـ
00:10:05المستودع الخاص بك. وهذا يعني بالطبع أن أي شخص يمكنه عمل نسخة (fork) من مستودعك، والقيام بشيء هناك، ودفع
00:10:14شيء ما في نسخته، ثم فتح طلب سحب مع مستودعك الأصلي. وهذا من شأنه أن يطلق
00:10:19سير العمل هذا. يبدو الأمر خطيرًا؟ حسنًا، هو كذلك نوعًا ما. وهو ما بدأ هذا الهجوم.
00:10:25هناك أيضًا محفز pull request (طلب سحب) عادي. لقد تحدثت عن pull request target من قبل،
00:10:31لكن لدينا أيضًا pull request، والذي يعمل بنفس الطريقة، ولكن pull request يقوم بتشغيل سير عمل
00:10:38CI/CD في سياق المستودع المنسوخ (forked). لذا فمهما كان الشيء الخبيث الذي قد يحدث هناك،
00:10:45فإنه يحدث في المستودع المنسوخ، وليس في المستودع الأساسي. لذا لا يمثل هذا مشكلة.
00:10:52أما pull request target من ناحية أخرى فيعمل في سياق المستودع الأساسي. وهذا بالطبع
00:10:58أمر خطير محتمل. إنه خطير محتمل لأن أي شخص يمكنه فتح طلب سحب. وبالطبع،
00:11:04ما حدث في هذه الحالة لهجوم TanStack، هو أنه في طلب السحب هذا، وفي تلك
00:11:10النسخة المنسوخة، ضمن المهاجم الكود الخبيث، كود الدودة، والبرمجيات الخبيثة في مستودع TanStack،
00:11:20في النسخة المنسوخة منه، قام بتضمينه هناك. ثم فتح المهاجم طلب السحب،
00:11:26وأدى ذلك إلى تنفيذ pull request target. وكما ذكرت، يؤدي ذلك إلى تشغيل
00:11:33مشغل GitHub actions (runner)، ثم يتم تشغيله في سياق المستودع الأساسي. ماذا يعني هذا؟
00:11:40هذا لا يعني أن المهاجم يحصل على وصول إلى الكود الأساسي أو يمكنه دمج الكود الخبيث
00:11:46في المستودع، ولكنه يعني، على سبيل المثال، أن ذاكرة التخزين المؤقت (cache) المستخدمة هناك
00:11:53ستتم مشاركتها مع عمليات تنفيذ GitHub actions اللاحقة التي تنبع من المستودع الأساسي،
00:12:00ربما من خطافات (hooks) مختلفة تمامًا أو محفزات أحداث مثل محفز الدفع (push).
00:12:05الشيء التالي الذي حدث هو تسميم ذاكرة التخزين المؤقت. ولكن ماذا يعني هذا؟ حسنًا،
00:12:11أضاف المهاجم كودًا إلى نسخته المنسوخة يضمن أنه عندما يتم تشغيل GitHub action
00:12:17لمحفز pull request target، فإنه سيقوم بتشغيل أمر hash files،
00:12:23وهو أمر مدعوم من قبل GitHub actions، لتخزين شيء ما في ذاكرة التخزين المؤقت لـ GitHub actions. الآن،
00:12:28ما الغرض من ذاكرة التخزين المؤقت هذه؟ الفكرة وراءها ببساطة هي تسريع
00:12:33سير عمل GitHub action. فيمكنك، على سبيل المثال، عمل بصمة (hash) للتبعيات. الفكرة هي أنه
00:12:39إذا لم تتغير التبعية التي تعتمد عليها حزمتك، فلماذا تمر بعملية
00:12:46التثبيت بالكامل مرة أخرى؟ هذا يستغرق وقتًا، والوقت هو مال لأنك تحاسب على
00:12:52وقت تشغيل سير عمل GitHub action الخاص بك. وبالطبع، لا تريد أن يكون لديك سير عمل
00:12:56يستغرق وقتًا طويلاً. لذا في معظم سير العمل، بالطبع، على سبيل المثال عند بناء حزم TanStack،
00:13:00تقوم بتثبيت تبعيات حزم TanStack، ثم تقوم بخطوة البناء وتبني
00:13:06حزمة TanStack الخاصة بك. مرة أخرى، إذا لم تتغير تبعيات TanStack هذه،
00:13:12فلماذا تعيد تثبيتها؟ هذه هي الفكرة وراء التخزين المؤقت. وهذا منطقي تمامًا. وبالطبع المشكلة هي،
00:13:18بما أن تنفيذ pull request target في GitHub actions وعمليات تنفيذ GitHub action الأخرى،
00:13:24مثل تلك الخاصة بمحفز الدفع، تشترك في نفس السياق، فهي تشترك في نفس ذاكرة التخزين المؤقت. وهذا
00:13:31هو المكان الذي يأتي منه تسميم الذاكرة المؤقتة، لأن المهاجم تمكن من تخزين إصدار خبيث مؤقتًا أو وضع
00:13:39ذلك الكود الخبيث في إحدى تبعيات TanStack، إن جاز التعبير، وتخزينه مؤقتًا. لذا كان على المهاجم
00:13:46مجرد الانتظار حتى يتم تشغيل سير عمل GitHub actions عادي لحزم TanStack.
00:13:53أي أن يقوم أحد المطورين بدفع كود ما، وعندها سيعيد تنفيذ GitHub actions الآخر هذا استخدام
00:14:01نفس ذاكرة التخزين المؤقت التي تم إعدادها بواسطة التنفيذ الخبيث السابق، وسيقوم الآن بسحب
00:14:08الذاكرة المؤقتة المسمومة والمجهزة، والتي تضمنت الكود الخبيث. هكذا وصل الكود الخبيث إذًا
00:14:13من النسخة المنسوخة إلى تنفيذ GitHub actions العادي لعملية دفع عادية من قبل مطور عادي
00:14:21لم يتأثر بأي كود خبيث. هكذا تم استخدام ذاكرة التخزين المؤقت كوسيلة نقل
00:14:28بين عمليتي تنفيذ GitHub action في النهاية. ثم كخطوة ثالثة، بمجرد أن
00:14:35وصل الكود الخبيث إلى تنفيذ منتظم لسير عمل TanStack CI/CD، بسبب حدث الدفع
00:14:44هذا، قام بسرقة رمز NPM قصير الأمد، رمز OIDC في النهاية، لنشر إصدار خبيث
00:14:54من حزمة TanStack. الآن، إلى ماذا أشير هنا؟ لدى NPM ميزة تسمى
00:15:00النشر الموثوق (trusted publishing)، والتي نظريًا تجعل نشر حزم NPM أكثر أمانًا، لأن
00:15:04هناك طريقتين تقريبًا لنشر حزمة على NPM، إن صح التعبير. الأولى هي أن تنشئ
00:15:11رمزًا (token) بحساب NPM الخاص بك وتستخدمه لنشر إصدارات جديدة من حزمتك. المشكلة
00:15:19هي أنه إذا سُرق هذا الرمز، يمكن لأي شخص نشر إصدار جديد من تلك الحزمة. لرفع مستوى
00:15:26الأمان، هناك عملية النشر الموثوق هذه حيث تقول NPM: لا، لا يمكنك نشر الحزم من
00:15:33جهازك، يجب أن تمر عبر أحد هؤلاء المزودين الموثوقين، وGitHub actions هو أحدهم،
00:15:37وهناك تكامل للنشر الموثوق لـ GitHub actions يمكنك إعداده. وبعد ذلك
00:15:44كجزء من عملية النشر الموثوق هذه، سيتم جلب رمز نشر قصير الأمد
00:15:50أو سيتم طلبه. ثم سيتم استخدام هذا الرمز قصير الأمد لتوقيع نسخة الحزمة
00:15:57الجديدة التي يتم نشرها. لذا نظريًا، الفكرة هي أن الرمز صعب السرقة لأنه
00:16:03ليس موجودًا على جهاز أي مطور. وبالإضافة إلى ذلك، فهو قصير الأمد. حتى لو سُرق،
00:16:08فلن يكون نشطًا لفترة طويلة. المشكلة بالطبع تكمن فقط في الكود الذي يتم تشغيله في سير عمل CICD
00:16:15الذي طلب ذلك الرمز الموثوق، فإذا تأثر هذا الكود، فإن ذلك الكود الخبيث
00:16:21لديه وصول إلى هذا الرمز الجديد كليًا والموثوق والقصير الأمد. وهذا ما حدث
00:16:27هنا. لذا استغل هذا الكود الخبيث هذا الرمز أو استخدم هذا الرمز ليقوم بنشر إصدار جديد
00:16:36من حزمة TanStack. الآن، ومن المثير للاهتمام، أن هذا الهجوم فشل قليلاً في الواقع لأنه
00:16:44حصل على ذلك الرمز الموثوق واستخدمه للتواصل مع واجهة برمجة تطبيقات NPM لنشر إصدار جديد
00:16:52من حزمة TanStack تضمن هذه الدودة، وتضمن الكود الخبيث. لكنه انتهى به الأمر في الواقع
00:16:58في سير عمل GitHub actions فشل في الاكتمال بسبب وجود خطأ ما في
00:17:06الكود الذي تم دفعه إلى CICD. فلو انتبه المهاجمون لتنفيذ
00:17:12هجومهم في وقت يتم فيه دفع كود صالح، فعندها بالطبع كان سير العمل هذا
00:17:19سيكتمل ولن يضطروا للاعتماد على نشر حزمة خبيثة يدويًا عن طريق التواصل
00:17:26مع واجهة برمجة تطبيقات NPM، بل كان بإمكانهم حقن الكود الخبيث في سير العمل هذا كما
00:17:32فعلوا، وترك سير العمل هذا ينتهي بنجاح، وعندها كان سيتم نشر نسخة مخترقة من TanStack
00:17:38بينما تبدو صالحة تمامًا لأنها كانت نتيجة دفع عادي من قبل مطور وسير العمل
00:17:45انتهى بنجاح. الطريقة التي سار بها هذا الهجوم نظرًا لأن سير العمل لم ينتهِ بنجاح
00:17:51جعلت من الأسهل قليلاً كشف ما كان يحدث من قبل مساهم خارجي هنا في النهاية
00:18:00لأنه أمكن رؤية نشر إصدار جديد من حزم TanStack بالرغم من أن
00:18:05سير عمل GitHub actions فشل، لذا لم يكن من المفترض نشر أي إصدار جديد. أمكن رؤية
00:18:12عدم تطابق هناك مما جعل اكتشاف هذا الهجوم أسهل قليلاً، وهو الجزء الذي
00:18:19حالفنا فيه الحظ جميعًا ومعنا مطورو TanStack. ومع ذلك، فهو هجوم متطور للغاية كما تلاحظون
00:18:26على الأرجح، وقد نجح تمامًا دون اختراق جهاز أي شخص، وبالرغم من اكتشافه
00:18:32بسرعة، إلا أنه ألحق أضرارًا جسيمة لأنه كما ذكرت لا يزال ينتشر، وكانت هذه
00:18:41حلقة طويلة عن كل ذلك، أعلم، لكنني أريد حقًا التأكيد على ضرورة العمل على تأمين نظامكم
00:18:49كما شاركت من قبل وكما أشارك في هذا الفيديو؛ فأنتم تريدون التأكد من تقليل
00:18:56خطر التعرض للتأثر؛ تم اكتشاف هذا الهجوم مرة أخرى بسرعة ومع ذلك لا يزال ينتشر
00:19:05لذا فالأمر لم ينتهِ بعد، ومن المحتمل ألا يتم اكتشاف جميع الهجمات بهذه السرعة
00:19:11في المستقبل. وكما ذكرت، حالفهم الحظ قليلاً هنا، وكان من الممكن أن يكون اكتشاف هذا الهجوم
00:19:18أصعب، وعندها ربما يكون الضرر أكبر، لكنه كبير بالفعل هنا و
00:19:24لم ينتهِ بعد، وسنرى المزيد من هذه الهجمات بكل تأكيد لأنني ذكرت أن سطح الهجوم
00:19:31أصبح أكبر وأكثر إغراءً، فهناك المزيد من الأشخاص الذين يكتبون الكود، والكثير منهم
00:19:36لا يدركون ما يفعلون، والذكاء الاصطناعي يساعد في تنفيذ مثل هذه الهجمات؛ نعم، هذا ما يحدث
00:19:42الآن؛ إذا لم تكن مضطرًا، فربما لا تثبت أي شيء، وتحقق جيدًا من إعداداتك و
00:19:48ستجد جميع الروابط أدناه إذا كنت تريد التعمق أكثر وإذا كنت تريد رؤية القائمة الكاملة للحزم
00:19:51المتأثرة وما إلى ذلك.
Community Posts
No posts yet. Be the first to write about this video!
Write about this video