เครื่องมือโอเพนซอร์สของ Microsoft ถูกแฮ็กและถูกนำไปใช้ขโมยรหัสผ่านของนักพัฒนา AI

(techcrunch.com)

3 คะแนน โดย GN⁺ 4 시간 전 | 2 ความคิดเห็น | แชร์ทาง WhatsApp

โครงการโอเพนซอร์สหลายสิบโครงการ ที่โฮสต์อยู่บน GitHub ถูกแฮ็กเกอร์เจาะระบบ และมีการฝังมัลแวร์ขโมยรหัสผ่านลงในโค้ด ทำให้ Microsoft ปิดกั้นการเข้าถึงโครงการเหล่านั้นและเริ่มสอบสวน
หลายโครงการที่ได้รับผลกระทบเกี่ยวข้องกับเครื่องมือที่ใช้ตอนเขียนโค้ดสำหรับบริการคลาวด์ Azure และ แอปพัฒนา AI เช่น Claude Code, Gemini CLI และ VS Code
เมื่อผู้ใช้เปิดเครื่องมือที่ติดเชื้อจากแอปเขียนโค้ด AI มัลแวร์จะทำงานเพื่อขโมย รหัสผ่านและข้อมูลรับรองที่ละเอียดอ่อน
ตามข้อมูลบน GitHub มี อย่างน้อย 70 โครงการ ถูกปิดใช้งาน และ Microsoft ได้นำบางรีโพซิทอรีลงชั่วคราวก่อนตรวจสอบและกู้คืน
กรณีนี้เป็นตัวอย่างล่าสุดของ การโจมตีซัพพลายเชน ที่มุ่งเล่นงานโค้ดโอเพนซอร์สยอดนิยม และมีรายงานว่าเป็นครั้งที่สองในรอบไม่กี่สัปดาห์ที่โครงการโอเพนซอร์สของ Microsoft ถูกเจาะ

ภาพรวมเหตุการณ์และการตอบสนองของ Microsoft

มีการยืนยันสัญญาณว่าแฮ็กเกอร์ได้เจาะโครงการและฝังมัลแวร์ขโมยรหัสผ่านลงในโค้ด ทำให้ Microsoft ปิดกั้นการเข้าถึง โครงการโอเพนซอร์สหลายสิบโครงการ บน GitHub และกำลังสืบสวนลำดับเหตุการณ์ของการเจาะระบบ
หลายโครงการที่ได้รับผลกระทบเชื่อมโยงกับเครื่องมือที่ใช้ในการเขียนโค้ดสำหรับบริการคลาวด์ Azure และแอปพัฒนา AI อย่าง Claude Code, Gemini command-line interface และ VS Code
ยังไม่สามารถยืนยันได้ทันทีว่ามีผู้ดาวน์โหลดเครื่องมือที่ได้รับผลกระทบไปใช้งานจริงกี่ราย
Microsoft ยืนยันว่าได้ถอดรีโพซิทอรีลง ซึ่ง 404 Media เป็นผู้รายงานเรื่องนี้เป็นแห่งแรก
- Ben Hope โฆษกของ Microsoft กล่าวว่า "ได้ลบรีโพซิทอรีบางส่วนออกชั่วคราวระหว่างการตรวจสอบเนื้อหาที่อาจเป็นอันตราย"
- บางรีโพซิทอรีได้รับการกู้คืนหลังการตรวจสอบ ขณะที่บางส่วนอาจยังคงออฟไลน์ระหว่างที่การดำเนินงานยังดำเนินต่อไป
- บริษัทได้ แจ้งลูกค้าจำนวนเล็กน้อย ที่อาจดาวน์โหลดเนื้อหาจากรีโพซิทอรีที่ได้รับผลกระทบ และหากพบว่าจำเป็นต้องมีมาตรการเพิ่มเติม ก็จะติดต่อโดยตรงผ่านช่องทางซัพพอร์ตที่ใช้อยู่เดิม
เมื่อตอบคำถามของ TechCrunch บริษัทไม่ได้ให้ตัวเลขที่ชัดเจนของลูกค้าที่ได้รับผลกระทบทันที

วิธีการทำงานของมัลแวร์

