ThaiCERT: Thai Computer Emergency Response Team
ศูนย์ประสานงานการรักษาความปลอดภัยคอมพิวเตอร์ ประเทศไทย 		  
 
 

ชื่อเรื่อง : 20 ช่องโหว่สำคัญที่เป็นอันตรายร้ายแรงต่อความปลอดภัยของอินเทอร์เน็ต
ที่มา : SANS / FBI Top 20 Lists: The Twenty Most Critical Internet Security Vulnerabilities
เรียบเรียงโดย : ศิริวรรณ อภิสิริเดช และ มนัชยา ชมธวัช
เผยแพร่เมื่อ : 28 ตุลาคม 2546

กล่าวนำ
โดยส่วนใหญ่แล้ว การบุกรุกระบบปฏิบัติการใดๆ ได้สำเร็จเป็นผลมาจากช่องโหว่เล็กๆ น้อยๆ ที่มีอยู่ในซอฟต์แวร์ที่ใช้งานบนระบบปฏิบัติการนั้น ด้วยเหตุนี้เอง ผู้บุกรุกจึงเปรียบเสมือนผู้ฉวยโอกาสซึ่งนำช่องทางที่ง่ายและสะดวกที่สุดมาใช้ร่วมกับเครื่องมือโจมตีที่มีประสิทธิภาพและหาได้ทั่วไป เพื่อโจมตีจุดอ่อนของระบบซึ่งเป็นที่รู้จักอย่างแพร่หลาย ผู้บุกรุกเหล่านั้นจะค้นหาว่ามีเครื่องคอมพิวเตอร์เครื่องใดยังไม่รับการแก้ไขช่องโหว่จากเครื่องคอมพิวเตอร์ของแต่ละองค์กร โดยอาศัยการตรวจสอบ (สแกน) จากอินเทอร์เน็ตหาช่องโหว่ที่ต้องการแล้วเข้าโจมตีโดยไม่สนใจว่า เครื่องคอมพิวเตอร์ดังกล่าวเป็นของใคร การละเมิดเข้าใช้งานระบบในเหตุการณ์การบุกรุกเครือข่ายของ Solar Sunrise Pentagon ถือเป็นตัวอย่างที่เห็นได้ชัดเจน รวมถึงการแพร่กระจายอย่างรวดเร็วและง่ายดายของหนอนอินเทอร์เน็ตอย่าง Code Red และ NIMDA ซึ่งมีความสามารถในการค้นหาและบุกรุกผ่านช่องโหว่ที่ยังไม่ได้รับการแก้ไข

เมื่อสองปีก่อน SANS Institute ร่วมกับ National Infrastructure Protection Center (NIPC) ได้เผยแพร่เอกสารสรุปถึงช่องโหว่ที่สำคัญ 10 รายการซึ่งเป็นอันตรายต่อความปลอดภัยของอินเทอร์เน็ต หนึ่งปีต่อมา หลายองค์กรได้นำรายการช่องโหว่นี้ไปใช้งานและได้มีการเพิ่มเติมขึ้นเป็น 20 ช่องโหว่ เพื่อให้ความสำคัญต่อความจำเป็นที่จะต้องแก้ไขหรือปิดช่องโหว่ที่มีอันตรายสูงสุดเป็นอันดับแรก ทั้งนี้ช่องโหว่ที่เป็นผลให้เกิดการบุกรุกขึ้นกับเครือข่ายของ Solar Sunrise Pentagon การแพร่กระจายของหนอน Code Red และหนอน NIMDA ก็ได้ถูกรวบรวมไว้ในรายการ 20 ช่องโหว่นี้เช่นกัน

รายการ 20 ช่องโหว่ที่ SANS และ FBI ปรับปรุงล่าสุดนี้แบ่งได้เป็น 2 กลุ่มคือ รายการ 10 ช่องโหว่สำคัญที่เป็นอันตรายต่อบริการบนระบบปฏิบัติการ Windows และรายการ 10 ช่องโหว่สำคัญที่เป็นอันตรายต่อบริการบนระบบปฏิบัติการ Unix ถึงแม้ว่าจะมีเหตุการณ์ละเมิดความปลอดภัยของทั้งสองระบบปฏิบัติการนี้เกิดขึ้นมากมายในแต่ละปี แต่การโจมตีที่ประสบความสำเร็จส่วนใหญ่เกิดขึ้นกับช่องโหว่ใดช่องโหว่หนึ่งหรือหลายๆ ช่องโหว่ของ 20 บริการที่จะกล่าวถึงนี้แทบทั้งสิ้น

ในขณะที่ผู้ดูแลระบบที่มีความเชี่ยวชาญด้านความปลอดภัยจะพบว่า รายการ 20 ช่องโหว่ที่ปรากฏในเอกสารฉบับนี้ถือเป็นข้อมูลสำคัญสำหรับช่วยเสริมสร้างความปลอดภัย รายการดังกล่าวนี้ยังมุ่งหวังที่จะช่วยให้ความรู้แก่องค์กรที่ขาดความรู้ความเข้าใจหรือไม่มีผู้ดูแลระบบที่มีความเชี่ยวชาญเฉพาะด้านความปลอดภัยคอมพิวเตอร์ไปพร้อมกันด้วย ผู้ที่มีหน้าที่รับผิดชอบต่อระบบและเครือข่ายขององค์กรหลายแห่งมักจะรายงานว่าตนเองไม่ได้แก้ไขจุดอ่อนมากมายที่มีในอยู่ระบบ เนื่องจากไม่มีวิธีการง่ายๆ ที่จะทราบได้ว่าช่องโหว่ใดเป็นอันตรายร้ายแรงที่สุด หรือตัวผู้ดูแลระบบเองมีหน้าที่อื่นที่ต้องดำเนินการเกินกว่าที่จะสามารถแก้ไขช่องโหว่ทั้งหมดได้ หรือไม่ทราบวิธีการแก้ไขช่องโหว่ที่เกิดขึ้นโดยไม่ทำความเสียหายต่อส่วนอื่น โดยทั่วไปแล้ว ผู้ตรวจสอบหรือผู้ดูแลด้านความปลอดภัยของระบบมักจะนำเครื่องมือตรวจสอบช่องโหว่มาใช้ค้นหาเปรียบเทียบกับรายการช่องโหว่ที่สำคัญประมาณ 500 หรือ 1000 หรืออาจเป็น 2000 รายการ แล้วส่งผลการตรวจสอบไปให้ผู้ดูแลระบบพร้อมกับสั่งให้ป้องกันระบบทั้งหมดจากการถูกโจมตีผ่านช่องโหว่ที่ตรวจพบ ทันทีที่ผู้ดูแลระบบได้รับรายงานแสดงถึงช่องโหว่ที่มีอยู่นับพันรายการบนเครื่องคอมพิวเตอร์จำนวนมากในระบบ ผู้ดูแลระบบอาจเกิดความสับสนและไม่สามารถวางแผนได้ว่าควรเริ่มต้นที่ใด

รายการ 20 ช่องโหว่ที่สำคัญนี้ได้จัดลำดับของช่องโหว่ตามความจำเป็นเร่งด่วนที่จะต้องได้รับการแก้ไขและจัดเรียงตามบริการที่มีใช้งาน เนื่องจากในหลายเหตุการณ์อาจใช้วิธีแก้ไขอย่างเดียวกัน เช่น ยกเลิกการใช้งานบริการ อัพเกรดให้ใช้งานซอฟต์แวร์เวอร์ชันล่าสุด หรือติดตั้ง patch ที่เกี่ยวข้อง ซึ่งสามารถแก้ปัญหาจากหลายๆ ช่องโหว่ที่ปรากฏในผลการใช้เครื่องมือตรวจสอบได้อย่างรวดเร็ว รายการที่ปรากฏในเอกสารฉบับนี้ได้รับการออกแบบมาเพื่อช่วยยับยั้งหรือบรรเทาปัญหาที่เกิดขึ้นโดยรวบรวมข้อมูลจากผู้เชี่ยวชาญด้านความปลอดภัยชั้นแนวหน้าจำนวนมาก ซึ่งทำงานในหน่วยงานชั้นนำที่ให้ความสำคัญด้านความปลอดภัย บริษัทผู้ผลิตหรือผู้จำหน่ายซอฟต์แวร์ด้านความปลอดภัยชั้นนำหรือบริษัทที่ปรึกษา ทีมผู้วิจัยและพัฒนาด้านความปลอดภัยชั้นนำจากมหาวิทยาลัย รวมถึงจาก CERT/CC และ SANS โดยรายชื่อทั้งหมดปรากฏอยู่ในตอนท้ายของเอกสาร

รายการ 20 ช่องโหว่สำคัญของ SANS และ FBI นี้เป็นเอกสารที่สามารถนำมาใช้งานได้จริง โดยได้รวมเอาคำแนะนำที่สามารถนำมาปฏิบัติตามได้ทีละขั้น รวมถึงได้แสดงทั้งแหล่งที่สามารถศึกษาข้อมูลเพิ่มเติมเพื่อการแก้ไขจุดอ่อนด้านความปลอดภัยที่ได้นำมาอธิบายไว้ และมีการอัพเดตข้อมูลอยู่ตลอดเวลา SANS / FBI จะทำการปรับปรุงรายการและคำแนะนำตามความร้ายแรงและตามวิธีการเหมาะสมทันทีที่ข้อมูลได้รับการตรวจสอบ นอกจากนั้น SANS / FBI ยินดีรับทราบข้อมูลจากผู้ดูแลระบบทุกท่านตลอดเวลา หากผู้ดูแลระบบคนใดมีประสบการณ์ในการรับมือกับผู้บุกรุก หรือการกำจัดช่องโหว่ที่เกิดขึ้น ซึ่งจะเป็นประโยชน์ต่อผู้ใช้งานคนอื่นๆ ได้ ให้ส่งคำแนะนำผ่านอี-เมล์มาที่ info@sans.org โดยใช้หัวข้อว่า "Top Twenty Comments"

หมายเหตุสำหรับผู้อ่าน:
หมายเลข CVE
ผู้อ่านจะพบว่ามีการอ้างอิงถึงหมายเลข CVE (Common Vulnerabilities and Exposures) ร่วมกับการอธิบายถึงช่องโหว่แต่ละช่องโหว่ หรือบางครั้งอาจพบการกล่าวถึงหมายเลข CAN โดยหมายเลข CAN ถูกใช้ก่อนที่จะเปลี่ยนเป็นหมายเลข CVE ซึ่งหมายความว่าช่องโหว่ดังกล่าวยังไม่ได้รับการตรวจสอบอย่างครบถ้วนสมบูรณ์ ข้อมูลเพิ่มเติมเกี่ยวกับโครงการ CVE สามารถศึกษาได้จาก http://cve.mitre.org

