Alibek Baxtiyorov

يوجد خطأ في أولوية العوامل الحسابية في أداة التحقق من صحة `cv.url()` داخل ملف `esphome/config validation.py`. ونظرًا لأن عامل `and` أكثر تقييدًا من عامل `or`، فإن أي عنوان URI من نوع `file:` يجتاز عملية التحقق من الصحة بغض النظر عن موقع الشبكة. تتحكم أداة التحقق هذه في حقل `url:` في مخطط مصدر git لتوجيه YAML الخاص بـ `external components`، والذي يتم تمريره لاحقًا إلى `git clone`. يمكن للمهاجم استخدام كتلة `external components` مصممة خصيصًا تحتوي على `url` يشير إلى مسار محلي، مثل `file:///attacker/repo`، لاستنساخ دليل محلي يسيطر عليه المهاجم. ثم يُضاف هذا الدليل إلى آلية الاستيراد في Python عبر محمل مكونات ESPHome، مما يسمح بتنفيذ تعليمات برمجية Python تعسفية عند معالجة تكوين YAML من خلال أوامر مثل `esphome config` أو `esphome run`.

يكشف مكون `web server` عن كلمات المرور بنص عادي. في الدالة `WebServer::text json ()`، يتم إخفاء حقل `state` في JSON للكيانات النصية التي تم تكوينها باستخدام `mode: password`، ولكن يتم كتابة كلمة المرور الخام في حقل `value` في JSON من خلال الدالتين `set json icon state value()` و`set json value()`. نظرًا لأن خادم الويب يستمع على المنفذ 80 دون مصادقة بشكل افتراضي، يمكن للمهاجم الموجود على الشبكة المحلية استرداد معلومات حساسة، مثل بيانات اعتماد شبكة WiFi أو رموز API، عبر نقطة النهاية `GET /text/<entity id>` أو دفق EventSource `/events`.

يوجد تجاوز في عدد الصحيح في تحليل بيانات تعريف مقطع W64 CUE. في الدالة `drwav metadata process chunk()`، يؤدي تقدير السعة في المرحلة الأولى إلى اقتطاع مقطع W64 ذي 64 بت `sizeInBytes` إلى `size t` قبل قسمته على `DRWAV CUE POINT BYTES`. في الإصدارات ذات 32 بت، يؤدي هذا الاقتطاع إلى حساب غير صحيح لسعة البيانات الوصفية الإضافية المخصصة مسبقًا. وبالتالي، تقوم الدالة `drwav read cue to metadata obj()` بحساب العدد الفعلي لنقاط التوجيه وحجم التخصيص باستخدام الحقل `cuePointCount` الذي يتحكم فيه المهاجم دون التحقق من مطابقته لتقدير السعة الأولي. ونظرًا لأن فرض الحدود في `drwav metadata get memory()` يعتمد على `DRWAV ASSERT` الذي يتم تعطيله في إصدارات البرامج النهائية، فإن ملف W64 WAV مصمم خصيصًا لهذا الغرض يمكنه إحداث تجاوز سعة مخزن الذاكرة المؤقتة (heap buffer overflow) في التطبيقات ذات 32 بت التي تقوم بتحليل بيانات تعريف WAV غير موثوق بها.

يفتقر المكون `BlobStorageController.cs` إلى السمة `[Authorize]` ولا يحتوي على سياسة تفويض عامة `FallbackPolicy` تم تكوينها في `Startup.cs`. وهذا يسمح للمهاجمين عن بُعد غير المصادق عليهم بالوصول إلى نقاط النهاية ”Upload“ و”Download“ و”List“ و”Modify“ و”Delete“. علاوة على ذلك، يتم استخدام المعلمتين `path` و`filename` اللتين يتم تمريرهما إلى نقاط النهاية هذه دون تعقيم في الدالة ` blob.WriteFileAsync()`. يؤدي هذا إلى اختراق المسار، مما يمكّن المهاجمين من قراءة وكتابة وتعديل وحذف ملفات عشوائية خارج دليل تخزين الكتل (blob) المقصود. إذا تم استهداف المسارات التي يمكن الوصول إليها عبر الويب، فيمكن استغلال ذلك لتنفيذ تعليمات برمجية عن بُعد من خلال تحميل برنامج ويب شيل (webshell).

