1 คะแนน โดย GN⁺ 4 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เกิดการโจมตีแบบ supply chain หลังมีการแทรก คอมมิตอันตราย จำนวนมากเข้าไปใน AUR (Arch User Repository) เพื่อดัดแปลงให้รัน npm install atomic-lockfile ระหว่างขั้นตอนติดตั้งแพ็กเกจ
  • จากผลการค้นหาบนมิเรอร์แบบอ่านอย่างเดียว พบคำสั่งอันตรายเดียวกันในไฟล์ PKGBUILD, .install และ .hook ของ ราว 408 แพ็กเกจ
  • คอมมิตอันตรายใช้วิธี ปลอมแปลงคอมมิต โดย สวมชื่อและอีเมลของคอมมิตก่อนหน้า เพื่อแอบอ้างเป็นผู้ดูแลปกติ ซึ่งเป็นคนละประเด็นกับการถูกยึดบัญชี
  • ฝั่ง Arch กำลังดำเนินการ รีเซ็ตและลบคอมมิตอันตราย รวมถึง ระงับบัญชี ที่เกี่ยวข้อง และขอให้รายงานแพ็กเกจอันตรายเพิ่มเติมรวมไว้ในเธรดเดียว
  • สมาชิกคอมมูนิตี้กำลังช่วยกันรายงานคอมมิตของแต่ละแพ็กเกจอย่างต่อเนื่อง เป็นการ รับมือแบบร่วมมือกัน ต่อเหตุการณ์ขนาดใหญ่ที่กระทบระบบนิเวศแพ็กเกจ AUR ในวงกว้าง

ภาพรวมเหตุการณ์และคำขอความร่วมมือ

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

รูปแบบมัลแวร์ — atomic-lockfile

  • แพ็กเกจที่ถูกดัดแปลงมีจุดร่วมคือรัน npm install atomic-lockfile และตามด้วยชื่อแพ็กเกจ npm เพิ่มเติม เช่น ora, fast-glob, glob, minimist, axios, commander, execa, chalk, debug
  • ประเภทไฟล์ที่พบคำสั่งอันตราย
    • สคริปต์ติดตั้ง รูปแบบ *-deps.install
    • สคริปต์ติดตั้งแพ็กเกจ *.install
    • ไฟล์ *.hook — เช่นรูปแบบ Exec = /bin/sh -c 'cd /tmp && npm install atomic-lockfile ... 2>/dev/null; exit 0' ที่รันจาก /tmp แล้วซ่อนข้อผิดพลาดก่อนจบการทำงาน
    • บางรายการฝังอยู่ในไฟล์ที่เกี่ยวข้อง เช่น install.sh
  • มีรายงานแพ็กเกจอันตรายที่ถูกสร้างขึ้นใหม่คือ exodus-wallet-bin ซึ่งตรวจพบว่าเป็นแพ็กเกจใหม่ที่ถูกสร้างขึ้น ราว 4 ชั่วโมงก่อนหน้า นับจากคอมมิตแรก

วิธีตรวจจับและขอบเขตผลกระทบ

  • ตรวจจับด้วยการตรวจสอบมิเรอร์แบบอ่านอย่างเดียวโดยตรง
    • หลัง git clone https://github.com/archlinux/aur.git ให้ไล่ดูทุก ref แล้วรัน git grep 'atomic-lockfile'
    • ผลลัพธ์คือรายชื่อยาวของ ราว 408 แพ็กเกจ ที่ติดตั้ง atomic-lockfile ซึ่งสามารถนำไปใช้กับงาน cleanup แบบอัตโนมัติได้
  • ตัวอย่างแพ็กเกจที่ถูกกล่าวถึงว่าได้รับผลกระทบ
    • runescape-launcher, oracle-bin, tesseract-gui, python-starsessions, bitcoin-core-git, apple-music-desktop, exodus-wallet-bin, anythingllm-appimage, arm-linux-gnueabihf-binutils เป็นต้น
    • รวมถึงกลุ่มแพ็กเกจวงกว้างอย่าง cutefish-*, python2-*, python-*
  • เมื่อมีการรายงานแยกจำนวนมากจนเกิดอีเมลจำนวนมาก จึงมีการแนะนำให้ รวมหลายรายการไว้ในอีเมลฉบับเดียว และมีการแชร์รายการแพ็กเกจแบบรวมใน IRC แยกต่างหาก