หมายเลข CVE และหมายเลข CAN ถูกแสดงไว้ในแต่ละช่องโหว่ที่สำคัญ ซึ่งผู้ดูแลระบบควรเข้าไปตรวจสอบทุกรายการที่ปรากฏ แหล่งข้อมูลช่องโหว่ที่มีใน CVE แต่ละรายการเชื่อมโยงกับรายการช่องโหว่ที่ถูกรวบรวมโดยบริการข้อมูลดัชนีช่องโหว่ ICAT ของ National Institute of Standard and technology (http://icat.nist.gov) ซึ่ง ICAT จะให้คำอธิบายอย่างย่อของแต่ละช่องโหว่ ลักษณะเฉพาะของแต่ละช่องโหว่ (เช่น ขอบเขตการโจมตีที่เกี่ยวข้อง และความเสียหายที่เกิดขึ้น) รายการของชื่อและเวอร์ชันของซอฟต์แวร์ที่มีช่องโหว่ รวมถึงการเชื่อมโยงไปยังคำแนะนำเกี่ยวกับช่องโหว่และข้อมูล patch ด้วย

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

กลับไปด้านบน ^

ช่องโหว่สำคัญของระบบปฏิบัติการ Windows

ช่องโหว่สำคัญของระบบปฏิบัติการ Unix

กลับไปด้านบน ^

ช่องโหว่สำคัญของระบบปฏิบัติการ Windows (W)
W1 Internet Information Services (IIS)

W1.1 คำอธิบาย
IIS มีแนวโน้มที่มีช่องโหว่ใน 3 ชนิดหลักได้แก่

1. การไม่สามารถจัดการกับการร้องขอที่ผิดจากธรรมดา(Failure to Handle Unanticipated Requests) ช่องโหว่ของ IIS มากมายเกิดจากการที่ IIS ไม่สามารถจัดการกับการร้องขอ HTTP (HTTP reqests) ที่ไม่ถูกต้อง ตัวอย่างของช่องโหว่ที่เป็นที่รู้จักกันดี คือ ช่องโหว่ Unicode directory traversal ซึ่งถูกใช้โดยหนอน Code Blue ในการเข้าใช้ช่องโหว่เหล่านี้ ผู้โจมตีจากภายนอกอาจกระทำการดังต่อไปนี้ :

2. บัพเฟอร์ล้น (Buffer Overflow) ส่วนขยายของ ISAPI มากมาย (รวมถึงส่วนขยายของ ASP, HTR, IDQ, PRINTER, และ SSI) มีช่องโหว่ที่อาจทำให้เกิดบัฟเฟอร์ล้นได้ ตัวอย่างที่เป็นที่รู้จักคือ ช่องโหว่ของส่วนขยาย .idq ISAPI ซึ่งถูกใช้โดยหนอน Code Red และหนอน Code Red II ผู้โจมตีภายนอกอาจทำให้เกิดผลดังนี้ :

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

W1.2 ระบบปฏิบัติการที่ได้รับผลกระทบ

W1.3 หมายเลข CVE ที่เกี่ยวข้อง

CVE-2001-0241, CVE-2001-0333, CVE-2001-0500, CAN-2002-0079, CVE-2000-0884,
CVE-2000-0886, CAN-2002-0071, CAN-2002-0147, CAN-2002-0150, CAN-2002-0364,
CAN-2002-0149, CVE-1999-0191, CAN-1999-0509, CVE-1999-0237, CVE-1999-0264,
CVE-2001-0151, CAN-1999-0736, CVE-1999-0278, CAN-2002-0073, CVE-2000-0778,
CVE-1999-0874, CVE-2000-0226, CAN-1999-1376, CVE-2000-0770, CVE-2001-0507

W1.4 วิธีการตรวจสอบว่า ได้รับผลกระทบจากช่องโหว่นี้หรือไม่
ในช่องโหว่ที่มีอยู่ทั้งหมดนั้น การที่เราจะปิดช่องโหว่บางช่องได้นั้นจะต้องใช้เฉพาะโปรแกรมแก้รวมของ
ไมโครซอฟต์เท่านั้น (cumulative security roll-up package from Microsoft) จึงน่าจะสันนิษฐานได้อย่างค่อนข้างแน่นอนว่า ระบบจะมีช่องโหว่เหล่านั้นแน่นอนถ้าหากไม่ได้รับการติดตั้งแพ็กเกจดังกล่าว ในการตรวจสอบว่าแพ็กเกจของการรักษาความปลอดภัยได้ถูกติดตั้งในระบบหรือไม่ สามารถทำได้โดยการตรวจสอบที่เรจิสทรีย์ว่าเป็นไปตามที่ระบุไว้ต่อไปนี้ในแพลตฟอร์มของระบบที่ใช้หรือไม่

Windows NT 4:

Windows NT 4 Terminal Server Edition:

Windows 2000:

Windows XP:

อีกทางเลือกหนึ่งคือ สามารถตรวจสอบโดยใช้โปรแกรม HFNetChk (ดูเพิ่มเติมที่หัวข้อ "พยายามติดตามข่าวปัจจุบัน" ภายใต้ W1.5) เพื่อตรวจสอบ patch ที่มีอยู่:

บางทีระบบอาจมีช่องโหว่จากการใช้แอพพลิเคชันตัวอย่าง ถ้าไฟล์ใดต่อไปนี้ปรากฏอยู่ในไดเรกทอรี %wwwroot%/scripts (เช่น C:\inetpub\wwwroot\scripts หรือ D:\web\scripts) หรือไดเรกทอรีย่อยใดๆ

W1.5 วิธีการป้องกันอันตรายจากช่องโหว่นี้

1. ติดตั้ง patch ล่าสุด (Apply the current patches) ในกรณีของ IIS 4 บน NT ซึ่งเป็น
Service Pack 6a หมายถึงการติดตั้งแพ็กเก็จรวมของการรักษาความปลอดภัย และ hotfix ส่วนในกรณีของ IIS 5 หรือ 5.1 บน Windows 2000 หรือ Windows XP (ตามลำดับ) แพ็กเก็จรวมของการรักษาความปลอดภัยและ hotfix ได้ถูกรวบรวมไว้ใน service packs แล้ว โดยท่านสามารถดาวน์โหลดได้จากเว็บไซต์ต่อไปนี้ :

IIS 4 on NT 4:

IIS 4 on NT 4 Terminal Server Edition:

IIS 5 on Windows 2000:

IIS 5.1 on Windows XP:

2. พยายามติดตามเหตุการณ์ปัจจุบันอยู่เสมอ(Stay Current) ทั้ง service packs, rollup patches, และ hotfixes แก้ไขได้แต่เพียงปัญหาช่องโหว่ที่ถูกค้นพบมาก่อน ส่วนช่องโหว่ใหม่ของ IIS ยังไม่ถูกค้นพบ จึงจำเป็นต้องทำการติดตั้ง patch ตามโปรแกรม HFNetChk (The Network Security Hotfix Checker) ช่วยผู้ดูแลระบบในการตรวจสอบหา patch ล่าสุดที่ถูกติดตั้งไว้ในระบบตัวเองหรือระบบอื่น เครื่องมือนี้ทำงานบน Windows NT4, Windows 2000, และ Windows XP เวอร์ชันปัจจุบันสามารถดาวน์โหลดได้จากบริษัทไมโครซอฟต์ที่ http://www.microsoft.com/technet/security/tools/hfnetchk.asp

3. กำจัดแอพพลิเคชันตัวอย่าง (Eliminate Sample Application) แอพพลิเคชันตัวอย่างรวมถึงเครื่องมือ iisadmin อาจถูกใช้เพื่อตรวจสอบว่าเซิร์ฟเวอร์ได้รับการติดตั้งอย่างถูกต้องหรือไม่ แต่จะต้องลบเครื่องมือนี้ออกทันทีทุกครั้งที่ใช้งานเสร็จ แอพพลิเคชันเหล่านี้อาจพบได้ในไดเรกทอรี %wwwroot%scripts แต่ทั้งนี้หนทางปฏิบัติที่เหมาะสมคือ ผู้ดูแลระบบไม่ควรเลือกตัวเลือกที่จะติดตั้งแอพพลิเคชันตัวอย่างและเครื่องมือของผู้ดูแลระบบที่ใช้ผ่านทางเว็บเลย

4. ทำการ Unmap ISAPI Extensions ที่ไม่จำเป็น (Unmap Unnecessary ISAPI Extensions) การนำ IIS ไปใช้งานโดยทั่วไปไม่มีความจำเป็นต้องใช้งาน ISAPI extension ส่วนใหญ่ที่ถูก map โดยอัตโนมัติ มาใช้งานโดยเฉพาะ .htr, .idq, .ism, และ .printer ทุกๆ ISAPI extensions ที่ไม่ได้ใช้ควรจะถูก unmap ซึ่งผู้ดูแลระบบสามารถทำได้ด้วยตนเองผ่านทาง Internet Services Manager แต่ IIS Lockdown Wizard จากไมโครซอฟต์ก็สามารถทำได้เช่นกัน โดยที่ท่านสามารถดาวน์โหลดเวอร์ชันล่าสุดได้จากเว็บไซต์ของบริษัทไมโครซอฟต์ที่ http://www.microsoft.com/technet/security/tools/locktool.asp

5. กรองการร้องขอ HTTP ช่องโหว่ IIS ทั้งหลาย (รวมถึงตระกูล Code Blue และ Code Red ด้วย) ใช้การร้องขอที่มีวัตถุประสงค์อันมิชอบที่อยู่ในรูป HTTP ใน directory traversal หรือการโจมตีให้บัฟเฟอร์ล้น เราสามารถตั้งค่าโปรแกรม URLScan filter ให้ปฏิเสธการร้องขอดังกล่าวก่อนที่เซิร์ฟเวอร์จะดำเนินการตอบสนองได้ โปรแกรม URLScan filter เวอร์ชันปัจจุบันได้ถูกรวมไว้ใน IIS Lockdown Wizard แล้ว แต่ท่านสามารถดาวน์โหลดเฉพาะตัวโปรแกรมนี้ได้จากเว็บไซต์ของบริษัทไมโครซอฟต์ที่ http://www.microsoft.com/technet/security/tools/urlscan.asp

กลับไปด้านบน ^

W2 Microsoft Data Access Components (MDAC) -- Remote Data Services

W2.1 คำอธิบาย
Remote Data Services (RDS) component ในเวอร์ชันเก่าของ Microsoft Data Access Components (MDAC) มีช่องโหว่ที่อนุญาตให้ผู้ใช้จากภายนอกสามารถเรียกคำสั่งบนระบบได้ด้วยสิทธิในระดับของผู้ดูแลระบบ ประกอบกับช่องโหว่ใน Microsoft Jet database engine 3.5 (ส่วนหนึ่งของ MS Access) ทำให้ช่องโหว่นี้อาจอนุญาตให้มีการเข้าถึงจากภายนอกแบบปิดบังชื่อ (anonymous external access) เข้าสู่ฐานข้อมูลภายในได้ ช่องโหว่เหล่านี้ได้ถูกค้นพบและมีวิธีแก้ไขเผยแพร่มานานกว่า 2 ปีแล้ว แต่ระบบที่ได้รับการตั้งค่าผิดหรือล้าสมัยก็ยังคงมีความเสี่ยงต่อการถูกโจมตีได้

W2.2 ระบบปฏิบัติการที่ได้รับผลกระทบ
ระบบ Microsoft Windows NT 4.0 ส่วนใหญ่ที่ใช้โปรแกรม IIS 3.0 หรือ 4.0, Remote Data Services 1.5, หรือ Visual Studio 6.0

W2.3 หมายเลข CVE ที่เกี่ยวข้อง
CVE-1999-1011

W2.4 วิธีวิธีการตรวจสอบว่า ได้รับผลกระทบจากช่องโหว่นี้หรือไม่
ถ้าระบบใช้ Microsoft Windows NT 4.0 และ IIS 3.0 หรือ 4.0 ให้ตรวจสอบว่ามีไฟล์ msadcs.dll อยู่หรือไม่ (ปกติจะถูกติดตั้งไว้ใน C:\Program Files\Common Files\System\Msadc\msadc.dll แต่ตำแหน่งการติดตั้งอาจแตกต่างไปขึ้นอยู่กับแต่ละระบบปฏิบัติการ)

W2.5 วิธีป้องกันอันตรายจากช่องโหว่นี้
คำแนะนำที่ดีสำหรับการแก้ไขช่องโหว่ของ RDS และ Jet ถูกเผยแพร่ไว้ที่ http://www.wiretrip.net/rfp/p/doc.asp?id=29&iface=2

ไมโครซอฟต์ออกประกาศข่าวความปลอดภัยหลายฉบับที่มีรายละเอียดและวิธีการแก้ไขช่องโหว่นี้โดยการเปลี่ยนแปลงการตั้งค่าต่างๆ ดังนี้ :

อีกทางเลือกหนึ่งคือการป้องกันปัญหานี้โดยการอัพเกรด ซึ่งท่านสามารถดาวน์โหลด MDAC เวอร์ชันล่าสุดได้ที่ http://www.microsoft.com/data/download.htm

กลับไปด้านบน ^

W3 Microsoft SQL Server

W3.1 คำอธิบาย
Microsoft SQL Server (MSSQL) ประกอบด้วยช่องโหว่อันตรายมากมายที่สามารถช่วยให้ ้ผู้โจมตีขโมยข้อมูลสำคัญ เปลี่ยนแปลงข้อมูลในฐานข้อมูล ทำลายระบบเซิร์ฟเวอร์ SQL และค่าต่างๆ ที่ตั้งไว้ และทำลายเครื่องเซิร์ฟเวอร์ ์ได้

ถึงแม้จะได้มีการเผยแพร่ให้สาธารณชนได้ทราบถึงช่องโหว่ของ MSSQL เหล่านี้แล้ว แต่ก็ยังมีการโจมตีช่องโหว่เหล่านี้ได้สำเร็จอยู่เสมอ แม้กระทั่งหนอน MSSQL ล่าสุดที่แพร่ระบาดในเดือนพฤษภาคม พ.ศ. 2545 ก็ใช้ช่องโหว่ของ MSSQL หลากหลายชนิดที่เป็นที่รู้จักทั่วไป เครื่องต่างๆที่ถูกโจมตีด้วยหนอนชนิดนี้ได้ทำให้การรับ/ส่งข้อมูลทางเครือข่ายเกิดความเสียหายเมื่อเครื่องเหล่านั้นทำการสแกนหาเครื่องอื่นๆ ที่มีช่องโหว่นี้ ท่านสามารถดูข้อมูลเพิ่มเติมเกี่ยวกับหนอนชนิดนี้ได้ที่

SQLSnake/Spida Worm (May 2002)

SQL-Slammer/SQL-Hell/Sapphire Worm (January 2003)

Internet Storm Center ได้บันทึกไว้ว่า พอร์ต 1433 (พอร์ตที่ MSSQL ใช้โดยอัตโนมัติ) เป็นหนึ่งในหลายๆ พอร์ตที่ถูกสแกนบ่อยที่สุด ท่านสามารถดูรายละเอียดเพิ่มเติมในส่วนของ MSSQL นี้ได้จาก CERT

ผู้โจมตีสามารถฉวยโอกาสโดยใช้ SQLSnake จากการที่ชื่อบัญชีของผู้ดูแลระบบที่ถูกตั้งมาโดยอัตโนมัติ (ชื่อบัญชี "sa") ไม่มีรหัสผ่าน
ดังนั้นจึงมีความจำเป็นที่จะต้องตั้งค่าให้เหมาะสมและปกป้องระบบใดๆ ให้เชื่อมั่นได้ว่าชื่อบัญชีและรหัสผ่านทั้งหมดของระบบได้รับการปกป้องหรือยกเลิกการใช้งานโดยสมบูรณ์กรณีที่ไม่ได้ใช้งาน สำหรับข้อมูลเพิ่มเติมเกี่ยวกับการตั้งค่าและจัดการกับรหัสผ่านของบัญชีชื่อ sa สามารถศึกษาได้จากเอกสาร Microsoft Developer Network เรื่อง Changing the SQL Server Administrator Login และ Verify and Change the System Administrator Password by Using MSDE บัญชีชื่อ sa ควรจะมีรหัสผ่านที่ง่ายต่อการจำแต่ยากต่อการเดา ถึงแม้ว่าจะไม่ได้ใช้ในการทำงานของ SQL/MSDE ก็ตาม

ผู้โจมตีสามารถฉวยโอกาสโดยใช้ SQL Slammer จากการล้นของบัฟเฟอร์ของบริการ SQL Server Resolution เมื่อหนอนส่งแพ็กเก็ตโจมตีไปที่พอร์ต 1434/UDP ของเครื่องที่เป็นเป้าหมายซึ่งมีช่องโหว่อยู่จะทำให้บัฟเฟอร์ล้นและความปลอดภัยของเครื่องลดลง ถ้าเครื่องใดๆ เปิดบริการ
SQL อยู่ก็มีความเสี่ยงที่จะเกิดการล้นของหน่วยความจำและได้รับแพ็กเก็ตดังกล่าว ซึ่งจะทำให้เกิดความเสียหายต่อระบบความปลอดภัยทั้งหมดของระบบและเซิร์ฟเวอร์ การป้องกันที่ดีที่สุดจากผลกระทบของหนอนชนิดนี้ที่ดีที่สุดคือการติดตั้ง patch หมั่นตั้งค่าระบบในการป้องกัน และกรองการเข้าออกของแพ็คเก็ตผ่านพอร์ต 1434/UDP ที่ทางออกของเครือข่ายที่เชื่อมไปสู่เครือข่ายภายนอก

เราอาจกล่าวได้ว่า Microsoft Server 2000 Desktop Engine (MSDE 2000) เป็นเซิร์ฟเวอร์ SQL กลายๆ ตัวหนึ่ง ("SQL Server Lite")
เจ้าของระบบหลายท่านไม่ได้ตระหนักว่าระบบของท่านมี MSDE ทำงานอยู่ และมี SQL Server ติดตั้งอยู่ อนึ่ง MSDE 2000 นั้น ถูกติดตั้งไว้เป็นส่วนหนึ่งของผลิตภัณฑ์ของ Microsoft ต่างๆ ดังนี้:

นอกจากนี้ยังมีแพ็กเกจของซอฟต์แวร์อื่นๆ อีกมากมายที่ใช้ซอฟต์แวร์ MSDE 2000 โดยที่ท่านสามารถตรวจสอบรายชื่อล่าสุดของแพ็กเกจซอฟต์แวร์ที่มี MSDE 2000 อยู่ได้จาก http://www.SQLsecurity.com/forum/applicationslistgridall.aspx เนื่องจากซอฟต์แวร์เหล่านี้ใช้ MSDE เป็น database engine หลัก มันจึงมีช่องโหว่เดียวกับ SQL/MSDE Server สำหรับ MSDE 2000 นั้นสามารถถูกตั้งค่าให้รอรับการเชื่อมต่อจากเครื่องลูกข่ายที่เข้ามาได้หลายวิธี โดยสามารถตั้งค่าให้เครื่องลูกข่ายสามารถใช้ named pipes โดยผ่านทางเซสชัน NetBIOS (TCP port 139/445) หรือใช้ซ็อกเก็ตกับการเชื่อมต่อของเครื่องลูกข่ายไปยังพอร์ต 1433/TCP หรือทั้งสองวิธี ไม่ว่าวิธีไหนก็ตามที่ใช้ SQL Server และ MSDE จะรอรับการเชื่อมต่อที่พอร์ต 1434/UDP เสมอ พอร์ตนี้ถูกใช้เป็นพอร์ตตรวจสอบเครื่องลูกข่ายจะส่งข้อความไปยังพอร์ตนี้เพื่อค้นหาวิธีที่เครื่องลูกข่ายควรจะใช้ในการเชื่อมต่อไปยังเซิร์ฟเวอร์

MSDE 2000 จะส่งข้อมูลของตัวเองกลับมาเมื่อใดก็ตามที่มีแพ็กเก็ตไบต์เดี่ยว 0x02 บนพอร์ต 1434/UDP ส่วนแพ็กเก็ตไบต์เดี่ยวอื่นๆ ก่อให้เกิดบัฟเฟอร์ล้นโดยไม่ต้องมีการพิสูจน์ตัวตนกับเครื่องเซิร์ฟเวอร์ และนอกจากนี้อันตรายร้ายแรงยังอาจเกิดจากการโจมตีโดยผ่านทาง UDP โดยไม่คำนึงว่ากระบวนการ MSDE 2000 จะทำงานอยู่ในระบบที่มีความปลอดภัยของ domain user หรือบัญชี SYSTEM ของเครื่องก็ตาม การฉวยโอกาสจากช่องโหว่ด้านความปลอดภัยนี้ได้จะหมายถึงการโจมตีระบบเป้าหมายได้อย่างสมบูรณ์

เนื่องจาก SQL Slammer ฉวยโอกาสจากการล้นของบัฟเฟอร์ในระบบเป้าหมาย การที่จะป้องกันความเสี่ยงนี้ได้คือจะต้องติดตั้ง patch อย่างสม่ำเสมอและตั้งค่าระบบอย่างรอบคอบ การดาวน์โหลดและใช้เครื่องมือป้องกันอาทิ เช่นMicrosoft SQL Critical Update Kit จะช่วยให้สามารถตรวจสอบระบบได้ว่ามีช่องโหว่นี้หรือไม่ ช่วย สแกนทั่วทั้งโดเมนหรือเครือข่ายว่ามีระบบที่ยังคงมีช่องโหว่อยู่หรือไม่ และช่วยอัพเดตไฟล์ที่ติดเชื้อหนอนชนิดนี้โดยอัตโนมัติด้วย SQL Critical Update

กรุณาอ่านรายงานและการวิเคราะห์หนอน SQL/MSDE Slammer เพิ่มเติมใน incidents.org การโจมตีชนิดนี้ส่งผลกระทบต่อการเส้นทางหลักของการเชื่อมต่ออินเทอร์เน็ต (Internet Backbone) เป็นเวลาหลายชั่วโมงในเช้าวันที่ 25 มกราคม พ.ศ. 2546

W3.2 ระบบปฏิบัติการที่ได้รับผลกระทบ
ระบบ Microsoft Windows ที่ติดตั้ง Microsoft SQL Server 7.0, Microsoft SQL Server 2000 หรือ Microsoft SQL Server Desktop Engine 2000

W3.3 หมายเลข CVE ที่เกี่ยวข้อง
CAN-2002-1138, CAN-2002-1137, CAN-2002-0056, CAN-2002-0649, CAN-2001-0542,
CAN-2000-1081, CVE-1999-0999, CAN-2002-0624, CAN-2002-0154, CAN-2000-1209,
CAN-2002-1123, CAN-2002-0186, CVE-2000-0202, CVE-2000-0402, CVE-2000-0485,
CVE-2000-0603, CVE-2001-0344, CVE-2001-0879, CAN-2000-0199, CAN-2000-1082,
CAN-2000-1083, CAN-2000-1084, CAN-2000-1085, CAN-2000-1086, CAN-2000-1087,
CAN-2000-1088, CAN-2001-0509, CAN-2002-0187, CAN-2002-0224, CAN-2002-0641,
CAN-2002-0642, CAN-2002-0643, CAN-2002-0644, CAN-2002-0645, CAN-2002-0650,
CAN-2002-0695, CAN-2002-0721, CAN-2002-0729, CAN-2002-0859, CAN-2002-0982,
CAN-2002-1145, CAN-2003-0118

W3.4 วิธีการตรวจสอบว่า ได้รับผลกระทบจากช่องโหว่นี้หรือไม่
บริษัท Microsoft ได้เผยแพร่เครื่องมือด้านความปลอดภัยไว้ที่ http://www.microsoft.com/sql/downloads/securitytools.asp สำหรับ toolkit ชื่อ SQL Critical Update Kit ประกอบด้วยเครื่องมือที่มีประโยชน์มากมายเช่น SQL Scan, SQL Check, and SQL Critical Update

Chip Andrews จาก sqlsecurity.com ได้เผยแพร่เครื่องมือชื่อ SQLPingv2.2 เครื่องมือนี้จะส่งแพ็กเก็ต UDP แบบไบต์เดี่ยว (ค่าไบต์เป็น 0x02) ไปยังพอร์ต 1434 ของเครื่องเดี่ยวหรือไม่ก็ทุกเครื่องในวง subnet ซึ่งจะทำให้เซิร์ฟเวอร์ SQL ที่กำลังรอรับการเชื่อมต่อที่พอร์ต 1434/UDP นั้นตอบสนองโดยการเปิดเผยรายละเอียดของระบบเช่น หมายเลขเวอร์ชัน ค่าต่างๆ เป็นต้น เครื่องมือ SQLPingv2.2 เป็นเครื่องมือสำหรับสแกนและค้นหาซึ่งเหมือนกับ SQL SCan ของ Microsoft ซึ่งจะไม่ละเมิดความปลอดภัยของระบบและเครือข่าย นอกจากนี้ยังมีเครื่องมือเกี่ยวกับความปลอดภัยอยู่ที่ SQL/MSDE Security Web site ของ Chip Andrews ด้วย

W3.5 วิธีการป้องกันอันตรายจากช่องโหว่นี้
โดยสรุป

1. ยกเลิกการทำงานของบริการ SQL/MSDE Monitor บนพอร์ต 1434/UDP
2. ติดตั้ง service pack ล่าสุดสำหรับ Microsoft SQL/MSDE server และ/หรือ MSDE 2000
3. ติดตั้ง cumulative patch ล่าสุดที่เผยแพร่หลังจาก service pack ล่าสุด
4. ติดตั้ง patch แต่ละตัวที่เผยแพร่ออกมาหลังจาก cumulative patch ล่าสุด
5. เก็บบันทึกการพิสูจน์ตัวตนบนเครื่องเซิร์ฟเวอร์ SQL
6. รักษาความปลอดภัยเครื่องเซิร์ฟเวอร์ทั้งระดับระบบและระดับเครือข่าย
7. ลดระดับสิทธิของบริการ MSSQL/MSDEServer และ SQL/MSDE Server Agent

รายละเอียด

1. ยกเลิกการทำงานของบริการ SQL/MSDE Monitor บนพอร์ต 1434/UDP

สามารถทำได้โดยการติดตั้งและใช้ฟังก์ชันภายใน SQL Server 200 Service Pack 3a Microsoft's database engine MSDE 2000 มีช่องโหว่จากการล้นของบัฟเฟอร์ซึ่งผู้โจมตีจากภายนอกสามารถฉวยโอกาสได้โดยไม่ต้องทำการพิสูจน์ตัวตนกับเครื่องเซิร์ฟเวอร์เลย การโจมตีแบบนี้อาศัยช่องทางของ UDP ไม่ว่ากระบวนการ MSDE 2000 จะทำงานในระบบความปลอดภัยของ domain user หรือบัญชี SYSTEM ของเครื่อง การโจมตีช่องโหว่นี้ถือว่าเป็นการบุกรุกระบบเป้าหมายโดยสมบูรณ์ หนอน MS-SQL/MSDE Slammer ส่ง แพ็กเก็ตที่มีขนาด 376 ไบต์ไปยังพอร์ต 1434 โดยใช้การสุ่มเป้าหมายด้วยอัตราเร็วสูงมาก ระบบที่ถูกโจมตีจะเริ่มส่งแพ็กเก็ตขนาด 376 ไบต์ทันทีที่ติดเชื้อหนอนชนิดนี้ หนอนจะส่งข้อมูลจำนวนมากไปยังหมายเลข IP ที่สุ่มขึ้นมารวมทั้ง IP แบบ multicast ทำให้เครือข่ายเป้าหมายไม่สามารถให้บริการได้ (Denial of Service) อีกต่อไป มีการรายงานว่าเครื่องเครื่องหนึ่งที่ได้รับเชื้อนี้สร้างข้อมูลออกมาในอัตราที่มากกว่า 50 Mb/sec

2. ติดตั้ง service pack สำหรับ Microsoft SQL server สำหรับ Microsoft SQL Server service pack เวอร์ชันล่าสุดคือ

3. ติดตั้ง cumulative patch ล่าสุดที่เผยแพร่หลังจาก service pack ล่าสุด

ท่านสามารถดาวน์โหลด cumulative patch สำหรับ SQL Server ทุกเวอร์ชันได้ที่ MS02-061 Elevation of Privilege in SQL/MSDE Server Web Tasks (Q316333/Q327068)

เพื่อติดตามการอัพเกรดต่อไปอย่างใกล้ชิด ควรตรวจดู cummulative patch ที่:

4. ติดตั้ง patch แต่ละอย่างที่เผยแพร่ออกมาหลังจาก cumulative patch ล่าสุด

ปัจจุบันไม่มี patch เผยแพร่ออกมาหลังจากการเผยแพร่การอัพเกรดของ MS02 -061 Elevation of Privilege in SQL/MSDE Server Web Tasks (Q316333/Q327068) แต่เพื่อติดตามการอัพเกรดต่อไปอย่างใกล้ชิด ควรตรวจดู patch แต่ละชนิดที่เผยแพร่ออกมาที่

5. เก็บบันทึกการพิสูจน์ตัวตนบนเครื่องเซิร์ฟเวอร์ SQL

เปิดให้มีการเก็บบันทึกการพิสูจน์ตัวตนบนเซิร์ฟเวอร์ SQL (ตามปกติจะไม่ได้เปิดไว้) วิธีนี้สามารถทำได้โดยผ่าน Enterprise Manager (Server properties; tab Security)

6. รักษาความปลอดภัยเครื่องเซิร์ฟเวอร์ทั้งระดับระบบและระดับเครือข่าย

จุดอ่อนจุดหนึ่งของ MSSQL ที่มักถูกโจมตีคือ ชื่อบัญชีของผู้ดูแลระบบที่ตั้งมาโดยอัตโนมัติ (คือ "sa") จะไม่มีรหัสผ่าน ถ้าชื่อบัญชี "sa" ของ SQL ไม่ได้รับการปกป้องด้วยรหัสผ่าน ถือว่าระบบไม่มีความปลอดภัยและอาจถูกโจมตีโดยหนอนอินเทอร์เน็ต และการโจมตีแบบอื่นๆ ดังนั้นควรปฏิบัติตามคำแนะนำจากหัวข้อ "System Administraor (SA) login" ใน SQL/MSDE Server Books Online เพื่อทำให้ชื่อบัญชี "sa" ที่มากับระบบมีรหัสผ่านที่แข็งแรง แม้ว่า SQL Server จะไม่ได้ทำงานด้วยชื่อบัญชีนี้ก็ตาม
มีเอกสารเกี่ยวกับระบบเครือข่ายของ Microsoft Developer ที่ การเปลี่ยน SQL Server Administrator Login และวิธีตรวจสอบและเปลี่ยนรหัสผ่านของผู้ดูแลระบบโดยใช้ MSDE

7. ลดระดับสิทธิของบริการ MSSQL/MSDEServer และ SQL/MSDE Server Agent

เปิดบริการ MSSQL/MSDES Server และ SQL/MSDE Server Agent ภายใต้ชื่อบัญชีของโดเมนที่ใช้ได้ (valid domain account) ด้วยสิทธิที่น้อยที่สุดที่จะยอมให้มีการเปิดบริการได้ และต้องไม่เป็นชื่อบัญชีของผู้ดูแลโดเมนหรือ SYSTEM (บน NT) หรือ LocalSystem (บน Windows 2000 หรือ XP) หากมีการเปิดบริการโดยใช้ชื่อบัญชีที่มีสิทธิพิเศษดังกล่าวข้างต้นในระดับ local หรือโดเมน จะทำให้ผู้โจมตีสามารถควบคุมเครื่องและ/หรือเครือข่ายได้อย่างสมบูรณ์

  1. เปิดใช้ WindowsNT Authentication คือการเปิดใช้การตรวจสอบการล็อกอินเข้าสู่ระบบทั้งที่สำเร็จและไม่สำเร็จ แล้วหยุดและเริ่มบริการ MSSQL Server ใหม่ ตั้งค่าการทำงานของเครื่องลูกข่ายให้ใช้ NT Authentication ด้วย
  2. ควรให้มีการกรองแพ็คเก็ตบริเวณขอบของเครือข่ายเพื่อป้องกันการเชื่อมต่อจากภายนอกมาใช้บริการโดยไม่ได้รับอนุญาต การกรองข้อมูลขาเข้าของ TCP port 1433 และ 1434 สามารถป้องกันผู้โจมตีจากภายนอกเครือข่ายที่จะมาสแกนหรือโจมตีช่องโหว่ของ Microsoft SQL servers ในเครือข่ายภายในซึ่งไม่อนุญาตในการให้บริการ SQL สู่ภายนอก
  3. ถ้าจำเป็นต้องเปิดใช้พอร์ต 1433/TCP และ 1434/TCP ที่ Internet gateways ให้เปิดใช้และตั้งค่าการกรองแพ็คเก็ตขาเข้า/ขาออก ให้รัดกุมที่สุดเพื่อป้องกันการใช้พอร์ตนี้ในทางที่ผิด

ท่านสามารถค้นหาข้อมูลเพิ่มเติมเกี่ยวกับการรักษาความปลอดภัยของ Microsoft SQL Server ได้จาก

กลับไปด้านบน ^

W4 NETBIOS -- Unprotected Windows Networking Shares

W4.1 คำอธิบาย
Microsoft Windows สามารถเปิดให้ผู้ใช้ใช้ไฟล์หรือโฟลเดอร์ร่วมกันผ่านทางเครือข่ายโดยใช้ระบบ Windows network shares การร่วมกันใช้ไฟล์หรือโฟลเดอร์ ดังกล่าวนี้กระทำโดยใช้โพรโตคอล Server Message Block (SMB) หรือ Common Internet File System (CIFS) โพรโตคอลเหล่านี้จะอนุญาตให้ผู้ใช้ที่อยู่บนเครื่องหนึ่งสามารถใช้ไฟล์ที่อยู่ในอีกเครื่องหนึ่งโดยเปรียบเสมือนว่าไฟล์นั้นอยู่ในเครื่องของผู้ใช้เอง
ถึงแม้ว่าคุณสมบัตินี้จะอำนวยความสะดวกในการทำงานบนวินโดวส์ หากผู้ใช้ตั้งค่าของ network shares ไม่ถูกต้อง อาจจะทำให้มีการเปิดเผยไฟล์ของระบบที่มีความสำคัญได้ หรืออาจจะเป็นการเปิดโอกาสให้ผู้ใช้หรือโปรแกรมที่มีวัตถุประสงค์ร้ายสามารถเข้ามาควบคุมเครื่องคอมพิวเตอร์ได้ ซึ่งวิธีหนึ่งที่ไวรัส Sircam (ดูรายละเอียดเพิ่มเติมที่ CERT Advisory 2001-22) และหนอน Nimda (ดูรายละเอียดเพิ่มเติมที่ CERT Advisory 2001-26) ใช้ในการกระจายตัวอย่างรวดเร็วในช่วงฤดูร้อนของปี 2001 คือโดยการค้นหาเครื่องที่ network shares ที่ไม่ได้รับการป้องกัน แล้วทำการสำเนาตัวเอง เข้าไว้ในเครื่องนั้น จะเห็นได้ว่า แฮกเกอร์สามารถแอบบุกรุกเข้ามาในเครื่องคอมพิวเตอร์โดยที่เจ้าของไม่รู้ตัวได้ หากเจ้าของเครื่องเปิดบางไดร์ฟให้ผู้ใช้ในเครือข่ายมีสิทธิในการอ่าน (readable) และเขียน (writeable) ได้ แต่ถ้าเจ้าของเครื่องมีความระมัดระวังในการตั้งค่า network shares ให้ถูกต้องก็จะสามารถลดความเสี่ยงลงได้

W4.2 ระบบปฏิบัติการที่ได้รับผลกระทบ
Windows 95, Windows 98, Windows NT, Windows Me, Windows 2000, และ Windows XP ล้วนแต่มีช่องโหว่นี้ทั้งสิ้น

W4.3 หมายเลข CVE ที่เกี่ยวข้อง
CAN-1999-0519, CVE-2000-0979, CAN-2000-1079, CAN-1999-0621, CAN-1999-0520, CAN-1999-0518

w4.4 วิธีการตรวจสอบว่า ได้รับผลกระทบจากช่องโหว่นี้หรือไม่
สำหรับ Windows NT (SP4), Windows 2000 หรือ Windows XP นั้น Microsoft Baseline Security Advisor จะรายงานว่าเครื่องนั้นมีจุดอ่อนจากการโจมตีโดยผ่านทาง SMB หรือไม่ และสามารถใช้ในการปิดรูรั่วนี้ได้ด้วย การทดสอบสามารถทำที่เครื่องตนเอง หรือบนเครื่องอื่นก็ได้ โปรแกรม Scanner ที่มีขายตามท้องตลาดที่ใช้สำหรับสแกนเครือข่ายส่วนใหญ่จะสามารถตรวจพบการแชร์ที่เปิดไว้ นอกจากนี้ยังมีเครื่องมือทดสอบที่มีความปลอดภัยและทำงานรวดเร็วสำหรับตรวจว่ามีการแชร์ไฟล์ SMB หรือไม่ และมีช่องโหว่ที่เกี่ยวข้องหรือไม่ ซึ่งใช้ได้บนเครื่องที่ใช้ Windows ทุกชนิดโดยท่านสามารถดาวน์โหลดเครื่องมือทดสอบนี้ได้ฟรีที่เว็บไซต์ของ Gibson Research Corporation (http://grc.com/) โดยเลือกลิงค์ไปที่ "ShieldsUP" เพื่อดาวน์โหลดโปรแกรมที่ใช้ในการประเมินช่องโหว่ของ SMB แบบ real-time ในระบบต่างๆ ซึ่งจะมีคำแนะนำอย่างละเอียดเผยแพร่เพื่อช่วยให้ผู้ใช้ Microsoft Windows สามารถจัดการกับช่องโหว่ SMB ได้ มีข้อสังเกตว่าถ้าเครื่องถูกเชื่อมต่อผ่านเครือข่ายซึ่งมีอุปกรณ์เชื่อมตัวกลางที่ SMB ได้รับการป้องกันแล้ว เครื่องมือ ShieldsUP จะรายงานว่าเครื่องนั้นไม่มีช่องโหว่ ทั้งที่จริงแล้วมีช่องโหว่ ตัวอย่างเช่น สำหรับผู้ใช้ที่เชื่อมผ่านเคเบิ้ลโมเด็ม ซึ่งผู้ให้บริการได้ทำการป้องกัน SMB ไม่ให้ผ่านมายังเครือข่ายของเคเบิ้ลโมเด็ม เครื่องมือ ShieldsUP จะรายงานว่าเครื่องของผู้ใช้ไม่มีช่องโหว่ อย่างไรก็ตาม ผู้ใช้คนอื่นๆ ที่ใช้การเชื่อมต่อด้วยเคเบิ้ลโมเด็มเช่นเดียวกันก็สามารถโจมตีช่องโหว่นี้ได้

W4.5 วิธีการป้องกันอันตรายจากช่องโหว่นี้

กลับไปด้านบน ^

W5 Anonymous Logon -- Null Sessions

W5.1 คำอธิบาย
การเชื่อมต่อแบบ Null Session เรียกอีกชื่อหนึ่งว่า Anonymous Logon เป็นกลไกที่อนุญาตให้ผู้ใช้ใดๆ สามารถดึงข้อมูล (เช่น ชื่อผู้ใช้และการแชร์) ผ่านทางเครือข่าย หรือสามารถเชื่อมต่อได้โดยไม่มีการพิสูจน์ตัวตน คุณสมบัตินี้ถูกใช้โดยแอพพลิเคชัน เช่น Windows Explorer เพื่อใช้ระบุรายละเอียดการแชร์ในเซิร์ฟเวอร์ที่อยู่ต่างเครือข่ายกัน บนระบบ Windows NT, 2000, และ XP มีบริการต่างๆที่เปิดอยู่ภายใต้ SYSTEM account หรือที่รู้จักกันในชื่อ Local System บน Windows 2000 และ XP ซึ่ง SYSTEM account นี้ ถูกใช้ในทำงานที่สำคัญของระบบมากมาย เมื่อเครื่องหนึ่งต้องการดึงข้อมูลระบบ (system data) จากอีกเครื่องหนึ่ง SYSTEM account จะทำการเปิด null session ไปยังเครื่องนั้น
SYSTEM account มีสิทธิพิเศษที่ไม่จำกัดและไม่มีรหัสผ่านดังนั้นโดยปกติแล้วจะไม่มีการอนุญาตให้สามารถล็อกออน (log on) เป็น System ได้ แต่บางครั้ง SYSTEM account ต้องการเข้าถึงข้อมูลบนเครื่องอื่นๆ เช่น แชร์ที่เปิดไว้ ชื่อ user และอื่นๆ ซึ่งเป็นคุณสมบัติของ Network Neighborhood แต่เนื่องจากมันไม่สามารถล็อกอินเข้าสู่ระบบอื่นๆ ได้โดยใช้ UserID และรหัสผ่าน มันจึงต้องใช้ Null session เพื่อเข้าถึงแทน ซึ่งผู้โจมตีก็สามารถล็อกอินเป็น Null Session ได้เช่นกัน

W5.2 ระบบปฏิบัติการที่ได้รับผลกระทบ
ทุกๆ ประเภทของ Microsoft Windows NT, 2000 และ XP

W5.3 หมายเลข CVE ที่เกี่ยวข้อง
CVE-2000-1200

W5.4 วิธีการตรวจสอบว่า ได้รับผลกระทบจากช่องโหว่นี้หรือไม่
ลองพยายามเชื่อมต่อเข้าสู่ระบบด้วย Null session โดยใช้คำสั่งต่อไปนี้
net use \\a.b.c.d\ipc$ ""/user:""
(เมื่อ a.b.c.d คือ IP address ของระบบที่ต้องการตรวจสอบ)

ถ้าได้รับการตอบสนองว่า "connection failed" แสดงว่าระบบนั้นไม่มีช่องโหว่ ถ้าไม่มีการตอบกลับหมายความว่าคำสั่งนี้ทำงานสำเร็จและระบบนั้นมีช่องโหว่

ใช้ "Hunt for NT" ได้เช่นกัน ซึ่งเป็นส่วนประกอบของ NT Forensic Toolkit จาก http://www.foundstone.com/

W5.5 วิธีการป้องกันอันตรายจากช่องโหว่นี้
Domain controllers ต้องใช้ Null sessions ในการสื่อสาร ดังนั้นถ้าท่านทำงานโดยเป็นส่วนหนึ่งของ domain ท่านจะสามารถลดจำนวนข้อมูลที่ผู้โจมตีสามารถเอาไปได้ให้น้อยที่สุด แต่จะไม่สามารถป้องกันการรั่วไหลของข้อมูลได้โดยสิ้นเชิง ในการจำกัดจำนวนข้อมูลที่ผู้โจมตีจะเอาไป ทำได้โดยการแก้ไขเรจีสทรีย์คีย์ต่อไปนี้

HKLM/System/CurrentControlSet/Control/LSA/RestrictAnonymous=1

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

การตั้งค่า RestrictAnonymous เป็น 1 จะยังคงทำให้ข้อมูลสามารถถูกใช้โดย anonymous users ได้ แต่จะลดการรั่วไหลของข้อมูลให้น้อยลง นี่เป็นการจำกัดในระดับเครื่องที่เข้มงวดที่สุดใน Windows NT ส่วนใน Windows 2000 และ XP สามารถตั้งค่าเป็น 2 แทนได้ ซึ่งจะห้าม anonymous users หรือกลุ่ม everyone รวมถึง null session users ไม่ให้เข้าถึงข้อมูลทั้งหมดที่ไม่ได้อนุญาตให้เข้าถึง แต่การตั้งค่าที่สูงกว่าเช่นนี้อาจมีผลต่อ domain synchronization หรือบริการอื่นๆ ดังนั้นจึงต้องมีการทดสอบอย่างละเอียดก่อน และมีความจำเป็นที่จะต้องตั้งค่านี้ให้แก่เครื่องต่างๆ ที่เชื่อมต่อกับอินเทอร์เน็ต และเครื่องอื่นๆ ทั้งหมดควรได้รับการปกป้องโดยไฟร์วอลล์ซึ่งได้รับการตั้งค่าป้องกัน NetBIOS และ CIFS ไว้

หากไม่ต้องการการแชร์ไฟล์และเครื่องพิมพ์ ให้ทำการ unbind NetBIOS จาก TCP/IP

หมายเหตุ : การตั้งค่า RestrictAnonymous บน domain controllers และบริการอื่นๆ สามารถรบกวนการทำงานปกติต่างๆ ในเครือข่ายได้

ผู้ใช้อินเทอร์เน็ตไม่ควรได้รับอนุญาตให้เข้าถึง domain controller ใดๆ ที่อยู่ในเครื่อข่ายภายใน หรือเครื่องคอมพิวเตอร์อื่นๆ ซึ่งไม่ได้เปิดให้สามารถมีการเข้าถึงจากภายนอก ในการระงับการเข้าถึงนั้น ให้ทำการป้องกันพอร์ต TCP และ UDP ดังนี้ 135, 137, 138, 139, และ 445 ที่เราท์เตอร์หรือไฟร์วอลล์

กลับไปด้านบน ^

W6 LAN Manager Authentication -- Weak LM Hashing

W6.1 คำอธิบาย
ถึงแม้ว่าระบบ Windows ส่วนใหญ่ไม่มีความจำเป็นต้องใช้ LAN Manager (LM) แล้ว แต่ Microsoft ก็ได้ติดตั้งระบบ hash ของรหัสผ่านสำหรับ LM (LANMAN hashes) ไว้โดยอัตโนมัติบนระบบ Windows NT, 2000, และ XP เนื่องจาก LM ใช้โครงสร้างการเข้ารหัสที่อ่อนแอ
กว่าโครงสร้างการเข้ารหัสของ Microsoft ปัจจุบัน (NTLM และ NTLMv2) รหัสผ่าน LM สามารถถูกเจาะได้ในเวลาอันสั้น แม้รหัสผ่านที่แข็งแกร่งก็สามารถถูกเจาะโดยวิธี brute-force (การลองทุกอักษร) ได้ภายใน 1 สัปดาห์

ความอ่อนแอของ LM hashes เกิดจาก

จะเห็นได้ว่ากระบวนการ hash ของ LM ดังที่กล่าวข้างต้นนั้นทำให้ผู้โจมตีต้องการเพียงเพื่อเจาะรหัสผ่านที่มีตัวอักษร 7 ตัว 2 ชุด และเป็นอักษรตัวใหญ่เพื่อเข้าถึงระบบได้โดยไม่ต้องพิสูจน์ตัวตน เนื่องจากความยากในการเจาะ hash จะเพิ่มขึ้นตามความยาวของ hash ดังนั้นกลุ่มตัวอักษร 7 ตัว 2 กลุ่มจะถูกโจมตีโดย brute-force ได้ง่ายกว่ากลุ่มสตริงที่ประกอบด้วยตัวอักษร 14 ตัว และเนื่องจากกลุ่มตัวอักษร 7 ตัว (รวมเว้นวรรคด้วย) นั้นเป็นตัวอักษรใหญ่ทั้งหมด ทำให้การโจมตีโดยใช้คำจากพจนานุกรม (dictionary-style attack) ก็ทำได้ง่ายเช่นกัน กระบวนการ hash ของ LM จึงทำให้นโยบายการตั้งรหัสผ่านที่ดีอ่อนแอลงได้

นอกจากความเสี่ยงที่เกิดจากการมี LM hashes เก็บไว้ใน SAM แล้ว กระบวนการพิสูจน์ตัวตนของ LAN Manager (LAN Manager authentication process) ที่อ่อนแอมักถูกเปิดให้ทำงานบนเครื่องลูกข่ายและเครื่องเซิร์ฟเวอร์จะยอมรับกระบวนการนั้นโดยอัตโนมัติ ผลที่ตามมาคือ เครื่องที่ใช้ hash algorithms ที่แข็งแกร่ง จะส่ง LM hashes ที่อ่อนแอผ่านเครือข่ายออกไปแทน LM hashes ที่แข็งแกร่ง ทำให้การพิสูจน์ตัวตนของเครื่องมีช่องโหว่และถูกดักจับแพ็คเก็ต (packet sniffing) ดังนั้นจึงทำให้ผู้โจมตีสามารถได้รับรหัสผ่านและสุ่มเดารหัสผ่านของผู้ใช้ได้โดยง่าย

W6.2 ระบบปฏิบัติการที่ได้รับผลกระทบ
ระบบปฏิบัติการ Microsoft Windows ทุกชนิด

W6.3 หมายเลข CVE ที่เกี่ยวข้อง
ไม่มี

W6.4 วิธีการตรวจสอบว่า ได้รับผลกระทบจากช่องโหว่นี้หรือไม่
ถ้าเครื่องใช้ Windows NT, 2000, หรือ XP ที่ได้รับการติดตั้งแบบเลือกค่าติดตั้งอัตโนมัติ (default) ก็กล่าวได้ว่าเครื่องนั้นมีช่องโหว่เนื่องจาก LAN Manager hases ถูกติดตั้งในเครื่องโดยอัตโนมัติ

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

โปรแกรมที่ดีโปรแกรมหนึ่งที่ใช้ในการตรวจสอบความแข็งแรงของรหัสผ่านซึ่งใช้งานบนระบบ Windows อย่าง LC4 (l0phtcrack เวอร์ชัน 4 ดาวน์โหลดได้จาก http://www.atstake.com/research/lc/download.html) จะแสดง hashes ทั้งหมดที่พบในฐานข้อมูลของ SAM (LM, NTLM, หรือ NTLMv2) และบอกให้ทราบถึงการเดารหัสผ่านที่สำเร็จแต่ละครั้งข้อควรระวัง: อย่ารัน paword scanner แม้ว่าจะเป็นเครื่องที่ท่านมีสิทธิ์เข้าถึงในระดับผู้ดูแลระบบโดยไม่ได้รับอนุญาตจากผู้บังคับบัญชาก่อน เพราะอาจขัดกับนโยบายความปลอดภัยขององค์กรท่านและส่งผลถึงความผิดทางวินัยได้

W6.5 วิธีการป้องกันอันตรายจากช่องโหว่นี้
1. ยกเลิกการทำงานของการพิสูจน์ตัวตนผ่านเครือข่าย
เครื่องมือที่ใช้แทนที่การทำงานของการพิสูจน์ตนเองของ LM ได้ดีที่สุดคือ NT LAN Manager เวอร์ชัน 2 (NTLMv2) วิธีการทำงานและตอบสนองของ NTLMv2 สามารถลดจุดอ่อนที่มีใน LM ได้โดยใช้กลไกการเข้ารหัสที่แข็งแกร่ง และกลไกการพิสูจน์ตัวตนที่ได้รับการปรับปรุงให้ดีขึ้นรวมทั้งกลไกด้านความปลอดภัยของการเชื่อมต่อ (session security mechanisms) ด้วย เรจิสทรีย์คีย์ที่ใช้ตั้งค่าเครื่องมือนี้อยู่ใน Windows NT และ 2000 คือ

Hive: HKEY_LOCAL_MACHINE
Key: System\CurrentControlSet\Control\LSA
Value: LMCompatibilityLevel
Value Type: REG_DWORD - Number
Valid Range: 0-5
Default: 0

คำอธิบาย : พารามิเตอร์นี้ระบุถึงชนิดของการพิสูจน์ตัวตนที่ใช้อยู่
0 - ส่งการตอบสนองของ LM และ NTLM; ไม่ใช้กลไกความปลอดภัยของการเชื่อมต่อของ NTLMv2
1 - ใช้กลไกความปลอดภัยของการเชื่อมต่อของ NTLMv2 ถ้ามีการร้องขอ
2 - ส่งเฉพาะการพิสูจน์ตัวตนของ NTLM
3 - ส่งเฉพาะการพิสูจน์ตัวตนของ NTLMv2
4 - DC ปฏิเสธการพิสูจน์ตัวตนของ LM
5 - DC ปฏิเสธการพิสูจน์ตัวตนของ LM และ NTLM (รับเฉพาะของ NTLMv2)

ถ้าเครื่องทั้งหมดเป็น Windows NT Service Pack 4 หรือใหม่กว่า สามารถตั้งค่านี้เป็น 3 บนเครื่องลูกข่ายทั้งหมด และ 5 บน domain controllers ทุกเครื่องเพื่อป้องกันการส่งผ่าน LM hashes บนเครือข่าย อย่างไรก็ตามระบบเก่า เช่น Windows 95/98 ตามที่ตั้งค่าอัตโนมัติไว้นั้น จะไม่มีการใช้ NTLMv2 กับเครื่องลูกข่าย (the default Microsoft Network client) ดังนั้นหากต้องการใช้ NTLMv2 ต้องติดตั้ง Directory Services Client และทันทีที่ติดตั้งเสร็จ ชื่อของค่าเรจิสทรีย์คือ "LMCompatibility" และค่าที่ตั้งได้คือ 0 และ 3

ถ้าไม่สามารถกำหนดให้เครื่องลูกข่ายที่ใช้ระบบเก่าใช้ NTLMv2 ได้ เราสามารถปรับปรุงระบบ hash ของ LMโดยการบังคับใช้ NTLM (NT Lan Manager เวอร์ชัน 1) ที่ domain controller (ตั้งค่า "LMCompatibilityLevel" เป็น 4) แต่ทางเลือกที่ปลอดภัยที่สุดสำหรับระบบเก่าคือการเปลี่ยนไปใช้ระบบที่ใหม่กว่า เนื่องจากระบบปฏิบัติการที่เก่ากว่าโดยทั่วไปแล้วจะมีระดับความปลอดภัยต่ำกว่า

2. ป้องกันไม่ให้มีการติดตั้ง LM Hash
ปัญหาใหญ่ปัญหาหนึ่งเกี่ยวกับการกำจัด LM hashes ที่ถูกส่งผ่านเครือข่ายคือ hashes ยังคงถูกสร้างและเก็บไว้ใน SAM หรือ Active Directory ทาง Microsoft มีกลไกเพื่อไม่ให้มีการสร้าง LM hashes ได้ แต่สำหรับเฉพาะ Windows 2000 และ XP เท่านั้น สำหรับบนระบบ Windows 2000 สามารถกระทำได้โดยใช้ค่าเรจิสทรีย์คีย์ต่อไปนี้

Hive: HKEY_LOCAL_MACHINE
Key: System\CurentControlSet\Control\LSA\NoLMHash

ถ้าคีย์นี้ถูกสร้างบนระบบ Windows 2000 Domain Controller แล้ว LanMan hashes จะไม่ถูกสร้างและเก็บไว้ใน Active Directory อีกเลย

ส่วนบนระบบ Windows XP สามารถกระทำได้โดยใช้ค่าเรจิสทรีย์คีย์ดังนี้

Hive: HKEY_LOCAL_MACHINE
Key: System\CurrentControlSet\Control\Lsa
Value: NoLMHash
Type: REG_DWORD - Number
Data: 1

หลังจากทำการแก้ไขค่าเรจิสทรีย์แล้ว ต้องให้เครื่องเริ่มทำงานใหม่ (reboot) เพื่อให้เกิดการเปลี่ยนแปลงตามที่แก้ไขไว้
สิ่งสำคัญที่ต้องคำนึงถึง : วิธีนี้เป็นเพียงวิธีป้องกัน ไม่ให้มีการสร้าง LM hash ขึ้นมาใหม่ สำหรับ LM hashes ที่มีอยู่แล้วจะถูกกำจัดทิ้งครั้งต่อไปเมื่อผู้ใช้เปลี่ยนรหัสผ่าน

นอกจากนี้ยังมีแหล่งอ้างอิงอื่นๆที่มีประโยชน์ เช่น บทความของ Microsoft ดังที่เห็นด้านล่าง :

กลับไปด้านบน ^

W7 General Windows Authentication -- Accounts with No Passwords or Weak Passwords

W7.1 คำอธิบาย
รหัสผ่าน วลีรหัสผ่าน (passphrases) และโค้ดที่เกี่ยวข้องกับความปลอดภัยนั้นโดยปกติแล้วจะถูกนำมาใช้ในการสื่อสารกันระหว่างผู้ใช้กับระบบสารสนเทศ ซึ่งโดยทั่วไปแล้วระบบการพิสูจน์ตัวตนผู้ใช้ รวมถึงการเก็บรักษาข้อมูลหรือไฟล์ส่วนใหญ่จะเชื่อมั่นในค่ารหัสผ่านที่ได้รับจากผู้ใช้ เนื่องจากข้อมูลการเข้าถึงระบบโดยผ่านขั้นตอนการพิสูจน์ตัวตนตามที่ระบบกำหนดจะไม่ได้รับการบันทึกไว้เป็นหลักฐาน หรือหากบันทึกก็จะไม่บันทึกละเอียดถึงขั้นที่มีการบันทึกการเข้าถึงระบบที่ผิดพลาดไว้ ดังนั้นจึงอาจมีการนำรหัสผ่านที่ได้รับจากวิธีการที่ไม่ถูกต้องมาใช้ในการเข้าถึงข้อมูลระบบโดยที่ผู้ดูแลระบบไม่สามารถตรวจพบได้ ทั้งนี้ ตัวผู้บุกรุกจะได้สิทธิอย่างสมบูรณ์ในการเข้าใช้งานทรัพยากรที่เจ้าของรหัสผ่านตัวจริงสามารถใช้ได้ทั้งหมด และผู้บุกรุกจะพยายามขยายผลให้สามารถเข้าถึงบัญชีผู้ใช้คนอื่นๆ เครื่องคอมพิวเตอร์ที่อยู่ข้างเคียง รวมถึงพยายามให้ได้รับสิทธิเป็นผู้ดูแลระบบ ถึงแม้ว่าผู้ใช้ทุกคนจะทราบถึงความเสี่ยงนี้ แต่ก็ยังคงมีการใช้รหัสผ่านที่ไม่ดีพอหรือไม่มีการกำหนดรหัสผ่านอยู่ ซึ่งหากองค์กรใดมีนโยบายเรื่องรหัสผ่านที่ดีจะลดโอกาสและความเสี่ยงเหล่านี้ได้

ช่องโหว่ของรหัสผ่านที่พบมากที่สุดได้แก่
1) บัญชีผู้ใช้ที่มีรหัสผ่านที่อ่อนแอหรือไม่มีรหัสผ่านเลย
2) ผู้ใช้มักไม่เก็บซ่อนรหัสผ่านของตนเองไว้เป็นอย่างดี (ในที่นี้ไม่เกี่ยวกับเรื่องความแข็งแกร่งของรหัสผ่าน)
3) ระบบปฏิบัติการหรือซอฟต์แวร์ที่ติดตั้งภายหลังสร้างชื่อบัญชีของผู้ดูแลระบบ (administrative accounts) โดยมีรหัสผ่านที่อ่อนแอหรือไม่มีรหัสผ่านเลย
4) ลำดับวิธีของ password hashing เป็นที่รู้จักโดยทั่วไปและ hashes มักถูกเก็บไว้ในที่ที่มีผู้รับรู้และเห็นเสมอ

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