يحتوي منفذ LINUXTCP في FreeModbus على خطأ في فحص حدود ”أكثر من واحد“ داخل الدالة `xMBPortTCPPool()` الموجودة في الملف `demo/LINUXTCP/port/porttcp.c`. تحدث المشكلة لأن الفحص `if (usTCPFrameBytesLeft > MB TCP BUF SIZE)` يستخدم مقارنة «أكبر من» صارمة بدلاً من «أكبر من أو يساوي» مقابل الحد الأقصى `MB TCP BUF SIZE` البالغ 263 بايت. يؤدي إطار MBAP (بروتوكول تطبيق Modbus) الذي يحتوي على حقل طول يبلغ 264 إلى أن تكون قيمة `usTCPFrameBytesLeft` هي 263، مما يؤدي إلى تجاوز الفحص. ونتيجة لذلك، تقوم الدالة `recv()` بكتابة ما يصل إلى 263 بايت بدءًا من إزاحة المخزن المؤقت 7 في المخزن المؤقت الثابت `aucTCPBuf` الذي تبلغ سعته 263 بايت، مما يتسبب في تجاوز سعة المخزن المؤقت بمقدار 7 بايت إلى المتغير الثابت المجاور `usTCPBufPos`. ويمكن إحداث ذلك بواسطة حزمة Modbus TCP واحدة مصممة خصيصًا وغير مصدقة.

يحتوي البرنامج على ثغرتين أمنيتين. أولاً، تقوم نقطة النهاية ’GET /json/cfg‘ باستدعاء الدالة `serveJson()` دون التحقق من رقم التعريف الشخصي (PIN) الخاص بالإعدادات، مما يسمح لأي عميل غير مصدق عليه على الشبكة بالاطلاع على تفاصيل التكوين العامة، بما في ذلك إعدادات الشبكة والأجهزة ومصابيح LED. ثانيًا، تتم إدارة حالة إلغاء قفل رقم التعريف الشخصي (PIN) الخاص بالإعدادات بواسطة متغير منطقي عالمي واحد هو `correctPIN` بدلاً من حالة خاصة بكل جلسة. ونتيجة لذلك، إذا قدم أي عميل رقم التعريف الشخصي (PIN) الصحيح المكون من 4 أرقام عبر نقطة النهاية ’POST /json‘، يتم تعيين المتغير `correctPIN` على القيمة ”صحيح“ (true) لجميع المستخدمين. وهذا يمنح جميع العملاء غير المصادق عليهم اللاحقين حق الوصول الكامل للكتابة إلى التكوين، مما يتيح إجراءات مثل تحديثات البرامج الثابتة عبر الهواء (OTA)، وإعادة تكوين شبكة WiFi، وإعادة الضبط إلى إعدادات المصنع حتى يتم إعادة تشغيل الجهاز.

تفشل الدالة `MochadTCP::MatchLine()` الموجودة في الملف `hardware/MochadTCP.cpp` في إجراء فحوصات الطول عند نسخ البيانات من `m mochadbuffer` (حتى 1028 بايت) إلى مخزن مؤقت ثابت سعة 50 بايت يُسمى `tempRFSECbuf` باستخدام `strcpy()`. يحدث هذا عبر ثلاثة فروع برمجية لأنواع الأجهزة DS10A و KR10A و MS10A. يمكن لمهاجم على الشبكة المحلية إرسال حزمة مصممة خصيصًا إلى جسر Mochad TCP على المنفذ 1099، الذي لا يتطلب أي مصادقة، لتسبب في تجاوز سعة `tempRFSECbuf` وإتلاف مكدس مؤشر ترابط الخيط العامل.

تقوم الدالة `tinyobj parse and index mtl file()` الموجودة في ملف `tinyobj loader c.h` بقراءة الأسطر من ملف مادة .mtl إلى مخزن مؤقت ثابت سعة 4096 بايت يسمى `linebuf` باستخدام `memcpy(linebuf, p, p len)`. يتم حماية هذه العملية بواسطة `assert(p len < 4095)`، ولكن نظرًا لأن `assert()` معطلة في إصدارات النشر (المُجمَّعة باستخدام -DNDEBUG)، فإن ملف .mtl مُصمم خصيصًا يحتوي على سطر يتجاوز 4096 بايت يمكن أن يتسبب في تجاوز سعة المكدس. وهذا يسمح لـ `linebuf` بالتجاوز إلى المتغير المجاور `namebuf` وذاكرة المكدس الأخرى، مما قد يؤدي إلى إتلاف مكدس التطبيقات التي تقوم بتحميل ملفات نماذج ثلاثية الأبعاد أو ملفات مواد ضارة. ويوجد هذا النمط نفسه في دالة أخرى داخل الملف نفسه.

