การกลับมาของ Shai-Hulud: แพ็กเกจ NPM ติดมัลแวร์กว่า 300 รายการ

 (helixguard.ai)
17 คะแนน โดย GN⁺ 2025-11-25 | 5 ความคิดเห็น | แชร์ทาง WhatsApp
  • มี คอมโพเนนต์มากกว่า 1,000 รายการ ใน NPM registry ถูกฝังการติดเชื้อด้วยวิธีเดียวกันภายในไม่กี่ชั่วโมง และมีการเผยแพร่เวอร์ชันใหม่ที่แฝงโค้ดอันตราย
  • แพ็กเกจอันตรายปลอมตัวเป็น สคริปต์ติดตั้ง Bun runtime โดยเพิ่ม setup_bun.js และ bun_environment.js ที่ถูกทำให้อ่านยาก เมื่อรันจะใช้ TruffleHog เพื่อขโมยข้อมูลรับรองในเครื่อง
  • ข้อมูลอ่อนไหวที่เก็บได้ เช่น โทเค็น AWS/GCP/Azure·GitHub·NPM ถูกส่งออกไปภายนอกผ่าน GitHub Action runner ชื่อ SHA1HULUD
  • สคริปต์อันตรายรัน npm publish แบบอัตโนมัติเพื่อ จำลองตัวเองในรูปแบบเวิร์ม ส่งผลให้มี GitHub repository มากกว่า 27,000 แห่ง ติดเชื้อ
  • เหตุการณ์นี้ถูกประเมินว่าเป็นกรณีที่ตอกย้ำ ภัยคุกคามด้านความปลอดภัยของซัพพลายเชน ต่อระบบนิเวศโอเพนซอร์สอีกครั้ง

ภาพรวมการโจมตี

  • วันที่ 24 พฤศจิกายน 2025 HelixGuard ตรวจพบว่า แพ็กเกจกว่า 1,000 รายการ ใน NPM registry ถูกฝังการติดเชื้อด้วยวิธีเดียวกันภายในไม่กี่ชั่วโมง
    • เวอร์ชันใหม่เหล่านี้ปลอมตัวเหมือนเพิ่ม Bun runtime และมีสคริปต์ preinstall: node setup_bun.js
    • ไฟล์ bun_environment.js ที่แจกมาด้วยเป็นโค้ดอันตรายแบบ obfuscated ซึ่งเมื่อรันจะดาวน์โหลดและเรียกใช้ TruffleHog
  • TruffleHog จะสแกนและขโมย โทเค็น NPM, ข้อมูลรับรอง AWS/GCP/Azure, ตัวแปรสภาพแวดล้อม จากเครื่องโลคัล
  • ข้อมูลที่ขโมยมาได้จะถูกส่งออกผ่านการสร้าง GitHub Action runner SHA1HULUD และผ่าน GitHub repository ที่มีคำอธิบายว่า Sha1-Hulud: The Second Coming.
  • HelixGuard ชี้ว่าการโจมตีนี้อาจเป็นฝีมือผู้โจมตีรายเดียวกับเหตุการณ์ “Shai-Hulud” เมื่อเดือนกันยายน 2025

การวิเคราะห์การทำงานของโค้ดอันตราย

  • จากการวิเคราะห์แพ็กเกจ @asyncapi/specs เป็นตัวอย่าง พบว่าเวอร์ชันที่เผยแพร่บน NPM ติดเชื้อ แต่ repository ต้นทางบน GitHub ยังปลอดภัย
  • ผู้โจมตีแก้ไข package.json เพื่อเพิ่ม setup_bun.js และตั้งให้สคริปต์ดังกล่าวเรียก bun_environment.js
  • bun_environment.js เป็น ไฟล์ JavaScript ที่ถูก obfuscate อย่างหนัก ขนาดมากกว่า 10MB โดยมีความสามารถหลักดังนี้
    • เก็บ ข้อมูลรับรองคลาวด์และโทเค็น จากตัวแปรสภาพแวดล้อม
    • สแกนหาคีย์ลับด้วย TruffleHog
    • ส่งข้อมูลออกผ่าน GitHub Actions
  • นอกจากนี้ยังแก้ไข package.json เพื่อแทรกโค้ดติดเชื้อ และรัน npm publish อัตโนมัติเพื่อ แพร่กระจายในรูปแบบเวิร์ม
