สรุป WannaCry สิ่งที่ควรรู้ และแนวทางแก้ไขปัญหา

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

Malware ประเภทเรียกค่าไถ่ (ransomware) ชื่อ WannaCry (WannaCrypt, WCry  หรือ Wana Decrypt0r version 2.0) ระบาดหนักชั่วข้ามคืน (ประเทศไทย) ประมาณ 02:00 น. เป็นต้นมา สร้างความเสียหายทั่วโลก โดยเวลา 12:00 น. วันที่ 13/5/2017 (ผ่านมาแล้ว 10 ชั่วโมง) โดนโจมตีไปกว่า 100,000 เครื่องทั่วโลก จุดเริ่มต้นถูกโจมตีที่แถบยุโรปก่อน

ในเวลาต่อมานักวิจัยด้านความมั่นคงปลอดภัย MalwareTech ได้ตรวจสอบ และพบว่า WannaCry จะตรวจสอบไปยัง domain ที่ชื่อว่า iuqerfsodp9ifjaposdfjhgosurijfaewrwergwea.com ก่อนเสมอ ว่ามี domain name ดังกล่าว หรือไม่ ถ้ามีจะหยุดการทำงานลง ทำให้นักวิจัยคนดังกล่าวทำการจด domain นั้นเพื่อทดสอบว่ามันคือ kill switch หรือไม่ ซึ่งก็เป็นไปตามคาด kill swtich ทำงาน การแพร่กระจายได้หยุดลง

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

พอเราทราบที่มาของมันแล้ว มาดูกันต่อไปว่า ตัว ransomware นี้อาศัยช่องโหว่ของ Server Message Block version 1 (SMBv1) บน Windows ที่มีชื่อเรียกว่า ETERNALBLUE  ในการแพร่กระจายตัวเองผ่านเครือข่าย ทั้งบนอินเตอร์เน็ต และเครือข่ายภายในองค์กร ซึ่งมันสั่งทำงานได้ด้วยตัวเองโดยไม่ต้องมีการสั่งจากผู้ใช้งานบนเครื่องที่ถูกติดตั้ง ransomware แบบตัวอื่น ๆ ก่อนหน้านี้ ทำให้มันทำตัวเหมือน worm ด้วยในตัวเดียวกัน (แพร่กระจาย และทำงานได้เอง)

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

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

ด้านล่างคือ วิดีโอตัวอย่าง ว่าถ้ามีเครื่องติด WannaCry อยู่ใน network มันจะ scan หาเครื่องต่อไปแล้ว copy ต่อเองผ่านช่องโหว่ SMBv1 บนระบบ network ภายใน แล้วยึดเครื่องเพื่อเรียกค่าไถ่เครื่องต่อไปได้เลย ฉะนั้น ถ้าเครื่องคอมพิวเตอร์ใดๆ เปิด public internet จะโดนแบบนี้แหละ เพราะบน internet มีเครื่องที่ WannaCry ใช้เป็น botnet ในการยึดเครื่องอยู่แล้วจำนวนมาก (หลายแสนเครื่องแล้ว)

จากช่องโหว่ที่นำมาสู่การแพร่กระจายดังกล่าวนั้น Microsoft ได้ออก patch MS17-010 ไปแล้วเมื่อเดือนมีนาคมที่ผ่านมา เพื่อปิดช่องโหว่ที่เกิดจากเครื่องมือแฮกของ NSA ที่หลุดออกมาเผยแพร่เมื่อหลายเดือนก่อน โดย patch ดังกล่าวครอบคลุม Windows version ดังต่อไปนี้

  • Windows Vista (Service Pack 2)
  • Windows Server 2008 (Service Pack 2) และ Windows Server 2008 R2 (Service Pack 1)
  • Windows 7 (Service Pack 1)
  • Windows 8.1 และ Windows RT 8.1
  • Windows Server 2012 และ Windows Server 2012 R2
  • Windows 10
  • Windows Server 2016

สำหรับใครที่ใช้ Windows Defender นั้น ทางไมโครซอฟท์อัพเดต Windows Defender ป้องกันภัย WannaCry แล้ว ซึ่งรวมไปถึงผู้ผลิตซอฟต์แวร์ความปลอดภัยแทบทุกรายก็อัพเดตซอฟต์แวร์ของตัวเองแล้วเช่นกัน

และหลังจากการแพร่กระจายของ WannaCry แพร่ออกไปเป็นวงกว้าง Microsoft ในวันที่ 13/5/2017 ได้ปล่อย patch หมายเลข KB4012598 เป็นกรณีพิเศษสำหรับ Windows version ที่หมดการสนับสนุนไปแล้ว ตามรายการด้านล่างนี้

  • Windows XP และ Windows XP Embedded
  • Windows Vista
  • Windows Server 2003 และ Windows Server 2003 Datacenter Edition
  • Windows Server 2008
  • Windows 8

เมื่อเรารู้ปัญหา การแพร่กระจาย และเครื่องมือในการแก้ไขปัญหา สุดท้ายก็มาสู่แนวทางในการแก้ไขปัญหา