تحتوي الدالتان `mtar write file header()` و`mtar write dir header()` في ملف `src/microtar.c` على ثغرة تتعلق بتجاوز سعة مخزن المكدس. يحدث هذا لأن اسم الإدخال المقدم من قبل المستدعي يتم نسخه إلى حقل `name` سعة 100 بايت في `mtar header t` المخصص في المكدس باستخدام `strcpy(h.name, name)` دون التحقق من أن طول متغير `name` أقل من 100 حرف. يمكن للتطبيقات التي تستخدم هذه الدوال لأرشفة أسماء ملفات يتحكم فيها مستخدمون خارجيون أو مهاجمون، والتي يزيد طولها عن 99 حرفًا، أن تتسبب في حدوث هذا الفائض.

تفشل الدالة `compile program()` الموجودة في ملف `webserver/openplc.py` في التحقق من صحة المتغير `file path` عند تحليل توجيهات `(*FILE:path content*)` الواردة في ملفات البرامج من نوع النص المنظم (.st) التي تم تحميلها. وهذا يسمح للمهاجم باستخدام تسلسلات اجتياز المسار لكتابة محتوى تعسفي إلى أي مسار في نظام الملفات خارج الدليل المقصود `./core`، مما يؤدي إلى تنفيذ التعليمات البرمجية عن بُعد من خلال آليات مثل مهام cron أو مفاتيح SSH المصرح بها. كما يحتوي البرنامج على بيانات اعتماد افتراضية مبرمجة بشكل ثابت (openplc:openplc)، مما يسهل الاستغلال.

تحتوي وحدة تخزين مكتبة نظام الملفات المحلي على ثغرة تتعلق باجتياز المسار في الدالتين `getLibraryEntry()` و`saveLibraryEntry()`. تحدث هذه المشكلة لأن معلمة المسار التي يزودها المستخدم يتم ضمها مباشرةً إلى مسار نظام الملفات عبر `fspath.join(libDir, type, path)` دون تنقية أو فحوصات احتواء أو تطبيع المسار. يمكن الوصول إلى الثغرة عبر نقاط النهاية GET و POST `/library/:lib/:type/*path`. يمكن للمستخدم المصادق عليه استخدام تسلسلات `../` لقراءة ملفات عشوائية خارج دليل المكتبة. يمكن للمستخدمين الذين يتمتعون بحق الوصول للكتابة إنشاء ملفات عشوائية، مما قد يؤدي إلى تنفيذ تعليمات برمجية عن بُعد من خلال حقن cron أو عن طريق تعديل ملف authorized keys في SSH.

تفتقر نقطة النهاية `POST /api/v1/convert/url/pdf` في ملف `ConvertWebsiteToPDF.java` إلى إجراءات الحماية من تزوير الطلبات من جانب الخادم (SSRF). ورغم أن نقطة النهاية تتحقق من أن عنوان URL الأولي يحيل إلى عنوان IP عام، إلا أنها تسترد ملف HTML وتمرره دون تنقية إلى عملية فرعية لـ WeasyPrint. وهذا يسمح للمهاجم باستخدام مراجع الموارد المضمنة، مثل علامات `<img>`، لإجبار الخادم على استرداد موارد الشبكة الداخلية أو نقاط نهاية بيانات التعريف السحابية وإدراج محتوياتها في ملف PDF الناتج.

يحدث عدم كفاية التحقق من صحة عناوين URL الخاصة بـ webhook في الدالة `isReservedIP()` الموجودة في `internal/webhook/validate.go`. تقوم الدالة بمقارنة عناوين IP المرشحة بقائمة CIDR المحجوزة، لكنها تتجاهل النطاق 0.0.0.0/8 وتفشل في استدعاء `ip.IsUnspecified()`. نظرًا لأن نظام Linux يعيد توجيه الاتصالات الموجهة إلى 0.0.0.0 إلى واجهة loopback (127.0.0.1)، يمكن للمهاجم تسجيل عنوان URL لـ webhook مثل ’http://0.0.0.0:PORT/‘ لتجاوز عمليات التحقق من عناوين IP المحجوزة. وهذا يسمح للخادم بإجراء طلبات HTTP صادرة إلى واجهة loopback الخاصة به، مما قد يؤدي إلى كشف الخدمات الداخلية فقط.

تقوم وظيفة إرسال webhook `safeDialContext()` (internal/webhook/webhook.go) بحل اسم المضيف المستهدف باستخدام `net.DefaultResolver.LookupHost` والتحقق من صحة عناوين IP الناتجة مقابل النطاقات المحجوزة. ومع ذلك، فإنها تستدعي لاحقًا `net.JoinHostPort(host, port)` باستخدام اسم المضيف الأصلي بدلاً من عنوان IP الذي تم التحقق من صحته. نظرًا لأن `net.Dialer.DialContext()` تقوم بعملية تحليل DNS الخاصة بها، يمكن للمهاجم الذي يتحكم في DNS الخاص باسم مضيف الويب هوك استخدام تقنية إعادة ربط DNS. من خلال استخدام مدة صلاحية قصيرة (TTL)، يمكن للمهاجم تقديم عنوان IP عام ومسموح به خلال مرحلة التحقق، وعنوان IP داخلي مختلف خلال مرحلة الاتصال الفعلية، متجاوزًا بذلك إجراءات الحماية من تزوير الطلبات من جانب الخادم (SSRF). إعادة ربط DNS هي تقنية تُستخدم لتجاوز الضوابط الأمنية عن طريق تغيير سجل DNS بين وقت التحقق ووقت الاستخدام.

