ความหงุดหงิดของฉันหมดเวลาเพราะมันเพิ่งเกิดขึ้นอีกครั้ง หากคุณได้อ่านบทวิเคราะห์ก่อนหน้าของฉันที่ชื่อว่าCVE-2022–29622: (In)vulnerability Analysisคุณอาจสงสัยว่าฉันหมายถึงอะไร เรื่องเดียวกัน เหยื่อต่างกัน อย่างไรก็ตาม วันที่มีความสำคัญในกรณีนี้ การวิเคราะห์ความคงกระพันก่อนหน้านี้ของฉันมาจากปี 2022 วันนี้ฉันจะวิเคราะห์ปัญหาอื่นจากปี 2018

คุณอาจถามว่า: “ทำไมคุณต้องจัดการกับบางอย่างในปี 2018” คำถามที่ยอดเยี่ยม! เนื่องจากฉันเพิ่งเปิดใช้ Dependency Track เพื่อดึงข้อมูลช่องโหว่จากดัชนี OSS ของ Sonatype

วันนี้ ขณะที่ฉันกำลังอ่านผ่านSCAเพื่อดูว่าเรามีส่วนประกอบใดที่เสี่ยงหรือไม่ และหากมี ให้จัดลำดับความสำคัญของงานแก้ไข ฉันเจอสิ่งที่น่าประหลาดใจมาก Koa.JSมีช่องโหว่ร้ายแรง?! หลังจากที่ฉันเคย “#FFS ทั้งสัปดาห์ต้องจัดใหม่” ฉันก็แบบว่า “หายใจเข้าลึกๆ แล้วดูว่ามันเกี่ยวกับอะไร คุณจำได้ว่าเกิดอะไรขึ้นครั้งสุดท้าย…”

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

เรารู้/เห็นอะไร ณ จุดนี้?

1. ถูกกล่าวหาว่ามีช่องโหว่ใน Koa ในปี 2018 โดยมีการกำหนดระดับความรุนแรงวิกฤต
2. ตามดัชนี Sonatype OSS และการติดตามการพึ่งพา ปัญหาส่งผลกระทบต่อฉันในปี 2565 ขณะใช้งาน Koa เวอร์ชันล่าสุด

• ไลบรารี Koa.JS เวอร์ชันใดที่ได้รับผลกระทบจาก "ช่องโหว่"
• หากมี "ช่องโหว่" ใน Koa.JS ล่าสุด

การวิเคราะห์ปัญหา

มาดูกันว่า “ช่องโหว่” คืออะไร/มีที่มาอย่างไร ให้ฉันเชื่อมโยงปัญหาที่เกี่ยวข้อง#1250 จาก GitHubที่นี่อย่างรวดเร็ว ฉันจะคัดลอกและวางตัวอย่าง (PoC?) ด้านล่างเพื่อให้เราสามารถวิเคราะห์ได้

const Koa = require('koa');
const app = new Koa();

app.use(async ctx => {
  ctx.redirect("javascript:alert(1);")
});

app.listen(3000);

“ในฐานะผู้พัฒนาเว็บแอปพลิเคชันหรือบริการบนเว็บ ฉันสามารถเปลี่ยนเส้นทางเบราว์เซอร์ของคุณไปยังที่ใดก็ได้ที่ฉันต้องการหากคุณเยี่ยมชมเว็บไซต์ของฉัน”

นั่นคือความหมายของรหัสข้างต้น ใน PoC ข้างต้นไม่มีเวกเตอร์การโจมตีสำหรับนักแสดงที่เป็นอันตรายเพื่อใช้ประโยชน์จากสิ่งใดๆ

หากคุณต้องการให้ “PoC” ที่เหมาะสมสำหรับช่องโหว่นี้ (ใช่แล้ว ฉันเพิ่งพูดไป) มันจะมีลักษณะดังนี้:

const Koa = require('koa');
const app = new Koa();
// Try: http://localhost:3000/?vector=javascript:alert(1);
app.use(async ctx => {
  ctx.redirect(ctx.request.query.vector);
});

app.listen(3000);

เมื่อพูดถึงช่องโหว่ XSS หากอะไรก็ตามที่ฉันป้อนเป็นค่าของvectorพารามิเตอร์แสดงในบริบท HTML อย่างไม่ปลอดภัย แอปพลิเคชันที่ฉันนำมาใช้จะมีความเสี่ยงต่อ Cross Site Scripting (เพิ่มเติมในภายหลัง)

ขยายดูว่า Sonatype นำเสนอสิ่งนี้อย่างไรและวิเคราะห์เพิ่มเติมอีกเล็กน้อย:

“การเปลี่ยนเส้นทางแบบเปิดที่นำไปสู่การเขียนสคริปต์ข้ามไซต์”? ประการแรก ไม่มีการเปลี่ยนเส้นทางแบบเปิด มันจะเปิดก็ต่อเมื่อคุณเปิดมัน และความแตกต่างระหว่าง PoC สองตัว (ตัวเดิมและตัวของผม) แสดงให้เห็นอย่างชัดเจน ในอันแรก ไม่มีเวกเตอร์โจมตี ดังนั้นจึงไม่มีการเปลี่ยนเส้นทางแบบเปิด PoC ของฉันมีเวกเตอร์การโจมตี ไม่มีการกรอง ดังนั้นจึงมีการเปลี่ยนเส้นทางแบบเปิด แต่อย่างที่คุณเห็น ไม่ว่าจะมีหรือไม่มีการเปลี่ยนเส้นทางแบบเปิดนั้นขึ้นอยู่กับฉัน ผู้พัฒนา ไม่ใช่ Koa.JS ยิ่งไปกว่านั้น ไม่ว่าจะมีการเปลี่ยนเส้นทางหรือไม่ก็ขึ้นอยู่กับฉันด้วย ฉันจะรวมอินพุตที่ผู้ใช้ให้ไว้เป็น/ใน URL เปลี่ยนเส้นทางด้วยวิธีที่ไม่ปลอดภัยหรือไม่นั้นขึ้นอยู่กับฉันด้วย เรากำลังพูดถึงช่องโหว่ Koa.JS อะไร ในทางเทคนิคแล้ว ไม่มีช่องโหว่และบางคนยังคงกำหนดระดับความรุนแรงวิกฤตให้กับช่องโหว่นั้น ไม่เป็นมืออาชีพอย่างแน่นอน

อย่างไรก็ตาม มา "ใช้ประโยชน์" ที่กล่าวว่า "ช่องโหว่" ที่ดำเนินการโดย PoC ที่เหมาะสม โปรดทราบว่าฉันต้องเปลี่ยนพอร์ตบริการจาก 3000 เป็น 4444 เนื่องจากฉันมีบางอย่างฟังอยู่ที่พอร์ต 3000

เราสามารถเห็น ส่วนหัวการตอบสนอง มีLocationค่า javascript:alert(1)จากนั้นเบราว์เซอร์เปลี่ยนเส้นทางไปที่...

หึ ฉันปลอดภัยแล้ว! ไม่มีกล่องแจ้งเตือนโผล่ขึ้นมา ใช่ ฉันสามารถป้อนhttps://google.comเป็นค่าของvectorพารามิเตอร์การค้นหาและถูกเปลี่ยนเส้นทางไปยัง Google ดังนั้นแอปพลิเคชันของฉัน (PoC)จึงเสี่ยงต่อการเปิดการเปลี่ยนเส้นทาง แต่ไม่ใช่เพราะ Koa แต่เป็นเพราะฉันส่งข้อมูลผู้ใช้ที่ไม่กรองไปctx.redirectยัง ไม่ใช่เรื่องที่ฉันกังวล ฉันจะไม่ทำแบบนี้