บริษัทความปลอดภัย Cloudsmith และเว็บไซต์วิเคราะห์มัลแวร์โดยชุมชน OpenSourceMalware เป็นหนึ่งในกลุ่มแรกที่ชี้ให้เห็นการแฮ็กครั้งนี้
มัลแวร์ถูกออกแบบให้ขโมย รหัสผ่านและข้อมูลรับรองที่ละเอียดอ่อนอื่น ๆ เมื่อผู้ใช้เปิดเครื่องมือที่ติดเชื้อในแอปเขียนโค้ด AI
เมื่อเข้าหน้าโครงการบน GitHub ซึ่งเป็นเว็บไซต์โฮสต์โค้ดของ Microsoft พบว่า อย่างน้อย 70 โครงการ แสดงสถานะว่า "disabled"
- ข้อความที่แสดงคือ "การเข้าถึงรีโพซิทอรีนี้ถูกปิดใช้งานโดยเจ้าหน้าที่ GitHub เนื่องจากละเมิดข้อกำหนดในการให้บริการของ GitHub"

บริบทของการโจมตีแบบซัพพลายเชน

นี่เป็นกรณีล่าสุดในช่วงหลายเดือนที่ผ่านมา ที่มีการเจาะโครงการโอเพนซอร์สที่ถูกใช้อย่างแพร่หลาย แล้วฝังมัลแวร์ไปยังผู้ใช้จำนวนมากที่ติดตั้งโค้ดนั้น
การแฮ็กประเภทนี้เรียกว่า การโจมตีแบบ "supply chain" โดยมุ่งเป้าไปที่โค้ดที่ถูกใช้ในผลิตภัณฑ์ซอฟต์แวร์จำนวนมาก หรือถูกใช้โดยผู้ใช้เฉพาะกลุ่ม
- เป้าหมายลักษณะนี้อาจเปิดทางให้แฮ็กเกอร์ได้เปรียบ เพราะบางกรณีมีสิทธิ์เข้าถึงระบบคลาวด์และข้อมูลลูกค้าจำนวนมาก
การที่นักพัฒนาเดี่ยวของโครงการโอเพนซอร์สตกเป็นเป้าไม่ใช่เรื่องแปลก และบางกรณีเป็นส่วนหนึ่งของความพยายามระยะยาวเพื่อสร้างความไว้วางใจจากนักพัฒนา
อย่างไรก็ตาม การที่บริษัทเทคโนโลยีรายใหญ่อย่าง Microsoft ซึ่งมีทรัพยากรสำหรับป้องกันการโจมตีลักษณะนี้ ถูกเจาะได้ก็ถือว่าไม่ปกติ

สัญญาณของการถูกเจาะซ้ำ

ตามรายงานของ Ars Technica เหตุการณ์นี้เป็น กรณีที่สองที่เป็นที่ทราบกัน ในช่วงไม่กี่สัปดาห์ที่ผ่านมา ที่โครงการโอเพนซอร์สของ Microsoft ถูกเจาะ
กลางเดือนพฤษภาคม นักวิจัยด้านความปลอดภัยระบุว่าโครงการโอเพนซอร์สของ Microsoft ชื่อ Durable Task ซึ่งช่วยนักพัฒนาสร้างแอป อาจถูกแฮ็ก
OpenSourceMalware เรียกเหตุการณ์ล่าสุดนี้ว่าเป็น "การถูกเจาะซ้ำ (re-compromise)" ของโครงการ Durable Task
- สิ่งนี้บ่งชี้ว่า Microsoft อาจยังไม่สามารถกำจัดแฮ็กเกอร์ออกไปได้หมดจากความพยายามครั้งแรก หรืออาจเป็นการเจาะระบบครั้งใหม่ที่แยกจากกันโดยสิ้นเชิง

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

brainer 1 시간 전

หรือว่านี่คือสาเหตุที่แม้ผมจะเปลี่ยนรหัสผ่านแล้ว ก็ยังมีความพยายามล็อกอินเข้าบัญชี MS ของผมเข้ามาเรื่อย ๆ อยู่ใช่ไหม?

GN⁺ 4 시간 전

ความคิดเห็นบน Hacker News

