Bitwarden CLI ถูกฝังมัลแวร์ในแคมเปญซัพพลายเชน Checkmarx ที่กำลังดำเนินอยู่

 (socket.dev)
1 คะแนน โดย GN⁺ 6 일 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • แพ็กเกจ Bitwarden CLI สำหรับ npm ถูกฝังมัลแวร์เป็นส่วนหนึ่งของ การโจมตีซัพพลายเชน Checkmarx ที่กำลังดำเนินอยู่ และขอบเขตผลกระทบที่ยืนยันได้ในตอนนี้จำกัดอยู่ที่บิลด์ @bitwarden/cli 2026.4.0
  • โค้ดอันตราย bw1.js ที่รวมอยู่ในแพ็กเกจ ใช้อินฟราสตรักเจอร์และวิธี obfuscation แบบเดียวกับ audit.checkmarx[.]cx/v1/telemetry และยังสอดคล้องกับร่องรอยการเจาะ CI/CD ผ่าน GitHub Action ที่ถูกฝังมัลแวร์
  • เป้าหมายการเก็บข้อมูลไม่ได้มีแค่ GitHub token แต่ครอบคลุม credential ของ AWS, Azure, GCP, .npmrc, SSH keys, environment variables และแม้แต่ไฟล์ตั้งค่า Claude/MCP
  • ข้อมูลที่ขโมยได้ถูกนำไปใช้สร้างและ commit ไปยัง GitHub repository สาธารณะ, กระจายการติดเชื้อซ้ำผ่านการ publish ใหม่ โดยใช้ npm token และฉีด workflow เพิ่มเติม รวมถึงมีฟังก์ชันสร้าง persistence เช่นการแก้ไข ~/.bashrc และ ~/.zshrc
  • องค์กรที่ใช้งาน Bitwarden CLI ควรจัดการเหตุการณ์นี้ในฐานะ การเปิดเผย credential และ การเจาะ CI/CD โดยการตรวจสอบ CI logs และเปลี่ยนความลับที่อาจรั่วไหลเป็นสิ่งสำคัญ

ภาพรวม

  • แพ็กเกจ Bitwarden CLI บน npm ถูกฝังมัลแวร์เป็นส่วนหนึ่งของ การโจมตีซัพพลายเชน Checkmarx ที่กำลังดำเนินอยู่ และเวอร์ชันเป้าหมายที่ยืนยันแล้วคือ @bitwarden/cli2026.4.0
    • มัลแวร์ถูกฝังอยู่ใน bw1.js ที่รวมมากับแพ็กเกจ
    • เส้นทางการโจมตีสอดคล้องกับร่องรอยการใช้ GitHub Action ที่ถูกฝังมัลแวร์ภายใน CI/CD pipeline ของ Bitwarden และตรงกับรูปแบบแคมเปญที่พบใน repository อื่น ๆ
  • ขอบเขตที่ยืนยันได้จนถึงตอนนี้จำกัดอยู่ที่ บิลด์ Bitwarden CLI และการฝังมัลแวร์เป็นไปตามเวกเตอร์ซัพพลายเชน GitHub Actions ที่ระบุใน Checkmarx campaign ที่กว้างกว่า
    • เกี่ยวข้องเฉพาะแพ็กเกจ CLI บน npm เท่านั้น
    • ส่วนขยาย Chrome, MCP server และงานเผยแพร่อย่างเป็นทางการอื่น ๆ ยังไม่พบว่าได้รับผลกระทบในขณะนี้
  • การสืบสวนยังดำเนินต่อไป และจะมีการเปิดเผยการวิเคราะห์ทางเทคนิคแบบเต็ม เวอร์ชันที่ได้รับผลกระทบ ตัวบ่งชี้การ compromise และแนวทางรับมือเพิ่มเติม
  • หากใช้งาน Bitwarden CLI จำเป็นต้อง ตรวจสอบ CI logs และ หมุนเปลี่ยนความลับ ที่อาจมีโอกาสรั่วไหล