W7.2 ระบบปฏิบัติการที่ได้รับผลกระทบ
ทุกระบบหรือแอพพลิเคชันที่ผู้ใช้พิสูจน์ตัวตนโดยใช้ชื่อบัญชี (user ID) และรหัสผ่าน (password)

W7.3 หมายเลข CVE ที่เกี่ยวข้อง
CAN-1999-0506, CAN-1999-0504, CVE-2000-0222, CAN-1999-0505

W7.4 วิธีการตรวจสอบว่า ได้รับผลกระทบจากช่องโหว่นี้หรือไม่
ถึงแม้ว่าค่า hash ของรหัสผ่านจะได้รับการเก็บรักษาอย่างปลอดภัย แต่ยังคงมีวิธีการเดารหัสผ่านโดยวิธีอื่น โดยทั่วไปแล้ว ตัวอย่างของความบกพร่องในการใช้งานรหัสผ่านที่เห็นได้ชัดเจน ได้แก่ การที่มียังคงมีชื่อผู้ใช้ที่ออกจากองค์กรแล้วอยู่ในบัญชีผู้ใช้โดยที่ยังคงเปิดให้ใช้งานได้ หรือมีบัญชีผู้ใช้สำหรับบริการที่ไม่ได้เปิดใช้งาน วีธีการเดียวที่จะสามารถทราบได้ว่ารหัสผ่านของผู้ใช้งานแต่ละคนเป็นรหัสผ่านที่ดีหรือไม่ ทำได้โดยการทดสอบด้วยเครื่องมือสุ่มเดารหัสผ่านซึ่งผู้บุกรุกนิยมใช้ ข้อควรระวัง: ผู้ใช้จะต้องไม่ใช้การตรวจสอบรหัสผ่านโดยที่ไม่ได้การยินยอมจากผู้ใช้งานระบบทุกคนอย่างชัดเจนหรือเป็นลายลักษณ์อักษร แม้ว่าจะเป็นระบบที่ตนเองมีสิทธิในระดับของผู้ดูแลระบบก็ตาม ผู้ดูแลระบบบางคนที่ใช้งานเครื่องมือสุ่มเดารหัสผ่านโดยไม่ได้รับอนุญาตอาจถูกให้ออกจากองค์กรได้ แม้ว่าจะไม่ได้มีเจตนาในการบุกรุกหรือทำอันตรายระบบก็ตาม