นี่เป็นแค่การคาดเดาและการสังเกตส่วนตัวล้วนๆ แต่ดูเหมือนว่า โมเดล RBAC แบบเดิมนั้นแทบพังอยู่แล้ว และตอนนี้เหมือนจะพังไปโดยสมบูรณ์
ผมคิดว่า ความเสี่ยงด้านซัพพลายเชน ภายในองค์กรเพิ่มขึ้นมาก เพราะทั้งผู้ช่วยเขียนโค้ดและวิศวกรไปแตะหลายโปรเจ็กต์ที่ไม่เกี่ยวกันพร้อมกัน โดยเฉพาะเมื่อเริ่มทำการทดลองต่างๆ ที่เมื่อก่อนแค่ไม่มีเวลาทำ
ไม่ได้จะบอกว่าเกี่ยวข้องโดยตรง แต่รู้สึกว่ามีผลอยู่ และการที่ทุกวันนี้หลายที่คอยยุให้ทั้งนักพัฒนาและผู้จัดการใช้ AI เขียนโค้ดแบบลวกๆ บนอุปกรณ์ส่วนตัว ก็ดูเหมือนจะกลายเป็นปัญหาในไม่ช้า
มันยากที่จะเชื่อว่าไม่มีรูปแบบร่วมกันเลยในบรรดาเหตุการณ์ซัพพลายเชนช่วงหลังๆ และผมคิดว่าที่มีกลุ่มแฮ็กเกอร์เชี่ยวชาญการโจมตีแบบนี้ก็เพราะผลตอบแทนมันสูง
- เพื่อความชัดเจน คอมเมนต์ต้นทางไม่ได้ฟันธงว่าเกี่ยวข้องกัน แต่เรื่องนี้ ไม่เกี่ยวอะไรกับ AI หรือ vibe coding เลย
  มันเป็นส่วนต่อเนื่องของ การขาดความปลอดภัยในการติดตั้ง dependency สำหรับนักพัฒนา ที่มีมานานแล้ว และของหนอน Shai Halud
  แฮ็กเกอร์ค้นพบว่าหลอกให้นักพัฒนาติดตั้งอะไรบางอย่างนั้นง่าย และอุปกรณ์ของนักพัฒนาก็เป็นเป้าหมายที่เหมาะอย่างยิ่ง เพราะมีข้อมูลอ่อนไหวอย่าง credentials, cloud CLI, MCP อยู่มากมาย
- บริษัทเราก็คล้ายกัน มีแนวคิดแบบ “ถ้าไม่ทำ AI ให้ได้มากที่สุดก็จะตามหลังคนอื่น” แพร่ไปทั่ว
  ให้ความรู้สึกเหมือนกำลังเล่นซ้ำ กระแส IoT ร้อนแรงเกินจริง ในอดีต คืออยากวิ่งนำฝูงโดยไม่สนใจความปลอดภัย
- ผมเถียงมาหลายปีแล้วว่าจำนวนคนมีน้อยเกินไปเมื่อเทียบกับจำนวนโปรเจ็กต์ทั้งหมด แต่ผู้บริหารบอกว่าโปรเจ็กต์ส่วนใหญ่อยู่ในสถานะว่างอยู่แล้ว เลยให้คนหนึ่งรับหลายงานได้
  สุดท้ายก็ออกมาแบบนี้
- สงสัยว่าหมายถึงต้องแทนที่การควบคุมการเข้าถึงตามบทบาท หรือ RBAC ด้วยอย่างอื่นเลย หรือหมายถึงว่าโมเดล RBAC บางแบบที่ใช้อยู่ตอนนี้พังแล้ว
  ส่วนตัวผมคิดว่า โมเดลความปลอดภัยแบบอิง capability น่าจะเป็นอนาคต แม้ชื่อจะฟังชวนสับสนไปหน่อย
แค่ถ้อยคำในพาดหัวก็มีอคติแล้ว และเนื้อหาก็เขียนเหมือนกับว่าเป็น ความผิดของโอเพนซอร์ส
แล้วยังโยนความรับผิดชอบของความพยายามโจมตีซัพพลายเชนไปให้ Microsoft อีก เลยยิ่งน่าขำ
เขายังเขียนว่า Microsoft did not immediately provide the specific number of customers affected, when asked by TechCrunch. แต่ TechCrunch ไม่ได้อธิบายเลยว่าโอเพนซอร์สทำงานแบบนั้นอยู่แล้ว
ผมเองก็ชอบวิจารณ์ Microsoft เวลาเหมาะสม แต่ครั้งนี้ผมคิดว่า Microsoft จัดการได้อย่างปลอดภัยและถูกต้อง
บทความเขียนเหมือนทุกอย่างเป็นความผิดของ Microsoft และเหมือนการจำกัดขอบเขตความเสียหายเป็นเรื่องน่าอาย
วลี steal passwords of AI developers ก็ทิ้งนัยกำกวมไว้ว่าเป็น “นักพัฒนา AI” หรือ “นักพัฒนาที่ใช้ AI”
คำอธิบายเรื่องการโจมตีซัพพลายเชนก็ไม่ได้อธิบายความหมายจริงๆ แต่พูดถึงแค่ผลลัพธ์กับเหตุผลของพื้นผิวการโจมตี ดังนั้นผมคิดว่ารายงานชิ้นนี้แย่มาก
- TechCrunch สะเพร่าอย่างมากและไม่น่าเชื่อถือ
  ผมเคยเห็นพวกเขาแต่งข้อเท็จจริงขึ้นมาเพื่อ SEO ทั้งที่เป็นการรายงานเรื่องงานที่ผมทำเอง และก็ไม่มีทางบังคับให้แก้ไขได้