การวิเคราะห์ทางเทคนิค

  • เพย์โหลดอันตราย bw1.js ใช้อินฟราสตรักเจอร์หลักร่วมกับ mcpAddon.js ของ Checkmarx ที่ถูกวิเคราะห์เมื่อวันก่อน
    • ใช้ C2 endpoint เดียวกันคือ audit.checkmarx[.]cx/v1/telemetry และถูก obfuscate ด้วย __decodeScrambled และ seed 0x3039
    • ยังทำการขโมย token และเผยแพร่ซ้ำผ่าน npm registry รวมถึงการ exfiltration แบบ commit ผ่าน GitHub API
  • โครงสร้างเพย์โหลดที่ฝังก็อยู่ในตระกูลเดียวกัน
    • ภายในโครงสร้าง gzip+base64 มีสคริปต์ Python ที่ scrape หน่วยความจำของ GitHub Actions Runner.Worker เพื่อขโมย GitHub token
    • ยังมี loader setup.mjs สำหรับแพ็กเกจ npm ที่ใช้เผยแพร่ซ้ำ, GitHub Actions workflow YAML, RSA public key ที่ hardcode ไว้ และสตริงแถลงการณ์เชิงอุดมการณ์
  • ขอบเขตการเก็บ credential กว้างมาก
    • GitHub token ถูกเก็บจากการ scrape หน่วยความจำ Runner.Worker และจาก environment variables
    • AWS credential ถูกค้นหาจากไฟล์ใน ~/.aws/ และ environment variables
    • Azure token ถูกรวบรวมผ่าน azd และ GCP credential ผ่าน gcloud config config-helper
    • .npmrc, SSH keys, environment variables และไฟล์ตั้งค่า Claude/MCP ก็เป็นเป้าหมายด้วย
  • มีการยืนยันรายละเอียดของ วิธี exfiltration ผ่าน GitHub อย่างชัดเจน
    • สร้าง repository สาธารณะภายใต้บัญชีของเหยื่อ โดยใช้รูปแบบชื่อธีม Dune {word}-{word}-{3digits}
    • commit ผลลัพธ์ที่ถูกเข้ารหัส และใส่ token ลงใน commit message พร้อม marker LongLiveTheResistanceAgainstMachines
  • รวมถึงมีกลไกแพร่กระจายผ่านซัพพลายเชนด้วย
    • ใช้ npm token ที่ขโมยมาเพื่อค้นหาแพ็กเกจที่มีสิทธิ์เขียน แล้ว เผยแพร่ซ้ำโดยแทรก preinstall hook
    • ฉีด GitHub Actions workflow เพื่อเก็บ repository secrets เพิ่มเติม
  • มี kill switch สำหรับ locale รัสเซีย
    • หาก locale ของระบบขึ้นต้นด้วย "ru" จะหยุดการทำงานอย่างเงียบ ๆ
    • ตรวจสอบ Intl.DateTimeFormat().resolvedOptions().locale และ environment variables ได้แก่ LC_ALL, LC_MESSAGES, LANGUAGE, LANG
  • รันไทม์คือ Bun v1.3.13 และดาวน์โหลดมาจาก GitHub Releases

