หา 7 CVE ในปี 2024 ง่ายนิดเดียว
หลายคนคิดว่า CVE หรือ Common Vulnerabilities and Exposures นั้นหายาก แต่ในความเป็นจริงแล้วการหา CVE อาจจะไม่ได้ยากเท่าที่คุณคิด คุณก็สามารถเจอ CVE แรกของคุณได้ภายใน 1 วัน!
CVE คืออะไร?
CVE ถ้าให้พูดเข้าใจง่าย ๆ คือ พจนานุกรมที่รวบรวมช่องโหว่ระดับความเสี่ยงต่ำจนไปถึงระดับรุนแรงในแต่ละซอฟต์แวร์นั่นเอง ซึ่ง CVE เหล่านี้ จะถูกออกโดย MITRE ซึ่งเป็นองค์กรที่ไม่แสวงหากำไรจากประเทศสหรัฐอเมริกาโดยมี Department of Homeland Security (DHS) และ Cybersecurity and Infrastructure Security Agency (CISA) เป็นผู้สนับสนุน
ซึ่ง CVE เหล่านี้ จะถูกนำไปใช้งานโดย Cybersecurity Expert เช่น Security Analyst เพื่อตรวจจับการโจมตีใหม่ ๆ หรือ Penetration Tester สำหรับการทดสอบเจาะระบบนั่นเอง อีกทั้ง CVE ยังเป็นเหมือนรางวัลของเหล่า Security Researcher เพราะบาง CVE นั้น มีขั้นตอนในการหาที่ซับซ้อนและช่องโหว่ที่เจอค่อนข้างรุนแรง ยิ่งเจอช่องโหว่ในบริษัทที่มีชื่อเสียงและแอปพลิเคชันที่ได้รับความนิยมยิ่งเพิ่มคุณค่าให้กับ CVE นั้น ๆ
จะเห็นได้ว่าการขอ CVE ช่องโหว่นั้น ไม่จำเป็นที่จะต้องมีความรุนแรงสูงก็สามารถ
ขอ CVE ได้แล้ว ผมขอยกตัวอย่าง Timeline ของผมที่เจอ CVE ทั้งหมด 7 ตัวในปี 2024 เพื่อเป็นแนวทางให้กับเพื่อน ๆ พี่ ๆ ที่อยากจะใช้เวลาว่างในการหา CVE ครับ
Timeline
วันที่ 2 กันยายน 2024 — Watcharr 1.43.0 Privilege Escalation (CVE-2024–48827)
วันที่ 11 กันยายน 2024 — Operately 0.1.0 Remote Code Execution (CVE-2024–48093)
วันที่ 4 ตุลาคม 2024 — Watcharr 1.43.0 Authentication Bypass (CVE-2024–50634)
วันที่ 4 ตุลาคม 2024 — PyMOL 2.5.0 Remote Code Execution (CVE-2024–50636)
วันที่ 4 ตุลาคม 2024 — UnoPIM 0.1.3 Stored Cross-Site Scripting (CVE-2024–50637)
วันที่ 7 ตุลาคม 2024 — UnoPIM 0.1.4 Stored Cross-Site Scripting (CVE-2024–52305)
วันที่ 11 พฤศจิกายน 2024 — Ever® Traduora 0.20.0 Authentication Bypass (CVE-2024–53484)
ตัวอย่างช่องโหว่ Ever® Traduora 0.20.0 Authentication Bypass (CVE-2024–53484)
ส่วนวิธีการหา CVE ผมขอยกตัวอย่าง Proof of Concept (PoC) ของ Ever® Traduora รุ่น 0.20.0 ที่มีช่องโหว่ Authentication Bypass (CVE-2024–53484)
มาให้เพื่อน ๆ พี่ ๆ ดูเป็นแนวทางครับ
Ever® Traduora คืออะไร ?
มันคือเว็บที่พัฒนาแบบ Open Source สำหรับการแปลภาษายอดนิยม และมีดาวบน Github กว่า 2,000 ดาว และ 200 Fork
หน้าตาของแอปก็จะประมาณว่า สามารถสร้างโครงการข้างใน แล้วให้คนหลาย ๆ คนเข้ามาช่วยกันแปล ข้อความเป็นภาษาอื่น ๆ ได้ เช่น บริษัทอาจจะมีแอปพลิเคชัน ที่ใช้งานในอีก 10 ภาษา เราก็เอาข้อความจุดต่าง ๆ ในแอปพลิเคชันมาใส่ไว้
เริ่มแรกผมทำการติดตั้งตัวแอปพลิเคชัน Ever® Traduora บนคอมพิวเตอร์ตัวเองก่อน และลองใช้งานฟังก์ชันต่าง ๆ เพื่อทำความเข้าใจกับระบบก่อน
ในตัวอย่างการโจมตีนี้ผมจะสร้างบัญชีสิทธิ์ต่ำ เอาไว้เป็นแฮกเกอร์ และต้องการจะยกระดับสิทธิ์ตัวเองเป็นสิทธิ์ผู้ดูแลระบบให้จงได้
ซึ่งฟังก์ชันที่ผมจะให้ความสำคัญเป็นหลักคือฟังก์ชันที่มีการใช้งานการยืนยันตัวตนเพื่อเข้าสู่ระบบ (Authentication) หรือว่าการ Login นั้นเอง
หลังจากนั้นใช้เครื่องมือในการทดสอบระบบอย่าง Burp Suiteในการช่วยหาช่องโหว่ และพบว่าเมื่อเข้าสู่ระบบสำเร็จด้วย API ชื่อ /api/v1/auth/signup เว็บแอปพลิเคชันจะมีการตอบกลับค่า Access Token กลับมา ดังนี้
"accessToken": "<ค่า JWT>"
ซึ่งค่า JWT (JSON Web Token) นั้น การจะสร้างหรือแก้ไขได้อย่างถูกต้อง จะต้องมีการถูก ลงลายเซ็นดิจิทัล (Digital Signature) ด้วย กุญแจลับ (JWT Signing Key)
แต่ถ้าหากกุญแจลับที่ว่านั้น ไม่ได้มีการสุ่มใหม่เป็นค่าที่ปลอดภัย ในการติดตั้งแอปพลิเคชัน ก็อาจสามารถทำให้แฮกเกอร์แกะเอากุญแจลับ จากโค้ดที่เป็น Open Source ไปใช้สร้างค่า Access Token ใด ๆ ในการเข้าสู่ระบบเพื่อเป็นบัญชีผู้ดูแลระบบก็ได้ โดยไม่จำเป็นต้องมีชื่อผู้ใช้งาน และรหัสผ่านจริง ๆ
ลองเดากันหน่อยว่า เว็บนี้ใช้ค่าอะไรเป็นค่าเริ่มต้นของ JWT Signing Key และมีการสุ่มหรือสร้างใหม่ตอนติดตั้งไหม? คำตอบก็คือใช้คำว่า
secret
(ที่ไม่ได้สุ่มใหม่เลย และไม่ได้เป็น secret อีกต่อไป จากการเปิดเผย CVE นี้ของผม!)
โดยทางผู้พัฒนา หวังว่าผู้ใช้งานจะไปตั้ง Environment Variable ชื่อ TR_SECRET เอง แต่ถ้าไม่ได้ตั้งเอาไว้… ก็จะเป็นคำว่า secret และรันแอปได้ปกติทุกอย่าง!!
ผลกระทบของช่องโหว่ Authentication Bypass
แฮกเกอร์สามารถใช้สิทธิ์ผู้ดูแลระบบ (จากการสร้าง JWT ปลอม)ในการเข้าถึงฟังก์ชันที่ไม่ควรจะสามารถทำได้ ยกตัวอย่างเช่น การยกสิทธิ์ บัญชีผู้ใช้งานทั่วไป (ของแฮกเกอร์) ให้กลายเป็น บัญชีผู้ดูแลระบบได้ เป็นต้น
ส่วนวิธีการสร้าง JWT Token นั้น มีขั้นตอน ดังนี้
1.เข้าสู่ระบบ ด้วยบัญชีผู้ใช้งานสิทธิ์ต่ำ และอ่านค่า Access Token (JWT) ของผู้ใช้งานสิทธิ์ต่ำ
2.หลังจากนั้นทำการ Decode ค่า JWT Token ออกมา เพื่อที่จะอ่านค่าใน Payload จะเห็นได้ว่าค่าบัญชีผู้ใช้งาน (sub) มีการใช้งาน Unique Identifier ซึ่งเป็นค่าสุ่มเอาไว้ใช้ในการระบุตัวตน ซึ่งการที่เราจะสร้าง JWT Token ของแอดมินได้ จึงจำเป็นที่จะต้องรู้ค่าบัญชีผู้ใช้งาน (sub) ของบัญชีแอดมินก่อน
เราสามารถใช้เว็บ https://jwt.io ในการดูเนื้อหา (Header, Payload และ Signature) ของ JWT รวมถึง สามารถใช้ในการแก้ไขได้
3.เมื่อทำการอ่านคู่มือใช้งาน API จะพบว่ามี API ชื่อ /users ที่อนุญาตให้ผู้ใช้งานสิทธิ์ต่ำแสดงผู้ใช้งานทั้งหมดในโครงการนั้น ๆ ในระบบได้ ซึ่งทำให้เราสามารถหาค่าบัญชีผู้ใช้งาน (sub) ของผู้ดูแลระบบได้สำเร็จ
4.หลังจากนั้นทำการแก้ไข JWT Payload และเปลื่ยนค่า Type เป็น admin และระบุค่า JWT Signing Key เป็น secret จะได้ JWT Token ที่ถูกปลอมแปลงสิทธิ์เป็นผู้ดูแลระบบขึ้นมา
เมื่อเรามี JWT Token ที่เราปลอมแปลงขึ้นมาใหม่ แฮกเกอร์สามารถใช้ JWT Token นั้น ในการใช้ฟังก์ชันต่าง ๆ ในระบบในสิทธิ์ผู้ดูแลระบบได้ โดยตัวอย่างต่อไปนี้จะเป็นการยกระดับสิทธิ์ผู้ใช้งานทั่วไป (ของแฮกเกอร์คนเดียวกันนี้) ให้เป็นสิทธิ์ผู้ดูแลระบบโดยการเรียกใช้งาน API ที่ทำการแก้ไข (PATCH) ข้อมูลของผู้ใช้งาน (ซึ่ง API นี้ใช้งานได้เฉพาะ สิทธิ์ผู้ดูแลระบบ!)
เมื่อเราทำการเข้าหน้าเว็บแอปพลิเคชันอีกครั้ง จะเห็นได้ว่าผู้ใช้งานสิทธิ์ต่ำ ก่อนหน้านี้ ถูกยกระดับสิทธิ์ (Privilege Escalation) เป็นผู้ดูแลระบบได้สำเร็จ
วิธีการขอหมายเลข CVE ?
สำหรับวิธีการขอ CVE เพื่อให้มั่นใจว่าจะไม่มีปัญหาตามมาทีหลัง เราควรทำตาม แนวทางการแจ้งช่องโหว่อย่างมีความรับผิดชอบ (Responsible Disclosure)
สรุปง่าย ๆ คือเราควรที่จะแจ้งผู้พัฒนาแอปพลิเคชันนั้น ๆ เมื่อมีการพบช่องโหว่ก่อน เพื่อให้เวลาทางผู้พัฒนาได้มีการออก การแก้ไขซอฟต์แวร์ (Security Patch) ตัวใหม่ก่อนที่เราจะเปิดเผยรายละเอียดช่องโหว่เอง หรือขอ CVE ผ่าน MITRE
ตัวอย่าง Security Patch ของ CVE นี้
การขอ CVE ผ่านฟอร์มของ MITRE
1.ให้ไปที่ https://cveform.mitre.org/ เพื่อกรอกแบบฟอร์มในการยื่นขอ CVE
2.ทำการกรอกข้อมูลในแบบฟอร์มให้ครบตามตัวอย่าง
3.ตรงส่วน Vulnerability Type ถ้าไม่มีประเภทช่องโหว่ที่ตรงกับของเราให้เลือก Other or Unknown (สำคัญ: ต้องใส่เลขรุ่นของแอปพลิเคชันที่มีช่องโหว่ ไม่งั้น MITRE จะไม่ออกเลข CVE ให้)
4.ใส่ข้อมูลให้ครบถ้วน ถ้าผู้พัฒนารับทราบช่องโหว่สามารถเลือก Yes ได้เลย
5.ในส่วน Discover(s)/Credits ถ้าทำหลายคนสามารถใส่ชื่อเพิ่มได้ ส่วน Reference(s) เอาไว้ใส่หลักฐาน เช่น Github Issue หรือ วิดีโอ PoC ใน YouTube เป็นต้น
6.เมื่อกดส่ง จะได้รับอีเมลตอบกลับอัตโนมัติจาก MITRE ถ้าเราอยากติดตาม หรือสอบถามข้อมูลเพิ่มเติม สามารถตอบกลับในอีเมลได้เลย
7.หลังจากนั้นทางทีมงาน MITRE จะทำการตรวจสอบความถูกต้อง และส่งอีเมลกลับมาอีกครั้งพร้อมเลข CVE ซึ่งระยะเวลาจะอยู่ระหว่าง 3 วันจนไปถึง 3 เดือน แต่โดยปกติจะตอบกลับภายใน 1 สัปดาห์
8.เมื่อได้เลข CVE ให้กลับไปที่ https://cveform.mitre.org/ อีกครั้ง แต่ครั้งนี้ให้เลือก Notify CVE about a publication และกรอกข้อมูลให้ครบถ้วน
9.กรอกเลข CVE และวันที่ที่ต้องการจะตีพิมพ์ CVE ส่วน Additional Information จะใส่ก็ได้ ไม่ใส่ก็ได้ หลังจากนั้นกดส่ง
10.ตรวจสอบ อีเมล จะเห็นว่ามีจดหมายจากทาง MITRE ส่งกลับมาแจ้งเตือน
11.ให้รออีก 1–3 วัน จะมีจดหมายส่งกลับมาว่า CVE ได้ถูกตีพิมพ์เป็นที่เรียบร้อย
ตรวจสอบ CVE
เราสามารถเข้าไปตรวจสอบ CVE ได้จากหลายที่
หน้าเว็บไซต์ CVE: https://www.cve.org/CVERecord?id=CVE-2024-53484
หน้าเว็บไซต์ NIST: https://nvd.nist.gov/vuln/detail/CVE-2024-53484
หน้าเว็บไซต์ Security Advisory ของ Github :
จบไปแล้วกับการหา CVE แบบง่าย ๆ หวังว่าบทความนี้จะมีประโยชน์ และช่วยทำให้หลาย ๆ คนเข้าใจวิธีการหา CVE มากขึ้น สำหรับบทความถัดไป ผมจะมาแชร์ประสบการณ์การล่า CVE ซอฟต์แวร์ค่ายเกมส์ระดับโลกอย่าง Electronic Arts (EA) ให้ฟังครับ!
