TechTalkThai ศูนย์รวมข่าว Enterprise IT ออนไลน์แห่งแรกในประเทศไทย
ยินดีต้อนรับสู่มุมมองของคนวงในเกี่ยวกับช่องโหว่ของห่วงโซ่อุปทานซอฟต์แวร์ หัวข้อนี้ถูกนำเสนอโดยนักวิจัยด้านความปลอดภัยชื่อ Yakir Kadkoda และ Ilay Goldman จาก Aqua Security ซึ่งมีประสบการณ์มากมายในงานด้าน Red Team พวกเขาให้ข้อมูลเชิงลึกอันมีค่าเกี่ยวกับช่องโหว่ที่แฝงตัวอยู่ในช่วงการพัฒนาซอฟต์แวร์ ที่เผยถึงความเสี่ยงที่องค์กรต้องเผชิญในการรักษาความปลอดภัยของห่วงโซ่อุปทานซอฟต์แวร์
โฟลว์ของการพัฒนาซอฟต์แวร์ในองค์กรส่วนใหญ่จะมีลำดับขั้นตอนดังรูปด้านล่าง (The Development Flow)
ผู้บรรยายกล่าวถึงขั้นตอนต่างๆ ที่เกี่ยวข้องกับโฟลว์การพัฒนาซอฟต์แวร์ โดยเน้นถึงช่องโหว่ที่อาจเกิดขึ้นในแต่ละขั้นตอน ขั้นตอนที่ครอบคลุมมีดังนี้
1. IDE: Visual Studio Code Extensions
Integrated Development Environments (IDEs) คือขั้นแรกของโฟลว์การพัฒนาซอฟต์แวร์ แน่นอนว่าหากคุณเป็นนักพัฒนาซอฟต์แวร์ไม่ว่าจะระดับมือโปร หรือ ระดับเริ่มต้น ก็คงต้องหาเครื่องมือสำหรับการเขียนโปรแกรมที่มีสิ่งอำนวยความสะดวก เพื่อทำให้งานของคุณทำได้อย่างรวดเร็วขึ้น โดยเฉพาะอย่างยิ่งการมีส่วนขยาย (Extensions) ทั้งนี้ผู้บรรยายชี้ให้เห็นว่า Visual Studio Code เป็นที่นิยมมากที่สุดในหมู่นักพัฒนาตามการสำรวจนักพัฒนาใน Stack Overflow ปี 2022 ทำให้ผู้บรรยายทำการวิจัยความเสี่ยงของ Extensions ต่าง ๆ บน Visual Studio Code และพบว่าใครก็สามารถเผยแพร่ส่วนขยายของตนไปยังตลาดกลาง (Marketplace) ได้ แต่ท้ายที่สุดแล้วขึ้นอยู่กับการตัดสินใจของนักพัฒนาว่าส่วนขยายใดน่าเชื่อถือ โดย Microsoft มีแหล่งข้อมูลต่างๆ เพื่อประกอบการตัดสินใจเช่น Publisher Name, Rating & Review, Q&A, Repository, Issues, and License ผู้บรรยายได้ค้นพบวิธีปลอมส่วนขยายและสามารถนำขึ้นสู่ตลาดกลาง โดยรูปด้านล่างจะแสดงทั้งของจริงและของปลอมดังภาพ
ผู้บรรยายพบว่าวิธีการตรวจสอบ ผู้พัฒนา Extension หรือ Publisher ยังไม่ดีเพียงพอ ทำให้ใครก็ตามที่ผ่านการตรวจสอบแล้ว สามารถเปลี่ยนชื่อ Publisher เป็นชื่ออื่น (คล้ายของผู้อื่น) โดยไม่ต้องผ่านการตรวจสอบอีกครั้ง แต่ Microsoft ทำการแก้ไขแล้วดังรูปด้านล่าง
นอกจากนี้ยังมีส่วนขยายอีกหลายรายการที่มีช่องโหว่ อาทิเช่น ช่องโหว่ที่ทำให้ผู้โจทตีเข้ายึดเครื่องของนักพัฒนาซอฟต์แวร์ หรือ แอบส่งข้อมูลออกไปนอกเครือข่าย ซึ่งองค์กรที่ขาดระบบตรวจสอบที่ดีอาจถูกเล่นงานจากช่องโหว่เหล่านี้ได้
ข้อเสนอแนะเพื่อลดผลกระทบ
- ตรวจสอบความน่าเชื่อถือของผู้เผยแพร่ก่อนติดตั้งส่วนขยาย
- สแกนส่วนขยายของ IDE เพื่อหาช่องโหว่ และกิจกรรมที่เป็นอันตราย
2. SCM: Repojacking
Source Code Management (SCM) คือเครื่องมือที่จำเป็นสำหรับจัดเก็บข้อมูล หรือ Source Code ทั้งภายในและภายนอกองค์กร ซึ่งมีทางเลือกมากมายเช่น Github GitLab หรือ Bitbucket ผู้บรรยายได้อธิบายถึงความอันตรายและข้อควรระวังเกี่ยวกับเทคนิค Repojacking หรือ การขโมยชื่อผู้ใช้งานที่ไม่มีการใช้แล้วเพื่อหลอกลวงผู้ใช้งาน ยกตัวอย่างเช่น องค์กรเรามีการใช้งาน Github โดยใช้ชื่อผู้ใช้งานว่า MyOrganization และจัดเก็บข้อมูลที่ myRepo ดังนั้นลิงก์ในการเข้าถึงที่จัดเก็บข้อมูลก็คือ https://github.com/MyOrganization/myRepo และหากองค์กรมีการเปลี่ยนชื่อผู้ใช้งานเป็น NewOrganization ดังนั้นลิงก์ในการเข้าถึงที่จัดเก็บข้อมูลคือ https://github.com/ NewOrganization/myRepo จากการเปลี่ยนชื่อผู้ใช้งานทำให้ชื่อ MyOrganization ว่างลง ดังนั้นหากผู้ใช้งานเข้าถึงที่เก็บข้อมูลเก่าโดยไม่ได้ตั้งใจ พวกเขาอาจถูกเปลี่ยนเส้นทางไปยังที่เก็บข้อมูลที่ถูกควบคุมโดยผู้ไม่หวังดี นำไปสู่โค้ดที่อันตราย
ผู้บรรยายได้อธิบายถึงตัวอย่างการโจมตีจริงที่น่าสนใจ ดังนี้
- ผู้ใช้งานเข้าถึงคู่มือการติดตั้งที่ไม่ได้อัปเดตหลังจากที่องค์กรเปลี่ยนชื่อผู้ใช้งาน ทำให้ลิงก์ในการเข้าถึงที่จัดเก็บข้อมูลยังคงเป็นของเก่า อาจทำให้ผู้ใช้งานสั่งติดตั้งผิดลิงก์ได้
- ผู้ใช้งานไม่ทราบว่าองค์กรเปลี่ยนลิงก์แล้ว ผู้ใช้งานอาจเข้าลิงก์เก่าที่ถูก Repojacking และสั่งติดตั้งโค้ดอันตรายลงเครื่อง
- ผู้ใช้งานอ่านโพสตาม Stack Overflow หรือ Blog ต่างๆเกี่ยวกับการติดตั้งใช้งาน Github ขององค์กร ซึ่งข้อมูลอาจไม่ได้อัปเดตนำไปสู่การติดตั้งโค้ดอันตรายลงเครื่อง
- ข้อเสนอแนะเพื่อลดผลกระทบ
- ตรวจสอบลิงก์ GitHub ทั้งหมด ทั้งในโค้ดของคุณและผู้อื่น
- ทำการตรวจสอบอย่างสม่ำเสมอ
- ไม่แนะนำให้เปลี่ยนชื่อที่จัดเก็บข้อมูล
3. Registry: Package Planting
Registry เป็นแหล่งเก็บข้อมูล แพ็คเกจซอฟต์แวร์หรือคอมโพเนนต์ต่าง ๆ ให้สามารถเข้าถึงได้ง่าย ซึ่งนิยมใช้ในการจัดเก็บแพ็กเกจโอเพนซอร์ส และแพคเกจที่สร้างขึ้นโดยชุมชนนักพัฒนา เช่น npm สำหรับภาษา JavaScript, pip สำหรับภาษา Python, และ RubyGems สำหรับภาษา Ruby
ผู้บรรยายยังกล่าวถึงช่องโหว่ใน NPM ที่อนุญาตให้ผู้ใช้เพิ่มผู้ใช้รายอื่นเป็นเจ้าของแพ็กเกจได้ ซึ่งคนร้ายอาจล่อลวงนักพัฒนาด้วยการเพิ่มชื่อผู้ใช้รายอื่นที่มีโปรไฟล์น่าเชื่อถือหรือได้รับความนิยมสูง ทำให้คนหลงเชื่อว่าแพ็จเกจของคนร้ายน่าเชื่อถือตามไปด้วย แต่ปัจจุบันผู้บรรยายได้แจ้งให้ NPM แก้ไขแล้ว
ข้อเสนอแนะเพื่อลดผลกระทบ
- ตรวจสอบแพ็คเกจที่ใช้ในงานของคุณเป็นประจำ
- ประเมินความเสี่ยงของแพ็กเกจโอเพนซอร์ส นำมาใช้ในงาน
4. CI/CD: Public CI/CD Logs
ในขั้นตอนการทำ CI/CD ผู้บรรยายได้อธิบายถึงความเสี่ยงที่อาจเกิดขึ้นกับ Logs ที่เผยข้อมูลความลับออกมาเช่น github token, access token, secret key และอื่นๆ โดยข้อมูลเหล่านี้ไม่ควรแสดงหรือเก็บในรูปแบบ Plain Text หากผู้ไม่หวังดีเข้าถึงข้อมูลความลับนี้อาจส่งผลร้ายแรงตามมาได้
ผู้บรรยายได้ยกเคสตัวอย่างของ Travis CI ที่ผู้โจมตีสามารถใช้ API เข้าไปอ่าน Log ของ job id ใดก็ได้ และจากการที่ไม่มี rate limit ผู้บรรยายจึงสามารถ Brute force ตามเลข id เพื่ออ่าน Log ทั้งหมดได้ ผลลัพธ์คือปรากฏ secret token กว่า 73,000 รายการและหลายรายการยังคงใช้งานได้อยู่ด้วย
ข้อเสนอแนะเพื่อลดผลกระทบ
- Logs ไม่ควรมีข้อมูลความลับ หรือปรากฏโดยไร้การเข้ารหัส
- ควรมีการทำ Rotate Secrets อยู่เป็นประจำ
- ใช้หลักการ Least-Privilege Principle หรือสิทธิ์ต่ำสุดกับ Token
5. Artifacts: Timing Attack
ขั้นตอนนี้เกี่ยวข้องกับการใช้การงานคอนเทนเนอร์ เช่น DockerHub และยังเกี่ยวพันไปถึงตัวจัดการแพ็กเกจสำหรับภาษาการเขียนโปรแกรม (เช่น Go, Maven, NPM) ผู้บรรยายกล่าวถึงความสำคัญในระหว่างกระบวนการ Build เพราะอาจถูกโจมตีได้หากมีการตั้งค่าไม่ถูกต้อง ตัวอย่างเช่น หากองค์กรของคุณมีการสร้างแพคเกจที่ใช้ภายในองค์กร และอัปโหลดขึ้นตัวจัดการแพคเกจเป็นแบบ Private เพื่อง่ายต่อการจัดการ ชื่อแพคเกจที่สร้างขึ้นแบบ Private นั้นควรระบุ Scope หรือชื่อเต็มในการเรียกใช้งาน @ne-test-org/hello-world เพราะคนร้ายอาจสร้างชื่อเดียวกันแต่ใช้ตัวจัดการเป็น Public นำไปสู่การติดตั้งแพ็กเกจอันตรายตั้งแต่ในกระบวนการ Build ของ Docker ซึ่งมีตัวอย่างมาแล้วจากเคสของบริษัท Paypal สามารถอ่านเพิ่มเติมได้จากลิงค์ https://hackerone.com/reports/925585
ผู้บรรยายแสดงวิธีการใช้ Timing Attack เพื่อหาชื่อแพ็กเกจแบบ Private บน NPM เพื่อโจมตีองค์กรที่อาจตั้งค่าผิดพลาดได้ (ซึ่งวิธีการนี้ยังสามารถใช้หาชื่อแพคเกจแบบ Private ได้อยู่)
ข้อเสนอแนะเพื่อลดผลกระทบ
- สร้างแพ็คเกจแบบ Public เป็นตัวยึดตำแหน่งชื่อเพื่อป้องกันการโจมตีประเภทนี้
- แนะนำให้อ่านเพิ่มเติมเรื่อง “Avoiding npm substitution attacks”
สุดท้ายนี้ผู้บรรยาย Yakir Kadkoda และ Ilay Goldman ยังบอกอีกว่าในแต่ละโฟลว์ของการพัฒนาซอฟต์แวร์อาจจะแตกต่างกันในแต่ละองค์กรตามเทคโนโลยีที่องค์กรเลือกใช้ และผู้บรรยายหวังว่าองค์กรจะสามารถสร้างห่วงโซ่อุปทานซอฟต์แวร์เพื่อป้องกันการโจมตีที่อาจเกิดขึ้นและปกป้องทรัพยากรที่มีค่าได้อย่างมั่นคงปลอดภัย