การป้องกันหลัก ๆ ณ ตอนนี้ มี 2 ส่วนหลัก ๆ คือ

1. อัพเดท patch ล่าสุดผ่าน Windows update สำหรับ Windows ที่ยังได้รับการสนับสนุนจาก Microsoft อยู่ และหากเป็น Windows ที่ทาง Microsoft ออก patch เป็นกรณีพิเศษ ให้ติดตั้งแก้ไขลงไป ซึ่งเป็นการแก้ไขปัญหาช่องโหว่นี้ที่ง่าย และตรงจุดที่สุด

2. สำหรับองค์กรที่มีจำนวนเครื่องเยอะจนไม่สามารถอัพเดทได้ทันทีทุกเครื่อง ให้ปิดการเข้าถึง internet ของเครื่องคอมพิวเตอร์ที่ยังไม่ได้อัพเดท patch MS17-010 เพื่อป้องกันขั้นแรก แล้วปิดการใช้งาน SMBv1 และ-หรือตั้ง Rule Firewall ไม่รับการเชื่อมต่อ port 139 และ 445 จากอินเทอร์เน็ต แล้วทยอยติดตั้ง patch ตัวดังกล่าวต่อไป เพื่อแก้ไขปัญหาให้ตรงจุดต่อไป

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

  1. SMBv1 ทำงานบน Windows XP หรือ Windows Server 2003 การปิดอาจทำให้มีปัญหาในการ shared file และ share printer
  2. ไม่สามารถใช้งานพวก Network Neighborhood สำหรับ Windows รุ่นเก่า ๆ ได้
  3. NAS, network multi-function printers และอุปกรณ์ที่ใช้การแชร์ไฟล์ บางรุ่นที่ใช้ SMBv1 หากปิดไปจะใช้อุปกรณ์พวกนี้ไม่ได้

ฉะนั้นหากอัพเดท patch เรียบร้อย ก็สามารถเปิด SMBv1 กลับมาใช้งานเพื่อทำงานต่อไปได้

แนวทางป้องกันสำหรับอนาคต

  1. ไม่ควรเปิด หรือใช้งานไฟล์ใด ๆ ที่ได้มาทางอีเมล จากบุคคลแปลกหน้า หรือคุ้นเคย โดยไม่มีการตรวจสอบอย่างแน่ชัดว่า ไฟล์ที่ส่งมานั้น เป็นการส่งมาโดยบุคลลนั้นจริง ๆ เพื่อปกป้องกันการแอบอ้าง และหลอกให้เราเปิดไฟล์นั้น ซึ่งนำมาสู่การถูกโจมตีด้วย malware ต่าง ๆ
  2. ใช้ Anti-malware หรือ Internet Security ในการป้องกันตัวเอง และทำการอัพเดทฐานข้อมูลป้องกัน malware อยู่เสมอ
  3. ควรอัพเดท operating system ต่างๆ ไม่ว่าจะ Windows, Linux หรือ Mac เป็นต้น โดยอัพเดทให้เป็นตัวล่าสุดอยู่ตลอดเสมอเท่าที่ทำได้ เพื่อป้องกันช่องโหว่ใหม่ ๆ ที่เราไม่รู้ว่าในอนาคตจะไปหวยออกที่ operating system ตัวไหน
  4. ทำการสำรองข้อมูลอย่างสม่ำเสมอ (backup data)

โดยคำแนะนำในการสำรองข้อมูลที่ช่วยลดความสูญเสียของข้อมูลเรา โดยใช้ HDD External 2 ชุด (ใช้คำว่าชุด เพราะอาจจะต่อ RAID หรือใช้แบบเดี่ยวๆ ก็ได้ แล้วแต่กำลังทรัพย์)

HDD External ชุดแรก เก็บแบบ Daily ผมเรียกชุดนี้ว่าแบบ online คือต่อไว้ตลอด โดยใช้โปรแกรม Auto Backup (ส่วนตัวใช้ Acronis True Image) ทำ Daily Backup ข้อมูลเอกสารสำคัญเก็บไว้ทั้งหมด รวมถึงพวกข้อมูลที่ sync บน Cloud อย่าง Dropbox ด้วย ต่อทิ้งไว้ตอนกลางคืนให้มันทำงานทุกวัน

HDD External ชุดสอง เก็บแบบ Weekly และ Monthly ผมเรียกชุดนี้ว่าแบบ offline คือต่อไว้เฉพาะตอนที่เราจะทำการ backup เท่านั้น โดยจะ copy ข้อมูลส่วนของ Daily มาใส่ไว้ที่นี่ ทุกๆ วันเสาร์หรืออาทิตย์เป็นเซ็ตๆ พอครบเดือน จะเก็บ full backup ล่าสุดของเดือนนั้นไว้ 1 เซ็ต สำหรับเดือนนั้นๆ ไว้ เก็บไว้สัก 3 เดือนก็ลบเดือนเก่าทิ้ง พอ backup เสร็จแล้ว ก็ถอดออกจากเครื่องแล้ววางไว้ในที่ปลอดภัย

