เมื่อแอปพลิเคชันหรือระบบไอที ถูกพัฒนาขึ้นมา ก็จะมีการทดสอบต่าง ๆ เพื่อทำให้แน่ใจว่า ระบบนั้น ๆ สามารถที่จะใช้งานได้ (Functional Testing) ตรงตามที่ระบุในเอกสาร การระบุข้อกำหนดซอฟต์แวร์ (Software Requirements Specification – SRS) โดยปกติข้อกำหนดมักจะแบ่งออกเป็น

1.Functional Requirement

ข้อกำหนดด้าน ฟีเจอร์ต่าง ๆ ที่ระบบควรจะทำหน้าที่ได้เป็นหลัก หรือที่เรียกว่า Functional Requirement เช่น การสมัครสมาชิก, โอนเงิน, ถอนเงิน ฯลฯ

2.Non-Functional Requirement

นอกเหนือจากนั้นก็ยังมีในส่วนของ Non-Functional Requirement ซึ่งก็คือ ข้อกำหนดอื่น ๆ ที่ไม่ใช่หน้าที่หลัก แต่ก็จำเป็นต้องทำ เช่น เรื่องของโทนสี, ความเร็วในการตอบสนอง หรือด้านความปลอดภัย

ประเด็นสำคัญของระบบไอที คือนอกเหนือจากระบบควรจะใช้งานได้ตามที่ควรจะเป็นแล้วนั้น ก็ควรจะต้องมีความปลอดภัยด้วยเช่นกัน ทั้งในแง่การเก็บรักษาข้อมูลที่ควรเป็นความลับ (Confidentiality – C), การป้องกันการแก้ไขที่ไม่ควรถูกแก้ (Integrity – I) และ การทำให้ระบบพร้อมใช้งาน (Availability – A) ตามหลัก CIA Triad ขั้นพื้นฐานของ IT Security นั่นเอง

Vulnerability Assessment and Penetration Testing (VAPT)

ในหลาย ๆ ซอฟต์แวร์ตอนที่มีการทำเอกสาร ข้อกำหนดของ ข้อเสนอโครงการ (Request For Proposal – RFP) ในหน่วยงานเอกชน หรือ TOR (Terms of Reference) ของหน่วยงานราชการ เพื่อจัดซื้อจัดจ้างการพัฒนาซอฟต์แวร์ ก็มักจะมีส่วนของ ข้อกำหนดด้านความปลอดภัยขั้นต่ำ เช่น ให้เขียนโค้ดโดยระมัดระวังความเสี่ยงตามเอกสาร OWASP เช่น OWASP Top 10 หรือ OWASP ASVS (Application Security Verification Standard) รวมถึงมีการส่งผลการทดสอบด้านความปลอดภัยของระบบ (Security Testing) ว่ามีการแก้ไขช่องโหว่ต่าง ๆ ที่ถูกตรวจพบ ก่อนการส่งมอบงาน

ไม่ว่าจะเป็น Vulnerability Assessment หรือ Penetration Testing ซึ่งทั้งสองอย่างนี้ก็เป็นเหมือน กำแพงหนึ่งชั้น (Layer) ที่จะคอยลดความเสี่ยงระบบจากภัยคุกคามต่าง ๆ ตามหลัก Defence in Depth เหมือนบ้านมีรั้ว แล้วยังต้องมี ตู้เซฟ มีน้องสุนัขเฝ้ายาม มีกล้องวงจรปิด มีสัญญาณกันขโมยด้วย เผื่อว่าถ้าหากการป้องกันชั้นใดชั้นหนึ่ง ถูกข้ามผ่าน (=แตก) ก็ยังมีการป้องกันชั้นถัด ๆ ไปช่วยยื้อเวลาได้อีก ซึ่งเป็นสิ่งที่ดีและควรจะทำ

Vulnerability Assessment (VA)

ผลจากการใช้โปรแกรมอัตโนมัติทำการสแกนระบบเพื่อหาช่องโหว่เบื้องต้น จะเรียกกันว่าการทำ Vulnerability Assessment (VA) เป็นการทำ Security Testing ในรูปแบบ Automated Testing คือ ทดสอบแบบอัตโนมัติ เน้นใช้โปรแกรมทำงานหาจุดอ่อนแทนคน

ถ้านึกภาพไม่ออก ว่าการสแกนช่องโหว่มันจะหน้าตาเป็นยังไง ตัวอย่างโปรแกรม OWASP ZAP ที่ใช้ทำ VA สแกนหาช่องโหว่เว็บได้ก็หน้าตาประมาณนี้

ตัวอย่างการใช้ OWASP ZAP ในการ Scan หาช่องโหว่