จุดที่ต่างจากเหตุการณ์ Checkmarx

  • bw1.js มีตัวบ่งชี้การ compromise เพิ่มเติมที่ไม่มีอยู่ในเอกสารเหตุการณ์ของ Checkmarx
    • ใช้ไฟล์ล็อกที่ hardcode ไว้คือ /tmp/tmp.987654321.lock เพื่อป้องกันการรันพร้อมกัน
    • ฉีดเพย์โหลดลงใน ~/.bashrc และ ~/.zshrc เพื่อสร้าง persistence ผ่าน shell profile
    • ใช้ การสร้างแบรนด์อย่างชัดเจน เช่นตั้งคำอธิบาย repository เป็น Shai-Hulud: The Third Coming และใส่สตริงดีบัก "Would be executing butlerian jihad!"
  • แม้เครื่องมือที่ใช้ร่วมกันจะชี้อย่างมากว่าเชื่อมโยงกับระบบนิเวศมัลแวร์เดียวกัน แต่ลักษณะการปฏิบัติการกลับทำให้การระบุผู้กระทำทำได้ยากขึ้น
    • หลังการค้นพบการโจมตี Checkmarx กลุ่ม TeamPCP อ้างผ่านบัญชีโซเชียล @pcpcats ว่าเป็นฝีมือของตน
    • มัลแวร์ดังกล่าวพยายามพรางตัวด้วยคำอธิบายที่ดูเหมือนปกติ
  • เพย์โหลดครั้งนี้มีท่าทีเปิดเผยต่างออกไป
    • สัญลักษณ์เชิงอุดมการณ์ ถูกฝังอยู่ในมัลแวร์โดยตรง เช่นชื่อ repository ว่า Shai-Hulud, แถลงการณ์ "Butlerian Jihad" และ commit message ที่ยกการต่อต้านเครื่องจักรขึ้นมา
    • จึงยังเป็นไปได้หลายทาง ทั้งผู้ปฏิบัติการรายอื่นที่ใช้อินฟราสตรักเจอร์เดียวกัน, กลุ่มย่อยที่มีอุดมการณ์เข้มข้นกว่า หรือการเปลี่ยนท่าทีต่อสาธารณะของแคมเปญเดิม

ข้อแนะนำ

  • องค์กรที่ติดตั้งแพ็กเกจ Bitwarden บน npm ที่เป็นอันตราย ควรจัดการเหตุการณ์นี้ในฐานะ การเปิดเผย credential และ การเจาะ CI/CD
  • ให้ลบแพ็กเกจที่ได้รับผลกระทบออกจากระบบนักพัฒนาและสภาพแวดล้อม build ทันที และเปลี่ยน credential ทั้งหมดที่อาจสัมผัสกับสภาพแวดล้อมดังกล่าว
    • รวมถึง GitHub token, npm token, cloud credential, SSH keys และความลับของ CI/CD
  • บน GitHub ควรตรวจสอบการสร้าง repository ที่ไม่ได้รับอนุญาตและ workflow ที่ผิดปกติ
    • ควรตรวจสอบไฟล์ที่ไม่คาดคิดใต้ .github/workflows/, การรัน workflow ที่น่าสงสัย, การดาวน์โหลด artifact และ repository สาธารณะที่ใช้รูปแบบชื่อธีม Dune {word}-{word}-{3digits}
    • หากอาจได้รับผลกระทบ ให้ตรวจสอบ repository ที่เพิ่งถูกเผยแพร่ว่ามีคีย์เวิร์ดต่อไปนี้หรือไม่
      • atreides
      • cogitor
      • fedaykin
      • fremen
      • futar
      • gesserit
      • ghola
      • harkonnen
      • heighliner
      • kanly
      • kralizec
      • lasgun
      • laza
      • melange
      • mentat
      • navigator
      • ornithopter
      • phibian
      • powindah
      • prana
      • prescient
      • sandworm
      • sardaukar
      • sayyadina
      • sietch
      • siridar
      • slig
      • stillsuit
      • thumper
      • tleilaxu
  • บน npm ควร audit ว่ามีการเผยแพร่ที่ไม่ได้รับอนุญาตหรือไม่
    • ตรวจสอบการ publish ที่ไม่ได้รับอนุมัติ, การเปลี่ยนเวอร์ชัน และ install hook ที่ถูกเพิ่มเข้ามาใหม่
  • ในสภาพแวดล้อมคลาวด์ ควรทบทวน access logs ใหม่
    • จำเป็นต้องติดตามการเข้าถึงความลับที่ผิดปกติ การใช้ token และ credential ที่ถูกออกใหม่
  • บน endpoint และ runner ควรติดตามร่องรอยการเข้าถึงไฟล์และอินฟราสตรักเจอร์ exfiltration ที่สังเกตพบ
    • ควรค้นหาการเชื่อมต่อออกภายนอกไปยัง audit[.]checkmarx[.]cx
    • ตรวจสอบว่ามี การรัน Bun ในสภาพแวดล้อมที่ปกติไม่เคยใช้หรือไม่
    • ควรตรวจสอบร่องรอยการเข้าถึง .npmrc, .git-credentials, .env, ที่เก็บ cloud credential, gcloud, az, azd
    • ตรวจสอบการมีอยู่ของ /tmp/tmp.987654321.lock และการแก้ไข ~/.bashrc, ~/.zshrc
  • ใน GitHub Actions ควรทบทวนว่ามีการสร้าง workflow ที่ไม่ได้รับอนุญาตหรือไม่
    • ต้องตรวจสอบว่า workflow ถูกสร้างบน temporary branch หรือไม่
    • ควรตรวจสอบด้วยว่ามีการสร้างหรือดาวน์โหลด artifact เช่น format-results.txt หรือไม่
  • ในระยะยาว ควรลด รัศมีความเสียหาย จากเหตุการณ์ซัพพลายเชนในอนาคต
    • ลดขอบเขตสิทธิ์ของ token และใช้ credential อายุสั้นเมื่อทำได้
    • จำกัดสิทธิ์ในการสร้างและเผยแพร่แพ็กเกจ และเพิ่มความเข้มงวดของสิทธิ์ GitHub Actions
    • ปิดการเข้าถึง artifact ที่ไม่จำเป็น และเฝ้าติดตาม repository สาธารณะหรือการเปลี่ยนแปลง workflow ที่เกิดนอกขั้นตอน release ปกติ