- ผมไม่เข้าใจว่ามีอะไรผิดกับประโยคนั้น
  Microsoft มี ปัญหาด้านความปลอดภัยระดับองค์กร และการที่ล็อก GitHub Actions ไม่ดีพอจนปล่อยให้ merge request ข้าม CI/CD ได้ ก็ทั้งช่วยให้เรื่องนี้เกิดขึ้นหรืออย่างน้อยก็เผยให้เห็นปัญหา
  นี่เป็นปัญหาของ Microsoft ที่มีมาตั้งแต่ก่อน AI และไม่ใช่เรื่องให้ถกเถียงกันด้วยซ้ำ: https://www.cisa.gov/sites/default/files/2025-03/CSRBReviewO...
  ในยุค AI ปัญหานี้ได้แพร่กระจายจนเหมือนโรคประจำถิ่นและกำลังถูกทำให้เป็นอาวุธ
- ถ้าอย่างนั้นก็อยากรู้ว่าคุณมอง postmortem อย่างไร
  ที่จริงแล้วเกิดอะไรขึ้น และควรอ่านมันแบบไหน?
ดูเหมือนจะเป็นโพสต์ที่เกี่ยวข้อง
https://news.ycombinator.com/item?id=48418318 (The Blight Reaches Microsoft: 73 Repos Disabled in 105 Seconds)
https://news.ycombinator.com/item?id=48450543 (Miasma Worm Hits Microsoft Again: Azure Functions Action and 72 Other Repositories Disabled After Supply Chain Attack Targeting AI Coding Agents)
https://news.ycombinator.com/item?id=48416155
https://news.ycombinator.com/item?id=48416269 (Miasma Worm Targets AI Coding Agents via GitHub Repos)
- ได้สร้าง เครื่องมือบรรเทา ที่สามารถแก้ไขหรือลบเวิร์มออกจากทุกรีโพซิทอรีที่ติดเชื้อ และเขียนบทความเกี่ยวกับเรื่องนี้ไว้ด้วย
  เมื่อวันจันทร์ แคมเปญ Hades ได้เพิ่มการรองรับ Composer, Go และ Pip ก่อนหน้านั้นรองรับแค่ NPM กับตัวแก้ไข AI assistant และแม้จะมี Ruby ด้วย แต่ดูเหมือนทุกวันนี้แทบไม่มีใครใช้ Rubygems แล้ว
  สิ่งที่แม้แต่ Microsoft เองก็มองข้ามคือ นี่คือเวิร์มตัวแรกที่ทำงานได้บนทุกแพลตฟอร์มของระบบนิเวศโค้ด มันทำงานทั้งบนเครื่องนักพัฒนา, เซิร์ฟเวอร์ และตัวรัน CI/CD แล้วแพร่เวิร์มไปยังทุกรีโพซิทอรีที่เครื่องเหล่านั้นเข้าถึงได้
  ถ้าจะหยุดเวิร์มนี้ คุณต้องปิดคอมพิวเตอร์ทั้งหมดรวมถึง AWS EC2, Google Cloud Platform, Azure และ Kubernetes cluster ให้พร้อมกันแบบ 100% มันแพร่กระจายข้ามทั้งอินฟราทั้งหมดอย่างแท้จริง
  ตามสไตล์มัลแวร์ของ APT28 kill switch คือการตั้งค่าภาษาโฮสต์เป็น ru_RU.KOI8-R หรือก็คือตั้งค่าตัวแปรสภาพแวดล้อม LANG จากนั้นกลไกการแพร่กระจายจะถูกปิดใช้งาน
  เครื่องมือบรรเทา: https://github.com/cookiengineer/antimiasma
  บทความบล็อก: https://cookie.engineer/weblog/articles/malware-insights-mia...