HDD External จะทำ full encryption (เข้ารหัส) หรือไม่ก็แล้วแต่ถนัด เพราะเป็นการป้องกัน การถูกเอา HDD ไปเปิดเพื่อดูข้อมูลโดยผู้ไม่หวังดีอีกชั้น

ทำแบบนี้เป็นประจำก็แบ่งเบาความเสียหายจาก ransomware ได้เป็นส่วนใหญ่แล้ว

หากคิดว่าการสำรองข้อมูลด้วย HDD จำนวน 2 ชุดอาจจะไม่เพียงพอ สามารถใช้ Cloud Service ช่วยสำรองข้อมูลต่างๆ ได้ อย่างเช่น Dropbox, Onedrive หรือ Google Drive เป็นต้น ก็ช่วยลดความเสี่ยงของข้อมูลลงไปได้อีกมากเลยทีเดียว

โดยงบประมาณก็แล้วแต่ขนาดข้อมูล ซึ่งผมใช้ HDD External 2.5″ ชุดแรกขนาด 500GB ทำ Daily และชุดสองทำ Weekly และ Monthly ขนาด 1TB ก็เพียงพอสำหรับข้อมูลสำคัญ (ค่าใช้จ่ายโดยรวมไม่น่าถึง 5,000 บาท) หรือถ้าใช้ Cloud Service ก็บอกเพิ่มค่าเช่าต่อปีไปตามขนาดข้อมูลสำคัญไปตามแต่กำลังทรัพย์

สุดท้าย ransomware ส่วนใหญ่ หากถูกเรียกค่าไถ่ และต้องการเอาข้อมูลกลับมา มักจะไม่สามารถนำข้อมูลกลับมาได้ในเร็ววัน ซึ่งแน่นอนว่าต้องขอแสดงความเสียใจด้วย สำหรับ WannaCry ณ. วันที่ 17/5/2017 เพราะยังไม่มีตัวถอดรหัสนำข้อมูลกลับได้ ถ้าโดนเข้ากับตัว ก็คงต้องทำใจจ่ายเงินอย่างเดียว

แต่ข่าวร้าย ในขณะนี้ server ของผู้ปล่อย malware ดังกล่าว ก็ไม่สามารถรองรับการส่ง private key เพื่อถอดรหัสกลับมาให้เราได้อย่างมีเสถียรภาพ การจ่ายเงินไปอาจไม่รับประกันว่าจะได้ private key กลับมาเพื่อถอดรหัส

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

ประวัติการแก้ไข

  • 13/5/2017 03:35 – อัพสถานะแรกบน facebook.com
  • 13/5/2017 12:40 – อัพเดทแนวทางป้องกันอื่นๆ เพิ่มเติม
  • 13/5/2017 15:00 – อัพเดทลำดับการเขียนใหม่เพื่อให้อ่านง่ายขึ้น
  • 13/5/2017 15:30 – อัพเดทเพิ่มเติมส่วน Windows XP, Windows Vista, Windows 8 และ Windows Server 2003
  • 13/5/2017 16:40 – อัพเดทเพิ่มเติมส่วน ไมโครซอฟท์อัพเดต Windows Defender ป้องกันภัย WannaCry
  • 18/5/2017 00:50 – อัพเดทขึ้น blog และรวบรวมข้อมูลอื่น ๆ ประกอบเข้ามาเพื่อความสมบูรณ์ของเนื้อหา

ข้อควรระวังในการให้รหัสผ่าน iCloud/Apple ID ตอนนำเครื่องส่งซ่อม

พอดีว่ามีเคสของพี่ที่รู้จักท่านหนึ่ง นำเครื่อง Macbook pro (2016) ส่งซ่อม แล้ว ศ. บริการในไทยขอรหัสผ่านเข้า account ของ iCloud ไปเพื่อใช้ในการซ่อมเครื่อง ซึ่งต้องบอกว่าอันนี้เป็นเคสที่ค่อนข้างซีเรียสนะ เพราะ account ตัว iCloud นั้นก็คือ Apple ID ด้วยนั้นเอง

คนที่ได้ Apple ID ไปนั้นสามารถเข้าถึงความสามารถ และข้อมูลใน iCloud ได้ทั้งหมด ไฟล์งานต่างๆ ใน iCloud Drive ระบบ tracking location device, สั่ง wipe และปลดการผูกตัวเครื่องกับ account ได้

(มีเคสมากมายที่เวลา iPhone โดนขโมย โจรมักใช้อุบายเพื่อบอกให้เราปลดพวกนี้แหละ)

ในส่วนของบริการทั่วไป ก็สามารถนำไป sign in ตัว iTunes เพื่อซื้อเพลง หนัง และบริการอื่น ๆ ได้ รวมไปถึง Apple online store เพื่อซื้อสินค้าได้ด้วย เพราะอย่าลืมว่า Apple ID ผูกบัตรเครดิตไว้อยู่ด้วยมันซื้อของจาก online store ได้

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

ซึ่งจากเคสตัวอย่างนี้ไม่ใช่แค่ Macbook แต่ยังรวมไปถึง iPhone, iPad และอุปกรณ์อื่นๆ ที่เชื่อมโยงเข้ากับ iCloud ทั้งหมด