ตัวบ่งชี้การ compromise

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

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

 
GN⁺ 6 일 전
ความคิดเห็นจาก Hacker News

  • สงสัยว่ามีวิธีป้องกันที่ดีกว่า การกำหนดเวลารอขั้นต่ำก่อนปล่อยรีลีส หรือไม่
    แค่ใส่ min-release-age=7 ใน .npmrc ก็น่าจะช่วยให้คน 334 คนที่ได้รับ @bitwarden/cli 2026.4.0 ซึ่งถูกอัปโหลดเมื่อราว 19 ชั่วโมงก่อน แล้วภายหลังพบว่าเป็นอันตราย หลีกเลี่ยงได้แล้ว
    แนวคิดนี้ใช้ได้ค่อนข้างดีกับกรณีอย่าง axios, ua-parser-js, node-ipc ด้วย และถึงจะกันกรณีที่แฝงตัวนานแบบ event-stream ไม่ได้ แต่ก็ดูเหมือนจะได้ผลกับการโจมตีซัพพลายเชนแบบฉับพลันส่วนใหญ่
    มีตัวอย่างการตั้งค่าสำหรับ npm/pnpm/bun/uv ว่าจะใส่ระยะเวลารออย่างไร และเพราะยังไม่มีเครื่องมือแบบคลิกเดียวเพื่อตรวจสอบและนำไปใช้ จึงทำ https://depsguard.com ขึ้นมาเอง
    เพิ่งไปเจอ https://cooldowns.dev ซึ่งเป็นไอเดียคล้ายกันเหมือนกัน

    • กำลังใช้ Aikido safe-chain อยู่
      มันไม่ได้แค่ตั้งเวลารอขั้นต่ำก่อนปล่อยรีลีส แต่ทำหน้าที่เป็นแรปเปอร์ครอบ npm/uv ฯลฯ เพื่อตรวจสอบแต่ละ dependency ก่อนติดตั้ง โดยเทียบกับ ฐานข้อมูลช่องโหว่ เชิงพาณิชย์เพื่อหา known issue หรือสัญญาณน่าสงสัย
    • ไอเดีย cooldown นั้นดี แต่ก็สงสัยว่าถ้าไม่มีใครอัปเดตทันทีจริง ๆ การโจมตีนี้จะถูกจับได้หรือไม่
      ในโลกจริงมักจะมีคนอัปเดตทันทีเสมอ แต่กระบวนการที่ทำให้เหตุการณ์แบบนี้ถูกเปิดเผยก็ดูจะพึ่งพาผู้ใช้ที่อัปเดตเร็วอยู่เหมือนกัน
    • คิดว่าควรเริ่มจาก อย่าเอา backend หรือเครื่องมือ CLI ไปไว้บน NPM
    • สำหรับการติดตั้งใหม่ก็เรื่องหนึ่ง แต่ dependency ที่มีอยู่แล้วน่าจะ pin เป็น patch version แล้ว ตรึง sha ได้ไม่ใช่หรือ
    • การโจมตีแบบนี้มักไม่ลามไปถึง upstream source ดังนั้นแนวทางแบบ https://www.chainguard.dev/libraries ที่ build จาก source น่าจะกันได้ประมาณ 98%
      ถ้าจำเป็นต้องดึง registry binary มาใช้ตรง ๆ ก็ใช้ cooldown เพื่อลดความเสี่ยงได้บ้าง
      สำหรับเคสหางยาวที่ลามไปถึงฝั่ง GitHub ก็ดูเหมือนต้องใช้ทั้ง heuristic ของ commit/maintainer และ การวิเคราะห์การเปลี่ยนแปลงโค้ดด้วย AI แล้วให้มนุษย์เข้ามารีวิวเมื่อมีสัญญาณผิดปกติ
      อนึ่ง ฉันทำงานอยู่ที่นี่

  • แก่นของเหตุการณ์นี้คือ build pipeline ถูกยึด จนมีการปล่อยแพ็กเกจที่ปนเปื้อนออกมา
    ถึงอย่างนั้น ถ้าคุณวางของสำคัญต่อธุรกิจไว้บน npm ก็น่าจะควร pinning dependency เอาไว้
    นักพัฒนาหลายคนคิดว่า lockfile ก็พอแล้ว แต่ถ้ายังมีช่วง ^ ค้างอยู่ ตอนอัปเดต lockfile มันก็อาจดึงเวอร์ชันใหม่ที่ฉันไม่ได้เลือกอย่างชัดเจนเข้ามาได้
    ถ้าเป็นระบบที่อาจกระทบถึงความอยู่รอดของบริษัท ความยุ่งยากระดับนี้ก็คุ้มที่จะรับไว้

    • ถ้ามองกลับกัน เวอร์ชันใหม่กว่าอาจมี การแก้ช่องโหว่ความปลอดภัย อยู่ และในอุดมคติก็อยากให้ระบบรับสิ่งนั้นไปใช้ได้อัตโนมัติเหมือนกัน

  • https://github.com/doy/rbw คือ ทางเลือก Rust แทน Bitwarden CLI
    ecosystem ของ Rust เองก็ดูจะค่อย ๆ โตไปทาง dependency tree ที่ใหญ่และลึกแบบ npm เหมือนกัน แต่ก็ยังมีจำนวนผู้เขียนที่ต้องเชื่อใจน้อยกว่ากรณีที่พบบ่อยใน JavaScript มาก

    • ถ้าดูที่ https://github.com/doy/rbw/blob/main/Cargo.toml#L16 จะเห็นว่าอันนี้ก็ มี dependency ไม่น้อย
      แต่อย่างน้อยเวอร์ชันก็ถูก pin ไว้
    • สงสัยว่าการใช้ ตัวจัดการรหัสผ่านในตัวของ Firefox มีข้อเสียอะไรหรือไม่
    • หลายคนมองว่า Rust ปลอดภัยกว่า แต่กลับมองข้ามไปง่าย ๆ ว่า ความเสี่ยงในการดึงมัลแวร์ผ่าน dependency เพิ่มขึ้นมาก
    • ถ้าใช้ชุด rbw + vaultwarden ก็ทำงานได้ค่อนข้างดีเหมือนเป็น Bitwarden เวอร์ชัน Rust ที่ self-hostable
    • เรื่องแบบนี้อาจผลักดันให้ซอฟต์แวร์จำนวนมากขึ้นไปอยู่บน สแตกแบบ .Net ที่จัดการอะไรได้เกือบทั้งหมดโดยไม่ต้องพึ่ง third-party dependency
      หรือไม่ก็อาจทำให้ภาษาใส่ความสามารถเพิ่มเข้าไปใน standard library มากขึ้น

  • ประสบการณ์กับ Bitwarden CLI แย่มาก
    พอรัน bw list ก็นึกว่าจะเห็นแค่ชื่อรหัสผ่าน แต่จริง ๆ แล้วมันแสดง ทั้งรหัสผ่านและรหัส TOTP ปัจจุบันทั้งหมด ออกมาหมด
    ที่น่ากลัวยิ่งกว่าคือพอ ssh เข้าเซิร์ฟเวอร์แล้วเปิด weechat ใน tmux ก็พบว่าเนื้อหาทั้งหมดของคำสั่ง bw เข้าถึงได้จาก input history ของ weechat
    ไม่เข้าใจเลยว่าทำไมถึงเป็นแบบนั้น และมันค้างอยู่ข้ามทั้ง tmux และ weechat session ต้องรีบูตเซิร์ฟเวอร์ถึงจะหาย
    หลังจากนั้นก็ลบ bw CLI ทันที และไม่คิดจะติดตั้งอีก
    สำหรับบริบท เทอร์มินัลที่ใช้คือ ghostty

    • อันนี้ออกจะเป็น การบ่น ที่ไม่เกี่ยวกับหัวข้อหลัก
    • เคยคิดจะลอง CLI แต่พอเห็นว่าเป็น ฐาน JavaScript ก็เลิกเลย
    • แปลกมากจริง ๆ
      สงสัยว่าใน weechat มี extension bwcli อะไรสักอย่างหรือเปล่า และเพิ่งรู้จากครั้งนี้เองว่า Bitwarden มี CLI ด้วย
      ฉันใช้ keepass บนเครื่องโลคัล

  • ไม่เคยใช้ CLI แต่ใช้ ปลั๊กอินเบราว์เซอร์ อยู่
    ถ้าอันนี้โดนเจาะคงแย่มาก แต่ก็ไม่รู้ว่าต้องทำอย่างไรถึงจะป้องกันได้
    เลยกำลังคิดว่าอาจต้องใช้ เวอร์ชันเก่าที่ผ่านการตรวจสอบแล้ว ต่อไป
    มันทำให้รู้สึกแปลกดีที่ชีวิตส่วนใหญ่ของฉันผูกอยู่กับการที่ความลับเหล่านี้ยังคงเป็นความลับต่อไป

    • ยิ่งมี จุดรวมการเชื่อมต่อ มาก พื้นที่โจมตีก็ยิ่งมาก
      เพราะแบบนั้นฉันเลยไม่ใช้ ส่วนขยายเบราว์เซอร์ ของตัวจัดการรหัสผ่านเลย
      หลังจากเคยเห็นผลิตภัณฑ์ที่มีปัญหาด้านความปลอดภัยจากการเชื่อมกับเบราว์เซอร์ ก็เลี่ยงหมด ส่วนการเชื่อมกับ iOS ไว้ใจมากกว่านิดหน่อยแต่ก็ยังระวังอยู่
    • คิดว่า cooldown ควรเป็นค่าเริ่มต้นในทุกที่
      ทั้ง package manager สำหรับงานพัฒนา, OS package manager, ส่วนขยายเบราว์เซอร์, ไปจนถึง auto-update ของแอปแบบ standalone
      บริษัทอย่าง Socket ต้องมีเวลาพอจะตรวจจับอัปเดตที่เป็นอันตราย แต่ถ้าทุกคนดาวน์โหลดกันภายในไม่กี่นาทีหลังเผยแพร่ การตรวจจับแบบนั้นก็แทบไม่มีความหมาย
    • ทรัพย์สินดิจิทัลที่สำคัญที่สุดของฉันคือ อีเมลและบัญชี Bitwarden ซึ่งปกป้องด้วย Yubikey ที่พกติดตัวตลอดหนึ่งดอก และกุญแจสำรองอีกหนึ่งดอกที่เก็บไว้อีกสถานที่หนึ่ง
      แนะนำการตั้งค่าแบบนี้มาก
      เห็นหัวข้อแล้วตกใจอยู่เหมือนกัน แต่ก็รู้สึกว่าตัวเองได้ทำสิ่งที่สมเหตุสมผลทั้งหมดแล้วโดยไม่ถึงขั้นหวาดระแวงเกินไป
    • แทนที่จะใช้ ปลั๊กอินเบราว์เซอร์ ก็ใช้แอปเดสก์ท็อปหรือ web vault ตรง ๆ ได้
    • วิธีป้องกันพูดสั้น ๆ ก็มีสองอย่างนี้
      https://cooldowns.dev
      https://depsguard.com
      อันที่สองฉันเป็นคนดูแลเอง และถ้ารู้จักอันแรกก่อนก็คงไม่จำเป็นต้องสร้างขึ้นมา
      ทั้งคู่ทำงานแทบเหมือนกัน ฝั่งฉันใช้ Rust เลยดู overkill ไปหน่อย

  • สิ่งสำคัญที่สุดตรงนี้คือ แค่ npm install ก็เพียงพอแล้ว
    ถ้าจุดถูกเจาะอยู่ที่ preinstall ความเชื่อที่ว่าค่อยไปตรวจหลังติดตั้งก็พังทันที
    เพราะถึงตอนนั้น payload ก็ได้โอกาสทำงานไปแล้ว
    เรื่องนี้ยิ่งน่าสนใจในสภาพแวดล้อมแบบ agent, CI, ephemeral sandbox เพราะถึงช่วงเวลาที่เปิดรับความเสี่ยงจะสั้น แต่ถ้าการติดตั้งเกิดขึ้นอัตโนมัติซ้ำ ๆ ก็โดนได้อยู่ดี
    อีกจุดที่น่าสังเกตคือ payload นี้ไม่ได้มุ่งแค่ความลับ แต่ยังเล็งไปที่ การตั้งค่า AI tooling ด้วย
    การแก้ไข shell profile อาจกลายเป็นช่องทางที่ทำให้ context ที่ coding assistant รอบถัดไปจะอ่าน ถูกปนเปื้อนได้จริงพอสมควร
    มุมมองนี้เขียนไว้ยาวกว่านี้พร้อมงาน AgentSH ที่ https://www.canyonroad.ai/blog/the-install-was-the-attack/

    • ในทางปฏิบัติไม่มีใครมาตรวจแพ็กเกจหลังติดตั้งอยู่แล้ว และการเจาะจงว่าปัญหาอยู่ที่ npm install script เป็นข้ออ้างที่ถูกโต้แย้งมาหลายครั้ง
      อย่างไรเสียสุดท้ายก็ต้องไปรันไบนารีจริงอยู่ดี
      และถ้าจะเถียงกันจริง ๆ ก็สามารถดาวน์โหลดแพ็กเกจก่อนเพื่อตรวจสอบได้ตั้งแต่ก่อนติดตั้ง แต่ถ้าไม่ได้เข้าใจอย่างลึกซึ้งว่าตัวติดตั้งรับประกันอะไรและมีขอบเขตแค่ไหน การไว้ใจกระบวนการดาวน์โหลดและแตกโค้ดอันตรายออกมาแบบครึ่ง ๆ กลาง ๆ ก็ดูแปลกกว่าเสียอีก

  • มี kill switch ตาม locale รัสเซีย ด้วย ฟังดูทั้งกล้าและขี้ขลาดในเวลาเดียวกัน

    • ที่แย่กว่าคือเราไม่รู้ด้วยซ้ำว่านี่เป็นร่องรอยจริง หรือเป็น false flag
    • ทำให้นึกถึงสุภาษิตอย่าง Discretion is the better part of valor ขึ้นมาหลายอัน
      พูดง่าย ๆ คือดูเหมือนท่าทีแบบ ไม่ยิงใส่เท้าตัวเอง
    • มันไม่ได้เป็น หลักฐานชี้ขาด ในตัวเอง
      ในเอกสารรั่ว Vault7 ก็มีการกล่าวถึงว่า NSA และ CIA จงใจทิ้งร่องรอยแบบนี้ไว้เพื่อทำให้ต้นทางสับสน และก็เป็นเทคนิคที่รัฐอื่น ๆ ใช้ได้เหมือนกัน
    • มันยังดูคล้าย ปฏิบัติการข่มขู่ ที่ประเทศอื่นเป็นคนทำด้วย
    • ใครจะไปตั้ง locale แบบนั้นในงาน npm publish GitHub CI กัน
      มันดูเป็น ร่องรอยหลอกให้หลงทาง ที่โจ่งแจ้งเกินไป แต่ขณะเดียวกันก็ชวนให้รู้สึกแรงว่ามีรัฐเข้ามาเกี่ยวข้อง

  • ถ้าเป็นผู้ใช้ KeePass ความเครียดแบบนี้จะน้อยกว่ามาก
    แค่ในช่วง 5 ปีที่ผ่านมา การใช้ KeePass กับโครงสร้างพื้นฐานแบบโลคัลก็ช่วยหลบเหตุการณ์ด้านความปลอดภัยไปได้หลายครั้ง

    • รอบนี้ปัญหาไม่ได้อยู่ที่ vault เอง แต่เป็นเครื่องมือสำหรับเข้าถึงมัน
      ไม่ได้แปลว่าเครื่องมือสำหรับ KeePass จะไม่มีปัญหาแบบนี้ได้ เลยยังไม่ค่อยเข้าใจว่าต่างกันตรงไหน
    • ต้องเข้าถึงรหัสผ่านได้ ทั้งจากโครงสร้างพื้นฐานและจากมือถือ เลยสงสัยว่า KeePass จัดการเรื่องนี้อย่างไร
      ที่ผ่านมาคิดว่าทำไม่ได้ แต่ก็ยอมรับว่าไม่ได้ศึกษาลึก
    • สำหรับคนที่ดูแลโครงสร้างพื้นฐานเองได้มันก็ดี แต่คำว่า stress free คงใช้กับผู้ใช้ทั่วไปได้ยาก
    • เข้าใจแนวทางแบบไฟล์เดียว แต่ในทางปฏิบัติ ซิงก์และแก้ conflict กันอย่างไร
      ถ้าสองอุปกรณ์ออฟไลน์อยู่แล้วต่างคนต่างเพิ่มรหัสผ่าน จากนั้นกลับมาออนไลน์อีกทีจะจัดการอย่างไร
    • สิ่งที่ยังจับต้นชนปลายไม่ถูกใน KeePass คือ cloud backup
      ถ้าเข้ารหัสแบ็กอัปแล้ว รหัสของมันจะเก็บไว้ที่ไหน แล้วรหัสผ่านของผู้ให้บริการคลาวด์เองจะเก็บไว้ที่ไหน

  • อีกเรื่องที่น่าประทับใจเป็นพิเศษในการโจมตีครั้งนี้คือ ผู้โจมตีต้องกะจังหวะให้ตรงกับช่วงที่ GitHub ไม่ล่ม พอดี

  • เพราะแบบนี้ฉันจึงไม่ใช้ ตัวจัดการรหัสผ่านจาก third party เลย
    เพราะมันต้องเชื่ออย่างต่อเนื่องว่าพวกเขาจะดูแลเรื่องความปลอดภัย การอัปเดต และแบ็กอัปได้ถูกต้อง
    ฉันทำ ตัวสร้างรหัสผ่านแบบ stateless ขึ้นมาเอง ทำให้ไม่ต้องมีการแบ็กอัปหรือซิงก์ข้อมูลข้ามอุปกรณ์เลย
    วิธีคือใส่มาสเตอร์พาสเวิร์ดยาวและแข็งแรงมาก พร้อมชื่อบริการและชื่อผู้ใช้ จากนั้นคำนวณ scrypt hash ด้วยพารามิเตอร์ที่เหมาะสมเพื่อให้ brute force แทบเป็นไปไม่ได้
    สำหรับบัญชีสำคัญก็ใช้ 2FA ร่วมด้วย