วิเคราะห์มาตรฐานในการตรวจสอบระบบสารสนเทศ สำหรับระบบความปลอดภัยบนระบบปฏิบัติการ Microsoft Windows (ตอนที่ 1)
by A.Pinya Hom-anek, GCFW, CISSP, CISA
ACIS Professional Team
ด้วยแนวโน้มทิศทางของการตรวจสอบภายใน (Internal Audit) และ การควบคุมภายใน (Internal Control) ในแนว Proactive กำลังกลายเป็นเรื่องสำคัญที่องค์กรทุกองค์กรที่ใช้ระบบสารสนเทศ ต้องนำมาปฏิบัติอย่างจริงจัง
ในรายละเอียดของการตรวจสอบ และ การควบคุมภายในนั้น หัวใจสำคัญก็คือขั้นตอนการประเมินความเสี่ยง (Risk Assessment) ซึ่งระบบปฏิบัติการที่เราใช้กันอยู่ในปัจจุบันส่วนใหญ่ก็หนีไม่พ้น Microsoft Windows 2000 Server หรือ Microsoft Windows Server 2003 ถ้าเป็นองค์กรใหญ่ก็มักจะใช้ระบบปฏิบัติการ UNIX ของ SUN หรือ HP (Solaris และ HP/UX ตามลำดับ) ตลอดจนระบบปฏิบัติการ Linux ก็กำลังได้รับความนิยมเพิ่มมากขึ้น ดังนั้นกระบวนการตรวจสอบ ระบบปฏิบัติการเหล่านี้จำเป็นต้องมีมาตรฐานอ้างอิงว่าระบบปลอดภัยอยู่ในขั้นที่เราสามารถไว้ใจได้ในระดับหนึ่งหรือเรียกว่า Risk Acceptance Level
ดังนั้น เราควรจะประเมินความเสี่ยงของระบบโดยการตรวจสอบหาช่องโหว่ของระบบทางเทคนิคเรียกว่า “Vulnerability Assessment (V/A)” โดยปกติแล้วมีโปรแกรม V/A Scanner หลายตัวที่สามารถช่วยทำให้งานตรวจสอบง่ายขึ้น
มาตรฐานในการตรวจสอบระบบสารสนเทศสำหรับระบบความปลอดภัยบนระบบปฏิบัติการ Microsoft Windows ที่ได้รับการยอมรับกันโดยทั่วไปก็คือ มาตรฐาน SANS/FBI Top 20 ที่มีมาตั้งแต่ปี 2000 ขณะนี้ SANS/FBI Top 20 ล่าสุดได้มีการปรับปรุงมา 4 ครั้ง และ ครั้งสุดท้ายปรับปรุงในปี 2004 เรียกว่า SANS Top 20 2004 โดยแบ่งออกเป็นการเตือนช่องโหว่ของระบบปฏิบัติการ Windows 10 ช่องโหว่ และ การเตือนช่องโหว่ระบบปฏิบัติการ UNIX/ Linux อีก 10 ช่องโหว่ (รายละเอียดดูที่ http://www.sans.org/top20)
ในปัจจุบันทาง SANS จำเป็นต้องปรับข้อมูลการเตือนช่องโหว่เป็นเวอร์ชั่นล่าสุด เพราะการโจมตีของไวรัสคอมพิวเตอร์ เวิร์ม (Worm) และ แฮกเกอร์รุ่นใหม่นั้นมีการเปลี่ยนแปลงไปมาก ไม่ว่าจะเป็น Blaster Worm, Slammer Worm, Nachi Worm และ JPEG Processing (GDI+) Exploit Worm เป็นต้น
มาตรฐานในการตรวจสอบระบบสารสนเทศสำหรับระบบความปลอดภัยบนระบบปฏิบัติการ Microsoft Windows (10 ช่องโหว่)
1. ช่องโหว่ของ Web Server และ Services
วิเคราะห์ปัญหาช่องโหว่
โดยปกติเรามักติดตั้ง Web Server หรือ HTTP Server ในแบบ Default คือไม่ได้แก้ไขค่าเริ่มต้นต่างๆ ที่มากับตัว Web Server ทำให้เกิดช่องโหว่ที่แฮกเกอร์ สามารถนำมาใช้ได้ ระบบของเราอาจเกิดปัญหาเช่น ปัญหา DoS Attack ทำให้ Web Server ไม่สามารถทำงานได้ หรือปัญหาการถูกโจมตีจนแฮกเกอร์สามารถ “ยึด” หรือ “Compromised” เครื่อง Web Server ของเราได้ และ สามารถเปลี่ยนหน้าเว็บเพ็จ ตลอดจนสามารถก๊อบปี้ไฟล์ข้อมูลของเราได้ด้วย
ช่องโหว่มักเกิดขึ้นเป็นประจำกับ Web Server IIS ของ Microsoft Windows NT/2000 ปกติเป็นเวอร์ชัน 3.0, 4.0 และ 5.0 ตามลำดับ สำหรับเวอร์ชัน 6.0 ที่มากับ Windows Server 2003 มีการปิดกั้นช่องโหว่ต่างๆ มาอย่างดีเมื่อเทียบกับเวอร์ชันก่อนหน้านี้ สำหรับ Apache Web Server ที่ทำงานบน Microsoft Windows ก็มีช่องโหว่เช่นกัน
วิธีการแก้ปัญหา
การลง “Patch” “Hotfix” หรือ อัพเดท Services Pack ล่าสุดของไมโครซอฟท์ เป็นทางออกที่ดีที่สุดในการป้องกันปัญหานี้
การติดตั้ง “Host-based IDS/IPS” ก็เป็นทางออกอีกทางหนึ่ง นอกจากนี้การติดตั้ง “Network-based IDS/IPS” ในลักษณะ In-line ก็สามารถช่วยได้
การเปลี่ยนแปลงค่า Default ต่างๆ หลังการติดตั้งก็เป็นเรื่องที่ต้องทำเช่นกัน รวมถึงการเก็บ Log File ในลักษณะ Remote Log โดยส่ง Log ไปเก็บที่ “Centralized Log Server” ก็เป็นแนวคิดที่ดีเพื่อเราสามารถจะตรวจสอบได้ภายหลังจากการโจมตีโดยไวรัสหรือแฮกเกอร์
การเปลี่ยนจาก IIS 5.0 มาใช้ IIS 6.0 ก็เป็นแนวทางที่ดี แต่ต้องดูเรื่อง “Compatibility” ของ Web Application ด้วย
2. ช่องโหว่ของ Windows Workstation Services
วิเคราะห์ปัญหาช่องโหว่
ระบบปฏิบัติการ Windows 2000 Server และ Windows XP เมื่อติดตั้งเสร็จเรียบร้อยจะเปิดบริการ Workstation Services โดยอัตโนมัติ โดยปกติแล้ว Workstation Services นั้น ใช้ในการติดต่อกันเองระหว่างเครื่องที่เป็น Workstation Platform ด้วยกันเพื่อปฏิบัติตาม “Request” ต่างๆ เช่นผู้ใช้ต้องการเข้าถึง “Resources” ของระบบเช่นเข้ามา “map network drive” ผ่านทางโปรโตคอล SMB
ปัญหาก็คือ Workstation Service มีช่องโหว่ช่องใหญ่ที่เราเรียกว่า “Stack-based buffer overflow” ซึ่งสามารถถูกโจมตีจาก “Remote Client” ได้ตลอดเวลา ถ้าเราไม่ทำการ “Harden” หรือปิดช่องโหว่ให้กับ Workstation Service (ข้อมูลเพิ่มเติมของช่องโหว่นี้ไมโครซอฟท์ได้กำหนดเป็นช่องโหว่รหัส MS03-049 สำหรับ Microsoft Windows 2000 และช่องโหว่รหัส MS03-043 สำหรับ Microsoft Windows XP)
วิธีการแก้ปัญหา
สำหรับ Windows XP ให้ลง Services Pack 2 และ ก่อนลง Services Pack 2 ให้ลองลงกับเครื่องที่ไม่สำคัญก่อนที่จะลงในเครื่องที่มีข้อมูลสำคัญ (ถ้ามีเครื่องเดียวก็ให้ Backup ข้อมูลไว้ก่อน)
สำหรับ Windows 2000 ให้ติดตั้ง “Patch” ล่าสุดก็คือ MS03-049 ตลอดจนปิด Port หมายเลข 139/TCP และ 445/TCP ที่บริเวณ Network Perimeter ขององค์กรเพื่อไม่ให้แฮกเกอร์เจาะผ่านทาง 2 Port นี้ หรือใช้ TCP/IP Filtering ที่มากับ Windows 2000 อยู่แล้วในการป้องกัน Port ดังกล่าว
3. ช่องโหว่ของ Windows Remote Access Services
วิเคราะห์ปัญหาช่องโหว่
การเข้าถึง Windows Platform ผ่านทาง Remote นั้นมีหลายทางไม่ว่าจะเป็นการ map network drive ผ่านโปรโตคอล SMB ด้วย Port TCP 139 หรือ Port TCP 445 หรือ การพยายาม Remote เข้ามาที่ Windows Platform โดยไม่ต้องมีชื่อผู้ใช้และรหัสผ่านก็สามารถเข้ามายัง Share Resource ต่างๆ ได้โดยวิธีที่เราเรียกว่า “Anonymous Logon” หรือ “Null Session Attack” โดยผ่านทาง IPC (Inter Process Communication) โดยใช้คำสั่ง net use \\\\ipc$ “” /user: “” ที่ command prompt ก็สามารถติดต่อกับ Share ต่างๆ ในเครื่องเป้าหมายได้โดยไม่ต้องรู้ชื่อผู้ใช้และรหัสผ่านในเครื่องเป้าหมาย ซึ่งแฮกเกอร์นิยมใช้วิธีนี้ในการจู่โจมระบบอยู่เป็นประจำ
ไวรัส Blaster/Nachi/Welchia Worm ก็ชอบใช้ช่องโหว่ของ RPC (Remote Procedure Call) Service ผ่านทาง Port TCP 135 ในการโจมตี Windows Platform ด้วยเช่นกัน ซึ่งอาจทำให้เครื่องเราถูกยึดโดยแฮกเกอร์ หรือ restart โดยไม่มีเหตุผลจากการถูกโจมตีแบบ “DoS Attack”
วิธีการแก้ปัญหา
ทำการติดตั้ง “Service Packs” และ “Hot Fix” ล่าสุดให้กับระบบปฏิบัติการ Windows ในทุกเวอร์ชั่นที่เราใช้งานอยู่ โดยเฉพาะ Windows XP SP2 มีการเปลี่ยนพฤติกรรมของโปรโตคอล RPC ซึ่งถูกตั้งค่าให้มีความปลอดภัยสูงเป็นค่าโดยกำหนด (Default) แตกต่างจาก Windows XP SP 1 และ Windows ในเวอร์ชั่นก่อนหน้านี้
การปิด “Default share C$ D$” และการแก้ไขค่า “Restrict Anonymous” ใน Registry ก็เป็นอีกวิธีหนึ่งในการแก้ปัญหา ในกรณีที่ไม่ได้ลง Patch หรือติดตั้ง Patch ไม่ครบถ้วน
* หมายเหตุ
Windows 98 และ Windows NT 4 Workstation นั้น ไมโครซอฟท์ประกาศเลิก support แล้วและ Windows NT 4 Server จะเลิก support ในปลายปี 2547
4.ช่องโหว่ของ Microsoft SQL Server (MSSQL)
วิเคราะห์ปัญหาช่องโหว่
หากเราใช้งาน RDBMS ตัวอื่นเช่น Oracle หรือ IBM DB2 ก็อาจไม่ได้รับผลกระทบโดยตรง แต่ถ้าเราใช้ Microsoft SQL Server ของไมโครซอฟท์ ช่องโหว่นี้มีผลกระทบรุนแรงกับระบบของเราโดยตรง ในเดือนพฤษภาคมปี 2546 และ เดือนมกราคม 2547 แฮกเกอร์ได้ปล่อย SQL Worm ออกมาก่อกวนในอินเทอร์เน็ต 2 ตัวได้แก่ SALSnake/SPIDA Worm และ SQL-Slammer/SQL-Hell/SQL-Sapphire Worm ตามลำดับ
การโจมตีของ Worm จะกระทำที่ Port 1433 และ 1434 โดยทำให้เกิด Traffic มหาศาลจนระบบเครือข่ายหนาแน่น และ ทำงานช้าลงอย่างเห็นได้ชัด บางทีระบบอาจล่มไปเลยก็มี Worm อาศัยช่องโหว่ของ “Default” System Admin account หรือ “sa” account ซึ่งปกติจะไม่มี password (Blank password) และ อาศัยช่องโหว่ “Buffer Overflow” ของตัว SQL Server Resolution Services ผ่านทาง Port UDP 1434
Microsoft Server 2000 Desktop Engine (MSDE 2000) หรือ ที่เรานิยมเรียกกันว่า “SQL Server Lite” ก็มีช่องโหว่เช่นกัน ซึ่งหลายคนมักมองข้ามในจุดนี้ นึกว่าเกิดช่องโหว่เฉพาะ Microsoft SQL Server เท่านั้น นั่นเป็นความเข้าใจที่ผิดเพราะ MSDE 2000 จะติดตั้งหรือมากับ Visual Studio.NET, ASP.NET Web Matrix Tool, Office XP (อันตรายที่สุดเพราะมักมีในทุกเครื่อง), Access 2002 และ Visual Fox Pro 7.0/ 8.0
วิธีการแก้ปัญหา
ทำการติดตั้ง “Service Packs” และ “Hot Fix” ล่าสุดให้กับ Microsoft SQL Server และ MSDE2000 ในทุกเวอร์ชั่นที่เราใช้งานอยู่ รวมถึง การปิดบริการ SQL MSDE Monitor Service ที่ Port UDP
5. ช่องโหว่ของระบบ Windows Authentication
การเข้าใช้งานระบบปฏิบัติการ Windows นั้น เราต้องทำการ “Login” หรือ “Authen” เข้าสู่ระบบ โดยใช้ชื่อผู้ใช้ (Username) และ รหัสผ่าน (Password) เสมอ ซึ่งบ่อยครั้งกลับกลายเป็นช่องโหว่ให้กับแฮกเกอร์และโปรแกรมไวรัสคอมพิวเตอร์ต่างๆ เนื่องจากมีการตั้งรหัสผ่านที่ง่ายเกินไป (บางครั้งไม่มีรหัสผ่านเลยด้วยซ้ำ) หรือ รหัสผ่านนั้นสั้นเกินไป (รหัสผ่านควรจะมีความยาวมากกว่าหรือเท่ากับ 8 ตัวอักษร) บางครั้งก็ใช้รหัสผ่านที่ถูกตั้งค่าโดยกำหนด (Default) หลังจากการติดตั้ง และ ไม่ได้เปลี่ยนรหัสผ่านเลยก็มี ในหลายกรณีที่ถูกแฮกเกอร์โจมตี
ระบบปฏิบัติการ Windows นั้น เก็บรหัสผ่านโดยวิธีการเก็บ “Hash” ของรหัสผ่าน (ไม่ได้เก็บรหัสผ่านโดยตรง) “Hash” คือข้อมูลที่มีความยาวเฉพาะตัว ซึ่งจะเท่ากันหมดในทุกรหัสผ่านเนื่องจากผ่านการ “Hash” มาแล้ว ทำให้แฮกเกอร์เดาได้ยากว่ารหัสผ่านที่เป็น Plain Text นั้นมีค่าเป็นอย่างไร และ เวลาที่ Windows ส่งรหัสผ่านข้ามระบบเครือข่าย Windows ก็จะใช้รหัสผ่านที่เก็บในรูป “Hash” หรือ “Message Digest” ในการติดต่อสื่อสารกันระหว่าง Windows Client และ Windows Server ดังนั้น การดักจับรหัสผ่านหรือการใช้โปรแกรมจำพวก “SNIFFER” เช่น “Ethereal” จึงไม่สามารถเห็นรหัสผ่านตรงๆ ได้ ต้องมีการแกะจากค่า “Hash” ซึ่งไม่ใช่เรื่องง่ายๆ สำหรับแฮกเกอร์ที่ยังไม่มีความรู้ลึกมากนัก
แต่แฮกเกอร์ที่มีความรู้เชิงลึก ได้ค้นพบช่องโหว่ของการใช้ “Hash Function” กับการเก็บค่า Hash ของรหัสผ่าน โดยพบว่าวิธีการเข้ารหัสของ Windows โดยใช้ “Hash Function” นั้น ง่ายเกินไป และ ง่ายพอที่แฮกเกอร์สามารถเจาะระบบได้
ดังนั้นไมโครซอฟท์ จึงได้ปรับเปลี่ยนวิธีการให้ซับซ้อนยิ่งขึ้น โดยจากเดิมใช้วิธีที่เรียกว่า “LM” Algorithm ก็เปลี่ยนเป็น “NTLM” และ “NTLM2” Algorithm ตามลำดับ แต่ก็ยังไม่วายตั้งค่าโดยกำหนด (Default) เป็น “LM” Algorithm เพื่อจะได้ “Backward Compatible” กับ Windows Client เวอร์ชั่นเก่าๆ เช่น Windows 95/98 เป็นต้น โดยตั้งไว้กับ Windows NT/2000 และ XP (ยกเว้น Windows 2003)
รหัสผ่านที่ถูกดักจับโดยโปรแกรม SNIFFER สามารถเข้ามาถอดรหัสได้โดยง่ายโดยใช้โปรแกรม เช่น โปรแกรม LC6 หรือ โปรแกรม CAIN ซึ่งถ้าใช้ “LM” Algorithm ก็จะยิ่งง่ายและถอดรหัสได้อย่างรวดเร็ว สำหรับ “NTLM” Algorithm โปรแกรม และ “NTLM2” Algorithm ก็สามารถถอดได้เช่นกัน แต่จะใช้เวลามากกว่าแบบ “LM” Algorithm โปรแกรมหลายเท่าตัว ถ้าตั้งรหัสผ่านอย่างรัดกุม การถอดรหัสก็จะยากและใช้เวลามากเสียจนแฮกเกอร์ไม่สามารถที่จะถอดรหัสได้สำเร็จ
วิธีการแก้ปัญหา
ก่อนอื่น รหัสผ่านต้องมีความแข็งแกร่งเพียงพอต่อการถอดรหัส กล่าวคือ ต้องมีความยาวไม่ต่ำกว่า 8 ตัวอักษร ใช้อักษรตัวเล็กตัวใหญ่และตัวเลขตลอดจนอักขระพิเศษผสมผสานกัน รหัสผ่านที่ดีไม่ควรอยู่ใน Dictionary และ ไม่ควรเดาได้ง่ายๆ นั่นหมายความว่าเราไม่ควรตั้งค่าให้มีความเกี่ยวพันกับตัวเราเช่น วันเกิด หรือ เบอร์โทรศัพท์ เป็นต้น
การบังคับนโยบายควบคุมรหัสผ่าน (Password Security Policy) ก็เป็นอีกเรื่องหนึ่งที่ควรปฏิบัติโดยฝ่ายสารสนเทศหรือผู้ดูแลระบบ และต้องได้รับการสนับสนุนนโนบายจากผู้บริหารระดับสูงด้วย
การปิดระบบเข้ารหัสแบบ “LM” Algorithm แล ะหันมาใช้ NTLMV2 Algorithm แทน ก็เป็นทางออกที่ดี แต่ระวังจะมีผลกระทบกับ Windows Client เวอร์ชั่นเก่าๆ ได้แก่ Windows 95/98 เป็นต้น (เพราะ Windows 95/98 ไม่สามารถใช้การเข้ารหัสแบบ NTLMV2 Algorithm ได้) สำหรับช่องโหว่ของระบบปฏิบัติการ Windows อีก 5 ประการนั้น ขอยกยอดไว้ใน eWeek ฉบับถัดไปนะครับ
จาก : หนังสือ eWeek Thailand
ปักษ์หลัง เดือนตุลาคม 2547
Update Information : 2 ธันวาคม 2547