สุดท้าย ไม่แน่ใช่แค่สินค้า Apple ที่ใช้ iCloud หรือ Apple ID เท่านั้น สินค้าหลาย ๆ ยี่ห้อ-รุ่นอย่างของ Android ที่ผูกกับ Google Account หรือ Windows ทีใช้ Microsoft Account ก็ไม่แตกต่างกัน ฉะนั้น หาก ศ. จำเป็นต้องใช้ข้อมูลเหล่านี้ เราควรนัดและปลดล็อคให้ภายใน ศ. บริการเองเท่านั้น ลำบากหน่อย แต่ข้อมูลของเราจะไม่ถูกนำไปใช้โดยไม่ผ่านการควบคุมดูแลที่ดี

แนะนำการใช้ HTTP Public Key Pinning (HPKP) เพื่อป้องกัน Certification Authority ออก TLS Certificate ซ้ำซ้อน

กระบวนการรับรอง SSL/TLS Certificate หรือ “ใบรับรองอิเล็กทรอนิกส์” (ต่อไปจะเรียกว่า TLS Certificate) จะผ่านทาง Certificate Authority หรือ “ผู้ออกใบรับรองอิเล็กทรอนิกส์” (CA)

โดยเว็บเบราว์เซอร์หรือระบบปฏิบัติการ (ต่อไปจะเรียกว่า client) จะมีรายการที่เรียกว่า Trusted Root Certification Authorities หรือ “รายการใบรับรองอิเล็กทรอนิกส์ของผู้ออกใบรับรองอิเล็กทรอนิกส์สำหรับผู้อื่น” อยู่ภายใน โดยมากมักอ้างอิงกับตัวระบบปฏิบัติการเป็นหลัก ซึ่งจะบรรจุ Root Certificate หรือ “ใบรับรองอิเล็กทรอนิกส์ลำดับชั้นบนสุด” เพื่อให้ client สามารถเชื่อใบรับรองอิเล็กทรอนิกส์ที่ได้รับรองจาก Certificate Authority เหล่านั้น (Trust any certificates issued by the Certificate Authorities)

การที่ Certificate Authority จะสามารถอยู่ในรายการดังกล่าวได้ จะต้องผ่านการตรวจสอบคุณสมบัติตามมาตรฐานจากหน่วยงาน CA/Browser Forum เพราะผู้ผลิต client ต่างๆ จะใช้ข้อมูลจาก CA/Browser Forum ในการบรรจุ Root Certificate ลงไปในซอฟต์แวร์ของตน (สมาชิกของ CA/Browser Forum)

รูปภาพจาก Root certificate

รายการ Trusted Root Certification Authorities ภายใน operating system ของ Windows

ปัญหาที่ระดับ Trusted Root Certification Authorities

จากการรับรองข้างต้น ดูเหมือนจะไม่มีปัญหาหากเครื่องของผู้รับบริการมีความปลอดภัย ไม่ถูกเพิ่มรายชื่อ Trusted Root Certification Authorities ใหม่แทรกเข้ามาได้ แต่หากพบปัญหา โดยมากมักถูกเพิ่มเข้ามาผ่านการติดตั้งซอฟต์แวร์ตัวอื่นๆ ภายหลัง ซึ่งมักจะเป็นจุดที่เจอได้ง่าย ตัวอย่างเช่น กรณีผู้ใช้โน้ตบุ๊ก Lenovo หลายรายพบว่าถูกติดตั้ง Adware มาจากโรงงาน, ดักฟังเว็บเข้ารหัส

แต่ยังมีอีกปัจจัยเสี่ยงคือ Trusted Root Certification Authorities เจ้าใดเจ้าหนึ่งในรายการที่เครื่องของผู้รับบริการถูกแฮก หรือเลินเล่อออกใบรับรองอิเล็กทรอนิกส์ของเว็บไซต์ซ้ำซ้อน จนทำให้มี TLS Certificate ที่เหมือนกับเว็บที่เราให้บริการ โดยเราที่เป็นผู้ให้บริการไม่ทราบ จึงทำให้การสื่อสารของบริการของเราสามารถถูกถอดรหัส และดักฟังได้โดยที่เรายังคงให้บริการได้เป็นปรกติ เหตุการณ์นี้ได้เกิดขึ้นแล้วกับ Google.com ผ่าน DigiNotar (รายละเอียดดูใน แฮกเกอร์สร้างใบรับรอง SSL สำหรับโดเมนของกูเกิลได้สำเร็จ, ทุกเว็บของกูเกิลเสี่ยงต่อการถูกดักฟัง) หรือ กูเกิลเตือนใบรับรองดิจิทัลปลอมจากอินเดีย มาแล้ว

Rogue-SSL-Certificate-Authority

รูปจาก What is Certificate Transparency? How It helps Detect Fake SSL Certificates

วิธีการต่างๆ ในการป้องกัน