สงสัยอย่างมากว่าน่าจะเป็นกรณีของการใช้ personal access token แบบดั้งเดิมอย่างเละเทะ
ถ้าจะส่งโทเค็นให้ AI agent บนอุปกรณ์ openclaw แปลก ๆ ก็ควรใช้โทเค็นแบบกำหนดขอบเขตละเอียด
บัญชี GitHub ของฉันครอบคลุม 3 องค์กรที่มีนโยบายต่างกันโดยสิ้นเชิง และก็ยังน่าแปลกใจอยู่ที่ classic token ยังถูกอนุญาต
อย่างน้อยก็ควรทำให้ต้องอนุญาตด้วยตนเองแยกตามแต่ละองค์กร
- ฉันคิดว่า AI agent ควรเป็น principal ด้านความปลอดภัยที่แยกออกมาต่างหาก และควรได้รับ access token เฉพาะสำหรับรีโพซิทอรีหรือองค์กรที่จำเป็นเท่านั้น
  การยื่น access token ที่ “ผลิตขึ้น” สำหรับบัญชีมนุษย์ไปให้ AI agent รู้สึกเหมือนเป็นเวอร์ชันใหม่ของการ “เขียนรหัสผ่านไว้บนโพสต์อิท”
- เห็นด้วย แต่ การจัดการสิทธิ์ ของโทเค็นแบบกำหนดขอบเขตละเอียดนั้นแทบจะเป็นฝันร้าย
  ไม่ง่ายเลยที่จะตัดสินว่าอะไรคือสิ่งที่แต่ละงานต้องใช้จริงและอะไรถูกต้องเหมาะสม
  แถมคนพัฒนาซอฟต์แวร์ก็มักคิดว่าควรโฟกัสที่โค้ดมากกว่าสิทธิ์ และบางทีก็มองว่าสิทธิ์เป็นความรับผิดชอบของคนอื่น
- ถ้า classic PAT เป็นต้นเหตุ แบบนี้ก็ไม่ได้หมายความว่ามี รีโพซิทอรีส่วนตัว เพิ่มเติมที่อาจเสี่ยงอยู่ด้วยหรือ นอกเหนือจากรีโพซิทอรี GitHub ล่าสุดที่ถูกพูดถึง?
- ฉันใช้ classic token ของบัญชีสิทธิ์ต่ำสำหรับการสแครปรีโพซิทอรีสาธารณะ
  ถ้าเป็นสิทธิ์ระดับองค์กรก็น่าจะเหมาะกับการใช้งานของฉันดีพอแล้ว
เมื่อวานฉันต้องรีเซ็ตรหัสผ่านบัญชี Microsoft ส่วนตัว เพราะได้รับ การแจ้งเตือนยืนยันตัวตนสองขั้นตอน ว่ามีความพยายามล็อกอินจากโรมาเนีย
ไม่รู้ว่าพวกเขารู้รหัสผ่านได้อย่างไร ผลิตภัณฑ์ Microsoft ที่ฉันมีมีแค่ Xbox เท่านั้น
ตั้งแต่ก่อนยุค AI แล้ว Microsoft ก็ให้ความรู้สึกว่ารั่วไหลเหมือนตะแกรง และแม้อยากให้บริษัทเลิกใช้ Microsoft ก็เหมือนถูกมัดไว้แล้ว
- แทบเป็นไปไม่ได้เลยที่จะตั้งค่าบัญชี Microsoft ส่วนตัวไม่ให้ยอมรับ การล็อกอินแบบไม่ใช้รหัสผ่าน
  ดังนั้นจริง ๆ แล้วบัญชีของคุณอาจถูกตั้งค่าแบบนั้นอยู่ และคำขอ MFA ที่ได้รับก็อาจไม่ใช่การยืนยันตัวตนสองขั้นตอน แต่เป็นเพียงความพยายามเข้าถึงบัญชี
  ฉันก็ได้รับคำขอแบบนี้วันละหลายครั้ง และได้รู้ว่าถ้าตั้งค่าแอป Microsoft Authenticator บนมือถือ ระบบจะบังคับเปลี่ยนเป็นแบบไม่ใช้รหัสผ่านหากมีการล็อกหน้าจออย่างใบหน้า ลายนิ้วมือ หรือ PIN
  ถ้าจะหลีกเลี่ยง คุณต้องปิดการล็อกเหล่านั้นทั้งหมดระหว่างตั้งค่าบัญชีในแอป Authenticator
  เพราะฉันแทบไม่ได้ใช้บัญชี Microsoft เลย ตอนนี้จึงใช้การยืนยันผ่านอีเมลแยกแทน Authenticator
  การที่มันทำงานแบบนี้ได้เองก็บ้าพออยู่แล้ว แต่ก็น่าจะมีใครสักคนใน Microsoft กำลังไล่ทำ KPI เรื่องการล็อกอินแบบไม่ใช้รหัสผ่านอยู่