การใช้งานก็ง่ายมาก ๆ หลังจากดาวน์โหลด (https://www.zaproxy.org/download/) และเปิดโปรแกรมขึ้นมาแล้ว จากนั้นก็แค่ 

1. ไปที่เมนู “Quick Start” ใส่ URL ของเว็บ ลงไปในช่อง “URL to attack:”
2. กดปุ่ม “Attack” รอหมุน ๆ สักพัก
3. ในเมนู “Alerts” จะมีการแสดงรายชื่อ ช่องโหว่ ขึ้นมา

จบการทำ VA สแกนเบื้องต้น ในการคลิก 3 ครั้ง! จบบทความ! .. เดี๋ยวก่อน ยังไม่จบ …

ผลของการทำ VA สแกน จะได้ออกมาเป็น

• รายชื่อช่องโหว่
• คำอธิบายของแต่ละช่องโหว่
• ค่าความเสี่ยงของแต่ละช่องโหว่
• แนวทางการแก้ไข

โปรแกรมทำ VA ส่วนมากจะรองรับการสร้างไฟล์ รายงานเป็นผล VA สแกนโดยอัตโนมัติ แต่ในองค์กรที่มีระบบ Ticket อาจเชื่อมต่อโปรแกรมทำ VA เพื่อส่งผลต่อไปยังระบบอื่น ๆ เช่นแจ้งเตือนใน Slack, สร้าง Ticket ใน Jira หรือ Gitlab หรือสร้างการ์ดใน Trello อัตโนมัติ เพื่อให้ทางผู้เกี่ยวข้องตรวจสอบและจัดการช่องโหว่ที่ถูกตรวจสอบพบในขั้นตอนต่อไป

โดยทั่วไปการสั่งสแกน VA มักจะแบ่งออกเป็น 2 แบบได้แก่

• Non-Credentialed Scan คือการสแกน VA ที่ไม่ต้องใส่รหัสผ่านของระบบปฏิบัติการ โดยหลักการคร่าว ๆ ถ้าไม่มีรหัสผ่าน โปรแกรม VA จะสแกนหา Service ที่เปิดอยู่และพยายามเชื่อมต่อเข้าไปเพื่อตรวจสอบหมายเลขรุ่น เพื่อนำไปเทียบกับรุ่นที่มีข้อมูลว่ามีช่องโหว่ รวมถึงการตั้งค่าที่สามารถตรวจสอบได้เฉพาะในส่วนที่ไม่ต้องใช้รหัสผ่าน
  
• Credentialed Scan คือการสแกน VA ที่ต้องใส่รหัสผ่านของระบบปฏิบัติการ เช่นรหัสผ่าน SSH หรือ Domain User เพื่อให้โปรแกรม VA เข้าสู่ระบบไปสแกนหาช่องโหว่อย่างละเอียดและถูกต้องมากยิ่งขึ้น โดยทั่วไปการทำ Credentailed Scan มักทำเพื่อต้องการหาว่า ระบบปฏิบัติการที่ใช้งานขาดแพตช์ด้านความปลอดภัยใดบ้าง แต่จะใช้เวลาในการสแกนที่นานกว่าในแบบ Non-Credentialed Scan

บางโปรแกรม VA อาจมีรูปแบบอื่น ๆ อีกเช่นการตรวจสอบไฟล์การตั้งค่าของอุปกรณ์เครือข่ายต่าง ๆ หรือมีการสแกนในรูปแบบที่จะต้องติดตั้งโปรแกรม Agent ในเครื่องเป้าหมายที่จะทำการสแกนเป็นต้น

ในส่วนของข้อดีและข้อสังเกตของ VA เมื่อเทียบกับ Pentest จะเป็นดังนี้

ข้อดีของการทำ VA: คือ ง่าย, เร็ว และถูก

• ง่าย: ถ้าหากติดตั้งโปรแกรม VA เรียบร้อยแล้ว การทำ VA มักจะทำได้โดยง่าย ไม่จำเป็นต้องมีผู้เชี่ยวชาญมาทำก็ได้ แค่ใส่ URL เว็บ ชื่อ Domain หรือหมายเลข IP และกด Scan นั่งรอผลสร้างเป็นรายงานอัตโนมัติ
  
• เร็ว: ใช้ระยะเวลาในการทดสอบไม่นาน… เมื่อเทียบกับการใช้คนมาทดสอบ
  
• ถูก: มีค่าใช้จ่ายที่มักจะถูกกว่าการทำ Pentest เพราะไม่จำเป็นต้องใช้ผู้เชี่ยวชาญและใช้ระยะเวลาในการทำไม่นาน

ข้อสังเกตของการทำ VA: คือ ไม่ละเอียด ไม่ครอบคลุม และอาจแจ้งผลผิดพลาดได้

• การทำ VA มักจะได้ผลการทดสอบที่ไม่ละเอียด ส่วนมากจะเน้นเฉพาะช่องโหว่ที่เกิดจากการตั้งค่าไม่ปลอดภัยเบื้องต้น (Security Misconfiguration) และการใช้ซอฟต์แวร์สำเร็จรูปรุ่นเก่าที่มีช่องโหว่ที่เคยถูกเปิดเผยต่อสาธารณะไปแล้ว
  
• ถ้าหากมีการตั้งค่าโปรแกรม VA ไม่เหมาะสม ในส่วนของฟังก์ชันเว็บแอปพลิเคชัน ที่จำเป็นต้องมีการยืนยันตัวตนก่อน อาจจะไม่ได้ถูกทดสอบไปด้วย
• มักจะมีผลการทดสอบที่ไม่แม่นยำรวมอยู่ด้วย เช่น โปรแกรม VA แจ้งว่ามีช่องโหว่แต่จริง ๆ ไม่มี (False Positive) หรือแจ้งว่าไม่มีช่องโหว่แต่จริง ๆ มีช่องโหว่นั้น ๆ (False Negative)
• มักจะกำหนดค่าความเสี่ยง (Risk) ของช่องโหว่ โดยไม่ได้คำนึงถึงบริบทจริง ๆ ของระบบนั้น ๆ เช่นช่องโหว่ที่ความเสี่ยง ควรเป็นต่ำ (Low) แต่ระบุเป็นความเสี่ยงสูงมาก (Critical)

• ไม่สามารถใช้โปรแกรม VA ทดสอบระบบ ที่มีความซับซ้อนในการใช้งาน หรือต้องใช้งานฟังก์ชันผ่านหน้าจอแอปพลิเคชัน ตามกระบวนการขั้นตอนเฉพาะเจาะจงได้อย่างมีประสิทธิภาพ

หมายเหตุ: ทางผู้เขียนอธิบาย ข้อดีและข้อสังเกตของการทำ VA โดยทั่วไป แต่ต้องบอกก่อนว่า แต่ละโปรแกรมที่ใช้ทำ VA ก็ไม่เหมือนกัน บางโปรแกรมอาจจะไม่มีข้อสังเกตที่อธิบายมา และบางโปรแกรมอาจไม่มีข้อดีตามที่อธิบายมาก็เป็นไปได้

ตัวอย่างโปรแกรมที่ใช้ทำ VA มักจะแบ่งออกเป็นการทำ 2 ประเภทคือ

• โปรแกรมทำ VA ระดับ Host
  คือเป็นโปรแกรม VA ที่เน้นการตรวจสอบระดับ Host โดยการระบุ หมายเลขไอพี หรือชื่อ Domain เข้าไป เพื่อให้โปรแกรม VA ทำการตรวจสอบหาช่องโหว่ในทุก Service
  • เสียเงิน: Tenable Nessus, Rapid7 InsightVM (Nexpose), Qualys Vulnerability Management
  • ฟรี: OpenVAS และ อื่น ๆ ที่อาจไม่ใช่โปรแกรม VA โดยตรงแต่พอใช้ทำได้ เช่น Nmap Script Engine (NSE) และ Metasploit Framework เป็นต้น

ตัวอย่างโปรแกรม OpenVAS ซึ่งใช้ทำ VA ระดับ Host

• โปรแกรมทำ VA ระดับ เว็บแอปพลิเคชัน
  คือเป็นโปรแกรม VA ที่เน้นการตรวจสอบระดับเว็บแอปพลิเคชัน โดยการระบุค่า URL เข้าไป เพื่อให้โปรแกรม VA ทำการตรวจสอบหาช่องโหว่ โดยเน้นเฉพาะส่วนของการทำงานเว็บ ซึ่งโปรแกรม VA ในระดับเว็บแอปพลิเคชัน มักจะเก่ง และหาช่องโหว่ในเว็บแอปพลิเคชัน ได้ดีกว่า โปรแกรมทำ VA ระดับ Host
  • เสียเงิน: Burp Suite Professional, Acunetix Vulnerability Scanner, Invicti (NetSparker), HCL AppScan
  • ฟรี: OWASP ZAP, nuclei, nikto, Arachni

ตัวอย่างโปรแกรม OWASP ZAP ซึ่งใช้ทำ VA ระดับ เว็บแอปพลิเคชัน

ในบทความนี้จะเน้นในส่วนของ OWASP ZAP และ OpenVAS เป็นหลัก ซึ่งก็คือ Version ที่เป็นของฟรีนั่นเอง 

ต่อมาในส่วนของการหาช่องโหว่นั้น โดยความคิดเห็นส่วนตัวของผู้เขียนจะแบ่งช่องโหว่ออกเป็น 2 ประเภท เพื่อที่จะสามารถอธิบายให้คนอื่นเข้าใจง่าย ๆ คือ

1. ช่องโหว่ในแอปพลิเคชันที่เขียนเอง
2. ช่องโหว่ในแอปพลิเคชันสำเร็จรูป

1.ช่องโหว่ของแอปพลิเคชันที่เขียนเอง

คือช่องโหว่ที่เกิดจากโค้ดที่มีการเขียนเอง หรือนำระบบสำเร็จรูปที่มีอยู่เดิมมาปรับแต่ง แก้โค้ดให้ตรงตามข้อกำหนดที่ต้องการ ในส่วนของประเภทนี้ สาเหตุของช่องโหว่ มักจะเกิดจากการเขียนโค้ดที่ไม่ปลอดภัย และใช้ วิธีการอ้างอิงช่องโหว่ตาม หมายเลข CWE (Common Weakness Enumeration)  ตัวอย่างเช่น ช่องโหว่ SQL Injection ก็จะอ้างอิงด้วยหมายเลข CWE-89 (https://cwe.mitre.org/data/definitions/89.html) ได้ 

กล่าวคือ CWE จะเป็นหมายเลข สำหรับอ้างอิงไปยังชื่อช่องโหว่ใด ๆ แต่ไม่เจาะจงว่า เป็นกรณีของช่องโหว่นั้นในซอฟต์แวร์อะไร รุ่นอะไร จึงเหมาะกับการที่ใช้อ้างอิง กรณีช่องโหว่ที่พบในแอปพลิเคชันที่พัฒนาขึ้นเอง จะเรียกว่า CWE เป็นหมวดหรือกลุ่มของช่องโหว่ก็อาจจะได้

ฐานความรู้รายชื่อและคำอธิบายแต่ละ CWE ถูกสร้างและดูแลโดยหน่วยงานของอเมริกาชื่อ MITRE และยังมีการจัดอันดับ CWE จำนวน 25 รายการแรกที่เป็นช่องโหว่ที่อันตรายที่สุดของซอฟต์แวร์ (https://cwe.mitre.org/top25/) ในแต่ละปีอีกด้วย

ตัวอย่างเช่น ช่องโหว่ที่ร้ายแรงที่สุดตามการจัดอันดับ CWE 25 อันดับแรก ของปี 2022 จะเป็นตามรายชื่อในรูปด้านล่างนี้

2.ช่องโหว่ของแอปพลิเคชันสำเร็จรูป

คือช่องโหว่ที่พบในแอปพลิเคชันสำเร็จรูป ไม่ว่าจะเป็น เว็บ CMS, ระบบปฏิบัติการที่ใช้งาน, เว็บสำเร็จรูปที่ซื้อมาติดตั้งพร้อมใช้งาน, ซอฟต์แวร์ของ Service เว็บหรือฐานข้อมูล, Web Framework และ Library ต่าง ๆ  เป็นต้น 

โดยความคิดเห็นส่วนตัวของผู้เขียนจะแบ่งช่องโหว่ในประเภทที่ 2 แยกย่อยออกเป็น 3 ประเภทย่อยไปอีก ตามสาเหตุของช่องโหว่ ก็คือ

2.1 ไม่ได้อัปเดต

เกิดจากการที่มีคนค้นพบ ช่องโหว่ในซอฟต์แวร์สำเร็จรูป และแจ้งข้อมูลนั้นไปยังผู้พัฒนาซอฟต์แวร์เพื่อทำการแก้ไข และออกรุ่นใหม่ (แพตช์) แต่ว่าทางเจ้าของระบบ (ลูกค้าที่ซื้อซอฟต์แวร์เหล่านั้นไปใช้งาน) ยังไม่ได้ทำการอัปเดตแพตช์ จึงทำให้ยังมีช่องโหว่อยู่นั่นเอง

ในหลาย ๆ ครั้งพบว่า เจ้าของระบบ ไม่กล้าอัปเดตซอฟต์แวร์ เพราะกลัวจะกระทบต่องาน ในระบบที่กำลังดำเนินการได้อย่างราบรื่นอยู่ หรือไม่สามารถอัปเดตได้เพราะไม่ได้ต่อสัญญาให้ทางผู้พัฒนาเข้ามาอัปเดตและสนับสนุนให้ในรุ่นถัด ๆ ไป (Maintenance service Agreement – MA) เลวร้ายไปกว่านั้นคือ บางครั้งพบว่า ซอฟต์แวร์ที่มีช่องโหว่นั้นเลิกพัฒนาไปแล้ว ไม่มีการออกแพตช์มาแก้ไข!

รูปจาก https://wptavern.com/get-email-alerts-for-security-vulnerabilities-in-your-wordpress-plugins 

ความแตกต่างหลัก ๆ ในการบริหารจัดการความเสี่ยงของช่องโหว่ที่พบในแอปพลิเคชันสำเร็จรูปเทียบกับ ช่องโหว่ในแอปพลิเคชันที่เขียนเอง คือ ในกรณีของแอปพลิเคชันสำเร็จรูปนั้น เรามักจะไม่สามารถหรือไม่ควรที่จะเข้าไปแก้ไขโค้ดเพื่อปิดช่องโหว่เอง แต่ควรให้ผู้พัฒนาแอปพลิเคชันนั้น ๆ แก้ไขและปล่อยแพตช์ซอฟต์แวร์รุ่นใหม่ออกมาให้เรานำไปใช้แทน เพราะว่าบางครั้งเราอาจจะได้ซอฟต์แวร์มาโดยไม่มีโค้ดแก้ไขเองไม่ได้ หรือด้วยลิขสิทธิ์ของซอฟต์แวร์ที่ไม่ให้เราดัดแปลง หรือถ้าหากเราแก้ไขเอง อาจทำให้เกิดข้อผิดพลาดอื่น ๆ เช่นไม่สามารถอัปเดตระบบในอนาคตได้ เพราะเข้ากันไม่ได้กับโค้ดจากเจ้าของซอฟต์แวร์ในรุ่นใหม่ ๆ 

ช่องโหว่ของแอปพลิเคชันสำเร็จรูปมักจะถูกอ้างอิงโดยหมายเลข CVE (Common Vulnerabilities and Exposures) ซึ่ง CVE จะระบุเจาะจงช่องโหว่ (ส่วนมากจะตาม CWE) กับซอฟต์แวร์ใดซอฟต์แวร์หนึ่ง ในรุ่นใดรุ่นหนึ่ง

ตัวอย่างเช่นผู้เขียน เคยพบและแจ้งช่องโหว่ XML External Entity Injection (XXE) ในซอฟต์แวร์ Cisco Prime Infrastructure รุ่น 3.1.6 ซึ่งเป็นรุ่นใหม่ล่าสุด ณ วันที่พบช่องโหว่และได้รายงานรายละเอียดของช่องโหว่นี้ให้กับทาง Cisco (https://www.cisco.com/c/en/us/support/docs/csa/cisco-sa-20170621-piepnm1.html) เพื่อทำการแก้ไข เมื่อทาง Cisco ทำการยืนยันแล้วว่าช่องโหว่มีอยู่ในซอฟต์แวร์นั้น ๆ รุ่นนั้น ๆ จริงก็จะติดต่อกับทาง MITRE เพื่อออกหมายเลข CVE โดยมีจุดประสงค์เพื่อที่จะใช้ในการ ติดตามและอ้างอิงช่องโหว่นั้น ๆ ว่าเป็นช่องโหว่เดียวกันซึ่งจะอ้างอิงด้วยหมายเลข CVE เดียวกันนั่นเอง

ตัวอย่างรายละเอียด CVE-2017-6662 จากฐานความรู้ CVE ของ MITRE  https://nvd.nist.gov/vuln/detail/CVE-2017-6662 

สำหรับในส่วนของช่องโหว่ที่เกิดจากโค้ดที่พัฒนาขึ้นมาสำหรับระบบใดระบบหนึ่ง ที่ไม่ใช่ซอฟต์แวร์สำเร็จรูป ที่มีการนำไปใช้งานอย่างค่อนข้างแพร่หลาย หรือภายใต้เงื่อนไขการกำหนดเลข CVE จะไม่สามารถหรือไม่ควรมีหมายเลข CVE กำกับช่องโหว่นั้น ๆ

ในแต่ละปีจะมีจำนวนหมายเลขช่องโหว่ CVE ถูกกำหนดขึ้นมาเป็นจำนวนมาก เพื่ออ้างอิงและติดตามถึงช่องโหว่ต่าง ๆ ที่ถูกค้นพบในซอฟต์แวร์สำเร็จรูป ตัวอย่างสถิติจาก Dashboard ของโปรแกรม VA อย่าง OpenVAS แสดงให้เห็นว่าในปี 2022 นี้มีช่องโหว่ในฐานข้อมูล CVE กว่า สองแสนช่องโหว่แล้ว !

2.2 ตั้งค่าไม่ปลอดภัย

นอกจากช่องโหว่ในแอปพลิเคชันสำเร็จรูปที่ไม่ได้อัปเดตแล้ว ก็จะมีกรณีของซอฟต์แวร์สำเร็จรูปที่ตั้งค่ามาอย่างไม่ปลอดภัย ไม่ว่าจะเป็นค่าเริ่มต้นที่ไม่ปลอดภัย ที่ไม่ได้ถูกแก้ไข

ตัวอย่างช่องโหว่ที่เกิดจากการตั้งค่าไม่ปลอดภัยที่พบบ่อย ๆ เช่น การใช้รหัสผ่านที่สามารถถูกคาดเดาได้ง่าย เช่นคำว่า admin

หรือการใช้งาน Service ที่ไม่ได้ตั้งค่า หรือปิดการตั้งค่า ที่จะยืนยันตัวตนผู้ใช้งาน (ทำให้ใครก็ได้ที่มี Network-Level Access จะสามารถใช้งานระบบได้) เช่น Service ของฐานข้อมูลต่าง ๆ เช่น Elasticsearch

รูปจาก https://book.hacktricks.xyz/network-services-pentesting/9200-pentesting-elasticsearch 
โดยเฉพาะอย่างยิ่งในระบบที่มีหมายเลขไอพี ที่สามารถเข้าถึงได้จากอินเทอร์เน็ต จะมีเหล่าแฮกเกอร์คอยสแกน และตามหาช่องโหว่เหล่านี้อยู่เป็นประจำ ตัวอย่างการค้นหา Service ชื่อ Elasticsearch ที่ตั้งค่าไม่ปลอดภัย โดยไม่มีการยืนยันตัวตน ผ่านเว็บไซต์ Shodan.io (https://www.shodan.io/search?query=elasticsearch+country%3Avn+port%3A9200)

2.3 Zero-Day

ช่องโหว่ Zero-Day คือ ช่องโหว่ที่เจ้าของระบบมีเวลา 0 วันในการแก้ไข=ไม่มีเวลาในการแก้ไข=ยังไม่มีแพตช์อย่างเป็นทางการจากผู้พัฒนาซอฟต์แวร์ แต่อาจมีวิธีการชั่วคราว (Workaround) มาช่วยลดความเสี่ยงได้ เช่น ช่องโหว่ Eternalblue สามารถปิดการรองรับ SMB รุ่น 1 หรือ ช่องโหว่ Log4Shell สามารถปิด JndiLookup  ถ้ามีแพตช์ออกมาแก้ไขแล้ว ช่องโหว่ Zero-Day ก็เปลี่ยนสถานะเป็นช่องโหว่ธรรมดา หรือถ้าโค้ดโจมตีช่องโหว่ (Exploit) ถูกแจกหรือขายหลังมีแพตช์ เร็ว ๆ หน่อยก็มักจะเรียก N-Day Exploit เช่น 1-Day Exploit คือ Exploit หลังแพตช์ออก 1 วัน ส่วนหมายเลข CVE จริง ๆ ไม่จำเป็นต้องมีก็ได้ ถ้ามีคนรู้น้อย หรือ ผู้พัฒนาซอฟต์แวร์กับคนรายงานช่องโหว่ ไม่มีนโยบายขอหมายเลข CVE มันก็จะไม่มีนั่นเอง ปัจจุบันมีช่องโหว่ที่โดนแพตช์ในแอปพลิเคชันสำเร็จรูปเยอะแยะที่ไม่มีหมายเลข CVE 

อาจจะเข้าใจยากสำหรับคนที่ไม่ได้ทำงานเกี่ยวกับการบริหารจัดการช่องโหว่ตรง ๆ สามารถดูเพิ่มเติมได้จากรูปที่ผู้เขียนทำไว้ด้านล่างนี้

โดยทั่วไปแล้วการทำสแกน VA จะไม่ได้ครอบคลุมการตรวจสอบพบช่องโหว่ที่เป็น Zero-Day แต่ช่องโหว่ Zero-Day อาจถูกพบได้จากการทำ Pentest ที่ไปเน้นเจาะในส่วนของแอปพลิเคชันสำเร็จรูป (ซึ่งมักจะไม่ค่อยเน้นกัน เพราะมักจะถือว่าถ้าอัปเดตรุ่นล่าสุด ก็ค่อนข้างปลอดภัยอยู่แล้ว) 

Penetration Testing (Pentest – PT)

นอกเหนือจากการทำ VA ก็จะมีการทำ Penetration Testing (Pentest – PT) ที่มักจะ มีการทดสอบแบบ VA รวมไปอยู่แล้ว หรือใช้โปรแกรมอัตโนมัติมาสแกนหาช่องโหว่ แต่ว่า นอกเหนือจากช่องโหว่ ที่โปรแกรม VA หาเจอแล้วนั้น จะมีผู้เชี่ยวชาญด้านการทดสอบเจาะระบบ (Penetration Tester) เข้ามาทดสอบเพิ่มเติม หรือเรียกว่าการทำ Manual Testing ในการหาช่องโหว่ที่โปรแกรม VA ไม่สามารถหาได้ รวมถึงการขยายผลและยืนยันผลการสแกนที่ได้รับจากโปรแกรม VA เพื่อประเมินความเสี่ยงและแก้ไขความถูกต้อง 

ตัวอย่างโปรแกรมที่มักจะถูกใช้ในการทำ Pentest เว็บแอปพลิเคชันคือ Burp Suite Professional ซึ่งจำเป็นต้องใช้คนมาวิเคราะห์และทดสอบเพิ่มเติม นอกเหนือจากการตรวจสอบผลของโปรแกรม VA เพียงอย่างเดียว

ตัวอย่างช่องโหว่ที่การทำ VA อาจหาไม่เจอแต่การทำ Pentest อาจจะหาเจอ เช่น การที่เราสามารถใช้ คูปองลดราคา 500 บาท ที่ควรใช้ได้ 1 ครั้ง แต่นำไปใช้งานซ้ำ ๆ ได้มากกว่า 1 ครั้ง หรือใช้เป็นส่วนลดในมูลค่าที่เกินกว่า 500 บาทที่ควรจะเป็น ในส่วนของการทำ VA โปรแกรมอัตโนมัติจะไม่เข้าใจ Business Logic ของระบบว่า คูปองลดราคามีหน้าตาเป็นอย่างไร? รวมถึงจะไม่เข้าใจว่า ควรจะลดได้กี่บาท? ส่งผลให้เป็นไปได้ยากมากที่โปรแกรม VA จะเจอช่องโหว่ในกรณีนี้ ควรต้องทำ Pentest เพื่อตรวจสอบหาช่องโหว่เพิ่มเติมนั่นเอง

ในบทความนี้ผู้เขียนจะไม่ลงลึกถึงรายละเอียดเกี่ยวกับการทำ Pentest มากนัก แต่จะเน้นหนักไปที่การทำ VA

ก่อนอื่นจะขอตอบคำถามคาใจใครหลาย ๆ คน ที่มักจะถูกถามมาบ่อย ๆ (FAQ) ก่อนจะไปที่ตัวอย่างการลงมือทำแบบง่าย ๆ

FAQ #1 การทำ VA ต้องทำบ่อยแค่ไหนและเริ่มต้นยังไง?

คำแนะนำความถี่ของการทำ VA โดยความคิดเห็นส่วนตัวของผู้เขียนคือ สำหรับระบบภายในที่ไม่สามารถเข้าถึงได้จากอินเทอร์เน็ตโดยตรง ควรทำอย่างน้อยทุกระบบปีละ 1 ครั้ง หรือเมื่อมีการพัฒนาระบบใหม่ หรือมีการแก้ไขระบบที่มีนัยสำคัญ ในส่วนของระบบที่เข้าถึงได้จากอินเทอร์เน็ตควรทำสแกน VA ทุกเดือนหรือทุกสัปดาห์ อาจตั้งเป็นการสแกนอัตโนมัติและส่งรายงานมาทางอีเมลหรือระบบภายในก็ได้

อันที่จริงความถี่ของการทำ VA อันนี้ขึ้นอยู่กับหลายปัจจัยมาก ไม่ว่าจะเป็นความเสี่ยงของแต่ละระบบที่ไม่เท่ากัน และนโยบายของแต่ละบริษัทที่บริหารความเสี่ยงไม่เหมือนกัน รวมไปถึง มาตรฐานที่บริษัทจะต้องทำตาม เช่น ถ้ายึดตามมาตรฐาน PCI DSS (Payment Card Industry Data Security Standards) ของบริษัทที่เก็บหรือส่งผ่านข้อมูลบัตรเครดิต (Cardholder Data – CD) อย่างหมายเลขบัตรเครดิต (Primary Account Number – PAN) จะต้องทำ VA ทั้งระบบเครือข่ายภายใน และภายนอก และมีการระบุความถี่ของการสแกน VA ไว้ที่ ปีละ 4 ครั้ง ทุก ๆ 3 เดือน หรือเรียกว่าทุกไตรมาสนั่นเอง

FAQ #2 ข้อแตกต่างระหว่าง VA กับ Pentest?

ในกรณีทั่วไป การทำสแกนด้วยโปรแกรม Vulnerability Assessment (VA) ในแง่ของโอกาสในการค้นพบช่องโหว่ และการลดความเสี่ยง (Risk Reduction) มักจะมีประสิทธิภาพน้อยกว่า การทำ Pentest

รูปจาก https://twitter.com/coffeetocode/status/794593057282859008/photo/1 

โดยผู้เขียนอยากจะยกข้อมูลเพิ่มเติมในส่วนของการเปรียบเทียบ VA กับ Pentest มาจากเอกสาร Penetration Testing Guidance รุ่น 1.1 ของ PCI (https://listings.pcisecuritystandards.org/documents/Penetration-Testing-Guidance-v1_1.pdf)  ดังนี้

หมายเหตุ: ข้อมูลในตารางนี้มีไว้อ้างอิงสำหรับกรณี VA และ Pentest ตามมาตรฐาน PCI DSS เท่านั้น อาจจะแตกต่างกับมาตรฐานอื่น ๆ หรือนโยบายของแต่ละบริษัท ทางผู้เขียนหยิบยกมาเป็นตัวอย่างเท่านั้น

	การสแกน VA	การทำ Pentest
จุดประสงค์	หาช่องโหว่ในระบบด้วยวิธีการอัตโนมัติ ที่ถ้าถูกแฮกช่องโหว่เหล่านั้น อาจทำให้เกิดผลกระทบในทางที่ไม่ดีต่อระบบและข้อมูลภายในได้	หาช่องโหว่ในระบบเหมือน VA ด้วยวิธีการอัตโนมัติแต่ตรวจสอบหาช่องโหว่เพิ่มเติม ที่โปรแกรมอัตโนมัติตรวจสอบไม่ได้รวมถึง ทดสอบโจมตีจริง ๆ ว่าช่องโหว่สามารถถูกโจมตีได้และจะเกิดผลกระทบอะไร
ทำเมื่อ	ปีละ 4 ครั้ง ทุก ๆ 3 เดือน (ทุกไตรมาส) หรือเมื่อมีการเปลี่ยนแปลงระบบที่มีนัยสำคัญ	ปีละ 1 ครั้ง หรือเมื่อมีการเปลี่ยนแปลงระบบที่มีนัยสำคัญ
วิธีการ	ใช้โปรแกรม VA เพื่อหาช่องโหว่อัตโนมัติและใช้คนมายืนยันผลที่ตรวจสอบพบว่ามีความถูกต้อง	ใช้ทั้งโปรแกรม VA เพื่อหาช่องโหว่อัตโนมัติ และใช้คนทำการตรวจสอบช่องโหว่เพิ่มเติม (Manual Testing)
รายงาน	มีการระบุค่าความเสี่ยงแต่ละช่องโหว่ ตามมาตรฐาน CVSS  รายงานผล VA สำหรับระบบเครือข่ายภายนอกต้องทำโดยบริษัทที่ PCI รับรอง (Approved Scanning Vendor – ASV) ส่วนรายงานผล VA สำหรับระบบเครือข่ายภายในต้องทำโดยบุคคลที่มีคุณสมบัติเหมาะสมเท่านั้น	รายงานมีการระบุ ผลการยืนยันการโจมตีในแต่ละช่องโหว่ รวมถึงผลการวิเคราะห์เพิ่มเติม ว่าผู้ไม่ประสงค์ดีสามารถใช้ประโยชน์อะไรจากช่องโหว่ที่พบได้อีก
ระยะเวลา	ทำในระยะเวลาอันสั้น โดยปกติแล้วใช้เวลาหลักนาทีต่อการสแกนระบบเป้าหมาย 1 เครื่อง (สแกนแบบ Non-Credentialed)	ใช้ระยะเวลาเป็นหลักวันหรือสัปดาห์ขึ้นกับจำนวนและความซับซ้อนของระบบเป้าหมายที่จะทำการทดสอบ

ซึ่งการทำ Pentest จะแบ่งแยกย่อยออกได้หลายรูปแบบ เช่น ตามข้อมูลที่ผู้ทดสอบเจาะระบบจะได้รับก่อนการดำเนินการทดสอบ ก็จะแบ่งเป็นแบบ Black box, Gray box และ White box

• Black box – ได้รับข้อมูลน้อยมาก

ผู้ทดสอบจะได้รับข้อมูลเกี่ยวกับระบบเป้าหมายน้อยมาก เช่น อาจจะรู้เฉพาะชื่อ URL หลักของเว็บ หรือรู้แค่หมายเลขไอพีของระบบ และทำการทดสอบ โดยเงื่อนไขสำคัญของทั้งการทำ VA และ Pentest คือ ทางผู้ทดสอบ จะต้องได้ Network-Level Access เข้าถึงระบบเป้าหมายที่จะทำการทดสอบได้

• Gray box – ได้รับข้อมูลบางส่วน

ผู้ทดสอบจะได้รับข้อมูลบางส่วนเกี่ยวกับระบบเป้าหมาย เช่น API Spec, User Account, Test Data คล้ายกับที่ Software Tester ได้รับ ในระหว่างการทำ Functional Testing โดยการทดสอบแบบ Gray box โดยปกติ จะรวมการทดสอบความเสี่ยง ที่อาจตรวจพบจากการทดสอบแบบ Black box ไปในตัว อยู่แล้ว เพราะว่า ในส่วนของระบบที่จะถูกทดสอบแบบมีข้อมูล ก็จะถูกทดสอบโดยแบบไม่มีข้อมูลไปด้วยนั่นเอง

• White box – ได้รับข้อมูลเยอะมาก

ผู้ทดสอบจะได้รับข้อมูลเยอะมาก จะได้เท่าที่ได้ถ้าทำแบบ Gray box แต่เพิ่มเติมในส่วนอื่น ๆ เช่นให้ บัญชีสำหรับเข้าไปในระบบปฏิบัติการที่ระบบทำงานอยู่ หรือให้โค้ดของโปรแกรมมาตรวจสอบด้วย ดังนั้นโดยปกติการทดสอบแบบ White box ก็มักจะรวมความเสี่ยง ที่อาจถูกตรวจพบจากการทดสอบในรูปแบบ Gray box และ Black box อยู่แล้วนั่นเอง

ยิ่งผู้ทดสอบได้รับ ข้อมูลมากเท่าไร ก็จะยิ่งหาความเสี่ยง หรือช่องโหว่ในการทำ Pentest ได้มีประสิทธิภาพมากขึ้นเท่านั้น แปลว่าการทำ Pentest แบบ White box จะเป็นการทดสอบที่มักจะพบช่องโหว่เยอะที่สุดในระยะเวลาเท่า ๆ กัน และการทดสอบแบบ Gray box ก็เป็นแบบกลาง ๆ ที่เจ้าของระบบอาจจะให้ข้อมูลบางส่วนที่สามารถให้กับทางผู้ทดสอบได้ โดยไม่เป็นการเปิดเผยข้อมูลที่เป็นความลับมากเกินไป

แต่ถ้าหากการทำ Pentest ไม่ได้เน้นที่จะหาช่องโหว่มากที่สุด แต่เน้นในเรื่องของความสมจริงของการทดสอบหาช่องโหว่ (Attack Simulation) ก็แน่นอนว่าควรทำแบบ Black box ที่เป็นคนนอกไม่มีข้อมูลมาลองแฮก หรือเป็นแบบ Gray box ที่มีบัญชีผู้ใช้งานสิทธิ์ต่าง ๆ เข้ามาทดสอบเป็นคนแฮก ก็จะสมจริง มากกว่าในรูปแบบ White box นั่นเอง

Black box vs Gray box vs White box

ทั้งนี้ทั้งนั้น การเลือกรูปแบบ Black box, Gray box และ White box ที่ผู้เขียนอยากจะแนะนำคือ

• เลือก White box หรือ Gray box เพื่อความปลอดภัย

 ถ้าหากระบบไม่เคยทำ Pentest มาก่อน ควรทดสอบเป็นอย่างน้อยขั้นต่ำ Gray box หรือ White box เพื่อเน้นความปลอดภัย ให้ลดความเสี่ยงให้ได้เยอะ ๆ 

• เลือก Black box ถ้าอยากทดสอบซ้ำในระบบเดิมที่เคย Pentest แล้ว แต่เปลี่ยนมุมมอง

แต่ถ้าหากระบบนั้น ๆ เคยถูกทำ Pentest มาก่อนแล้ว ก็เป็นตัวเลือกที่ไม่เลว ว่าในครั้งถัดไปจะลองที่จะทดสอบในรูปแบบ Black box เพื่อเน้นมุมมอง จากผู้โจมตีภายนอก ที่อาจไม่รู้การทำงานของโค้ด หรือไม่มีบัญชีเข้าไปใช้งานระบบ รวมถึงกรณีที่ถ้าระบบที่จะทดสอบมีขอบเขตงาน Pentest เยอะและเวลามีจำกัดมาก ๆ แต่อยากจะทดสอบทั้งหมด อย่างละนิดละหน่อย ก็เลือกเป็นแบบ Black box เพื่อทดสอบในภาพกว้าง ภาพรวมได้เช่นกัน แต่ต้องเข้าใจว่าความละเอียดของความเสี่ยงที่จะถูกตรวจก็จะไม่มีทางเท่าในรูปแบบ Gray box หรือ White box

ซึ่งเราอาจจะเรียกการสแกน VA แบบ Credentialed Scan ว่าเป็น VA แบบ White box และเรียกการสแกน VA แบบ Non-Credentialed Scan ว่าเป็นการ VA แบบ Black box ก็ได้ บางคนก็นิยมเรียกการ สแกน VA ที่มีการสร้างเซิร์ฟเวอร์ในระบบเครือข่ายภายใน (Jump host) สำหรับติดตั้งโปรแกรม VA หรือการที่จะต้อง Allowlist ให้หมายเลขไอพีจากโปรแกรม VA เป็นการทำ VA แบบ Gray box ซึ่งการเรียกเหล่านี้อาจจะไม่มีถูกไม่มีผิด แล้วแต่มุมมองของแต่ละคนที่จะอ้างอิงข้อมูลที่ให้ผู้ทดสอบ

หลายคนเรียกรวม ๆ ผลการทำ VA และ Pentest ว่าผลจากการทำ VAPT และสิ่งที่น่าสนใจก็คือ ในโลกแห่งความเป็นจริง ไม่ว่าระบบจะผ่านการทำ VAPT มาแล้ว หรือ มีข้อกำหนดให้เขียนโค้ดป้องกันความเสี่ยงตามเอกสาร OWASP มาแล้ว ระบบอะไรก็ยังมีความเสี่ยงหลงเหลือ (Residual Risk) ให้โดนแฮกได้ ด้วยข้อจำกัดต่าง ๆ นอกเหนือจากขอบเขตที่จะควบคุมได้ ตัวอย่างก็มีให้เห็นเยอะไป อย่างโปรแกรม เว็บ และแอปพลิเคชันของเหล่า MANAMANA (Microsoft, Apple, Netflix, Alphabet, Meta, Amazon, Nvidia และ Adobe) ที่มีวิศวกรซอฟต์แวร์ระดับโลกเขียน รวมถึงมีการทดสอบอยู่เป็นประจำจากผู้เชี่ยวชาญด้านความปลอดภัยก็ยังแตก ยังโดนแจ้งช่องโหว่ผ่านโครงการล่าช่องโหว่ (Bug Bounty Program) หรือมีการประกาศเป็นสาธารณะกันอยู่เรื่อย ๆ 

ตัวอย่างคือช่องโหว่จากซอฟต์แวร์ Microsoft Exchange Server ที่ทำให้ผู้ไม่ประสงค์ดีสามารถยึดเครื่องเซิร์ฟเวอร์ได้ (Remote Code Execution) ที่อ้างอิงด้วยหมายเลข CVE-2022-41082 ก็ยังเกิดขึ้นแม้ว่า Microsoft มีการพัฒนาและจ้างผู้เชี่ยวชาญมาตรวจสอบความปลอดภัย ซอฟต์แวร์ Microsoft Exchange Server แล้วก็ตาม

ที่มา: https://msrc-blog.microsoft.com/2022/09/29/customer-guidance-for-reported-zero-day-vulnerabilities-in-microsoft-exchange-server/ 

ดังนั้น ก่อนจะทำการ VAPT หรืออ้างอิงข้อกำหนด OWASP ลงใน RFP/TOR จะต้องเข้าใจก่อนว่า กระบวนการเหล่านี้ มีไว้สำหรับการ “ลดความเสี่ยง” ให้ระบบมีความปลอดภัยมากขึ้น แต่ “ไม่สามารถรับรองได้ว่า ระบบจะไม่มีช่องโหว่หลงเหลืออยู่เลย” ถ้าหากมีใครมาบอกว่า การทำ VAPT หรือเขียนโค้ดตามข้อกำหนด OWASP แล้วจะไม่มีช่องโหว่เลย ให้สงสัยได้เลยว่า เค้าอาจจะไม่ได้พูดความจริงทั้งหมดก็เป็นไปได้

FAQ #3 บริษัทควรทำ VA เอง vs จ้างคนอื่นทำ VAให้?

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

แต่ถ้าในแง่ค่าใช้จ่าย ถ้าเกิดต้องทำบ่อย ๆ แน่นอนว่า การทำ VA เองภายในบริษัท ใช้ค่าใช้จ่ายน้อยกว่าจ้าง Vendor เข้ามาทำ VA แน่นอน อยากจะเปรียบเทียบข้อดีและข้อสังเกตดังนี้

ข้อดีของการที่บริษัททำ VA เอง คือ ประหยัดค่าใช้จ่ายบริษัทและสนับสนุนให้เกิดองค์ความรู้ด้านการตรวจสอบช่องโหว่กับบุคลากรภายในบริษัท

• ประหยัดค่าใช้จ่าย ยิ่งถ้าทำบ่อย ๆ ทำเองได้ จะช่วยลด Cost ได้เยอะ เมื่อเทียบกับจ้าง Vendor ภายนอกเข้ามาทำ
• เมื่อทำเอง และทำได้บ่อย ๆ อาจช่วยในการทำให้ระบบปลอดภัยตั้งแต่เนิ่น ๆ ก่อนล่วงเลยไปถึงสถานะถัด ๆ ไป หรือเกิดความเสียหายจากช่องโหว่ในระบบ
• ทำให้พนักงานภายในบริษัท เกิดองค์ความรู้ รวมถึงตระหนักถึงการหลีกเลี่ยงความเสี่ยงและช่องโหว่ต่าง ๆ มากยิ่งขึ้น 

ข้อสังเกตของการที่บริษัททำ VA เอง คือ อาจขาดความน่าเชื่อถือ, (เหนื่อย) และขาดการให้คำแนะนำ

• โดยทั่วไป Regulator, ลูกค้า, บริษัท Partner, บริษัทแม่ในต่างประเทศ ที่ขอผลการทำ VA เป็นข้อระบุภาคบังคับว่าผล VA จะต้องเป็นการว่าจ้างให้ Vendor ภายนอกทำเพื่อความน่าเชื่อถือของผลลัพธ์
• ทำ VA เอง เมื่อนำไปอ้างอิง ความน่าเชื่อถือของผล VA อาจน้อยกว่าจ้าง Vendor ภายนอกทำ เพราะว่า ถ้าหากคนทำระบบทดสอบระบบเอง อาจทำ VA ในรูปแบบที่จะมองไม่เห็นจุดบกพร่องของตัวเอง โดยมีความเอนเอียง (Bias) ให้ผ่านผลจากการทำ VA ได้ง่ายและเร็วเนื่องจากไม่ต้องการแก้ไขระบบ หรือด้วยการเมืองภายในบริษัท (ตัวอย่างเช่น ปิด Service ให้ไม่สามารถใช้งานได้ก่อนการทดสอบ หรือตั้งค่าให้ปลอดภัยเกินไป จนทำให้ระบบใช้งานไม่ได้ชั่วคราว เพื่อผ่านผล VA แต่ไม่ได้นำไปปรับใช้งานจริง)
• เหนื่อย !! โดยเฉพาะ ถ้าไม่มีทีม IT Security ภายในบริษัท แต่มีนโยบายให้ทีม IT ที่ดูแลเรื่องอื่น ๆ มาทำ VA อาจไม่สามารถทำ VA ได้อย่างเต็มประสิทธิภาพที่ควรจะเป็น ในกรณีของบริษัทขนาดใหญ่ ถ้าอยากจะทำ VA ภายใน ควรสร้างทีม IT Security ที่ทำในส่วนของ Red Team เพื่อ VAPT โดยเฉพาะ ไม่ซ้ำซ้อนกับตำแหน่ง IT อื่น ๆ ในองค์กร
• ในกรณีที่ระบบมีเงื่อนไขในการเข้าถึงที่ซับซ้อน อาจไม่สามารถตั้งค่าให้ประสิทธิภาพการทำ VA เหมาะสมกับที่ควรจะเป็นได้ เช่นตำแหน่งในระบบเครือข่ายที่โปรแกรม VA จะทำงาน อาจไม่สามารถเข้าถึงเครื่องเป้าหมายที่จะถูกทดสอบได้
• ในการแก้ไขช่องโหว่จากรายงานผลของโปรแกรม VA มักจะเป็นคำอธิบายกว้าง ๆ ที่ไม่สามารถนำไปปรับใช้ได้โดยตรง ถ้าหากจ้าง Vendor ภายนอก อาจจะได้รับคำปรึกษาที่ชัดเจนกว่า รวมถึงในส่วนของ ค่าความเสี่ยง (Risk) จากผล  VA ที่อาจจะไม่ถูกต้องกับบริบทของระบบจริง ๆ

FAQ #4 ควรใช้โปรแกรม VA ฟรี vs ใช้โปรแกรม VA เสียตัง?

ความคิดเห็นส่วนตัวของผู้เขียนมองว่า โปรแกรม VA แต่ละตัวก็มีความเก่งในแบบฉบับของตัวเอง โปรแกรม VA  ยี่ห้อ A อาจจะหาช่องโหว่ XXX ที่โปรแกรม VA ยี่ห้อ B หาไม่เจอ และในทางกลับกัน โปรแกรม VA ยี่ห้อ B ก็อาจจะหาช่องโหว่ YYY ที่โปรแกรม VA ยี่ห้อ A หาไม่เจอเช่นกัน

ในบางกรณี โปรแกรม VA เสียตัง จะใช้งานได้ดีกว่า โปรแกรม VA ฟรีที่นักพัฒนาบางส่วนอาจจะไม่ได้พัฒนาโปรแกรม VA นั้นเป็นงานหลัก เพราะว่าโปรแกรม VA เสียตัง มักจะมีทีมงานที่คอยปรับปรุงคุณภาพและเพิ่มเติมช่องโหว่ใหม่ ๆ ที่รวดเร็วและเยอะกว่า แต่บางโปรแกรม VA ฟรีที่มีชุมชนออนไลน์จำนวนมากช่วยกันปรับปรุงโค้ดหรือเพิ่มช่องโหว่ ก็มีประสิทธิภาพที่ดีมาก เช่นกัน

ทางที่ดีควรมีการเลือกใช้โปรแกรม VA ที่มีการปรับปรุงเพิ่มช่องโหว่ หรือความเสี่ยงใหม่ ๆ ในการทดสอบอยู่เสมอ ไม่ควรใช้โปรแกรม VA ที่ไม่มีการพัฒนาต่อแล้ว และอาจใช้มากกว่า 1 โปรแกรม เพื่อตรวจสอบผลลัพธ์ของกันและกัน

ตัวอย่างโปรแกรม VA ที่เสียเงิน คือ Tenable Nessus Professional

FAQ #5 โปรแกรม VA ทำงานอย่างไร?

หลักการทำงานของโปรแกรม VA โดยทั่วไปจะมีอยู่ 3 ขั้นตอนคือ

1. ค้นหา Host จากหมายเลขไอพีหรือชื่อ Domain ที่เป็นเป้าหมายว่าสามารถเข้าถึงได้ โดยปกติแล้วจะเป็นการทำ ICMP Ping (ส่ง ICMP Packet) ไปที่เครื่องเป้าหมาย หรือถ้าหากอยู่ใน Subnetwork เดียวกันอาจใช้วิธี ARP Ping แทนได้
2. ค้นหา Service ภายใน หมายเลขไอพีหรือชื่อ Domain ที่เป็นเป้าหมายว่า มี UDP หรือ TCP Port หมายเลขอะไรเปิดอยู่บ้าง
3. ทำการตรวจสอบช่องโหว่ Service ใน Protocol ต่าง ๆ เช่น FTP, SMB, SSH และ HTTP ที่พบว่า เป็นซอฟต์แวร์รุ่นอะไร มีแอปพลิเคชันอะไรทำงานอยู่ที่ Service นั้น เพื่อตรวจสอบหาช่องโหว่ตามหมายเลข CWE หรือ CVE รวมถึงตรวจสอบการตั้งค่าที่ไม่ปลอดภัยจากการทดลองเชื่อมต่อเข้าไปใช้งาน Service นั้น ๆ

ดังตัวอย่างตามรูปด้านล่างนี้

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

ทดลองทำการสแกน VA โดยใช้โปรแกรม OpenVAS

ในตัวอย่างต่อไปนี้ผู้เขียนจะแสดงตัวอย่างการติดตั้งโปรแกรม OpenVAS เพื่อทดสอบการสแกน VA ด้วยวิธีการติดตั้งผ่าน Docker Container โดย จากที่สำรวจมาพบว่ามี Docker Image ของ OpenVAS อยู่ประมาณ 3 อัน ที่เป็นที่นิยม แต่ว่าส่วนมากจะไม่ได้ทำการปรับปรุงเป็นรุ่นล่าสุด อันที่ใหม่ที่สุดจะเป็นของ immauss/openvas (https://github.com/immauss/openvas, https://hub.docker.com/r/immauss/openvas)

ขั้นแรกผู้อ่านจะต้องดาวน์โหลดและติดตั้ง Docker ให้เรียบร้อยก่อนจาก URL ต่อไปนี้https://www.docker.com/products/docker-desktop/

จากนั้นใน Windows ใช้ cmd.exe และใน Linux หรือ macOS ใช้ Terminal ในตัวอย่างนี้ผู้เขียนใช้ macOS และติดตั้ง OpenVAS ด้วยคำสั่งต่อไปนี้

wget https://raw.githubusercontent.com/immauss/openvas/master/compose/docker-compose.yml
sed -ie 's/8080:9392/9392:9392/g' docker-compose.yml
sed -ie 's/$TAG/22.4-beta/g' docker-compose.yml
docker-compose up

หลังจากคำสั่งรันเสร็จ จะมี Service ของ OpenVAS เปิดอยู่บนเครื่องของผู้อ่านที่ TCP Port 9392 สามารถเข้าได้จาก URL

http://127.0.0.1:9392/

จากนั้นชื่อผู้ใช้งานและรหัสผ่านเริ่มแรกจะเป็นค่า admin ให้ทำการเข้าสู่ระบบ (อย่าลืมไปเปลี่ยน!)

Task Wizard (สแกนแบบง่าย)

จากนั้นเข้าไปยังเมนูที่ใช้สำหรับการ สแกน ได้ที่ URL http://127.0.0.1:9392/tasks หรือกดที่เมนู Scans -> Tasks

จากนั้นเราสามารถเริ่มต้นการสแกน VA ได้ด้วยการกดไปที่ปุ่ม ไม้กายสิทธิ์ตามรูปด้านล่าง และเลือกที่ Task Wizard เพื่อทำการสร้าง Task การสแกน

ทำการใส่หมายเลขไอพีของเป้าหมาย ในตัวอย่างนี้เราจะทดสอบสแกนหมายเลขไอพี 192.168.1.58

หลังจากนั้นเราจะพบกับ Task ใหม่ที่เพิ่มขึ้นมาในเมนู Tasks (http://127.0.0.1:9392/tasks)

การสแกน VA ของ OpenVAS ด้วยปุ่ม Task Wizard จะเรียกได้ว่าง่ายที่สุดแค่กรอกหมายเลขไอพีก็จะกดสแกนได้ทันที !

Advanced Task Wizard (ตั้งค่าการสแกนเพิ่มเติม)

แต่อย่างไรก็ตามถ้าหากเราต้องการจะสร้าง Task ที่สามารถกำหนดค่าเพิ่มเติมได้ นอกจากการใส่หมายเลขไอพี ในตัวอย่าง Task Wizard สามารถเข้าถึงได้ที่ปุ่ม Advanced Task Wizard (http://127.0.0.1:9392/tasks) ในหน้า Tasks

จากนั้นจะมี Pop-Up ชื่อว่า Advanced Task Wizard แสดงขึ้นมาดังตัวอย่างในรูปนี้

จากรูปด้านบนจะพบว่า เราสามารถที่จะกำหนดตัวเลือกเพิ่มเติมได้ เช่น

1. Target Host(s): สามารถตั้งค่าหมายเลขไอพี ที่ต้องการสแกนได้ครั้งละจำนวนมาก ด้วยการ ใส่เครื่องหมาย Comma (,) คั่นระหว่างหมายเลขไอพีหรือชื่อ Domain
2. Schedule: จะเป็นส่วนของการตั้งเวลาในการสแกน ค่าเริ่มต้นจะเป็นการสแกนทันที (Start immediately) ซึ่งสามารถเลือกวันที่จะถูกสแกนล่วงหน้า โดยสามารถเลือกเวลาที่จะเริ่ม รวมถึงหยุดการสแกนได้
3. SSH/SMB/ESXi Credential: กำหนดรหัสผ่าน เพื่อทำการสแกนช่องโหว่ในรูปแบบ Credentialed Scan เพื่อให้ OpenVAS เข้าสู่ระบบ ในระดับระบบปฏิบัติการและทำการรวบรวมข้อมูลเพื่อตรวจสอบช่องโหว่นอกเหนือจากการตรวจสอบภายนอกผ่าน Service ต่าง ๆ
4. Email report to: เป็นส่วนของการตั้งค่าอีเมลเพื่อรับรายงานผลการสแกนใน Task นั้น ๆ

ถัดจากนั้นกดปุ่ม Create จะพบกับ Task ใหม่ที่ถูกสร้างขึ้นมาของการสแกนที่ตั้งค่าดังกล่าว

Credentials (กำหนดรหัสผ่านสำหรับทำ Credentialed Scan)

จากตัวอย่างใน Advanced Task Wizard ที่ผู้อ่านสามารถทำ Credentialed Scan เพื่อให้โปรแกรม OpenVAS เข้าสู่ระบบไปสแกนเพิ่มเติมได้ ซึ่ง OpenVAS ต้องการให้ผู้ใช้งานเก็บรหัสผ่านที่จะใช้สแกนล่วงหน้าก่อน ที่เมนู Configuration -> Credentials และกดเพิ่ม Credential ที่ต้องการ

จากนั้นใน Advanced Task Wizard ในส่วนของเมนู SSH Credential ก็จะสามารถเลือก Credential ที่เพิ่มเข้ามาได้ดังตัวอย่างด้านล่างนี้

Hosts (กำหนด รายชื่อหมายเลขไอพีที่จะทำการสแกนบ่อย ๆ)

ถ้าหากว่า ตามนโยบาย หรือลักษณะการทำสแกน VA อาจต้องทำบ่อย ๆ หรือมีจำนวนมาก สามารถใช้ฟังก์ชัน Hosts ของ OpenVAS ในการเก็บรายชื่อหมายเลขไอพีเป้าหมายไว้ได้ โดยไปที่เมนู Assets -> Hosts และกดเพิ่ม Host ใหม่ดังรูปด้านล่างนี้

จากนั้นในหน้าเว็บ Hosts ก็จะมีรายการหมายเลขไอพีที่ถูกเพิ่มเข้าไปมาแสดง

จากนั้นในหน้าเว็บ Hosts ก็จะมีรายการหมายเลขไอพีที่ถูกเพิ่มเข้าไปมาแสดง

Results (ผลการสแกน)

หลังจากที่ทำการสแกน VA เสร็จเรียบร้อยแล้ว สามารถไปที่เมนู Scans -> Results เพื่อตรวจสอบผลลัพธ์ได้ ดังตัวอย่างในรูปต่อไปนี้

ตามผลการสแกนด้านบน พบว่ามีช่องโหว่เป็นจำนวนมาก (144 รายการ) โดยแต่ละรายการจะมีการจัดระดับความเสี่ยง สำหรับโปรแกรม OpenVAS จะมีระดับความเสี่ยง 4 ระดับ (จะใช้คำว่า Severity แทน Risk) ดังนี้

1. ความเสี่ยงสูง (High) สีแดง
2. ความเสี่ยงปานกลาง (Medium) สีส้ม
3. ความเสี่ยงต่ำ (Low) สีฟ้า
4. ความเสี่ยงต่ำมาก หรือเป็นข้อมูลประกอบ (Informational) สีเทา

เมื่อตรวจพบช่องโหว่ เช่น Apache Tomcat AJP RCE Vulnerability (Ghostcat) จะแสดงชื่อช่องโหว่ใน Column ชื่อ Vulnerability และ ระดับความเสี่ยงใน Column ชื่อ Severity และเมื่อกดเข้าไปดูรายละเอียดในแต่ละช่องโหว่ เช่นตัวอย่างในรูปด้านล่างนี้

จะพบกับคำอธิบาย ในรายละเอียดของแต่ละช่องโหว่ เช่น ช่องโหว่ PHP-CGI-based setups พบว่าในส่วนของ Detection Result มีแสดงตัวอย่าง URL และ HTTP Request ที่ใช้ในการทดสอบช่องโหว่แสดงอยู่ด้วย

รวมถึงมี ผลของการรันคำสั่งตามที่ทดสอบช่องโหว่ว่าสามารถรันโค้ด <?php phpinfo(); ?> บนเซิร์ฟเวอร์เป้าหมายได้สำเร็จ อยู่ท้ายข้อความ Result:

จากตัวอย่างช่องโหว่ PHP-CGI-based setups จะมีอ้างอิงหมายเลข CVE หลายอัน เช่น CVE-2012-2336 และแนะนำวิธีการแก้ไข โดยการปรับปรุงรุ่นของ PHP ให้เป็นรุ่นล่าสุด

ช่องโหว่ PHP-CGI-based setups จะเป็นตัวอย่างช่องโหว่ประเภท ช่องโหว่ของแอปพลิเคชันสำเร็จรูป สาเหตุข้อย่อยใน “2.1 ไม่ได้อัปเดต” ตามที่ผู้เขียนอธิบายไปก่อนหน้า

ต่อไปจะเป็นตัวอย่างของ ช่องโหว่ของแอปพลิเคชันสำเร็จรูป สาเหตุข้อย่อยใน “2.2 ตั้งค่าไม่ปลอดภัย” ในตัวอย่างนี้คือช่องโหว่ PostgreSQL weak password โดยโปรแกรม OpenVAS ตรวจสอบพบว่า Service ที่ TCP Port หมายเลข 5432 มีการเปิดใช้งานโปรแกรมจัดการฐานข้อมูล PostgreSQL และได้มีการทดสอบลองเดารหัสผ่านที่มักจะถูกใช้งาน และพบว่าสามารถเข้าสู่ระบบได้ด้วยการใช้รหัสผ่านของผู้ใช้งาน postgres เป็นค่า postgres

ในส่วนของช่องโหว่ที่เกิดจากการตั้งค่าไม่ปลอดภัย จะไม่มีการอ้างอิงไปยังหมายเลข CVE และจะแนะนำการแก้ไขในส่วนของ Solution ว่าให้ไปทำการเปลี่ยนรหัสผ่าน เป็นค่าที่ปลอดภัยมากยิ่งขึ้นโดยเร็วที่สุด

สำหรับในการใช้งานแบบง่าย ๆ สามารถทำได้ดังที่ผู้เขียนเล่ามา ติดตั้ง, ใส่หมายเลขไอพี, กดสแกน, ตรวจสอบผล, แก้ไขช่องโหว่ตามคำแนะนำ ! 

แอบส่อง ArcherySec และ DevSecOps

แต่สำหรับในบริษัทที่มีการใช้งาน CI/CD Pipeline ในการทำ DevOps สามารถที่จะนำการสแกน VA ไปปรับใช้ในกระบวนการ DevOps ได้เช่น เมื่อ Jenkins ดึงโค้ดจาก Gitlab มา build และ Deploy ขึ้นเซิร์ฟเวอร์ไปแล้ว ให้มาเรียก API ของ OpenVAS เพื่อทำการสแกนหาช่องโหว่อัตโนมัติ โดยจะเรียกการทำสแกน VA แบบอัตโนมัติในลักษณะนี้ว่า DevSecOps ดังรูปด้านล่าง

ในตัวอย่างรูปนี้จะเป็นการใช้โปรแกรมชื่อ ArcherySec (https://hub.docker.com/r/archerysec/archerysec) ซึ่ง Open Source และฟรี สามารถนำมาปรับใช้งานได้ โดย ArcherySec จะอยู่นอกเหนือจากขอบเขตของเนื้อหาในบทความนี้แต่ผู้เขียนอยากใส่ไว้คร่าว ๆ ให้ไปอ่านต่อกันเอง

ตัวอย่างการติดตั้ง ArcherySec ด้วย Docker

$ docker pull archerysec/archerysec
$ docker run -e NAME=$ARC_USER -e EMAIL=$ARC_EMAIL -e PASSWORD=$ARC_PASSWORD  -it -p  8000:8000 archerysec/archerysec:latest

ในกรณีที่ไม่ต้องการ(ติดตั้ง)แบบง่าย ๆ นั่นเอง การติดตั้งครั้งแรกอาจจะยากกว่า แต่ถ้าตั้งค่าทุกอย่างเรียบร้อยแล้ว ในการสแกน VA ครั้งต่อไปโดยเฉพาะในระดับเว็บแอปพลิเคชันที่สามารถใช้ OpenVAS เข้ามาสแกน VA ได้ ก็จะสะดวกขึ้นมาก ๆ

ตัวอย่างการตั้งค่าเพื่อผูก OpenVAS เข้ากับ ArcherySec

นอกเหนือจากการนำ ArcherySec ไปใช้ใน CI/CD Pipeline ในการสแกน VA แบบอัตโนมัติเมื่อมีการ Trigger ด้วยเงื่อนไขอะไรบางอย่าง อย่างการ Deploy Docker container แล้วก็ยังสามารถนำ ArcherySec ใช้งานแบบ เดี่ยว ๆ (Standalone) โดยการนำผลสแกน VA จากทั้ง OpenVAS และ OWASP ZAP มาใส่รวมกันได้อีกด้วย

ตัวอย่างการอัปโหลดผลการสแกนจาก OpenVAS ใส่ไปที่ระบบ ArcherySec

จากนั้นเมื่อเข้าไปดูรายชื่อช่องโหว่และ Dashboard ก็จะสามารถบริหารจัดการช่องโหว่ที่นำเข้ามาจากโปรแกรม VA ต่าง ๆ ได้ในที่เดียว

ถ้าหากพบว่าช่องโหว่ไหนในผลการสแกน VA ไม่มีอยู่จริง (False Positive) ก็สามารถกดปุ่ม Yes ใน Column ชื่อ False Positive (1) ได้ หรือถ้าหากช่องโหว่มีการแก้ไขแล้วก็สามารถกดปุ่ม Close ใน Column ชื่อ Mark (2) ได้เช่นกัน

สำหรับในบริษัท หรือหน่วยงานที่มีระบบ Ticket อยู่แล้ว เช่น Jira อาจตั้งค่าให้ ArcherySec ไปเปิด Ticket ไว้อัตโนมัติก็ได้ด้วย

รูปจาก https://docs.archerysec.com/docs/jira-connector

สำหรับรายละเอียดและข้อมูลการทำ VA ในองค์กรด้วยตัวเองแบบง่ายบ้าง ยากบ้างปน ๆ กันไป ก็ขอจบลงแต่เพียงเท่านี้ แล้วพบกันใหม่ Stay Safe ครับผม!