โฆษณา

การติดเชื้อบน GitHub และการส่งข้อมูลออก

  • สคริปต์อันตรายสร้างไฟล์ .github/workflows/formatter_123456789.yml และลงทะเบียน runner SHA1HULUD
  • เวิร์กโฟลว์ดังกล่าวจะจัดแพ็กข้อมูลลับของ repository เป็นไฟล์ actionsSecrets.json ที่ เข้ารหัส Base64 สองชั้น
  • จากนั้นจะสร้าง GitHub repository ชื่อสุ่มที่มีคำอธิบาย Sha1-Hulud: The Second Coming. เพื่ออัปโหลดข้อมูล
  • HelixGuard ยืนยันว่ามี GitHub repository มากกว่า 27,000 แห่ง ติดเชื้อ
  • ข้อมูลลับที่ถูกขโมยมีข้อมูลรับรองของบริการหลากหลาย เช่น AWS_ACCESS_KEY_ID, SLACK_WEBHOOK_URL, CODECOV_TOKEN, WEBFLOW_TOKEN

รายชื่อแพ็กเกจที่ติดเชื้อ

  • HelixGuard รายงานว่ามี แพ็กเกจ NPM หลายร้อยรายการ ติดเชื้อ
    • ตัวอย่างสำคัญได้แก่แพ็กเกจจากองค์กรอย่าง @asyncapi, @ensdomains, @posthog, @zapier, @postman, @voiceflow
    • แต่ละแพ็กเกจมีหลายเวอร์ชันที่ติดเชื้อ เช่น @asyncapi/specs@6.8.2, @postman/csv-parse@4.0.5
  • แพ็กเกจที่ติดเชื้อส่วนใหญ่ปลอมตัวเป็นโปรเจกต์โอเพนซอร์สปกติ และอยู่ในลักษณะ ถูกแทรกโค้ดอันตรายในกระบวนการ deploy อัตโนมัติ

นัยสำคัญด้านความปลอดภัย

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

บทความที่เกี่ยวข้อง

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

 
ahwjdekf 2025-11-27

ระบบนิเวศ js นี่เป็นกองขยะเละเทะจริง ๆ นั่นแหละ
 
developerjhp 2025-11-25

ผมได้ลองทำสคริปต์สแกนแบบเรียลไทม์ขึ้นมาครับ

ที่ path ของรีโพซิทอรีที่น่าสงสัย
npx sha1-hulud-scanner
ให้พิมพ์คำสั่งนี้ได้เลยครับ

ซอร์สโค้ด : https://github.com/developerjhp/sha1-hulud-scanner
 
