การโจมตีแหล่งที่มาของโทรจันเพื่อแนะนำการเปลี่ยนแปลงรหัสที่นักพัฒนามองไม่เห็น

นักวิจัยจากมหาวิทยาลัยเคมบริดจ์ได้เผยแพร่เทคนิคในการแทรกโค้ดที่เป็นอันตรายลงในซอร์สโค้ดที่ได้รับการตรวจสอบโดยผู้ทรงคุณวุฒิ วิธีการโจมตีที่เตรียมไว้ (CVE-2021-42574) นำเสนอภายใต้ชื่อ Trojan Source และขึ้นอยู่กับรูปแบบของข้อความที่ดูแตกต่างออกไปสำหรับคอมไพเลอร์/ล่าม และบุคคลที่ดูโค้ด ตัวอย่างของวิธีการนี้แสดงให้เห็นสำหรับคอมไพเลอร์และล่ามต่างๆ ที่จัดหาให้กับ C, C++ (gcc และ clang), C#, JavaScript (Node.js), Java (OpenJDK 16), Rust, Go และ Python

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

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

ในขณะที่ตรวจสอบโค้ด นักพัฒนาจะต้องเผชิญกับลำดับภาพของอักขระ และจะเห็นความคิดเห็นที่ไม่น่าสงสัยในโปรแกรมแก้ไขข้อความ เว็บอินเทอร์เฟซ หรือ IDE สมัยใหม่ แต่คอมไพเลอร์และล่ามจะใช้ลำดับเชิงตรรกะของอักขระ และจะ ประมวลผลการแทรกที่เป็นอันตรายตามที่เป็นอยู่ โดยไม่ต้องสนใจข้อความแบบสองทิศทางในความคิดเห็น ปัญหานี้ส่งผลกระทบต่อโปรแกรมแก้ไขโค้ดยอดนิยมต่างๆ (VS Code, Emacs, Atom) รวมถึงอินเทอร์เฟซสำหรับการดูโค้ดในที่เก็บ (GitHub, Gitlab, BitBucket และผลิตภัณฑ์ Atlassian ทั้งหมด)

มีหลายวิธีในการใช้วิธีการดำเนินการที่เป็นอันตราย: การเพิ่มนิพจน์ "return" ที่ซ่อนอยู่ซึ่งนำไปสู่การทำงานให้เสร็จสิ้นล่วงหน้า การใส่ความคิดเห็นเกี่ยวกับนิพจน์ที่ปกติจะมองเห็นได้ว่าเป็นโครงสร้างที่ถูกต้อง (เช่น เพื่อปิดใช้งานการตรวจสอบที่สำคัญ) การกำหนดค่าสตริงอื่น ๆ ที่นำไปสู่ความล้มเหลวในการตรวจสอบสตริง