เครื่องมือสุ่มเดารหัสผ่านที่ดีที่สุด ได้แก่

W7.5 วิธีการป้องกันอันตรายจากช่องโหว่นี้
การป้องกันที่ดีและเหมาะสมที่สุดจากข้อบกพร่องในการใช้งานรหัสผ่านคือ การบังคับใช้นโยบายที่รัดกุม ซึ่งประกอบด้วยคำแนะนำเพื่อให้ผู้ใช้ทราบถึงข้อควรปฏิบัติในการใช้งานรหัสผ่านที่ดี และการตรวจสอบความถูกต้องของรหัสผ่าน

  1. ตรวจสอบให้มั่นใจว่ารหัสผ่านทั้งหมดมีความปลอดภัย หากมีฮาร์ดแวร์ที่เหมาะสมและเวลาเพียงพอ ผู้บุกรุกสามารถคาดเดารหัสผ่านใดๆ ได้โดยวิธีการลองรหัสผ่านโดยใช้ทุกตัวอักษร (brute force) แต่มีวิธีการที่ง่ายกว่าและได้ผลดีในหาค้นหารหัสผ่านโดยไม่ต้องใช้เวลาหรือทรัพยากรมากนัก ผู้ที่ต้องการสุ่มเดารหัสผ่านจะใช้การโจมตีในรูปแบบที่รู้จักกันในชื่อ dictionary-style เนื่องจากเป็นที่ทราบทั่วไปว่ารหัสผ่านของผู้ใช้ต้องผ่านกระบวนการเข้ารหัสก่อนที่จะเก็บลงในเครื่อง โปรแกรมสุ่มเดารหัสผ่านส่วนใหญ่จึงใช้วิธีการเปรียบเทียบระหว่างรหัสผ่านที่เข้ารหัสเก็บไว้ในเครื่อง กับคำศัพท์ในพจนานุกรม (หลายๆ ภาษา) ชื่อบางชื่อ หรือการผสมชื่อและคำศัพท์ในพจนานุกรมที่ผ่านการเข้ารหัสด้วยวิธีเดียวกัน ดังนั้นรหัสผ่านที่มาจากการผสมคำต่างๆ ด้วยวิธีการใดๆ จะถูกโจมตีด้วยวิธีการ dictionary ได้โดยง่าย หลายองค์กรแนะนำให้ผู้ใช้สร้างรหัสผ่านขึ้นโดยการผสมตัวอักษรเข้ากับอักขระพิเศษ และไม่ควรนำมาจากคำเพียงคำเดียว (เช่น "password") แล้วนำมาแปลงจากตัวอักษรเป็นอักขระพิเศษ (เช่น "pa$$w0rd") การผสมกันตามตัวอย่างนี้ไม่สามารถใช้ป้องกันการโจมตีแบบ dictionary ได้ ทั้งนี้การใช้รหัสผ่านว่า "pa$$w0rd" มีความเสี่ยงใกล้เคียงกับการใช้รหัสผ่านว่า "password" โดยตรง

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

    หลังจากที่ผู้ใช้ได้รับคำแนะนำที่เหมาะสมเรื่องการตั้งรหัสผ่านที่ดี สิ่งที่ควรดำเนินการต่อไปเพื่อตรวจสอบว่าคำแนะนำดังกล่าวได้รับการปฏิบัติตาม วิธีการที่ดีที่สุดคือการตรวจสอบในขณะที่ผู้ใช้ใส่ค่ารหัสผ่านใหม่ที่ต้องการเปลี่ยน บนระบบปฏิบัติการ Unix สามารถทำได้โดยใช้โปรแกรม Npasswd ซึ่งจะทำหน้าที่ตรวจสอบค่ารหัสผ่านที่ผู้ใช้ใส่ว่าเป็นไปตามนโยบายการใช้งานรหัสผ่านหรือไม่ก่อนที่จะแก้ไขลงในระบบ ส่วนระบบที่เปิดใช้งาน PAM สามารถเรียกใช้งาน cracklib เพื่อทำหน้าที่ดังกล่าว (เป็นไลบรารีที่ทำหน้าที่ตรวจสอบรหัสผ่าน)

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

    อีกวิธีการหนึ่งที่อาจนำมาใช้ป้องกันการใช้งานรหัสผ่านที่ไม่ดีพอหรือไม่มีการกำหนดรหัสผ่านคือ การนำวิธีการพิสูจน์ตัวตนผู้ใช้ด้วยวิธีการอื่น เช่น การใช้ token ที่ทำหน้าที่สร้างรหัสผ่านหรือใช้วิธีทาง biometrics หากระบบใดประสบปัญหาจากการใช้งานรหัสผ่านที่ไม่ปลอดภัยเพียงพอ ควรเปลี่ยนมาใช้งานวิธีการอื่นๆ ในการพิสูจน์ตัวตนผู้ใช้

  2. เก็บรักษารหัสผ่านที่ใช้งานให้ปลอดภัย หากผู้ดูแลระบบคนใดเก็บค่า hash ของรหัสผ่านไว้ในไฟล์ /etc/passwd ควรปรับเปลี่ยนให้ระบบใช้การเก็บในไฟล์ /etc/shadow แทน สำหรับระบบเครือข่ายที่ใช้งาน NIS หรือ LDAP ซึ่งไม่สามารถเก็บรักษาค่า hash ให้ปลอดภัย ซึ่งผู้ใดก็ตาม (ยกเว้นผู้ที่ไม่ได้ผ่านการพิสูจน์ตัวตน) สามารถอ่านค่า hash ของรหัสผ่านที่เก็บและนำมาใช้เพื่อพยายามคาดเดารหัสผ่านได้ ผู้ดูแลระบบจะต้องกำหนดสิทธิการใช้งานให้เหมาะสมและปลอดภัย พร้อมทั้งตรวจสอบรหัสผ่านที่ผู้ใช้แต่ละคนใช้งานด้วยเครื่องมือสุ่มเดารหัสผ่านเป็นระยะๆ ตามความเหมาะสม

    ถึงแม้ว่าผู้ใช้บางคนจะใช้รหัสผ่านที่ดี แต่บัญชีผู้ใช้ของผู้ใช้คนดังกล่าวก็อาจถูกละเมิดการใช้งานได้ หากไม่มีการเก็บซ่อนรหัสผ่านของตน นโยบายการใช้งานรหัสผ่านที่ดีควรรวมคำแนะนำที่ว่า ผู้ใช้ไม่ควรบอกรหัสผ่านของตนเองให้ผู้อื่นทราบ ไม่ควรจดบันทึกรหัสผ่านของตนให้ผู้อื่นพบเห็น และต้องเก็บรักษาไฟล์ใดๆ ที่มีข้อมูลรหัสผ่านของตนซึ่งนำไปใช้ในเพื่อการพิสูจน์ตัวตนโดยอัตโนมัติให้ปลอดภัย (การเก็บรักษารหัสผ่านให้ปลอดภัยจะเป็นไปได้ง่ายขึ้นหากเลือกใช้งานการพิสูจน์ตัวตนโดยอัตโนมัติเท่าที่จำเป็นจริงๆ เท่านั้น) ควรกำหนดอายุการใช้งานรหัสผ่าน เพื่อให้รหัสผ่านใดๆ ที่ไม่เป็นไปตามคำแนะนำที่กำหนดก่อให้เกิดความเสี่ยงในระบบเพียงช่วงเวลาสั้นๆ และไม่อนุญาตให้นำรหัสผ่านเก่ามาใช้งานอีก โดยต้องมีการแจ้งเตือนให้ผู้ใช้ทราบว่ารหัสผ่านของตนกำลังจะหมดอายุและมีโอกาสแก้ไขล่วงหน้าก่อนที่รหัสผ่านจะหมดอายุทุกครั้ง ทั้งนี้ เมื่อพบกับข้อความเตือนว่า "Your password has expired and must be changed" ผู้ใช้มักมีแนวโน้มที่จะเลือกรหัสผ่านที่ไม่ดีมาใช้งาน

  3. ควบคุมการใช้งานบัญชีผู้ใช้อย่างรัดกุม
  4. ปรับปรุงแก้ไขนโยบายการใช้งานรหัสผ่านที่ดีขององค์กรเป็นระยะๆ มีเครื่องมือมากมายที่สามารถนำมาติดตั้งเพิ่มเติมสำหรับการควบคุมระบบปฏิบัติการหรือควบคุมบริการต่างๆ ที่ทำงานผ่านเครือข่าย เพื่อช่วยจัดการนโยบายการใช้งานรหัสผ่านที่ดี เช่น Enterprise Security Manager (ESM) ของบริษัท Symantec ซึ่งเป็นเครื่องมือเฝ้าตรวจการทำงานของเครื่องแบบ host-based ในส่วนของการเปลี่ยนแปลงนโยบาย การสร้างบัญชีผู้ใช้รายใหม่ และความปลอดภัยของรหัสผ่าน โดยจะพยายามสุ่มเดารหัสผ่านตามนโยบายที่ใช้งานบนเครือข่าย การทำงานของ ESM จะอยู่ในรูปแบบของ client-manager คือโปรแกรมตรวจสอบจะถูกติดตั้งลงในเครื่องเซิร์ฟเวอร์หรือเครื่องเวิร์กสเตชัน เพื่อรายงานผลไปยังเครื่องกลางที่ทำหน้าที่เป็น manager เมื่อเข้าไปตรวจสอบผลจะมีข้อมูลที่ได้รับการบันทึกไว้ที่แสดงและรายงานให้ผู้ดูแลระบบทราบถึงสถานะการใช้งานขององค์กรในขณะนั้น นอกจากนี้ ESM จะเฝ้าตรวจประวัติของการตรวจสอบและการเปลี่ยนแปลงใดๆ ที่เกิดขึ้นโดยเปรียบเทียบกับค่าการใช้งานเครือข่ายที่ได้กำหนดไว้