- บางองค์กรที่ฉันเคยทำงานด้วยตั้งให้มี พรอมป์ตการยืนยันตัวตนหลายปัจจัย ขึ้นมาโดยไม่สนว่ารหัสผ่านจะถูกหรือไม่ จุดประสงค์คือเพื่อถ่วงเวลาของผู้โจมตีให้เสียเปล่า
  ไม่แน่ใจว่า Microsoft ทำแบบนั้นด้วยหรือเปล่า
อยากให้ใครสักคนอธิบายทีว่าทำไมถึงเพิ่มไฟล์ที่ทำให้อ่านยากแบบนี้เข้าไปได้ในรีโพจำนวนมากขนาดนี้ ไม่มี code review กันเลยหรือ?
พาดหัวก็ทำให้เข้าใจผิดด้วย setup คือการเพิ่มการตั้งค่าที่ทำให้คนที่ทำงานกับรีโพนั้นรันอัตโนมัติ และคนเหล่านั้นต้องใช้ VSCode, Cursor, Claude, Gemini
คนที่ใช้ Codex, opencode หรือรันฮาร์เนสอื่น ๆ น่าจะปลอดภัย
รายละเอียด: https://www.stepsecurity.io/blog/miasma-worm-hits-microsoft-...
- ผมมีเพื่อนสนิทคนหนึ่งทำงานอยู่ที่บริษัทยักษ์ใหญ่แห่งหนึ่ง บอกชื่อบริษัทไม่ได้ แต่เป็นบริษัทใน S&P 500
  ทำงานมาค่อนข้างนานแล้วแต่ไม่เคยเห็นเลยว่าตัวโปรเจ็กต์ที่ตัวเองรับผิดชอบหน้าตาจริง ๆ เป็นอย่างไร แค่โคลนรีโพไว้และรู้ว่ามันใช้ภาษาอะไร เท่านั้นเอง
  ทุกอย่างกำลังถูกเอา AI มาต่อ ๆ กันแบบลวก ๆ โปรเจ็กต์นั้นคือ ระบบ authentication และ authorization ของผลิตภัณฑ์ทั้งบริษัท
  เจ้าตัวบอกว่า “ผมกด Tab ทั้งวัน แล้วก็เขียนในรีวิวว่า ‘เป็นพฤติกรรมที่ตั้งใจไว้’ รีวิวก็ให้ AI ทำหมด ไม่มีมนุษย์เข้ามาเกี่ยวข้อง CEO กับ CTO ก็สั่งแบบจริงจังให้ทำอย่างนี้ ถ้ามีอะไรพัง ก็ไม่มีใครรู้ว่ามันทำงานยังไงเพราะไม่มีใครเคยอ่านโค้ดจริง การประเมินผลงานวัดจากจำนวนโทเค็นที่ใช้ ไม่ใช่งานที่เราทำ”
  ตอนนี้หลายบริษัทก็น่าจะเป็นแบบนี้ และจะคิดว่าไม่มี code review จริง ๆ เลยก็ไม่เกินจริง
- ในคอมมิตอันตรายมีจำนวนมากที่แสดงผู้เขียนเป็น github-actions
  นั่นหมายความว่ามีการยืนยันตัวตนผ่านฝั่ง GitHub CI/CD ภายใน และคอมมิตแบบนั้นมีเยอะเกินกว่าที่เครื่องมืออัตโนมัติใด ๆ จะหาเข็มพิษในกองฟางได้ง่าย ๆ
  เพราะงั้นเรื่องนี้จึงเกี่ยวข้องกับ การเจาะระบบความปลอดภัยของ GitHub ในเดือนกันยายน 2025
  “ดาว GitHub ของห้ารีโพร่วมกันมี 1,459 ดวง และ mantine-datatable รีโพเดียวกินไป 1,225 ดวง ดาวเป็นตัวชี้วัดคร่าว ๆ ว่ามีนักพัฒนากี่คนที่ checkout ซอร์สไว้ในเครื่อง และนั่นคือกลุ่มที่การโจมตีกำลังเล็งเป้า”
  “คอมมิตทั้งหมดไม่ได้ถูกเซ็น ใช้ตัวตน github-actions และทิ้งร่องรอยแบบเดียวกันหกไฟล์ พร้อมข้อความ chore: update dependencies [skip ci] การไล่กวาดห้ารีโพในเวลา 49 วินาทีไม่ใช่การคอมมิตโดยมนุษย์ แต่เป็นระบบอัตโนมัติ สิ่งนี้สอดคล้องกับการแพร่ตัวเองของ Shai-Hulud ที่หลังจากเก็บ GitHub token ซึ่งมีสิทธิ์เขียนได้จากการติดเชื้อครั้งก่อน ก็จะผลัก persistence payload เข้าไปในทุกรีโพที่ token นั้นเข้าถึงได้”
  https://safedep.io/miasma-worm-ai-coding-agent-config-inject...
  การทำงานจริง: https://safedep.io/config-files-that-run-code/
  ผมไม่ได้เกี่ยวข้องกับคนพวกนั้นนะ แต่ที่นี่คือคำอธิบายที่ทั้งง่ายและละเอียดที่สุดเท่าที่ผมหาเจอเกี่ยวกับสิ่งที่กำลังเกิดขึ้นตอนนี้