จากเหตุการณ์ข้างต้น มีวิธีหลายวิธีในการป้องกันเหตุการณ์ดังกล่าว อย่าง การทำ DNS-Based Authentication of Named Entities (DANE) บน TLSA record ที่ระดับ DNS ร่วมกับการทำ DNSSEC แต่มีความยุ่งยากที่ต้องติดตั้งและดูแลระบบ DNS ที่มีการปรับปรุงเพื่อให้รองรับ DNSSEC และ DANE เพิ่มมากขึ้น รวมไปถึง client ก็ยังไม่รองรับเป็นการทั่วไปสักเท่าไหร่

2016-06-10_020012

แต่ก็ยังมีวิธีที่ง่ายกว่า และมีการรองรับโดยเบราว์เซอร์เจ้าใหญ่อย่าง Google Chrome และ Mozilla Firefox แล้ว คือHTTP Public Key Pinning (HPKP) เป็นกลไกที่ระบุว่าจะใช้ TLS Certificate ใดบ้าง ในการเชื่อมต่อเพื่อใช้งาน โดยจะรับรองผ่าน Certificate Authority เพียงเจ้าเดียว หรือหลายเจ้าก็ได้

รู้จัก HTTP Public Key Pinning (HPKP)

ขั้นตอนการทำงานของ HPKP คือตรวจสอบจากค่าแฮชของ TLS Certificate นั้น ว่าตรงกับที่ระบุไว้ใน HTTP Header ในครั้งแรกที่ได้เข้าใช้บริการนั้นหรือไม่ (เทคนิคที่ว่าคือ Trust on First Use หรือ TOFU) เพราะหลังจากได้ข้อมูลดังกล่าวแล้ว client จะเชื่อค่าแฮชนั้นบนระยะเวลาที่กำหนดไว้ และจะอัพเดตค่าแฮชใหม่อีกครั้ง หลังจากที่ระยะเวลาดังกล่าวสิ้นสุดลง หากในระหว่างนั้นค่าแฮชของ TLS Certificate มีการเปลี่ยนแปลงไปจากที่รับรู้มาก่อนหน้านี้ จะไม่เชื่อถือ TLS Certificate ดังกล่าว

2016-06-09_230144

วิธีการเปิดใช้งานคือ เพิ่ม header ที่ชื่อ Public-Key-Pins หรือ Public-Key-Pins-Report-Only เมื่อมีการเข้าถึงผ่าน HTTPS โดยมีรูปแบบในตัวข้อมูลดังต่อไปนี้

Public-Key-Pins: pin-sha256="base64=="; max-age=expireTime [; includeSubDomains][; report-uri="reportURI"]

Public-Key-Pins-Report-Only: pin-sha256="base64=="; max-age=expireTime [; includeSubDomains][; report-uri="reportURI"]

อธิบายโค้ดแต่ละส่วน

  • pin-sha256 required
    ชุดตัวอักษรแบบ Base64 ซึ่งแปลงจากชุดตัวอักษรแฮชแบบ SHA-256 โดยข้อมูลดังกล่าวได้จาก Subject Public Key Information (SPKI) fingerprint ของไฟล์ Private Key, ไฟล์ Certificate Signing Request หรือไฟล์ Certificate (ที่ได้จาก Certificate Authority)
    หมายเหตุ ในอนาคตอาจจะใช้ชุดตัวอักษรแฮชแบบอื่นๆ นอกจาก SHA-256 ก็ได้ ขึ้นอยู่กับมาตรฐานในอนาคต
  • max-age required
    ระยะเวลาที่บอก client ว่าจะจำค่าแฮชดังกล่าวไว้นานเท่าใดหน่วยเป็นวินาที
  • includeSubDomains Optional
    เป็นชุดพารามิเตอร์ที่ไว้ระบุว่าค่าแฮชดังกล่าวรวมถึง subdomain ด้วย
  • report-uri Optional
    เป็นชุดพารามิเตอร์ที่บอกว่าหากพบการตรวจสอบแล้วผิดพลาด ให้แจ้งไปยัง URL ที่ระบุไว้ โดยจะเป็นการ POST ชุดข้อมูลเป็น JSON ในรูปแบบต่อไปนี้

    {
         "date-time": date-time,
         "hostname": hostname,
         "port": port,
         "effective-expiration-date": expiration-date,
         "include-subdomains": include-subdomains,
         "noted-hostname": noted-hostname,
         "served-certificate-chain": [
           pem1, ... pemN
         ],
         "validated-certificate-chain": [
           pem1, ... pemN
         ],
         "known-pins": [
           known-pin1, ... known-pinN
         ]
    }

    ข้อมูลเพิ่มเติมอ่านต่อที่ Reporting Pin Validation Failure

จุดแตกต่างของ Public-Key-Pins และ Public-Key-Pins-Report-Only คือ

Public-Key-Pins จะตรวจสอบค่าแฮชของ TLS Certificate หากไม่ตรงตามที่กำหนดไว้จะไม่ยินยอมให้ client เข้าใช้งาน ถ้ามีการกำหนด report-uri ไว้ จะส่งรายงานไปยัง URL นั้น

Public-Key-Pins-Report-Only จะตรวจสอบค่าแฮชของ TLS Certificate หากไม่ตรงตามที่กำหนดไว้จะรายงานไปยัง URL ที่กำหนดไว้ที่ report-uri แต่ยังยินยอมให้ client เข้าใช้งาน