กลับไปด้านบน ^

W8 Internet Explorer

W8.1 คำอธิบาย
Microsoft Internet Explorer (IE) เป็นเว็บบราวเซอร์ที่ติดตั้งอยู่แล้วบน Microsoft Windows ทุกๆ เวอร์ชันของ IE มีช่องโหว่ที่ร้ายแรง ซึ่งผู้ดูแลเว็บที่มีจุดประสงค์ร้ายสามารถออกแบบหน้าเว็บให้อาศัยช่องโหว่เหล่านี้บน IE ของผู้ใช้ขณะเปิดหน้าเว็บเหล่านี้ได้

ช่องโหว่สามารถถูกแบ่งย่อยออกได้เป็นหลายชนิด ได้แก่ การปลอมแปลงหน้าเว็บ (web page spoofing) ช่องโหว่ของ ActiveX control ช่องโหว่ของ Active scripting ช่องโหว่ของการแปลที่ผิดพลาดสำหรับ MIME-type และ content-type และ บัฟเฟอร์ล้น (buffer overflows) ผลที่ตามมาอาจทำให้เกิดการเปิดเผย cookies ไฟล์หรือข้อมูลภายในเครื่อง การสั่งให้โปรแกรมทำงานภายในเครื่อง การดาวน์โหลด และสั่งโค้ดอันตรายให้ทำงานหรือการเข้าควบคุมระบบที่มีช่องโหว่ทั้งระบบ