- เพื่อนร่วมงานถามอย่างจริงจังว่า “ถ้าตอนนี้โค้ดส่วนใหญ่ถูกสร้างขึ้นมา แล้วจริง ๆ ใครเป็นคนอ่านมันทั้งหมด?”
  เป็นบริษัทเล็กก็จริง แต่ผมรู้สึกว่าบางคนมี แรงผลักให้เชื่อ AI แบบถวายตัว จนเกือบจะเป็นเรื่องศาสนา
  ผมอ่านโค้ดที่ตัวเองสร้างมากกว่า 90% เหมือนกำลังรีวิวโค้ดของนักพัฒนาจูเนียร์
  ตอนนี้ผมกำลัง vibe coding ฟีเจอร์ใหม่ค่อนข้างหนัก แต่พอ GitHub PR กลับมาใช้งานได้อีกครั้ง ผมก็ตั้งใจจะอ่านให้ละเอียดทุกบรรทัด
- ถ้าบัญชีที่สามารถ push เข้ารีโพได้ถูกยึดไปแล้ว ก็คงไม่จำเป็นต้องมี PR review
พวกเรากำลังฝาก ใบรับรอง root CA ของ Secure Boot ไว้กับคนพวกนี้งั้นหรือ?
- หมายถึงบริษัทเดียวกับที่สอบตกในการทบทวนด้านความปลอดภัยปี 2023 นั่นหรือเปล่า? [0]
  “เมื่อดูแยกกัน ข้อบกพร่องแต่ละอย่างที่อธิบายไว้ข้างต้นอาจพอเข้าใจได้ แต่เมื่อรวมกันแล้ว มันชี้ถึงความล้มเหลวของการควบคุมและการกำกับดูแลองค์กรของ Microsoft รวมถึงวัฒนธรรมองค์กรด้านความปลอดภัย”
  ผลิตภัณฑ์และบริการของ Microsoft อยู่ทุกหนแห่ง เป็นหนึ่งในบริษัทเทคโนโลยีที่สำคัญที่สุดในโลก และอาจสำคัญที่สุดด้วยซ้ำ ตำแหน่งนี้มาพร้อมความรับผิดชอบระดับโลกขั้นสูงสุด จำเป็นต้องมีวัฒนธรรมองค์กรที่ยึดความปลอดภัยอย่างมีความรับผิดชอบโดยเริ่มจาก CEO เพื่อไม่ให้ปัจจัยด้านการเงินหรือการออกสู่ตลาดมาบั่นทอนความมั่นคงปลอดภัยไซเบอร์และการปกป้องลูกค้าของ Microsoft
  “น่าเสียดายที่ตลอดการทบทวนนี้ คณะกรรมการพบชุดการตัดสินใจทั้งเชิงปฏิบัติการและเชิงกลยุทธ์ที่บ่งชี้ว่าวัฒนธรรมองค์กรของ Microsoft ให้ทั้งการลงทุนด้านความปลอดภัยและการบริหารความเสี่ยงอย่างเข้มงวดเป็นเรื่องลำดับความสำคัญต่ำ การตัดสินใจเหล่านี้ก่อให้เกิดต้นทุนและความเสียหายอย่างมีนัยสำคัญต่อกลุ่มลูกค้า Microsoft ทั่วโลก”
  “คณะกรรมการเชื่อมั่นว่า Microsoft ต้องแก้ไขวัฒนธรรมด้านความปลอดภัยของตน”
  [0] https://www.cisa.gov/resources-tools/resources/CSRB-Review-S...