วิธีแอบอ้าง/ปลอมแปลง

  • มีการตั้งข้อสงสัยกับแพ็กเกจที่เกี่ยวข้องกับบัญชีหนึ่ง (arojas) ว่าเป็น การยึดบัญชี หรือ การปลอมคอมมิต กันแน่
  • จากนั้นมีการยืนยันว่าคอมมิตอันตรายใช้วิธี แอบอ้างชื่อและอีเมลของคอมมิตก่อนหน้า (impersonate) — กล่าวคือเป็นการปลอมแปลง metadata ของคอมมิต
  • มีรายงานด้วยว่าแพ็กเกจอื่นของผู้ใช้รายเดียวกันบางส่วนถูกแก้ไขเรียบร้อยแล้ว

สถานะการรับมือ

  • คอมมิตของแพ็กเกจที่ถูกรายงานถูกทยอยจัดการ และบางรายการมีการตอบกลับว่า แก้ไขเสร็จแล้ว (Done)
  • เมื่อมีรายงานเพิ่มเติมเข้ามาอย่างต่อเนื่อง ผู้ประสานงานได้ตรวจสอบรายการที่รับเข้ามาเป็นชุด ควบคู่ไปกับการดำเนินการ ระงับบัญชีและรีเซ็ต ที่ยังดำเนินอยู่
  • มีผู้ร่วมหลายรายช่วยรายงานแต่ละแพ็กเกจพร้อมลิงก์คอมมิต เป็นการ รับมือเชิงร่วมมือที่ขับเคลื่อนโดยคอมมูนิตี้