W8.2 ระบบปฏิบัติการที่ได้รับผลกระทบ
ช่องโหว่เหล่านี้พบได้ในระบบ Microsoft Windows ที่ใช้โปรแกรม Microsoft Internet Explorer เวอร์ชันใดๆ ก็ตาม สิ่งสำคัญที่ต้องคำนึงถึงคือ IE ถูกติดตั้งมากับซอฟต์แวร์ Microsoft หลากหลายชนิด ดังนั้นจึงปรากฏอยู่ในทุกระบบของ Windows แม้กระทั่งบนเซิร์ฟเวอร์ซึ่งไม่จำเป็นต้องใช้บราวเซอร์เลย

W8.3 หมายเลข CVE ที่เกี่ยวข้อง
CAN-2002-0193, CAN-2002-0190, CVE-2002-0027, CVE-2002-0022, CVE-2001-0875, CVE-2001-0727, CVE-2001-0339, CVE-2001-0154, CVE-2001-0002

W8.4 วิธีการตรวจสอบว่า ได้รับผลกระทบจากช่องโหว่นี้หรือไม่
ถ้าท่านใช้ Internet Explorer ในระบบและไม่ได้ทำการติดตั้งโปรแกรมแก้รวม (cumulative security patch) ไว้ ก็จะมีโอกาสพบช่องโหว่นี้ในระบบ ถ้ามีโปรแกรม Windows Updates เปิดใช้ในท่านสามารถทำการตรวจสอบว่า IE ได้ถูกติดตั้งไว้หรือไม่ และ patch อันใดสำหรับ IE ที่ได้รับการติดตั้งในระบบของท่านไว้แล้วบ้างโดยเปิดเว็บไซต์ http://windowsupdate.microsoft.com/ ถ้าไม่มี Windows Updates ในระบบ ให้ใช้ HFNetChk (Network Security Hotfix Checker) หรือ Microsoft Baseline Security Analyzer (MBSA) ก็ได้เช่นกัน

ท่านสามารถไปที่ http://browsercheck.qualys.com/ เพื่อประเมินผลกระทบของช่องโหว่เหล่านี้ที่มีต่อระบบของท่านได้

W8.5 วิธีการป้องกันอันตรายจากช่องโหว่นี้
Patches สำหรับช่องโหว่เหล่านี้มีสำหรับ IE เวอร์ชัน 5.01, 5.5, 6.0 ส่วน IE เวอร์ชันก่อนหน้านี้ก็มีช่องโหว่เช่นเดียวกัน แต่อย่างไรก็ตามอาจไม่มี patches สำหรับเวอร์ชันก่อนหน้านี้ ถ้าท่านใช้ IE เวอร์ชันก่อนหน้านี้ก็ควรจะอัพเกรดเปลี่ยนเป็นเวอร์ชันล่าสุดและติดตั้ง patch ด้วย

ถ้าท่านใช้ IE 5.01 หรือใหม่กว่า ให้เริ่มต้นโดยการอัพเกรดเป็น service pack ล่าสุดโดยท่านสามารถดาวน์โหลด IE เวอร์ชันล่าสุดได้จาก

หลังจากอัพเกรด IE 5.5 หรือ IE5.01 เป็น service pack 2 แล้ว ท่านควรเพิ่ม cumulative security patch (Q323759) ด้วยซึ่งจะช่วยแก้ไขช่องโหว่อื่นๆ เพิ่มเติม (patch นี้ได้ถูกรวมไว้ใน IE 6 service pact 1 แล้ว) สำหรับข้อมูลเพิ่มเติมเกี่ยวกับช่องโหว่ที่ patch นี้แก้ไขและการเปลี่ยนแปลงที่เหมาะสมสำหรับการตั้งค่าต่างๆ ที่อาจก่อให้เกิดความเสี่ยง โปรดอ่าน Security Bulletin และ Knowledge Base article ที่เกี่ยวข้องเพิ่มเติม

โดยในบทความดังกล่าวจะกล่าวถึงการเปลี่ยนแปลงของช่องโหว่การสั่งใช้สคริปจากคนละเครือข่าย (cross-site scripting) ซึ่งบางอย่างอาจยังไม่ได้รับการแก้ไขอย่างสมบูรณ์ด้วย patch โปรดศึกษาเพิ่มเติมที่ http://sec.greymagic.com/adv/gm010-ie/ หากเป็นไปได้ ควรจะยกเลิก การใช้สคริปทุกที่ที่ไม่จำเป็นต้องใช้

เพื่อปกป้องระบบ ท่านควรจะติดตามการอัพเดตของ IE อย่างสม่ำเสมอด้วย Windows Update, HFNetChk, หรือ Microsoft Baseline Security Analyzer (MBSA) ท่านสามารถรับข้อมูลอัพเดตของ IE ได้จาก Internet Explorer Home ของ Microsoft

กลับไปด้านบน ^

W9 Remote Registry Access

W9.1 คำอธิบาย
Microsoft Windows 9x, Windows CE, Windows NT, Windows 2000, Windows ME และ Windows XP ใช้ฐานข้อมูลแบบ central hierarchical database หรือเรียกอีกชื่อหนึ่งว่า เรจิสทรีย์ (Registry) เพื่อควบคุมซอฟต์แวร์ การตั้งค่าอุปกรณ์ และการตั้งค่าผู้ใช้ในระบบ

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

W9.2 ระบบปฏิบัติการที่ได้รับผลกระทบ
Microsoft Windows 9x, Windows CE, Windows NT, Windows 2000, Windows ME และ Windows XP ทุกเวอร์ชัน

W9.3 หมายเลข CVE ที่เกี่ยวข้อง
CAN-1999-0562, CVE-2000-0377, CVE-2000-0663, CVE-2002-0049, CAN-2001-0045, CAN-2002-0642

W9.4 วิธีการตรวจสอบว่า ได้รับผลกระทบจากช่องโหว่นี้หรือไม่
NT Resource Kit (NTRK) ที่ได้มาจาก Microsoft นั้นมีโปรแกรมที่ชื่อว่า "regdump.exe" ซึ่งจะทดสอบสิทธิ์การเข้าถึงเรจิสทรีย์จากนอกเครื่อง โดยจะทำการทดสอบจากเครื่อง Windows NT ไปยังเครื่อง Windows NT/Windows 2000 หรือเครื่อง Windows XP บนอินเทอร์เน็ตหรือเครือข่ายภายใน

นอกจากนั้น ท่านสามารถดาวน์โหลดรายการสคริปต์คำสั่ง (collection of command line shell scripts) ที่จะใช้ทดสอบสิทธิ์การเข้าถึงเรจิสทรีย์และช่วงของความปลอดภัยที่เกี่ยวข้องได้จาก http://www.afentis.com/top20

W9.5 วิธีการป้องกันอันตรายจากช่องโหว่นี้
ในการป้องกันช่องโหว่นี้ จะต้องทำการจำกัดการเข้าถึงเรจิสทรีย์ของระบบและพิจารณาการกำหนดสิทธิ์สำหรับเรจิสทรีย์คีย์ที่สำคัญอย่างรอบคอบ สำหรับผู้ใช้ Microsoft Windows NT 4.0 ควรตรวจสอบให้แน่ใจว่าได้ทำการติดตั้ง Service Pack 3 (SP3) ก่อนการปรับค่าเรจิสทรีย์

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

2. บนเมนู "Edit" คลิกที่ "Add Key"


3. ใส่ค่าต่อไปนี้

4. ไปที่ subkey ต่อไปนี้

5. บนเมนู "Edit" คลิกที่ "Add Key"