เมื่อทราบองค์ประกอบของตัวชุดข้อมูลบน HTTP header แล้ว ส่วนที่สำคัญคือชุดข้อมูล Base64 ที่จะใช้ใน pin-sha256 ซึ่งจะได้จากไฟล์ Private Key, ไฟล์ Certificate Signing Request หรือไฟล์ Certificate

ชุดคำสั่งที่จะได้ค่าดังกล่าวมานั้นมีดังนี้

1. ดึงค่า Base64 จาก Private Key

openssl rsa -in private.key -outform der -pubout | openssl dgst -sha256 -binary | openssl enc -base64

2. ดึงค่า Base64 จาก Certificate Signing Request

openssl req -in cert-signing-request.csr -pubkey -noout | openssl rsa -pubin -outform der | openssl dgst -sha256 -binary | openssl enc -base64

3. ดึงค่า Base64 จาก Certificate

openssl x509 -in certificate.crt -pubkey -noout | openssl rsa -pubin -outform der | openssl dgst -sha256 -binary | openssl enc -base64

ตัวอย่างเมื่อรันคำสั่งตามข้างต้น จะได้ผลดังภาพด้านล่าง

2016-06-10_003753

ค่าที่ได้จะต้องเหมือนกันทั้ง 3 คำสั่ง แล้วนำเอาข้อมูลที่ได้ไปใส่ลงใน HTTP Header

ปรกติ ก่อนใช้ Public-Key-Pins มักจะทดสอบด้วย Public-Key-Pins-Report-Only ก่อน เพื่อไม่ให้เกิดการ block การใช้งานเกิดขึ้นหากกำหนดค่า pin-sha256 ผิดพลาด เมื่อทดสอบเสร็จแล้วจึงกำหนดค่า Public-Key-Pins อีกครั้ง แต่บางคนอาจจะกำหนด Public-Key-Pins แล้วปรับ max-age ไว้ไม่เยอะก็ได้ (ตรงนี้แล้วแต่สะดวก) แล้วจึงกำหนด max-age ที่มีระยะเวลายาวนาน 1-2 เดือน เป็นอย่างน้อยที่สุด

Public-Key-Pins: max-age=5184000; 
pin-sha256="C8XLmj2eoYs1gqjNksWfsIA89sIAKNraGspBaXU/l+4="; 
report-uri="https://thaicyberpoint.report-uri.io/r/default/hpkp/enforce"

Public-Key-Pins-Report-Only: max-age=5184000; 
pin-sha256="C8XLmj2eoYs1gqjNksWfsIA89sIAKNraGspBaXU/l+4="; 
report-uri="https://thaicyberpoint.report-uri.io/r/default/hpkp/reportOnly"

คำแนะนำเพิ่มเติม

การมีค่า pin-sha256 เพียงค่าเดียวกัน อาจจะมีปัญหาในช่วงที่ Certificate กำลังจะหมดอายุ หรือ Private Key ชุดเก่าหลุดจนเกิดปัญหา ทำให้ต้องมีการใช้ Private Key ชุดใหม่ เราจึงควรสร้าง Private Key สำรองเพื่อใช้สำหรับต่ออายุ Certificate หรือเหตุการณ์ที่ไม่คาดคิดในอนาคตไปสัก 2-3 ชุด แล้วใส่ค่า Base64 ของ Private Key ชุดดังกล่าวที่ยังไม่ได้ถูกใช้งานลงไปพร้อมกันด้วย

Public-Key-Pins: pin-sha256="pzel6nQW2KK7geOhEeaci3qEDf1TJeg7CNCFqU9RvkQ=";
pin-sha256="IlsUjvSKCiDJYyuVTifR07/qaIKCUn0ZK8z9mG1rAZ0=";
pin-sha256="Rlef6668r6l11a8M2Ahf46PqK0Q4q+vnk/aRUCU+PeM="; 
max-age=5184000;
report-uri="https://thaicyberpoint.report-uri.io/r/default/hpkp/enforce"

Public-Key-Pins-Report-Only: pin-sha256="pzel6nQW2KK7geOhEeaci3qEDf1TJeg7CNCFqU9RvkQ=";
pin-sha256="IlsUjvSKCiDJYyuVTifR07/qaIKCUn0ZK8z9mG1rAZ0=";
pin-sha256="Rlef6668r6l11a8M2Ahf46PqK0Q4q+vnk/aRUCU+PeM="; 
max-age=5184000;
report-uri="https://thaicyberpoint.report-uri.io/r/default/hpkp/reportOnly"

การใช้งาน HPHK ในเว็บเซิร์ฟเวอร์