ตัวอย่างเช่น ผู้โจมตีอาจเสนอการเปลี่ยนแปลงที่มีบรรทัด: if access_level != "user{U+202E} {U+2066}// ตรวจสอบว่า admin{U+2069} {U+2066}" {

ซึ่งจะแสดงในอินเทอร์เฟซการตรวจสอบเหมือนกับว่า access_level != “user” { // ตรวจสอบว่าเป็นผู้ดูแลระบบ

นอกจากนี้ ยังมีการเสนอรูปแบบการโจมตีอื่น (CVE-2021-42694) ที่เกี่ยวข้องกับการใช้โฮโมกลิฟฟิก ซึ่งเป็นอักขระที่มีลักษณะคล้ายกัน แต่มีความหมายต่างกันและมีรหัสยูนิโค้ดที่แตกต่างกัน (เช่น อักขระ “ɑ” มีลักษณะคล้ายกับ “ ก”, “ɡ” - “ก”, “ɩ” - “ล”) อักขระที่คล้ายกันสามารถใช้ได้ในบางภาษาในชื่อฟังก์ชันและตัวแปรเพื่อทำให้นักพัฒนาเข้าใจผิด ตัวอย่างเช่น อาจมีการกำหนดฟังก์ชันสองฟังก์ชันที่มีชื่อแยกไม่ออกซึ่งดำเนินการต่างกัน หากไม่มีการวิเคราะห์โดยละเอียด ก็ไม่ชัดเจนในทันทีว่าฟังก์ชันใดในสองฟังก์ชันนี้ถูกเรียกในตำแหน่งใดตำแหน่งหนึ่งโดยเฉพาะ

เพื่อเป็นมาตรการรักษาความปลอดภัย ขอแนะนำให้คอมไพเลอร์ ล่าม และเครื่องมือแอสเซมบลีที่รองรับอักขระ Unicode แสดงข้อผิดพลาดหรือคำเตือนหากมีอักขระควบคุมที่ไม่ได้จับคู่ในความคิดเห็น ตัวอักษรสตริง หรือตัวระบุที่เปลี่ยนทิศทางของเอาต์พุต (U+202A, U+202B, U +202C, U+202D, U+202E, U+2066, U+2067, U+2068, U+2069, U+061C, U+200E และ U+200F) อักขระดังกล่าวควรไม่ได้รับอนุญาตอย่างชัดเจนในข้อกำหนดภาษาการเขียนโปรแกรม และควรเคารพในตัวแก้ไขโค้ดและอินเทอร์เฟซของพื้นที่เก็บข้อมูล

ภาคผนวก 1: มีการจัดเตรียมแพตช์ช่องโหว่สำหรับ GCC, LLVM/Clang, Rust, Go, Python และ binutils GitHub, Bitbucket และ Jira ก็แก้ไขปัญหาเช่นกัน อยู่ระหว่างการแก้ไขสำหรับ GitLab เพื่อระบุรหัสที่มีปัญหา ขอแนะนำให้ใช้คำสั่ง: grep -r $'[\u061C\u200E\u200F\u202A\u202B\u202C\u202D\u202E\u2066\u2067\u2068\u2069]' /path/to/ แหล่งที่มา

ภาคผนวก 2: Russ Cox หนึ่งในผู้พัฒนาระบบปฏิบัติการ Plan 9 และภาษาโปรแกรม Go วิพากษ์วิจารณ์การให้ความสนใจมากเกินไปต่อวิธีการโจมตีที่อธิบายไว้ ซึ่งเป็นที่รู้จักมานานแล้ว (Go, Rust, C++, Ruby) และไม่ได้ดำเนินการอย่างจริงจัง . ตามข้อมูลของ Cox ปัญหาส่วนใหญ่เกี่ยวข้องกับการแสดงข้อมูลที่ถูกต้องในตัวแก้ไขโค้ดและอินเทอร์เฟซเว็บ ซึ่งสามารถแก้ไขได้โดยใช้เครื่องมือและเครื่องวิเคราะห์โค้ดที่ถูกต้องในระหว่างการตรวจสอบ ดังนั้น แทนที่จะดึงดูดความสนใจไปที่การโจมตีแบบเก็งกำไร เป็นการเหมาะสมกว่าที่จะมุ่งเน้นไปที่การปรับปรุงโค้ดและกระบวนการตรวจสอบการพึ่งพา

Ras Cox ยังเชื่อด้วยว่าคอมไพเลอร์ไม่ใช่ตำแหน่งที่ถูกต้องในการแก้ไขปัญหา เนื่องจากการแบนสัญลักษณ์อันตรายในระดับคอมไพเลอร์ ยังคงมีเครื่องมือจำนวนมากที่การใช้สัญลักษณ์เหล่านี้ยังคงเป็นที่ยอมรับ เช่น ระบบการสร้าง แอสเซมเบลอร์ ผู้จัดการแพ็คเกจและตัวแยกวิเคราะห์การกำหนดค่าและข้อมูลต่างๆ ตามตัวอย่าง มีการให้โปรเจ็กต์ Rust ซึ่งห้ามการประมวลผลโค้ด LTR/RTL ในคอมไพเลอร์ แต่ไม่ได้เพิ่มการแก้ไขให้กับตัวจัดการแพ็คเกจ Cargo ซึ่งอนุญาตให้มีการโจมตีที่คล้ายกันผ่านไฟล์ Cargo.toml ในทำนองเดียวกัน ไฟล์ต่างๆ เช่น BUILD.bazel, CMakefile, Cargo.toml, Dockerfile, GNUmakefile, Makefile, go.mod, package.json, pom.xml และ needs.txt อาจกลายเป็นแหล่งที่มาของการโจมตีได้

ที่มา: opennet.ru