- รากแห่งความเชื่อถือ ของ Secure Boot โดยปกติไม่ใช่ใบรับรองของ Microsoft แต่เป็นใบรับรองของ OEM ซึ่งอาจแย่กว่าเสียอีก: https://www.binarly.io/blog/pkfail-untrusted-platform-keys-u...
  ยังไงก็ตาม คุณก็มีอิสระที่จะลบใบรับรองของ Microsoft แล้วลงทะเบียนใบรับรองของตัวเอง
- มันใกล้เคียงกับ “ถูกบังคับให้ยอมรับ” มากกว่า “ไว้วางใจ”
  เหตุการณ์นี้ก็แค่สานต่อประวัติของ Microsoft ที่ไม่ได้เป็นบริษัทซึ่งดูแลความปลอดภัยอย่างเหมาะสม แต่กลับเคยเป็น ตัวปัญหาด้านความปลอดภัย เองด้วยซ้ำ
- การไว้ใจ Microsoft ในเรื่องความปลอดภัยเป็นเรื่องโง่
  ตลอด 40 ปีที่ผ่านมา พวกเขาแสดงให้เห็นซ้ำแล้วซ้ำเล่าว่าไม่ได้ใส่ใจ
อาจจะรู้ตัวช้าไปหน่อย แต่ผมพูดมาสักพักแล้วว่า ต่อให้คุณไม่อยากใช้ AI ด้วยเหตุผลอย่าง “โค้ดมันแย่” ก็ควรพิจารณาใช้ AI สำหรับ การตรวจสอบความปลอดภัย
อย่างน้อยก็ควรใช้เครื่องมือสำหรับสแกนหาช่องโหว่ในโค้ด
เวกเตอร์การโจมตีไม่ได้มีแค่ปลั๊กอินที่ขโมยข้อมูลเท่านั้น แต่ยังรวมถึงช่องโหว่ 0-day ของซอฟต์แวร์แทบทุกตัวที่คุณใช้อยู่ และพวก script kiddie ที่ถือ LLM มาบุกโจมตีเว็บเซอร์วิสของคุณด้วย
การแฮ็กจะเพิ่มขึ้นและแย่ลงเรื่อย ๆ ดังนั้นที่ไหนก็ตามที่ไม่ลงทุนกับการตรวจสอบและเครื่องมือด้านความปลอดภัยไซเบอร์ ก็ควรคิดทบทวนใหม่
ไม่ควรมีใครไปรัน npm install หรือ pip install บนเครื่องตัวเอง
ถ้าใช้ แซนด์บ็อกซ์ ที่เหมาะสมอย่างสม่ำเสมอ (https://github.com/ashishb/amazing-sandbox) ก็จะลดขอบเขตความเสียหายจากการโจมตีแบบนี้ได้มาก
- Docker backend รันคำสั่งใน คอนเทนเนอร์แบบ rootless หรือเปล่า?
  ผมไล่อ่านโค้ดคร่าว ๆ แล้ว แต่ยังไม่เห็นส่วนที่ยืนยันเรื่องนี้ได้
- Docker ไม่ใช่ กลยุทธ์การทำแซนด์บ็อกซ์ ที่จริงจัง
- ถ้าหมายถึงไม่ควรรัน npm install หรือ pip install บนเครื่องตัวเอง แล้วทางเลือกที่เสนอคืออะไร?
  หมายถึงว่าไม่ควรติดตั้งนอกแซนด์บ็อกซ์ใช่ไหม?
- มี องค์ประกอบด้านการตรวจจับ อยู่ในนี้ด้วยไหม?
  การพัฒนาในแซนด์บ็อกซ์เป็นเรื่องดี แต่ขั้นถัดไปคือการ deploy ขึ้น production
  แล้วเราจะรู้ได้อย่างไรว่าเกิดพฤติกรรมอันตรายในแซนด์บ็อกซ์ เพื่อจะได้ไม่ปล่อยมัลแวร์นั้นต่อไปอีก?
เป็นเรื่องตลกเกินไปที่ GitHub ของ Microsoft ระงับการเข้าถึงโค้ดเบสของ Microsoft Azure และของผู้ใช้ Microsoft รายอื่นทั้งหมดเพราะ ละเมิดข้อกำหนดการใช้งาน
มันทำให้เห็นภาพโครงสร้างองค์กรนี้ได้ชัดเจนดี: https://www.businessinsider.com/big-tech-org-charts-2011-6