พอได้ข้อมูลครบตามนี้ ก็เอาไปใส่ในเว็บเซิร์ฟเวอร์ โดยบทความจะยกตัวอย่าง 3 ตัว คือ Apache, Nginx และ IIS โดยขออ้างอิงเพียง Public-Key-Pins ส่วน Public-Key-Pins-Report-Only ก็ใส่ไปคล้ายๆ กัน ต่างกันแค่ชื่อเริ่มต้นเท่านั้น

  1. Apache – (ต้องเปิด mod_headers ด้วย) เพิ่มในส่วนของ Web Server config อาจจะใส่ในส่วนของ vhost ก็ได้
    Header always set Public-Key-Pins "pin-sha256=\"pzel6nQW2KK7geOhEeaci3qEDf1TJeg7CNCFqU9RvkQ=\";pin-sha256=\"IlsUjvSKCiDJYyuVTifR07/qaIKCUn0ZK8z9mG1rAZ0=\";pin-sha256=\"Rlef6668r6l11a8M2Ahf46PqK0Q4q+vnk/aRUCU+PeM=\"; max-age=5184000;report-uri=\"https://thaicyberpoint.report-uri.io/r/default/hpkp/enforce\""
  2. Nginx – (ต้องเปิด ngx_http_headers_module ด้วย) เพิ่มในส่วนของ Web Server config อาจจะใส่ในส่วนของ vhost ก็ได้
    add_header Public-Key-Pins 'pin-sha256="pzel6nQW2KK7geOhEeaci3qEDf1TJeg7CNCFqU9RvkQ=";pin-sha256="IlsUjvSKCiDJYyuVTifR07/qaIKCUn0ZK8z9mG1rAZ0=";pin-sha256="Rlef6668r6l11a8M2Ahf46PqK0Q4q+vnk/aRUCU+PeM=";max-age=5184000;report-uri="https://thaicyberpoint.report-uri.io/r/default/hpkp/enforce"';
  3. IIS – แก้ไขที่ Web.config
    <httpProtocol>
     <customHeaders>
     <add name="Public-Key-Pins" value="pin-sha256=&quot;pzel6nQW2KK7geOhEeaci3qEDf1TJeg7CNCFqU9RvkQ=&quot;;pin-sha256=&quot;IlsUjvSKCiDJYyuVTifR07/qaIKCUn0ZK8z9mG1rAZ0=&quot;;pin-sha256=&quot;Rlef6668r6l11a8M2Ahf46PqK0Q4q+vnk/aRUCU+PeM=&quot;;max-age=5184000;report-uri=&quot;https://thaicyberpoint.report-uri.io/r/default/hpkp/enforce&quot;" />
     </customHeaders>
    </httpProtocol>

เมื่อตั้งค่าต่างๆ เรียบร้อยแล้ว ลองทดสอบผ่านทาง SSL Server Test เพื่อดูผลว่าตัวทดสอบสามารถตรวจจับข้อมูลที่เราได้ตั้งค่าได้หรือไม่

2016-06-10_013750

2016-06-10_150936

โดยหากเจอปัญหาค่าแฮชที่ตรวจสอบไม่ตรงตามขั้นตอนข้างต้น จะขึ้นข้อความตามด้านล่างนี้ บน Google Chrome และ Mozilla Firefox (อาจจะเปลี่ยนแปลงไปบ้างในแต่ละรุ่นที่ออกมาในอนาคต)

hpkp_test_chrome

รูปจาก What is Public Key Pinning / HPKP ? 

รูปจาก About Public Key Pinning 

ส่วนในกรณีที่ใช้การเขียนซอฟต์แวร์สำหรับเชื่อมต่อผ่าน API นั้น เราสามารถใช้การตรวจสอบในลักษณะนี้ ในการตรวจสอบความน่าเชื่อถือของการเชื่อมต่อได้ด้วยการเขียนชุดคำสั่งตรวจสอบได้เช่นกัน ตัวอย่างเช่น Designing Evolvable Web APIs with ASP.NET – Chapter 15. Security โดยเราจะใช้ลักษณะ Trust on First Use ตามแบบเว็บเบราว์เซอร์ หรือจะใช้การบันทึกค่าแฮชของ TLS Certificate ไว้ในตัวซอฟต์แวร์ก็ได้ เพราะการพัฒนาซอฟต์แวร์ที่เราควบคุมสภาพแวดล้อมได้ หากบันทึกค่าแฮชไว้ภายในตัวซอฟต์แวร์ก็จะช่วยลดความเสี่ยงในเรื่อง Trust on First Use ได้

อะไรคือความเสี่ยงของ Trust on First Use?

คำตอบคือ หากในครั้งแรกที่เข้าใช้บริการ เครื่องที่เข้าใช้งานได้รับข้อมูลที่เป็นค่าแฮชปลอมบน HTTP Header ไปก่อนแล้ว วิธีการนี้ก็จะไม่สามารถตรวจสอบได้อีกต่อไปว่าจะเชื่อค่าแฮชชุดใดกันแน่ที่เป็นค่าแฮชจริง การใช้เทคนิค Trust on First Use จึงเป็นเพียงแค่ช่วยเพิ่มความสะดวกสำหรับคนใช้งานเบราว์เซอร์ทั่วไป