6. ใส่ค่าต่อไปนี้

7. ไปที่ subkey ต่อไปนี้

8. บนเมนู "Edit" คลิกที่ "Add Value"

9. ใส่ค่าต่อไปนี้

10. ไปที่ subkey ต่อไปนี้

11. เลือก "winreg." คลิก "Security" แล้วคลิก "Permissions" จากนั้นเพิ่มชื่อหรือกลุ่มที่ท่านต้องการอนุญาตให้เข้าถึงเรจิสทรีย์ได้

12. ออกจาก Registry Editor และทำการรีสตาร์ทเครื่อง

13. ถ้าต้องการเปลี่ยนรายชื่อผู้ใช้ที่จะอนุญาตให้เข้าถึงเรจิสทรีย์ ให้ทำตามขั้นตอนที่ 10-12 อีกครั้ง

กลับไปด้านบน ^

W10 Windows Scripting Host

W10.1 คำอธิบาย
ในปี 2000 "The Love Bug" (หรือที่รู้จักในชื่อ "ILOVEYOU") เป็นหนอนที่เกิดจาก Visual Basic script (VBScript) ซึ่งก่อให้เกิดความเสียหายถึงหลายล้านเหรียญสหรัฐ หนอนชนิดนี้และชนิดอื่นที่ออกตามมาได้ฉวยประโยชน์จาก Windows Scripting Host (WSH) ซึ่งอนุญาตให้ไฟล์ที่เป็นตัวหนังสือ (text file) ซึ่งมีนามสกุลเป็น ".vbs" สามารถถูกสั่งให้ทำงานเสมือนเป็น Visual Basic script การใช้ WSH นี้ทำให้หนอนแพร่กระจายโดยการรวมเอา VBScript ไว้เป็นส่วนหนึ่งของไฟล์และเริ่มทำงานเมื่อไฟล์ถูกเปิดหรือถูกพรีวิว (preview)

ถึงแม้ว่าผู้ดูแลระบบจะทำการ patch และอัพเดตแอพพลิเคชันต่างๆ เช่น โปรแกรมท่องเว็บ (browser) โปรแกรมอ่านเมล์ (mail client) และแอพพลิเคชันอื่นๆ ก็ตาม การติดตั้ง patch เหล่านี้เพื่อกำจัดผลกระทบที่เกิดจากหนอนเหล่านี้ถือว่ายังไม่ใช่วิธีแก้ปัญหาความเสี่ยงจากการใช้สคริปที่สมบูรณ์นัก การปิดการทำงานของ Windows Scripting Host นั้น เพื่อเป็นการป้องกันการแพร่ระบาดของหนอนไว้ก่อนซึ่งจะเป็นการดีกว่าการแก้ไขปัญหาทีหลัง

W10.2 ระบบปฏิบัติการที่ได้รับผลกระทบ
ผู้ใช้สามารติดตั้ง Windows Scripting Host ได้ด้วยตนเอง หรือด้วย Internet Explorer 5 (หรือสูงกว่า) บน Windows 95 หรือ NT มันถูกติดตั้งโดยอัตโนมัติบน Windows 98, ME, 2000 และ XP

W10.3 หมายเลข CVE ที่เกี่ยวข้อง
CAN-2001-1325, CVE-2001-0149

W10.4 วิธีการตรวจสอบว่า ได้รับผลกระทบจากช่องโหว่นี้หรือไม่
ถ้าท่านใช้ Windows 95 หรือ NT พร้อมด้วย IE 5 หรือเวอร์ชันสูงกว่า หรือใช้ Windows 98, ME, 2000 หรือ XP และไม่ได้ปิดการทำงานของ WSH แสดงว่าเครื่องของท่านมีช่องโหว่นี้

W10.5 วิธีการป้องกันอันตรายจากช่องโหว่นี้

กลับไปด้านบน ^

ช่องโหว่สำคัญของระบบปฏิบัติการ Unix (U)
U1 Remote Procedure Call (RPC)

U1.1 คำอธิบาย
Remote Procedure Call (RPC) เป็นบริการที่อนุญาตให้โปรแกรมที่ทำงานบนคอมพิวเตอร์เครื่องหนึ่งสามารถเรียกใช้งานโปรแกรมย่อย (โพรซีเยอร์) ที่คอมพิวเตอร์อีกเครื่องได้ โดยใช้การส่งข้อมูลไปยังเครื่องที่ต้องการและรับค่าผลลัพธ์ที่ได้กลับมา RPC ถูกนำไปใช้งานอย่างแพร่หลายร่วมกับบริการชนิดดิสทริบิวต์เน็ตเวิร์ก เช่น การดูแลระบบจากระยะไกล การแชร์ไฟล์ผ่าน NFS (Network File System) หรือ NIS (Network Information System) อย่างไรก็ตาม บริการ RPC มีข้อบกพร่องมากมายที่ผู้บุกรุกสามารถนำไปใช้ในการโจมตีระบบได้ โดยส่วนใหญ่แล้ว บริการ RPC ทำงานภายใต้สิทธิของผู้ดูแลระบบ (root) ผลที่จะตามมาก็คือ ระบบใดก็ตามที่ยังคงเปิดให้ใช้งานบริการ RPC ที่มีช่องโหว่สามารถจะถูกผู้บุกรุกนำไปใช้ในการเข้าถึงจากภายนอกด้วยสิทธิของผู้ดูแลระบบโดยไม่ได้รับอนุญาตได้ มีสถิติที่ชัดเจนแสดงให้เห็นว่า การโจมตีด้วยวิธี distributed denial of service (DDoS) ส่วนใหญ่ที่เกิดขึ้นระหว่างปี 2542 ถึงช่วงต้นปี 2543 เกิดขึ้นจากเครื่องถูกละเมิดการใช้งานผ่านช่องโหว่ของบริการ RPC การโจมตีที่เกิดขึ้นสำเร็จในวงกว้างเกิดขึ้นกับระบบของกองทัพสหรัฐอเมริการะหว่างเหตุการณ์ Solar Sunrise ของ Pentagon ซึ่งเกิดจากข้อบกพร่องของบริการ RPC ที่พบในระบบคอมพิวเตอร์จำนวนมากของกระทรวงกลาโหม

U1.2 ระบบปฏิบัติการที่ได้รับผลกระทบ
ระบบปฏิบัติการ Unix และ Linux เกือบทุกเวอร์ชันที่ได้รับการติดตั้งบริการ RPC และมีการเปิดใช้งาน

U1.3 หมายเลข CVE ที่เกี่ยวข้อง
CVE-1999-0166, CVE-1999-0167, CVE-1999-0168, CVE-1999-0170, CVE-1999-0211,
CVE-1999-0977, CVE-1999-0018, CVE-2000-0666, CVE-1999-0002, CVE-2001-0803,
CVE-1999-0493, CAN-2002-0573, CVE-2001-0717, CVE-1999-0003, CVE-1999-0019,
CVE-1999-0208, CVE-1999-0696, CVE-1999-0693, CVE-1999-0008, CVE-2001-0779,
CAN-2002-0033, CAN-2002-0391, CAN-2002-0677, CAN-2002-0679

U1.4 วิธีการตรวจสอบว่า ได้รับผลกระทบจากช่องโหว่นี้หรือไม่
ใช้เครื่องมือตรวจสอบช่องโหว่หรือคำสั่ง 'rpcinfo' เพื่อตรวจสอบว่าระบบที่ใช้งานมีการเปิดให้บริการบริการ RPC ที่มักจะถูกนำไปใช้ในการบุกรุกระบบหรือไม่ ได้แก่

RPC Service RPC Program Number
rpc.ttdbserverd 100083
rpc.cmsd 100068
rpc.statd 100024
rpc.mountd 100005
sadmind 100232
cachefsd 100235
snmpXdmid 100249

โดยทั่วไปแล้ว บริการ RPC จะถูกโจมตีด้วยการพยายามทำให้เกิด buffer overflow เนื่องจากโปรแกรมที่ทำงานผ่าน RPC ไม่มีขั้นตอนการตรวจสอบความผิดพลาดจากการทำงานและตรวจสอบอินพุตที่เข้ามา ช่องโหว่ของ buffer overflow จะปล่อยให้ผู้บุกรุกส่งข้อมูลใดๆ (โดยส่วนใหญ่จะอยู่ในรูปของโค้ดที่ทำอันตรายต่อระบบ) เข้าสู่พื้นที่ในหน่วยความจำของโปรแกรม เนื่องจากโปรแกรมไม่มีส่วนที่ทำหน้าที่ตรวจสอบความผิดพลาดหรือตรวจสอบอินพุตที่ถูกส่งเข้ามา ข้อมูลดังกล่าวจึงสามารถเขียนทับตำแหน่งสำคัญของหน่วยความจำที่หน่วยประมวลผลจำเป็นต้องเรียกใช้งาน ในกรณีที่การโจมตีเป็นผลสำเร็จ โค้ดที่ถูกส่งเข้ามาจะถูกเรียกใช้งานโดยระบบปฏิบัติการ และเนื่องจากบริการ RPC ทำงานภายใต้สิทธิของผู้ดูแลระบบ ดังนั้น หากการโจมตีผ่านบริการ RPC เกิดขึ้นสำเร็จจะทำให้การเข้าใช้งานระบบจากภายนอกที่ตามมาทำได้ด้วยสิทธิของผู้ดูแลระบบทันทีแม้ว่าไม่ได้รับอนุญาตก็ตาม

U1.5 วิธีการป้องกันอันตรายจากช่องโหว่นี้
ผู้ดูแลระบบควรปฏิบัติตามขั้นตอนต่อไปนี้ เพื่อป้องกันระบบจากการโจมตีผ่านบริการ RPC

  1. ปิดหรือลบทิ้งบริการ RPC ใดๆ ที่แน่ใจว่าไม่มีความจำเป็นต่อการทำงานของเครือข่าย
  2. ติดตั้ง patch ล่าสุดสำหรับบริการใดๆ ที่ไม่สามารถลบออกจากระบบได้

    patch สำหรับซอฟต์แวร์บนระบบปฏิบัติการ Solaris
    http://sunsolve.sun.com

    patch สำหรับซอฟต์แวร์บนระบบปฏิบัติการ IBM AIX
    http://www.ibm.com/support/us
    http://techsupport.services.ibm.com/server/fixes

    patch สำหรับซอฟต์แวร์บนระบบปฏิบัติการ SGI
    http://support.sgi.com

    patch สำหรับซอฟต์แวร์บนระบบปฏิบัติการ Compaq (Digital Unix)
    http://www.compaq.com/support

    patch สำหรับซอฟต์แวร์บนระบบปฏิบัติการ Linux
    http://www.redhat.com/apps/support/errata
    http://www.debian.org/security

  3. ตรวจสอบข้อมูล patch จากผู้ผลิตหรือผู้ขายเป็นประจำ เพื่อนำ patch ใหม่มาติดตั้งได้ในทันที
  4. ปิดกั้นการเข้าถึงพอร์ต RPC (พอร์ต 111) ที่เราเตอร์หรือไฟร์วอลล์ที่ทางเข้าออกเครือข่าย
  5. ปิดกั้นการเข้าถึงพอร์ต RPC "loopback" ได้แก่ พอร์ต 32770 - 32789 (ทั้ง TCP และ UDP)
  6. หากระบบปฏิบัติการใดสนับสนุนการทำงานของฟีเจอร์ non-executable stack ให้นำฟีเจอร์ดังกล่าวมาใช้งาน การใช้งานฟีเจอร์ non-executable stack นี้ไม่ได้เป็นการป้องกันระบบจากการโจมตีแบบ buffer overflow ทุกแบบ แต่สามารถยับยั้งการโจมตีโดยวิธีพื้นฐานที่นิยมใช้งานอย่างแพร่หลายในอินเทอร์เน็ตได้
  7. สำหรับระบบที่ใช้งานระบบไฟล์แบบ NFS (Network File System) ให้ปฏิบัติดังนี้
    1. สร้างบัญชีรายชื่อของเครื่องหรือไอพีแอดเดรสที่สามารถเข้าใช้งานได้
    2. หากเป็นไปได้ ให้กำหนดการติดตั้งให้ใช้งานระบบไฟล์แบบอ่านอย่างเดียวหรือไม่มีการใช้งาน suid
    3. ใช้คำสั่ง 'nfsbug' ในการตรวจหาช่องโหว่ที่มี

สามารถศึกษาข้อมูลเพิ่มเติมได้จากเอกสารสรุปคำแนะนำเกี่ยวกับช่องโหว่ของบริการ RPC ที่สำคัญสามโปรแกรม ได้แก่ Tooltalk, Calendar Manager และ Statd ที่ http://www.cert.org/incident_notes/IN-99-04.html

รายละเอียดของเอกสารที่อธิบายถึงช่องโหว่ของโปรแกรมที่ใช้งานบริการ RPC ตามที่ได้กล่าวถึงด้านบน แสดงไว้ที่นี่

กลับไปด้านบน ^

U2 Apache Web Server

U2.1 คำอธิบาย
บ่อยครั้งที่ผู้ดูแลเว็บเซิร์ฟเวอร์ลงความเห็นว่า โปรแกรม Internet Information Server (ISS) ของบริษัทไมโครซอฟท์มีแนวโน้มหรือความเสี่ยงต่อการถูกละเมิดการใช้งานมากกว่าโปรแกรมทั่วไป (อ่านรายละเอียดจาก W1. Internet Information Server) ในขณะที่ โปรแกรม Apache Web Server ซึ่งเป็นโปรแกรมชนิดโอเพนซอร์สที่สามารถทำหน้าที่เป็นเว็บเซิร์ฟเวอร์ได้เช่นกันมีความปลอดภัยอย่างสมบูรณ์ ความคิดนี้อาจถูกต้อง หากนำระดับความปลอดภัยของโปรแกรม Apache ไปเปรียบเทียบกับโปรแกรม ISS ถึงแม้ว่า การทำงานของโปรแกรม Apache จะได้รับการยอมรับอย่างแพร่หลายในเรื่องของความปลอดภัย แต่เมื่อพิจารณาแล้วยังไม่สามารถพิสูจน์ได้ว่าโปรแกรม Apache เป็นโปรแกรมที่ปราศจากช่องโหว่ใดๆ

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

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

ข้อสำคัญอีกข้อหนึ่งคือ การที่จะสามารถป้องกันไม่ให้ข้อมูลภายในเว็บถูกแก้ไขหรือขโมยได้นั้นจำเป็นต้องเริ่มตั้งแต่การสร้างความปลอดภัยให้กับระบบปฏิบัติการที่ใช้ ในความเป็นจริงแล้ว การสร้างความปลอดภัยให้กับระบบปฏิบัติการของเครื่องที่ทำงานเป็นเซิร์ฟเวอร์เป็นสิ่งจำเป็นไม่ว่าบริการบนเครื่องนั้นเป็นบริการใดก็ตาม แต่บริการของเว็บมักจะเปิดให้ภายนอกเข้าใช้งานซึ่งอาจทำให้เกิดอันตราย ดังนั้นตัวบริการและข้อมูลต่างๆ ในเว็บควรถูกแยกเป็นอิสระออกจากส่วนอื่นๆ ของระบบ ตัวอย่างเหตุการณ์ที่ข้อบกพร่องซึ่งหลงเหลืออยู่ในระบบสามารถทำให้ระบบถูกโจมตีได้แสดงไว้ที่ http://www.wired.com/news/technology/0,1282,43234,00.html