GN⁺ 2025-11-25
ความคิดเห็นจาก Hacker News

  • ขอแชร์ทิปอย่างหนึ่ง: ควรใช้ PNPM แทน NPM
    PNPM 10.x บล็อกช่องทางโจมตีได้หลายแบบ
    1️⃣ โดยค่าเริ่มต้นจะไม่รันสคริปต์ post-install และต้องอนุมัติด้วยตนเอง
    2️⃣ สามารถตั้งให้ติดตั้งได้ต่อเมื่อผ่านไประยะหนึ่งหลังจากปล่อยรีลีสใหม่แล้วเท่านั้น (เช่น 4 วัน)
    NPM ไม่น่าไว้ใจ เกินไปสำหรับสภาพแวดล้อม CLI ในโปรดักชัน
    ควรจำกัดสิทธิ์ของ publisher key ให้เหลือน้อยที่สุด, ผูกกับแพ็กเกจเฉพาะ, และผูก IP กับ CI/CD runner
    อย่าเก็บ publishing key ไว้ในเครื่องโลคัล และถ้าจำเป็นก็ควรพิจารณา OIDC Trusted Publisher หรือการเข้าถึงแบบใช้โทเค็น

    • NPM ดูเหมือนเป็นผลลัพธ์ของ หนี้ทางเทคนิค ที่สะสมมากเกินไป
      แค่ lockfile ก็ลองแก้กันมาตั้งห้ารอบแล้ว แต่ก็ยังไม่สมบูรณ์
      ถ้าดูจากโครงสร้างและ commit history ก็เห็นว่าทีมกำลังพยายามปรับปรุงอย่างหนัก แต่ให้ความรู้สึกเหมือนเริ่มจาก หลุม ที่ลึกเกินไป
      ทุกวันนี้ก็ยังตรวจจับ early EOF ระหว่างส่งไฟล์ไม่ได้ และยังทิ้งไฟล์ไม่สมบูรณ์ไว้ในแคช ทำให้ในอินเทอร์เน็ตช้า ๆ เสียเวลาอย่างมากกับการอัปเดตที่ล้มเหลว
    • ฉันชอบแนวทางจัดการซีเคร็ตแบบไดนามิกของ HashiCorp Vault / OpenBao
      ตอนแรกมันซับซ้อน แต่สามารถจัดการซีเคร็ตในรูปแบบ lease ได้
      สร้าง lease สำหรับทุก CI build แล้วลบอัตโนมัติเมื่อจบงาน พร้อมรองรับ TTL และการหมุนเวียนอัตโนมัติ
      ทำให้ซ่อน credential ระยะยาวไว้ได้ และออกโทเค็นอายุสั้นเฉพาะตอน build เท่านั้น
      การโจมตีแบบนี้อย่างน้อยก็มีข้อดีตรงที่ทำให้เกิด การถกเรื่องความปลอดภัย อย่างจริงจังในบริษัทมากขึ้น
    • แค่ใช้ npm ci ก็พอ
      เพราะมันจะติดตั้งเฉพาะเวอร์ชันที่ระบุใน package-lock.json จึงช่วยลดความเสี่ยงจากการโจมตีผ่านการอัปเดตอัตโนมัติได้
      สิ่งสำคัญคือการมีวินัยในการอัปเดตแบบ ตั้งใจอัปเดตเท่านั้น
    • ใน ecosystem ของ Python ก็ป้องกันคล้ายกันได้ด้วยตัวเลือก pip install --only-binary=:all:
      มันจะบล็อก source distribution ทั้งหมดและติดตั้งเฉพาะ wheel
      แต่ก็อาจมีข้อจำกัดด้านเวอร์ชัน
      ใน uv สามารถใช้ตัวเลือก --exclude-newer เพื่อเลียนแบบฟีเจอร์ “ระยะเวลาขั้นต่ำหลังออกรีลีส” ของ PNPM ได้
    • ไม่นานมานี้ฉันเห็นบทความเรื่อง “dependency cooldown” แล้วรู้สึกเห็นด้วยมาก
      ฉันตรึงเวอร์ชัน dependency ทั้งหมดไว้และตรวจดูการแจ้งเตือนจาก dependabot ด้วยตัวเอง
      แต่ก็ยังไม่แน่ใจว่านี่คือการระวังเกินไป หรือเป็นนิสัยที่ถูกต้องกันแน่

  • วันนี้มีบทความที่เกี่ยวข้องมากโดยเฉพาะ: “We should all be using dependency cooldowns”
    การอัปเดต dependency อัตโนมัติอาจอันตรายยิ่งกว่าช่องโหว่ที่มีอายุแค่วันเดียว
    การย้อนกลับ แพ็กเกจที่ติดเชื้อ ซึ่งกระจายไปแล้วใน lock file หลายพันไฟล์นั้นยากกว่ามาก

    • ฉันคิดว่าควรอัปเดตเฉพาะเมื่อจำเป็นจริง ๆ จะดีกว่า
      ถ้ามันยังทำงานได้ดีก็ไม่มีเหตุผลต้องไปยุ่ง
    • แต่ถึงทำแบบนั้น สุดท้ายก็ยังต้องให้คนอื่นเป็นคนแก้บั๊กอยู่ดี และถ้าทุกคนใช้ cooldown กันหมด ก็อาจลงเอยด้วยการไม่คืบหน้าไปไหน
    • ใน uv ของ Python สามารถใช้คำสั่ง uv lock --exclude-newer $(date --iso -d "24 hours ago") เพื่อให้ได้ผลคล้ายกัน
      มีการพูดคุยที่เกี่ยวข้องใน issue #14992
    • ทำได้ง่าย ๆ ด้วย npm-check-updates เหมือนกัน
      คำสั่ง npx npm-check-updates -c 7 ใช้ตั้ง cooldown 7 วันได้
      ดู เอกสาร npm-check-updates
    • ฉันไม่เห็นด้วยกับตรรกะนี้
      cooldown อาจยืดเวลาการแพร่กระจายของช่องโหว่ 0-day ได้
      ถ้าทุกคนใช้ cooldown แบบเดียวกัน ก็จะมีแค่ ความล่าช้าในการค้นพบ เท่านั้น

  • ฉันเป็น ผู้ร่วมก่อตั้ง PostHog
    เราเป็นหนึ่งในผู้ได้รับผลกระทบจากการโจมตีครั้งนี้
    เวอร์ชันที่ติดเชื้อคือ posthog-node 4.18.1, 5.13.3, 5.11.3 / posthog-js 1.297.3 / posthog-react-native 4.11.1 / posthog-docusaurus 2.0.6
    เราเปลี่ยนคีย์และรหัสผ่านทั้งหมดแล้ว และปล่อยเวอร์ชันใหม่ออกมาแล้ว
    ตอนนี้กำลังวิเคราะห์สาเหตุ และจะอัปเดตที่ status.posthog.com

    • แนะนำให้ตั้ง การแจ้งเตือน ถ้ามีการปล่อยแพ็กเกจใหม่ที่ไม่ได้เชื่อมโยงกับการรัน CI/CD
    • อยากรู้ว่า JS ที่ติดเชื้อส่งผลกับผู้ใช้จริงหรือไม่
      ถ้าเว็บไซต์ใด deploy เวอร์ชันที่ติดเชื้อไปแล้ว ก็อยากรู้ว่ามีผู้เข้าชมได้รับผลกระทบหรือไม่
    • ถ้ายังไม่รู้สาเหตุ ก็มีความเป็นไปได้ว่าการโจมตียัง แพร่กระจายอยู่
    • เวอร์ชันล่าสุดก็อาจติดเชื้อได้อีก แล้วทำไมผู้คนถึงควรเชื่อถือในครั้งนี้ เป็นคำถามที่น่าสงสัย
    • ดีใจที่อัปเดตที่นี่มองเห็นง่ายกว่าประกาศบน Twitter หวังว่าจะกู้คืนได้เรียบร้อย

  • ขอถามจริงจัง: การเริ่มโปรเจ็กต์ใหม่ด้วย Node ยังถูกต้องอยู่ไหม
    ฉันกำลังทำ SaaS frontend ด้วย Astro และรู้สึกกังวลทุกครั้งที่ต้องอัปเดต dependency
    การขาด ความปลอดภัย ใน ecosystem ของ npm ดูรุนแรงเกินไปมาก

    • ปัญหาไม่ได้อยู่ที่ Node หรือ JS แต่เป็น โมเดลการแพ็กเกจ
      แม้แต่ ecosystem ที่พึ่งพาซับแพ็กเกจจำนวนมากอย่าง Rust สักวันหนึ่งก็น่าจะเจอเรื่องแบบเดียวกัน
      การไม่มี package manager แบบ C, C++, Odin อาจเป็นทางเลือกที่ฉลาดกว่าด้านความปลอดภัยก็ได้
    • ฉันมองว่าเป็นปัญหาของ npm เอง มากกว่า Node
      ช่วงหลังฉันเชื่อถือ JSR ของ Deno มากกว่า
      แพ็กเกจที่อิงกับ JSR มีการเผยแพร่ข้ามไปยัง npm ด้วย และก็มีแพ็กเกจเฉพาะของ Deno เช่นกัน
      ตัวอย่างเช่น Lume แม้จะช้าแต่เป็น SSG ที่เสถียรและน่าประทับใจ
    • นี่ไม่ใช่ปัญหาเฉพาะของ Node
      แค่ npm เป็นรีโพซิทอรีที่ใหญ่ที่สุด จึง มีมูลค่าสูง ในสายตาผู้โจมตีเท่านั้น
      มันเกิดขึ้นกับ RubyGems หรือ Cargo ได้สบาย ๆ
    • ความเห็นที่ว่าควรเลี่ยง Node นั้นเกินไปหน่อย
      แค่เป็น ecosystem ที่ถูกใช้งานมากที่สุด จึงโดนโจมตีมากเป็นพิเศษเท่านั้น
      แค่จัดการ dependency อย่างรอบคอบและไม่อัปเดตทุกวันก็พอ
    • เราพัฒนาแพลตฟอร์มวิเคราะห์ความปลอดภัยของผลิตภัณฑ์ด้วย PHP
      ข้อดีคือไม่ต้องมี dependency เกิน 100 ตัวเพื่อแค่ render หน้าเว็บ
      ดู ลิงก์โปรเจ็กต์

  • ทุกวันนี้ฉันทำงานพัฒนาทุกอย่างอยู่ใน คอนเทนเนอร์ Podman เท่านั้น
    โค้ดที่ยังไม่ได้อ่านจะถูกรันในสภาพแวดล้อมแยกเสมอ
    มันไม่สมบูรณ์แบบ แต่ฉันมองว่าเป็น นิสัยด้านความปลอดภัย ขั้นพื้นฐานอย่างน้อยที่สุด

    • คนส่วนใหญ่ใน 99.99% ของกรณีไม่ได้เจอปัญหา จึงชินชากับความเสี่ยง
      ปกติความปลอดภัยมักเป็นเรื่องที่ โยนให้ผู้เชี่ยวชาญ รับผิดชอบ จึงเปลี่ยนแปลงได้ยากในโลกจริง
    • dependency tree ของ npm ลึกมาก เลยสงสัยว่าการแยกด้วยคอนเทนเนอร์ทำงานอย่างไรในกรณีแบบนี้
    • อยากรู้วิธีปฏิบัติแบบเจาะจงว่าจัดการ npm package อย่าง PostHog SDK ภายในคอนเทนเนอร์อย่างไร
    • Podman ปลอดภัยกว่า Docker และถ้าจำเป็นก็ควรพิจารณาการแยกเพิ่มเติมอย่าง QEMU ด้วย
    • ฉันถึงขั้น SSH เข้าไปด้วยผู้ใช้โลคัลอีกคนหนึ่งแล้วพัฒนางานผ่าน tmux เลย

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

    • MS ยังจัดการ Windows ให้ดีไม่ได้ด้วยซ้ำ
      อะไรที่ไม่ทำเงินจากไลเซนส์องค์กรก็ถูกปล่อยทิ้ง
      เลยทำให้ Windows 11 ดูเหมือนก้อนการตลาดมากกว่าอย่างอื่น

  • ตอนนี้เรากำลัง เฝ้าติดตาม กิจกรรมการโจมตีอยู่ และกำลังอัปเดตรายชื่อแพ็กเกจที่ติดเชื้อใน บล็อกของ Wiz
    เรากำลังทำ reverse engineer เพย์โหลดอันตราย และจะแชร์ผลภายในไม่กี่ชั่วโมง

  • ฟีเจอร์แชต “Talk to a human” ของ PostHog กลับตอบแบบ บอต จริง ๆ เลยทำให้หงุดหงิด
    ลิงก์สำหรับซัพพอร์ตฉุกเฉินก็ไม่ได้แนะนำอย่างเหมาะสม
    งั้นขอถามตรง ๆ — ควรหลีกเลี่ยงเวอร์ชันไหนบ้าง?

    • ฉันเป็นผู้ร่วมก่อตั้ง เราแจ้งไว้แล้วทั้งในเธรดหลักและที่ status.posthog.com
      เวอร์ชันที่ติดเชื้อคือ posthog-node 4.18.1, 5.13.3, 5.11.3 / posthog-js 1.297.3 / posthog-react-native 4.11.1 / posthog-docusaurus 2.0.6
      ถ้าอัปเดตเป็นเวอร์ชันล่าสุดก็ปลอดภัย
    • ฉันได้รับรายการเวอร์ชันเดียวกันนี้จากช่อง Slack เหมือนกัน

  • สงสัยว่าทำไมความวุ่นวายเรื่องแพ็กเกจแบบนี้ถึงเกิดใน ecosystem ของ Node ตลอด
    ไม่เข้าใจว่าทำไมคอมมูนิตี้นี้ถึงเชื่อว่าการมี install hook ซับซ้อนและการอัปเดตอัตโนมัติเป็นวิศวกรรมที่ดี
    พอเข้าใจเลยว่าทำไมผู้สร้าง Node ถึงจากไปแล้ว

    • Node เหมือน PHP ยุคใหม่
      ecosystem ใหญ่มหาศาล, เน้นนักพัฒนามือใหม่, ขาดจิตสำนึกด้านความปลอดภัย, และแม้แต่ฟีเจอร์เล็ก ๆ ก็ยังพึ่งไลบรารี
    • ถ้าเป็น ecosystem ที่จริงจัง ก็ควรมี package maintainer
      ควรมีผู้ดูแลที่เชื่อถือได้คอยตรวจสอบเหมือน Debian แต่คอมมูนิตี้ JS กลับปฏิเสธสิ่งนี้ว่าเป็น gatekeeping
      เลยทำให้เหตุการณ์แบบนี้เกิดซ้ำแล้วซ้ำอีก
    • การกดคนอื่นให้ต่ำลงเพื่อให้ตัวเองรู้สึกเหนือกว่า มันได้ผลแค่ชั่วคราว
      ท่าทีแบบนั้นไม่ได้เปลี่ยนอะไรเลย

  • อาจนอกเรื่องไปหน่อย แต่ฉันสงสัยว่า HelixGuard คือใคร
    เว็บไซต์ดูแย่มาก และแทบไม่มีข้อมูลอะไรเลย
    บอกว่าลูกค้าเป็นเว็บเทรดคริปโต ซึ่งก็ดูน่าสงสัยพอสมควร
 
laeyoung 2025-11-25

2️⃣ สามารถตั้งค่าให้ติดตั้งได้ก็ต่อเมื่อผ่านไประยะเวลาหนึ่ง (เช่น 4 วัน) หลังจากปล่อยรีลีสใหม่

เป็นฟีเจอร์ที่ดีมากเลยครับ บางครั้ง Google ก็อัปโหลดเวอร์ชันที่มีบั๊กจนใช้งานไม่ได้ขึ้นไปบน NPM เหมือนกัน ทำให้มีช่วงที่ผมงงว่าเป็นบั๊กของตัวเองหรือเปล่าอยู่บ่อย ๆ