สุดท้าย ในปัจจุบัน (ณ วันที่ 10/6/2016) มีเบราว์เซอร์อย่าง Google Chrome และ Mozilla Firefox รองรับ และหวังว่าจะมีเบราว์เซอร์ตัวอื่นๆ ในอนาคตที่จะเพิ่มเติมการตรวจสอบนี้เข้ามาในตัวเบราว์เซอร์ น่าจะช่วยให้เราให้บริการกับลูกค้าได้ปลอดภัยมากขึ้น รวมไปถึงซอฟต์แวร์ต่างๆ ที่พัฒนาจะใช้การจดจำค่าแฮชเหล่านี้เป็นค่าเริ่มต้น เพื่อช่วยป้องกัน และควบคุมการใช้ TLS Certificate ที่เราเป็นผู้รับผิดชอบเองจริงๆ ไม่ใช่เกิดจากการสวมรอย หรือออก TLS Certificate ที่ผิดพลาดจาก Certificate Authority ที่เราไม่ได้ใช้บริการอยู่

อ้างอิงจาก

ตรวจสอบ favicon ให้ดี อาจมีการใช้ favicon เพื่อทำให้เข้าใจผิดว่ากำลังใช้ https ที่มีใบรับรองที่ถูกต้อง

อ่านข่าวเรื่องอัพเดท Firefox 47 บน Android แล้วเอา favicon ออกจาก address bar เลยสนใจว่าเรื่องนี้ว่าเอาออกทำไม

อธิบายก่อนว่า favicon หรือ favourite icon เป็นรูปขนาดเล็ก (ไอคอน) ที่มักแสดงอยู่ แถวๆ URL ของเว็บ หรือเดี่ยวนี้คงไว้ใกล้ๆ กับหัวข้อเว็บกัน (title bar) ตามภาพด้านล่าง

favicon-in-desktop-browsersรูปนำมาจาก นำมาจาก https://css-tricks.com/favicon-quiz/

พอมาดูใน Firefox รุ่นบน Android และตำแหน่งที่ไว้ favicon ก็เข้าใจประเด็นว่าทำไมถึงต้องนำออกไป ตามภาพด้านล่าง

Mozilla_Firefox_Favicon_Removal

รูปนำมาจาก https://blog.mozilla.org/blog/2016/06/07/tab-video-improvements/

นั้นแสดงว่ามีรายงานว่าการไว้ favicon ตรงนั้น น่าจะถูกนำไปใช้ประโยชน์ในการหลอกผู้ใช้ว่าเว็บใช้ SSL/HTTPS ที่ปลอดภัยอยู่ (ซ้ำราย บนมือถือมักตรวจสอบ SSL/TLS fingerprint ได้ยาก iOS นี่เช็คไม่ได้เลย) ซึ่งใน browser เก่าๆ หรือบนมือถือที่มีพื้นที่จอจำกัด มักเอามาไว้ใกล้ๆ กัน หรือแสดงผลสลับกันตอนเปลี่ยน tab ทำให้สับสน ซึ่งประเด็นนี้ใน browser อื่นๆ เราก็ควรจะใส่ใจเช่นเดียวกัน เพราะบางครั้งก็สร้างความสับสนได้มากเช่นกัน (ตัวอย่างตามภาพท้ายเนื้อหา)

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

2016-06-09_142953

 

2016-06-09 14.32.55

ข้อมูลส่วนบุคคลเป็นสิ่งที่ควรควบคุมการเผยแพร่

จากกรณีในกระทู้ กลโกงบัตรเครดิตรูปแบบใหม่เพื่อเอาเงินจากบัตรเครดิต เข้าสู่บัญชี E-Wallet ยี่ห้อหนึ่ง ส่วนที่น่าสนใจคือ ข้อมูลบุคคลของลูกค้าหลายๆ อย่าง เป็นข้อมูลที่หาได้ไม่ยากนักตาม social network ต่างๆ บางอย่างเป็นข้อมูลที่ลูกค้าเผยแพร่โดยไม่ตั้งใจ  ตัวอย่างเช่น

  • หมายเลขบัตรประจำตัวประชาชน (อยากโชว์บัตรหน้าบัตรใหม่ หรือหลุดจากการเผยแพร่ของหน่วยงานภาครัฐ และเอกชนต่างๆ)
  • วันเดือนปีเกิด (มาพร้อมๆ กับพวกชอบโชว์บัตรประจำตัวประชาชน หรือข้อมูลที่เผยแพร่ผ่าน social network หลายๆ บริการ)
  • ที่อยู่ตามภูมิลำเนา
  • ที่อยู่ในการจัดส่งเอกสารในบริการนั้นๆ (ใบแจ้งหนี้ที่มักไม่ได้ทำลายจนอ่านไม่ได้ก่อนทิ้ง)
  • หมายเลขบัตรเครดิต (ในกรณีของบริการบัตรเครดิต ในบิลแจ้งหนี้จะมีส่วนของบาร์โค้ดที่ผ่านหมายเลขบัตรเครดิตได้อยู่)
  • วงเงินที่ใช้ในบริการนั้นๆ (ในกรณีของบริการบัตรเครดิต หรือหมายเลขโทรศัพท์มือถือ ที่มักมาพร้อมๆ กับใบแจ้งหนี้เสมอ)
  • หมายเลขโทรศัพท์ที่ใช้ผูกกับบริการนั้นๆ 

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

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

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