U2.2 ระบบปฏิบัติการที่ได้รับผลกระทบ
ระบบปฏิบัติการ Linux เกือบทุกเวอร์ชัน และระบบปฏิบัติการ Unix หลายเวอร์ชันที่ได้รับการติดตั้งโปรแกรม Apache และมีการเปิดใช้งาน ระบบปฏิบัติการ Unix ทุกเวอร์ชันที่ใช้งานโปรแกรม Apache (ผู้ดูแลระบบปฏิบัติการ Windows ที่ใช้งานโปรแกรม Apache สำหรับระบบปฏิบัติการ Windows ควรให้ความระมัดระวังช่องโหว่ที่อาจให้ผลกระทบอย่างเดียวกันหรือใกล้เคียงกัน)

U2.3 หมายเลข CVE ที่เกี่ยวข้อง
CAN-2002-0392, CAN-2002-0061, CVE-1999-0021, CVE-1999-0172, CVE-1999-0266,
CVE-1999-0067, CVE-1999-0260, CVE-1999-0262, CVE-2000-0010, CVE-1999-0174,
CVE-1999-0066, CVE-1999-0146, CAN-2002-0513, CAN-2002-0682, CAN-2002-0257,
CVE-2000-0208, CVE-2000-0287, CVE-2000-0941, CAN-2000-0832, CVE-1999-0070,
CVE-2002-0082, CAN-2002-0656, CAN-2002-0655, CVE-2001-1141, CAN-2002-0657,
CAN-1999-0509, CVE-1999-0237, CVE-1999-0264

U2.4 วิธีการตรวจสอบว่า ได้รับผลกระทบจากช่องโหว่นี้หรือไม่
ตรวจสอบว่า เวอร์ชันของโปรแกรม Apache ที่ใช้งานและ patch ที่ติดตั้งในเครื่องว่าเป็นเวอร์ชันล่าสุดหรือไม่ ได้จากเว็บไซต์ http://httpd.apache.org หากเวอร์ชันที่ใช้งานมิได้เป็นเวอร์ชันล่าสุด แสดงว่าเครื่องเซิร์ฟเวอร์ที่ใช้งานอาจมีช่องโหว่ใดๆ อยู่ ภายในเว็บไซต์นี้จะแสดงข้อมูลของช่องโหว่ล่าสุด รวมถึงรายละเอียดว่าจะตรวจสอบว่าเครื่องเว็บเซิร์ฟเวอร์ที่ใช้งานได้รับผลกระทบจากช่องโหว่เหล่านั้นหรือไม่

U2.5 วิธีการป้องกันอันตรายจากช่องโหว่นี้
ผู้ดูแลระบบควรปฏิบัติตามขั้นตอนต่อไปนี้ เพื่อช่วยป้องกันเครื่องเว็บเซิร์ฟเวอร์ที่ใช้งานโปรแกรม Apache

  1. ดาวน์โหลด patch ล่าสุดจากเว็บไซต์ของ Apache ที่ http://www.apache.org/dist/httpd/patches/ และติดตั้งลงในเครื่องให้เป็นเวอร์ชันล่าสุดอยู่ตลอดเวลา
  2. แก้ไขค่า token ที่โปรแกรม Apache ใช้ในการตอบกลับไปยังปลายทาง เพื่อให้ข้อมูลส่วนหัว (header) ที่เว็บเซิร์ฟเวอร์จะส่งไปผิดจากความเป็นจริง เป็นการช่วยซ่อนข้อมูลว่าซอฟต์แวร์ที่ใช้ในการให้บริการเว็บคือโปรแกรมใด และเวอร์ชันใด ถึงแม้ว่าวิธีการนี้จะไม่สามารถป้องกันการตรวจสอบข้อมูลดังกล่าวจากผู้บุกรุกได้ แต่สามารถช่วยป้องกันเว็บเซิร์ฟเวอร์จากหนอนอินเทอร์เน็ต ซึ่งปรับเปลี่ยนวิธีการโจมตีตามข้อมูลที่ได้รับจากข้อมูลส่วนหัวที่เว็บเซิร์ฟเวอร์ตอบกลับ ศึกษาข้อมูลเพิ่มเติมว่าวิธีการที่กล่าวถึงในข้อนี้สามารถยับยั้งการถูกบุกรุกจากหนอน Apache/mod_ssl ได้อย่างไร ได้จาก Security Focus discussion และรายละเอียดของหนอนชนิดนี้ถูกแสดงไว้ที่ CERT Advisory CA-2002-27
  3. คอมไพล์โมดูลของโปรแกรม Apache เฉพาะโมดูลที่จำเป็นต่อการทำงานของเว็บเซิร์ฟเวอร์เท่านั้น ในทำนองเดียวกับการที่ระบบปฏิบัติการไม่ควรถูกติดตั้งบริการที่ไม่จำเป็น ตัวโปรแกรม Apache ก็ควรจะมีขนาดเล็กที่สุดเพื่อช่วยลดความเสี่ยงที่จะเป็นช่องทางในการโจมตีจากวิธีการอื่นๆ ในอนาคต
  4. พิจารณาความเหมาะสมที่จะกำหนดให้โปรแกรม Apache ทำงานใน chroot() environment เครื่องเว็บเซิร์ฟเวอร์ควรถูกกำหนดให้เริ่มต้นทำงานภายใต้ฟังก์ชัน chroot ของระบบปฏิบัติการ Unix เพื่อป้องกันความเสียหายของระบบหากการร้องขอ HTTP ที่ต้องการทำอันตรายต่อระบบเกิดขึ้นได้สำเร็จ เมื่อเว็บเซิร์ฟเวอร์ทำงานภายใต้ chroot ส่วนต่างๆ ของเว็บจะต้องถูกจัดเก็บไว้ภายในขอบเขตนี้เท่านั้น (คล้ายเป็น "Silver Bubble") และจะทำให้การทำงานของเว็บเซิร์ฟเวอร์ไม่สามารถเข้าถึงส่วนอื่นใดของไดเรกทอรีในระบบปฏิบัติการภายนอกพื้นที่ที่เป็น chroot() ได้เลย เว็บเซิร์ฟเวอร์แต่ละเครื่องสามารถนำเอาวิธีการ chroot() ไปใช้ได้หลากหลาย สามารถศึกษาวิธีการได้จากคู่มือของซอฟต์แวร์ที่ใช้งาน และหาข้อมูลเพิ่มเติมได้จาก WWW Security FAQ
  5. ไม่ให้โปรแกรม Apache ทำงานภายใต้สิทธิของผู้ดูแลระบบ ให้สร้างบัญชีผู้ใช้ขึ้นมาใหม่ แล้วให้สิทธิการใช้งานเครือข่ายและฐานข้อมูลน้อยที่สุด โดยให้สามารถใช้งานบริการของเว็บได้และให้โปรแกรม Apache ทำงานภายใต้สิทธิของผู้ใช้คนใหม่นี้ นอกจากนั้น ไม่ควรใช้ชื่อ nobody เนื่องจากชื่อดังกล่าวถูกนำไปใช้กับบริการ NFS ในการแมปไปเพื่อให้ใช้สิทธิเป็นผู้ดูแลระบบ
  6. ลบไฟล์ข้อมูลเอกสาร html ที่ถูกสร้างโดยอัตโนมัติออกจากเครื่อง รวมทั้งไฟล์สคริปต์ CGI สองไฟล์คือ test-cgi และ printenv เนื่องจากคนทั่วไปทราบถึงจุดอ่อนของไฟล์เหล่านี้เป็นอย่างดี และบ่อยครั้งที่ไฟล์เหล่านี้ถูกนำไปใช้เพื่อการโจมตี
  7. ข้อควรทำในการจัดการเรื่องสคริปต์ CGI
  8. ส่วนสำคัญที่สุดคือ การตรวจสอบให้มั่นใจว่าระบบปฏิบัติการที่ใช้งานในเครื่องเว็บเซิร์ฟเวอร์และบริการอื่นๆ ที่ทำงานในเครื่องได้รับการดูแลสร้างความปลอดภัย มิฉะนั้นขั้นตอนทั้งหมดที่อธิบายข้างต้นจะไม่มีประโยชน์ใดๆ เลยต่อความปลอดภัยของเว็บเซิร์ฟเวอร์ ดังนั้น ผู้ดูแลระบบจะต้องปฏิบัติตามข้ออื่นๆ ให้ครบทั้ง 20 ข้อ และอาจศึกษาข้อมูลเพิ่มเติมได้จาก SANS Consensus Security Guides และ Center for Internet Security's Benchmarks

สามารถศึกษาข้อมูลเพิ่มเติมเกี่ยวกับความปลอดภัยของโปรแกรม Apache ได้จาก http://www.sans.org/Gold/apache.php และ http://www.infosecuritymag.com/articles/april01/features1_web_server_sec.shtml

กลับไปด้านบน ^

U3 Secure Shell (SSH)

U3.1 คำอธิบาย
Secure Shell (ssh) เป็นบริการที่นิยมใช้งานเพื่อให้เกิดความปลอดภัยในการล็อกอินเข้าสู่ระบบ การเรียกใช้งานคำสั่ง และการรับส่งไฟล์ข้ามเครือข่าย ระบบปฏิบัติการที่มีพื้นฐานมาจากระบบปฏิบัติการ Unix แทบทั้งหมดสามารถใช้งานได้ทั้ง OpenSSH ซึ่งเป็นแพ็กเกจชนิดโอเพนซอร์ส และเวอร์ชันทางการค้าของบริษัท SSH Communication Security ถึงแม้ว่าบริการ ssh จะมีความปลอดภัยมากกว่าการใช้งานโปรแกรม telnet, ftp และ R-commands ซึ่งเป็นโปรแกรมที่ ssh ถูกนำมาใช้ทดแทนอยู่มากก็ตาม การนำโปรแกรม ssh ทั้งสองแบบมาใช้งานยังทำให้เกิดจุดอ่อนขึ้นมากมายในระบบ จุดอ่อนเหล่านี้ ส่วนใหญ่เป็นข้อผิดพลาดเล็กๆ น้อยๆ ที่ไม่ส่งผลกระทบอย่างกว้างขวาง แต่มีบางจุดที่เป็นอันตรายต่อความปลอดภัยอย่างรุนแรงซึ่งควรได้รับการแก้ไขทันที อันตรายร้ายแรงที่สุดที่เกิดจากช่องโหว่ของบริการ ssh ที่เปิดใช้งานคือ การปล่อยให้ผู้บุกรุกเข้าโจมตีเพื่อให้ได้รับสิทธิเป็นผู้ดูแลระบบในการเข้าถึงเครื่องจากภายนอก

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

นอกจากนั้น ผู้ที่ใช้งานแพ็กเกจ OpenSSH ควรระลึกอยู่เสมอว่า ไลบรารีของแพ็กเกจ OpenSSL (เป็นแพ็กเกจที่ต้องติดตั้งร่วมกับ OpenSSH) อาจส่งผลกระทบต่อความปลอดภัยของ OpenSSH เนื่องช่องโหว่ของ OpenSSL เองด้วย ศึกษาข้อมูลเพิ่มเติมได้จาก CERT Advisory CA-2002-23 และผู้ใช้จะต้องให้ความระมัดระวังถึงแพ็กเกจ OpenSSH ในบางเวอร์ชันที่อาจถูกแฝงไว้ด้วยโปรแกรมโทรจันแล้วนำมาเผยแพร่ในอินเทอร์เน็ต ซึ่งเกิดขึ้นระยะหนึ่งในช่วงกลางปี 2545 สามารถตรวจสอบและหาข้อมูลเพิ่มเติมว่าโปรแกรมเวอร์ชันที่ใช้งานมีโทรจันแฝงตัวอยู่หรือไม่ ได้จาก http://www.openssh.org/txt/trojan.adv

U3.2 ระบบปฏิบัติการที่ได้รับผลกระทบ
ระบบปฏิบัติการ Unix และ Linux ใดๆ ที่ใช้งานแพ็กเกจ OpenSSH เวอร์ชัน 3.3 หรือก่อนหน้านั้น หรือแพ็กเกจ SSH ของบริษัท SSH Communication Security เวอร์ชัน 3.0.0 หรือก่อนหน้านั้น

U3.3 หมายเลข CVE ที่เกี่ยวข้อง
ความปลอดภัยในการติดต่อผ่าน Secure Shell ด้วย ssh: CVE-2000-0575, CVE-2000-0992,
CVE-2001-0144, CVE-2001-0361, CAN-2001-0471, CVE-2001-0553, CVE-2001-0259

เกี่ยวกับ OpenSSH: CVE-2000-1169, CVE-2001-0144, CVE-2001-0361, CVE-2001-0872,
CVE-2000-0525, CVE-2001-0060, CVE-2002-0002, CAN-2002-0575, CAN-2002-0639,
CVE-2002-0083, CAN-2002-0640, CAN-2002-0656, CAN-2002-0655, CVE-2001-1141,
CAN-2002-0657

U3.4 วิธีการตรวจสอบว่า ได้รับผลกระทบจากช่องโหว่นี้หรือไม่
ใช้เครื่องมือตรวจสอบช่องโหว่เพื่อค้นหาว่า ระบบที่ใช้งานอยู่นั้นเป็นเวอร์ชันที่มีช่องโหว่หรือไม่ หรือตรวจสอบเวอร์ชันของซอฟต์แวร์ที่ใช้งานด้วยคำสั่ง 'ssh -V'

U3.5 วิธีการป้องกันอันตรายจากช่องโหว่นี้

  1. อัพเกรดซอฟต์แวร์ที่ใช้งานไม่ว่าจะเป็น OpenSSH หรือ SSH ให้เป็นเวอร์ชันใหม่ล่าสุด หรือหากโปรแกรม SSH หรือ OpenSSH ที่ใช้งานอยู่นั้นถูกติดตั้งพร้อมกับการติดตั้งระบบปฏิบัติการ ให้ติดตั้ง patch ล่าสุดที่ได้รับจากผู้ผลิตหรือผู้ขาย ถ้ามีการใช้งาน OpenSSL ให้ตรวจสอบว่าไลบรารีภายในแพ็กเกจของ OpenSSL เวอร์ชันที่ใช้งานเป็นเวอร์ชันที่ใหม่ล่าสุดแล้ว
  2. หลีกเลี่ยงการใช้งานโพรโตคอล SSH1 ให้มากที่สุดเท่าที่จะเป็นไปได้ เนื่องจากมีโพรโตคอล SSH2 ซึ่งได้รับการแก้ไขข้อบกพร่องที่เกิดขึ้นแล้ว
  3. ในการใช้งานบริการ ssh ทั้งสองแบบจะมีออปชันการทำงานที่หลากหลายให้สามารถเลือกจำกัดได้ว่า เครื่องคอมพิวเตอร์เครื่องใดบ้างที่จะสามารถติดต่อเข้ามา หรือผู้ใช้คนใดที่ได้รับอนุญาตให้แสดงตัวกับระบบผ่านทางกลไกใดได้ ผู้ดูแลระบบควรจะตัดสินใจว