يجادل مؤلفو هذه المقالة ضد آليات التشفير الرئيسية القياسية في OpenSSH.استخدم المهاجمون مؤخرًا نطاق nlm لحزمة npm لسرقة الرموز المميزة لـ npm من دلائل المستخدم الرئيسية. في ضوء هذا الحدث ، بدأنا في التحقق من نقاط الضعف المماثلة الأخرى وفكرنا في كيفية الحد من مخاطر وعواقب مثل هذه الحوادث.
معظمنا لديه مفتاح RSA SSH في متناول اليد. يمنح هذا المفتاح المالك مجموعة متنوعة من الامتيازات: كقاعدة ، يتم استخدامه للوصول إلى بيئة الإنتاج أو في GitHub. على عكس الرموز المميزة لـ nmp ، يتم تشفير مفاتيح SSH ، وبالتالي فمن المقبول عمومًا أنه لن يحدث أي شيء سيئ ، حتى إذا وقعت في الأيدي الخطأ. ولكن هل هو كذلك حقا؟ دعنا نكتشف.
user@work /tmp $ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/user/.ssh/id_rsa): mykey
...
user@work /tmp $ head -n 5 mykey
-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: AES-128-CBC,CB973D5520E952B8D5A6B86716C6223F
+5ZVNE65kl8kwZ808e4+Y7Pr8IFstgoArpZJ/bkOs7rB9eAfYrx2CLBqLATk1RT/
يتم تشفير هذا المفتاح ، كما هو موضح بواسطة أحد الأسطر الأولى من الملف. بالإضافة إلى ذلك ، في البداية لا يوجد مفتاح تشفير MII - base64 يستخدم في RSA. وبالطبع ، فإن AES تلفت انتباهك! إنه جيد ، أليس كذلك؟ و CBC ، للوهلة الأولى ، مع ناقل التهيئة العشوائي. لا يوجد رمز مصادقة (MAC). حسنًا ، لن يكون هناك أي حشوة أوراكل ، أليس كذلك؟
إن معرفة ما تعنيه محتويات DEK-Info حقًا ليس بهذه البساطة. يعرض البحث عن الكلمة الأساسية "DEK-Info" في مستودع opensh-portable أمثلة فقط على المفاتيح. لكن النقطة هنا هي أن مفتاح AES ليس أكثر من تجزئة MD5 بسيطة (كلمة مرور || ناقل التهيئة [: 8]). وهذا أمر سيئ ، لأن أفضل الممارسات لتخزين كلمات المرور تقول أن كلمات المرور في شكلها الخالص ، بسبب قلة انتروبيا ، هي مواد تشفير سيئة. ولجعلها أفضل ، تحتاج إلى وظيفة باهظة الثمن مثل Argon2. لكن MD5 ، على عكس الأخير ، سهل الحساب.
النقطة الإيجابية الوحيدة في هذا المخطط هي أن الملح يوضع بعد كلمة المرور ، وبالتالي ، لن يعمل على حساب الحالة المتوسطة MD5 (IV [8:]) والعثور على كلمات المرور بناءً عليها. ولكن هذا قليل من العزاء ، خاصة في عصر تتوفر فيه الآلات التي تقوم بإجراء مليارات مكالمات MD5 في الثانية - أكثر مما يمكن أن تأتي به كلمات المرور.
قد تتساءل كيف عاش OpenSSH لرؤية هذا. للأسف ، الجواب بسيط: استخدمت أداة سطر الأوامر OpenSSL هذا المخطط بشكل افتراضي في البداية ، وأصبحت ببساطة هي القاعدة.
في النهاية ، يصبح من الصحيح أن المفاتيح القياسية المشفرة بكلمة المرور ليست أفضل من المفاتيح غير المشفرة العادية ببساطة لأن آلية التشفير غير فعالة. ومع ذلك ، فإننا نتحدث أكثر جرأة - فهي أسوأ. ومن السهل القول.
من غير المحتمل أن يستخدم العديد من الأشخاص مدير كلمات المرور لتخزين كلمة المرور لمفتاح SSH. بدلاً من ذلك ، سيتذكره المستخدم ببساطة. وبما أن هذه إحدى المجموعات المحفوظة ، فمن المحتمل أن يكون المستخدم قد استخدمها بالفعل في مكان آخر. ربما يتطابق حتى مع كلمة مرور المستخدم من الجهاز. من الممكن جدًا تخمينها (وظيفتها التكوينية غير موثوقة جدًا) ، وإذا أصبحت كلمة المرور معروفة ، يمكنك التحقق منها باستخدام المفتاح العام.
لا توجد شكاوى حول زوج مفاتيح RSA نفسها: السؤال الوحيد هو طرق التشفير المتماثل للمفتاح الخاص. من المستحيل تنفيذ الهجوم الموصوف أعلاه ، مع معرفة المفتاح العام فقط.
كيف يمكنني إصلاح الموقف؟
يوفر OpenSSH تنسيق مفتاح جديد للاستخدام. بالمعنى الجديد الذي تم تقديمه في 2013. يستخدم هذا التنسيق bcrypt_pbkdf ، وهو في الأساس bcrypt ذات التعقيد الثابت الذي يتم تنفيذه بموجب معيار PBKDF2.
بشكل ملائم ، تتلقى تلقائيًا مفتاحًا بتنسيق جديد عند إنشاء مفاتيح Ed25519 ، لأن تنسيق مفتاح SSH القديم لا يدعم الأنواع الأحدث من المفاتيح. هذا غريب نوعًا ما ، لأننا في الحقيقة لا نحتاج حقًا إلى التنسيق الأساسي لتحديد كيفية عمل تسلسل Ed25519 ، نظرًا لأن Ed25519 نفسها تحدد عمل التسلسل. ولكن إذا كنت حقًا بحاجة إلى وظيفة تكوينية جيدة ، فلا يمكنك أن تهتم بمثل هذه التفاهات. نتيجة لذلك ، إحدى الإجابات هي
ssh-keygen -t ed25519 .
إذا كان عليك ، لأسباب التوافق ، الالتزام بـ RSA ، يمكنك استخدام ssh-keygen -o. وبالتالي ، يمكن الحصول على تنسيق جديد حتى للأنواع القديمة من المفاتيح. يمكنك تحديث المفاتيح القديمة باستخدام الأمر
ssh-keygen -p -o -f . إذا كانت مفاتيحك موجودة على Yubikey أو البطاقات الذكية ، فقد تم أخذ هذه التعديلات في الاعتبار بالفعل.
بطريقة أو بأخرى ، نسعى جاهدين من أجل خروج أفضل. من ناحية ، هناك مثال جيد على aws-vault ، حيث تم نقل معلومات الاعتماد من القرص إلى سلاسل المفاتيح. هناك نهج آخر: نقل التنمية إلى البيئات المشتركة. أخيرًا ، يجب أن تفكر معظم الشركات الناشئة في التخلي عن التخزين طويل المدى لمفاتيح SSH والانتقال إلى مركز شهادات SSH مع وقت تخزين رئيسي محدود مقترن بنظام تسجيل دخول واحد. لسوء الحظ ، في حالة GitHub هذا النهج غير ممكن.
ملاحظة : من الصعب التحقق من هذه المعلومات في مصدر موثوق ، ولكن إذا كانت الذاكرة تخدمنا جيدًا ، فإن المعلمة المُحدثة في المفاتيح الخاصة لتنسيق OpenSSH PEM تؤثر فقط على طريقة التشفير. ومع ذلك ، هذا لا يلعب أي دور: المشكلة هي وظيفة تشكيل المفتاح ، ونعتقد أن هذه حجة أخرى ضد مناقشة البروتوكولات في أجزاء. سيكون هناك منشور منفصل حول هذا الموضوع في مدونتنا.
وأخيرًا -
رابط إلى المفتاح الكامل. هذا في حال كنت على وشك اختراق أي شيء اليوم.