تسمح نقطة النهاية ’/cfg wifi set‘ الموجودة في ’src/httpserver/http fns.c‘ بإجراء تغييرات في التكوين من خلال طلب GET دون الحاجة إلى رمز CSRF (تزوير الطلبات عبر المواقع). يُعد CSRF نوعًا من الهجمات التي تخدع الضحية لتقديم طلب ضار. إذا كان المعلمة `web admin password enabled` مفقودة من الطلب، يقوم النظام بمسح كلمة مرور مسؤول الويب، وتعيينها إلى سلسلة فارغة. وهذا يسمح للمهاجم باستخدام حمولة بنقرة واحدة لاختطاف تكوين شبكة WiFi وتعطيل الحماية بكلمة المرور إذا قام مسؤول معتمد بزيارة رابط ضار.

يفشل البرنامج في تنقية تسميات القنوات المستلمة عبر أمر MQTT SetChannelLabel في الدالة `CHANNEL SetLabel()` (src/cmnds/cmd channels.c). يتم تخزين هذه التسميات باستخدام `strdup()` ثم يتم إرجاعها دون تعقيم بواسطة `CHANNEL GetLabel()`. بعد ذلك، يتم عرض التسميات عبر `hprintf255()` في أكثر من 15 موقعًا في src/httpserver/http fns.c دون ترميز HTML. يمكن للمهاجم الذي لديه وصول إلى وسيط MQTT حقن حمولة `<script>` في تسمية قناة، والتي يتم تنفيذها عندما يعرض المستخدم لوحة الويب الخاصة بالجهاز. هذه مشكلة برمجة عبر المواقع (XSS) مخزنة، حيث يتم تخزين البرامج النصية الخبيثة بشكل دائم على الخادم المستهدف وتقديمها للمستخدمين الآخرين.

تفشل الدالة `http fn ota exec()` في `src/httpserver/http fns.c` في إجراء ترميز HTML عند معالجة معامل الاستعلام `host`. يسمح هذا بعكس المعامل مباشرة في استجابة HTML عبر الدالة `hprintf255()`. يمكن للمهاجم استخدام رابط مُعد خصيصاً يستهدف نقطة النهاية `/ota exec` لتنفيذ JavaScript تعسفي في متصفح مسؤول مصرح له.

تقوم واجهة برمجة تطبيقات (API) قارئات الرسائل بقراءة قيمة `format` من سلسلة استعلام HTTP في الملف `readers/api/http/transport.go` دون التحقق من صحتها. يتم إدراج هذه القيمة مباشرةً في استعلامات SQL الأولية باستخدام `fmt.Sprintf()` داخل قارئ PostgreSQL (`readers/postgres/messages.go`) وقارئ TimescaleDB (`readers/timescale/messages.go`). تسمح هذه الثغرة لمستخدم معتمد لديه أذونات للاستعلام عن رسائل القناة بتنفيذ حقن SQL، وهي تقنية يتم من خلالها إدراج عبارات SQL ضارة في حقول الإدخال لتنفيذها بواسطة قاعدة البيانات.

يفشل تنفيذ حارس الطلب `AuthToken` الموجود في `api/src/main.rs` في التحقق من صحة قيمة رأس HTTP `Authorization` مقابل جلسة عمل أو مخزن الرموز أو التوقيع. فهو يكتفي بالتحقق من وجود الرأس فقط. ونتيجة لذلك، يمكن لأي طلب يحتوي على رأس `Authorization` غير فارغ تجاوز آلية الحماية والوصول إلى جميع نقاط النهاية المحمية.

يمكن لمهاجم غير مصدق هويته تنفيذ تعليمات جافا سكريبت تعسفية في عملية الخادم عن طريق إنشاء قاعدة حسابية خبيثة وتشغيلها. تفتقر نقطة النهاية ’POST /calc-rule/create‘ إلى حارس الطلب AuthToken، مما يسمح بالوصول دون مصادقة لإنشاء قاعدة تحتوي على حقل `script` تعسفي. يتم بعد ذلك تنفيذ هذا البرنامج النصي المخزن عبر الدالة `quick js::Context::eval()` دون عزل في بيئة آمنة.