สิ่งสำคัญที่ควรทราบจากความคิดเห็นเกี่ยวกับปัญหาใน GitHub คือ:

ปัญหาเกิดจากการที่ Koa พิมพ์ไฮเปอร์ลิงก์ HTML ในส่วนเนื้อหาของการตอบสนองการเปลี่ยนเส้นทาง และนั่นสามารถกระตุ้นการโจมตีแบบสคริปต์ข้ามไซต์ได้

อ่า เข้าท่ากว่านี้หน่อย! มาดูกันว่ายังเป็นอยู่ไหม

ไม่ มันไม่ใช่อย่างนั้นอีกต่อไปแล้ว ไม่มีเนื้อหาตอบกลับ ฉันเดาว่าฉันสามารถสรุปได้ว่า "ช่องโหว่" นี้ไม่ส่งผลกระทบต่อฉัน ฉันสามารถไปและทำเครื่องหมายว่าเป็นผลบวกลวงในการติดตามการพึ่งพา

การวิเคราะห์บริบท

ฉันเสนอ "การวิเคราะห์บริบท" เพื่อให้ผู้เชี่ยวชาญด้านความปลอดภัยทุกคนนำไปใช้และดำเนินการก่อนที่จะรายงาน "ปัญหา" ให้นี่เป็นอีกตัวอย่างหนึ่งและแสดงให้คุณเห็นว่ามันเสร็จสิ้นอย่างไร (ฉันยังคงแนะนำให้คุณอ่านCVE-2022–29622: (In)vulnerability Analysisแม้ว่ามันจะอธิบายถึงความสำคัญของบริบทได้ดีกว่ามาก)

1. Koa.JS แบบสำเร็จรูปจะไม่เปลี่ยนเส้นทางคุณไปที่ใดก็ได้ ดังนั้นจึงมีและไม่มี “Open Redirect” ตามที่ระบุไว้โดย Sonatype OSS Index
2. จาก "PoC" ที่มอบให้บน GitHub มีโอกาสสำหรับนักพัฒนาที่จะทำสิ่งโง่ๆ ที่อาจนำไปสู่ ​​XSS แต่ดู #1 ด้านบน Koa.JS ไม่ได้ทำการเปลี่ยนเส้นทางด้วยตัวเอง ดู #2 ด้านล่าง
3. นักพัฒนาซอฟต์แวร์ต้องติดตั้งแอปพลิเคชันของตนด้วยวิธีที่ไม่ปลอดภัยเพื่อให้มี "ช่องโหว่" ที่รายงานอยู่ นี่ค่อนข้างหมายความว่า Koa.JS แม้ว่าจะทำได้ดีกว่านี้ แต่คุณไม่สามารถเรียกมันว่าเสี่ยงได้ มันไม่เหมาะสมทางบริบท ช่องโหว่ดังกล่าวอาจปรากฏอยู่ในเว็บแอปพลิเคชันที่ไม่ปลอดภัยเท่านั้น

ผมขอยกตัวอย่างวิธีจัดการกับสถานการณ์เช่นนี้ให้ดีที่สุด ดูปัญหานี้ที่ฉันส่งไปยัง Swagger Parser และวิธีการสื่อสาร มาวิเคราะห์รายงานปัญหากัน:

1. ชื่อเรื่องระบุว่า “พฤติกรรม Resolver ที่ไม่ปลอดภัย” ฉันไม่ได้พูดถึง LFI (การรวมไฟล์ในเครื่อง) ในชื่อเรื่อง นี่เป็นเพราะแม้ว่าจะมีความเป็นไปได้ที่จะมีการรวมไฟล์ในเครื่องหากฉันยุ่ง เกี่ยว กับเรื่องนี้ แต่ในฐานะนักพัฒนาก็ขึ้นอยู่กับฉันจริงๆ ที่จะรู้ว่าฉันทำงานด้วยอะไรและทำงานอย่างไร พฤติกรรมเริ่มต้นคือ (อาจจะยังไม่ปลอดภัย) แต่ห้องสมุดด้วยตัวมันเองโดยปราศจากการมีส่วนร่วมของฉันจะไม่ทำอะไรเลย
2. จากนั้น ฉันระบุเวอร์ชันของไลบรารีที่ฉันพูดถึงอย่างชัดเจน ฉันทำให้บริบทชัดเจนยิ่งขึ้นโดยระบุเงื่อนไขที่พฤติกรรมเริ่มต้นที่ไม่ปลอดภัยของไลบรารีจะส่งผลต่อแอปพลิเคชัน สิ่งนี้ทำให้ชัดเจนว่าห้องสมุดเองไม่มีช่องโหว่ แต่มีพฤติกรรมที่ไม่ปลอดภัยซึ่งสามารถปรับปรุงได้เพื่อช่วยนักพัฒนา
3. เมื่อตั้งค่าบริบทแล้ว ฉันจึงจัดเตรียม PoC ที่ใช้งานได้ ข้อมูลโค้ดที่มีช่องโหว่ (ที่ฉันเขียนเป็น PoC ไม่ใช่ส่วนหนึ่งของ Swagger Parser!) และผลลัพธ์ที่แท้จริงของการใช้ประโยชน์จากแอป/บริการที่มีช่องโหว่ซึ่งใช้ ห้องสมุดอย่างไม่ปลอดภัย
4. ฉันได้ตรวจสอบและพบว่าในฐานะนักพัฒนา ฉันสามารถกำหนดค่าไลบรารีในลักษณะที่ช่วยลดปัญหาได้ (ในระดับหนึ่ง) ฉันแบ่งปันสิ่งนี้กับผู้พัฒนา หากไม่มีสิ่งใด อย่างน้อยพวกเขาก็สามารถอัปเดตเอกสารประกอบเพื่อสร้างความตระหนักได้
5. ฉันได้ให้บริบทเพิ่มเติม การวิเคราะห์ และตัวอย่างว่าควรปรับปรุงสิ่งต่างๆ อย่างไร

บทสรุป

ก่อนอื่น Sonatype ควรทำดัชนี OSS ให้ดียิ่งขึ้น และตรวจสอบให้แน่ใจว่ามีข้อมูลเวอร์ชันสำหรับช่องโหว่แต่ละรายการในฐานข้อมูล นั่นคือขั้นต่ำเปล่า (คะแนนโบนัสสำหรับการลบรายการเฉพาะนี้ออกจากฐานข้อมูลทั้งหมด)

ฉันสงสัยว่า Dependency Track ได้รับผลกระทบจาก FOMO ดังนั้นจึงยินดีที่จะรายงานปัญหาตามชื่อส่วนประกอบที่ตรงกันหากไม่มีหมายเลขเวอร์ชัน ฉันเข้าใจในระดับหนึ่งว่าพวกเขาจะไม่เสี่ยงต่อการพลาดช่องโหว่ที่สำคัญ ปัญหาเกี่ยวกับพฤติกรรมนี้ (ผลบวกลวง) คือไม่สนับสนุนการนำการวิเคราะห์องค์ประกอบของซอฟต์แวร์มาใช้ มันจะทำให้นักพัฒนากลัวเหมือนผลบวกปลอมของการวิเคราะห์รหัสคงที่ ต่อต้าน

บริบท! บริบทเลือดผู้คน! ฉันเสนอ:

1. “การวิเคราะห์บริบท” ที่ผู้เชี่ยวชาญด้านความปลอดภัยทุกคนนำมาใช้และดำเนินการก่อนที่จะรายงาน “ปัญหา”
2. แยกแยะ “พฤติกรรมที่ไม่ปลอดภัย” ออกจาก “ความเปราะบาง”
3. ทำความเข้าใจความแตกต่างระหว่างไลบรารีซอฟต์แวร์และแอปพลิเคชัน/บริการ