1 ความคิดเห็น

 
GN⁺ 4 시간 전
ความคิดเห็นจาก Lobste.rs
  • เรื่องนี้น่าจะเป็นจุดจบของความเชื่อใจที่ยังหลงเหลืออยู่ต่อการมีส่วนร่วมแบบ ไม่ระบุตัวตนและไม่ผ่านการตรวจสอบ ในชุมชน
    ให้ความรู้สึกเหมือนกำลังดูความไว้วางใจถูกกัดกร่อนไปแบบเรียลไทม์

    • พูดตามตรงว่าเป็นเรื่องดี และก็ควรเกิดขึ้นตั้งนานแล้ว อุตสาหกรรมเราควรได้สติได้แล้ว
      เราฝาก ข้อมูลส่วนตัวและข้อมูลอ่อนไหว ไว้กับคอมพิวเตอร์มากเกินไป และมันก็กลายเป็นศูนย์กลางของชีวิตสมัยใหม่ไปแล้ว ถ้าคอมพิวเตอร์ส่วนตัวติดมัลแวร์ นั่นถือเป็นหายนะจริง ๆ และสิ่งที่หวังได้ดีที่สุดก็คือหวังว่าตัวเราไม่น่าสนใจพอที่แฮ็กเกอร์จะจงใจเล่นงานเป็นการเฉพาะ
      แต่ถึงอย่างนั้น เรากลับทำให้การรันโปรแกรมสุ่ม ๆ ด้วย สิทธิ์เต็มทั้งหมด กลายเป็นเรื่องปกติมาโดยตลอด[1] แล้วก็ยังทำเป็นแปลกใจทุกครั้งที่มันพิสูจน์ว่าเป็นความคิดที่แย่
      [1] หมายถึงในระดับสิทธิ์ของผู้ใช้ปัจจุบัน ในการตั้งค่าส่วนใหญ่ root แทบไม่มีความหมายในทางปฏิบัติ
    • KDE ได้ถอด AUR ออกจาก pipeline สำหรับการ build ของตัวเองไปแล้วเมื่อหนึ่งสัปดาห์ก่อน ซึ่งน่าจะเป็นการตอบสนองต่อเวอร์ชันก่อนหน้าของการโจมตีนี้
    • น่าสนใจถ้าจะใช้ โมเดลเว็บแห่งความเชื่อถือ กับการตรวจทานแพ็กเกจ AUR แล้วผูกเข้ากับระยะพักรอสำหรับอัปเดตล่าสุด
      ลองจินตนาการถึงระบบที่ให้ตัวเลือกแบบนี้ตอนติดตั้งหรืออัปเดตแพ็กเกจ AUR: ถ้าเป็นแพ็กเกจที่เพิ่งอัปเดต ก็รอให้เย็นลงสัก 1 สัปดาห์, ใช้เวลาสักไม่กี่นาทีตรวจทานแพ็กเกจด้วยตัวเองแล้วทิ้งรีวิวแบบลงลายเซ็นที่ผูกกับชื่อเสียงไว้, หรือพึ่งพารีวิวแบบลงลายเซ็นจากคนอื่นหลายคนที่มีความน่าเชื่อถือสะสมมากพอ
      ระยะพักรออาจไม่สอดคล้องในทางเทคนิคกับนโยบายของ Arch ที่พยายามให้ทุกแพ็กเกจอัปเดตล่าสุดไปพร้อมกัน แต่อย่างไรเสียแพ็กเกจ AUR ก็ไม่ได้อยู่ในขอบเขตการสนับสนุนอย่างเป็นทางการอยู่แล้ว
  • ผ่านมาหลายชั่วโมงแล้วแต่ แพ็กเกจ NPM นี้ยังไม่ถูกถอดออก: https://www.npmjs.com/package/atomic-lockfile

  • ถ้าต้องการตรวจสอบว่าแพ็กเกจที่ติดตั้งไว้ได้รับผลกระทบหรือไม่ สามารถใช้สคริปต์เล็ก ๆ นี้ร่วมกับไฟล์ aur_pkg_list.txt ได้

    installed_pkgs="$(yay -Qq)";  
    grep refs aur_pkg_list.txt | awk -F/ '{print $4}' | tr -d ')' \  
    | while read -r pkg; do \  
        echo "$installed_pkgs" | grep "^$pkg\$"; \  
    done  
    

    ใส่ semicolon ไว้แล้ว เลยแปลงเป็นคำสั่งบรรทัดเดียวได้ง่าย :-)

    • ดูเหมือนว่าจะไปจับแมตช์แบบ substring ด้วย เช่น ktea ก็ไปแมตช์กับ kteatime ด้วย
      เวอร์ชันนี้น่าจะใช้ได้

      grep refs aur_pkg_list.txt | awk -F/ '{print $4}' | tr -d ')' | while read -r pkg; do  
         echo "$installed_pkgs" | grep "^$pkg\$";  
      done  
      
  • มีความเป็นไปได้ว่าเรื่องนี้ดำเนินมาได้พักใหญ่แล้ว ดูจากอีเมลเมื่อ 18 วันก่อนฉบับนี้ เหมือนจะมีการใช้ payload อันตราย ที่คล้ายกัน แต่ดูเหมือนว่า malicious commit ถูกลบออกจาก repository ไปทั้งหมดแล้ว

  • ว่าแต่มีแหล่งข้อมูลที่เปรียบเทียบ ท่าทีด้านความปลอดภัยของซัพพลายเชน ของ Linux distribution ยอดนิยมต่าง ๆ ได้ดีไหม? บทความส่วนใหญ่ที่ผมหาเจอจนถึงตอนนี้ดูเหมือนเป็นการตลาดแฝง ๆ หรือไม่ก็ดูเหมือนบทความห่วย ๆ ที่ AI เขียนขึ้นมา อาจต้องลงมือหาข้อมูลเองจริง ๆ
    ส่วนที่น่าหดหู่คือ แม้จะชอบอุดมคติของการพัฒนาแบบชุมชน แต่เพราะความกังวลเรื่องซัพพลายเชน ก็กลับทำให้เริ่มมองตัวเลือกที่ปิดกว่า หรือแม้แต่ซอฟต์แวร์แบบ proprietary อย่างจริงจังมากขึ้น