https โดนแฮกได้ยังไง จะระวังตัวยังไง

https โดนแฮกได้ยังไง จะระวังตัวยังไง

สอนแฮกเว็บแบบแมวๆ·7 มิถุนายน 2016

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

คำตอบสั้น ๆ ง่าย ๆ คือ มีโอกาสโดนดักข้อมูลครับ

คราวนี้ลองมาดูกันต่อ หลายคนอาจสงสัยว่าแล้ว เอ๊ะ! เว็บที่เป็น https:// แล้วขึ้นเตือนว่า “การเชื่อมต่อของคุณไม่เป็นส่วนตัว” มีหน้า error ขึ้นกุญแจสีแดงแบบนี้ กับเว็บที่เป็น https:// ที่เป็นกุญแจสีเขียวใช้งานได้ปกติ แตกต่างกันยังไง?

อยากรู้จริงปะครับ เรื่องมันยาว... จะเริ่มละนะครับ พร้อมยัง? จะอ่านกันจบไหมเนี่ย~

การโดนดักข้อมูลบน HTTP

เราคงไม่ต้องพูดถึง http:// กันมากแล้วเนอะ กรณี http:// คือไม่มีการเข้ารหัสใด ๆ ถ้าโดนแฮกเกอร์ในวง network เดียวกัน เช่นใช้ WiFi เดียวกัน อาจเป็นแบบ WPA/2 Personal หรือพวก captive portal ที่ล็อคอินผ่านหน้าเว็บก็ได้ สามารถโดนดักข้อมูลด้วยการทำ man-in-the-middle (จากนี้ขอย่อว่า MitM) แบบ passive ได้ง่ายและสบายมาก ๆ วิธีการคือ..

1. monitor mode

เปิด wireshark เลือก network interface ของ WiFi ที่ทำ monitor mode ได้ซึ่ง wireless chipset + driver ต้องรองรับด้วย ใครใช้ Macbook มันเปิดได้อยู่แล้วใครใช้ยี้ห้ออื่นต้องใช้พวก Alfa WiFi adaptor มาต่อ อธิบายภาษาไอที: ปกติ เครื่องที่เราใช้ wifi เช่น iphone หรือ macbook ตัว wireless chipset จะทำงานเป็น managed mode หมายถึงเป็น ผู้ใช้งานที่ จะต่อไปยัง access point เพื่อจะรับ-ส่งข้อมูลกันในหรือนอก network, ส่วนพวก access point/hotspot พวกนี้จะทำงานใน master mode คือรอให้ ผู้ใช้งานมาต่อ รับหน้าที่บริหารจัดการการส่งข้อมูลระหว่างผู้ใช้งาน และจะมี mode อื่น ๆ อีก เช่น repeater mode ไว้เปิดให้อุปกรณ์ access point ที่จะเอามาขยายสัญญาณ เป็นต้น แต่มีอยู่ mode นึงครับชื่อว่า monitor mode ในโหมดนี้สิ่งที่ wireless chipset ในคอมจะทำคือไม่ส่งข้อมูลใด ๆ ออกไป แต่จะทำการ “อ่าน” ข้อมูลทั้งหมดที่ลอยอยู่ในอากาศ โดยไม่สนว่า ข้อมูลที่ลอยอยู่ในอากาศนั้นเป็นของ access point ไหนหรือ client ไหนก็ตาม ถ้าเจอในอากาศดักมาให้หมด! แต่เงื่อนไขคือดักได้ทีละ 1 channel ในขณะนึงเท่านั้น (โปรแกรมบางตัวเช่น airodump-ng ใน aircrack suite มันดักทีละหลาย channel ได้เพราะมันทำการ hopping เร็ว ๆ ข้าม channel รัว ๆ ครับแต่จริง ๆ มันอยู่ได้ทีละ 1 channel เท่านั้น)

2. promiscuous mode

เลือกเปิด promiscuous mode อันนี้เปิดได้อยู่แล้วทำได้ทั้งใน วงแลนหรือ WiFi อธิบายภาษาไอที: ปกติใน network แบบเก่าที่ใช้ hub การส่งข้อมูลระหว่างเครื่อง A ไปยัง เร้าเตอร์ B ข้อมูลใน data packet จะระบุต้นทางเป็น A ปลายทางเป็น B ซึ่งถ้ามีเครื่อง C ใน network เดียวกัน ต่อให้ C ได้รับ packet ที่ A จะส่งให้ B มันก็จะไม่ยอมรับ ทำการ drop packet ทิ้ง แต่การเลือกเปิด promiscuous mode คือให้ไม่สนว่าปลายทาง data packet จะส่งไปเครื่องไหน ให้เลือกดักข้อมูลไว้ก่อนเลย แต่ปกติแล้ว promiscuous mode เปิดไว้เฉย ๆ มันก็ดักข้อมูลยังไม่ได้ทันทีเพราะสมัยนี้เค้าไม่ได้ใช้ hub กันแล้วข้อมูลมันไม่ได้ส่งหาทุกคน ดังนั้นการจะเปิด mode นี้ต้องมีตัวช่วยอื่น ๆ ด้วย เช่นสามารถดักรับข้อมูลในอากาศได้อยู่แล้วด้วย monitor mode แล้วจึงเปิด promiscuous mode ให้ wireshark นำ data packet ของการคุยกันระหว่างเครื่องอื่นที่ดักได้มาแสดงผล.. โหมดนี้แหละที่คนชอบเรียกกันว่า sniffer mode เพราะว่าชื่อจริงมันอ่านย๊ากก (แซวเล่นนะครับ)

3. WPA/2 Personal

ครบเงื่อนไข 2 ข้อแรกนี้ ถ้าอยู่บน open WiFi ที่ต่อได้เลยหรือเป็น login ผ่านหน้าเว็บก็จบเลย ดักข้อมูลได้ทันที *แต่* ถ้าเป็น WPA/2 Personal ก็จะต้องใส่รหัส Pre-Shared Key ลงไปในออฟชั่น preference ของ Wireshark ก่อน (กรณีนี้คือคนดักข้อมูลเข้าไปใช้ WiFi สาธาณะนั้น ๆ ได้ถ้าไม่ได้ก็ต้อง aircrack หากันเองนะครับ) ให้มัน เอาคีย์ไปถอดรหัส data packet ที่ดักมาจาก monitor mode ได้จากนั้นก็จะแอบดักดูข้อมูลทั้งหมดที่อยู่ในอากาศของคนอื่นใน WiFi เดียวกันได้ทันที

ถ้ามี username / password / credit card อะไรถูกส่งผ่าน http:// ก็เห็นกันชัด ๆ เต็มตาไปเลยจ้า

ที่ว่ามาคือการทำ passive MitM บน WiFi ในอากาศครับ แต่ถ้าบน ethernet (LAN) ละ? กรณีนี้ ถ้าเราทำการ mirror traffic จาก switch ออกมา หรือไปคั่นกลางเพื่อดักข้อมูลไม่ได้ สิ่งที่ต้องทำคือ active MitM ครับ วิธียอดนิยมก็เช่นการทำ ARP Spoofing, DNS Spoofing ทั้งหลายนั้นเอง อธิบายภาษาไอที: ปกติเวลาในวง LAN เครื่องสองเครื่อง*จะส่งข้อมูลหากันภายใน network* ย้ำว่าภายในนะครับ จะรู้ว่า ใครมีหมายเลข IP อะไร ผ่าน protocol ที่ชื่อว่า ARP ที่จะคอยส่งคำถาม/คำตอบว่า IP ในวง LAN นี้มี MAC address อะไร เพื่อจะส่งข้อมูลหากันถูกเครื่องนะครับ การทำ ARP Spoofing คือการ หลอกประกาศ หลอกตอบ เครื่องอื่น ๆ ในวง LAN ว่าเราเป็นใครอีกคนที่จริง ๆ แล้วไม่ใช่เรานะครับ ส่วนมากที่จะใช้กันคือ หลอกว่าเครื่องของแฮกเกอร์เป็นเร้าเตอร์ เพราะว่าเมื่อ คอมสักเครื่องในวง LAN เผลอเข้าใจผิดว่าเครื่องแฮกเกอร์เป็นเร้าเตอร์ เวลาจะส่งข้อมูลออกไปภายนอก network เช่นไปเฟซบุ๊กเงี้ย มันจะส่งไปที่เร้าเตอร์ก่อน ทำให้แฮกเกอร์ที่ไม่ใช่เร้าเตอร์จริง ๆ ดันได้รับข้อมูลไปด้วย ผลคือสามารถดักอ่านข้อมูลคนอื่นได้นะครับ โปรแกรมที่ทำได้ก็เช่นบน Linux มี ettercap/arpspoof บน Windows มี Cain & Able โบราณสุด ๆ... ส่วนอีกทริคที่นิยมใช้กันคือ การประกาศหรือหลอกตอบว่า เครื่องเร้าเตอร์มี MAC address มั่ว ๆ ที่ไม่มีอยู่จริงในวง LAN ผลคือ คอมที่หลงเชื่อไปนั้นจะเข้าเน็ตเข้าเว็บอะไรไม่ได้นะครับ นี้เป็นหลักการของโปรแกรม netcut ที่ไว้ตัดเน็ตแกล้งกันนั้นเอง

แต่เทคนิคการทำ spoofing ทั้งหลายนี้ สามารถถูกตรวจเจอได้ง่าย ๆ ว่าใครเป็นคนทำ หาตัวคนร้ายได้ไม่ยาก เพราะเครื่องแฮกเกอร์จะต้องคอยส่ง data packet ปลอม ๆ พวกนี้ ผู้ดูแลระบบหรืออุปกรณ์ network security สมัยใหม่สามารถตรวจเจอได้ กลับกันในแบบ passive MitM อันแรกนี้สิ โอกาสตรวจเจอยากกว่ามากครับ เพราะฉะนั้นแอดมินขอย้ำว่าใช้ WiFi สาธาณะร่วมกับคนอื่น มีความเสี่ยงจะโดนดักข้อมูลได้เยอะนะครับ ถ้ายังส่งข้อมูลที่ไม่ได้เข้ารหัส.. แต่เดี๋ยวก่อน วิธีดักข้อมูลแบบ passive ที่ว่ามาใช้ใน WPA/2 Enterprise ไม่ได้ครับ ที่มันมีให้กรอก username/password ของใครของมันเวลา login เป็นหน้าต่างขึ้นมา (ไม่รวมแบบกรอกผ่านหน้าเว็บนะครับ) ใครใช้อยู่ก็ไปกังวลแบบ active แทนวิธีป้องกันสำหรับผู้ดูแลระบบก็ทำพวก dynamic arp inspection/dhcp snooping/static IP คอย monitor network traffic เช็คสุขภาพ network ตัวเอง คอยวิเคราะห์ log จากอุปกรณ์ network security บ่อย ๆ จะช่วยลดความเสี่ยง-แก้ปัญหาการโดนดักข้อมูลแบบ active MitM ได้ครับ!

หรือโชคร้ายกว่านั้นหน่อยถ้า เราไม่ได้ถูกทำ MitM ทั้งแบบ passive หรือ active ในวง network เดียวกัน แต่อุปกรณ์ network ระหว่างการส่งข้อมูลจากเครื่องเราไปยังเว็บปลายทางดันโดนแฮก หรือโดนเข้าถึงได้จากผู้ไม่หวังดี ก็สามารถดักเห็นข้อมูลของผู้ใช้งานทุกคนที่ไม่ได้เข้ารหัสบน http:// ได้เช่นกันครับ

https://www.eff.org/pages/tor-and-https

จากรูปจะเห็นว่าการที่ เราเข้าเว็บ site.com จริง ๆ แล้วข้อมูลเรามันไม่ได้เด้งดึ๋งจากเครื่องเราผ่านเข้า web server ของ site.com ตรง ๆ แต่มันผ่านมือคนหลายมือ และแต่ละมือ ก็มีโอกาสจะเข้าถึงข้อมูลเราได้ง่าย ๆ ถ้าไม่ได้มีการเข้ารหัสข้อมูลครับ เช่นจาก ISP ผู้ให้บริการอินเทอร์เน็ตบ้านเราอย่าง True, 3BB บลา ๆ พวกนี้ ข้อมูลเราวิ่งผ่าน อุปกรณ์เค้าเต็ม ๆ มันก็ไม่ใช่เรื่องยากเกินความสามารถเลยที่เค้าจะเลือกจะเข้าถึงข้อมูลเราได้ และอาจนำข้อมูลนี้ไปแชร์ต่อใครก็ตามเช่น รัฐบาล หรือ ตำรวจ เคยได้ยินไหม ประโยคที่เวลาคนโดนแฮก หรือมีคดีไซเบอร์แล้วคนชอบบอกว่า “ไปขอ log จาก ISP มาสิ” นี้แหละครับ

ตัวอย่างอีกเหตุการณ์การง่าย ๆ ที่แต่ละ มือคน ที่ข้อมูลเราวิ่งผ่านจะเห็นข้อมูลเรา องค์กรทั่ว ๆ ไปจะมี web proxy server อยู่เวลาพนักงานในบริษัทจะเข้าเว็บจะวิ่งผ่านเครื่องนี้เพื่อจุดประสงค์บางอย่างเช่น จะบล็อคเว็บบางเว็บไม่ให้พนักงานเข้า หรือช่วยในการลดปริมาณข้อมูลการส่งออกด้วยการทำ caching (เป็นการทำสำเนาข้อมูลของเว็บที่เคยเข้าแล้วเก็บไว้แล้วส่งให้คนถัดไปที่จะมาเข้าเว็บเดิมแทนที่จะต้องวิ่งไปคุยกับเว็บนั้นหลาย ๆ รอบเปลืองเน็ตบริษัท) ตัว web proxy server นี้แหละตัวดี ผู้ดูแลระบบสามารถเปิด wireshark/tcpdump ดักข้อมูลที่ไม่ได้เข้ารหัสของทุกคนในบริษัทได้ครับ

การโดนดักข้อมูลที่เป็น HTTPS

คราวนี้จะเกิดอะไรขึ้นถ้า.. เกิดเหตุการณ์แบบเดียวกันแบบที่เล่ามาข้างบนเลยโดน passive/active MitM เละเทะ แต่ปรากฏว่าเว็บที่เราใช้เป็น HTTPS ครับ ตามในกระทู้พันทิปที่ถามถึงครับ ผลคือคนที่ดักข้อมูล ก็ดักได้ต่อไปครับ แต่ว่า ข้อมูลที่ได้มานั้น จะถูกเข้ารหัสด้วย SSL หรือ TLS .. จนถึงจุดนี้ทุกอย่างแลดู สวยงามดี งั้นถ้าเราเข้าเว็บที่เป็น https:// มีการเข้ารหัสแล้ว แสดงว่าต่อให้เราโดนดักข้อมูล ก็สบายใจได้ เพราะคนที่ได้ข้อมูลไปไม่สามารถถอดรหัสได้นี่นา คำตอบคือ... ไม่ใช่เสมอไปครับ

เพราะว่าตั้งแต่เกิดการใช้งาน https:// เพื่อเข้ารหัสข้อมูลป้องกันการถูกดักอ่านข้อมูลนั้น ก็มีการศึกษาค้นคว้าวิจัย วิธีโจมตี https ต่าง ๆ นา ๆ หลายรูปแบบ บางการโจมตี มุ่งไปที่ช่องโหว่ในตัวการเข้ารหัสด้วย SSL/TLS โดยตรง เพื่อหวังจะถอดรหัสอ่านข้อมูลข้างในเช่น BEAST, CRIME, POODLE, FREAK, LOGJAM อะไรพวกนี้นะครับ เป็นชื่อช่องโหว่ หลายคนในวงการไอที อาจเคยคุ้น ๆ หูกันมาบ้าง พวกช่องโหว่เหล่านี้ ใช้โจมตีในสถานการณ์จริง ๆ ค่อนข้างยากมาก เพราะมีเงื่อนไขเยอะ ส่วนใหญ่หลุดออกมาจากโลก academic ตีพิมพ์จาก paper ปริญญาเอก โดยทั่ว ๆ ไปเราจะไม่ได้นำมาใช้แฮกกัน คนจะสนใจโจมตีช่องโหว่พวกนี้ได้ต้องเป็นระดับรัฐครับเช่น NSA ของอเมริกา เพราะต้องมีงบ มี resource เยอะถึงจะทำได้ หรือทำแล้วคุ้มค่าจริง ๆ ส่วนคนธรรมดาที่อยากจะดักข้อมูลที่เป็น https:// เค้าจะใช้แนวทางดังต่อไปนี้ครับ

1. SSLStrip

เทคนิคนี้มีชื่อที่อธิบายกระบวนการของมันเองได้ชัดเจนครับคือการ strip ถอดเจ้า SSL/TLS ออกนั้นเอง วิธีการคือ เราต้องทำ MitM ใน network ให้ได้ก่อนครับ วิธีทำดังที่อธิบายไว้แล้วข้างบน

http://bahansen.info/the-attack/execution/attack-vector-1-sslstrip/

จากนั้น แฮกเกอร์ที่อยู่ตรงกลางในรูปคือตรงคำว่า “SSLStrip” นั้นแหละ จะทำการดักว่า ถ้าเหยื่อ (คอม ด้านซ้าย) พยายามจะต่อเข้าเว็บ เฟซบุ๊ก https ให้แฮกเกอร์ทำการเรียก เฟซบุ๊ก https แทนเครื่องเหยือ แต่ตอนส่งข้อมูลกลับมา ให้ส่งว่าเว็บที่กำลังเข้าอยู่เป็น เฟซบุ๊ก http คือการ “ถอด s ออก” เปลี่ยนจาก https เป็น http อย่างแยบยล ถ้า ผู้ใช้งานไม่ทันได้สังเกตว่าอยู่ดี ๆ เว็บที่เข้าอยู่จาก https เปลี่ยนเป็น http แล้วล็อคอินเข้าใช้งาน หรือส่งข้อมูลตามปกติ ก็ทำให้แฮกเกอร์สามารถดักอ่านข้อมูลได้ครับ

ทางแก้ไขสำหรับผู้ใช้งานทั่วไปคือ ระวังอย่าให้โดน MitM ครับ ถ้าไม่โดน MitM ก็โดน SSLStrip ไม่ได้แน่ ๆ ต่อมาคือ คอยสังเกตว่าเว็บที่เราใช้งานที่มันจะต้องเป็น https มันยังเป็น https อยู่รึเปล่า ถ้าวันดีคืนดี s มันหายไปเป็น http ธรรมดาแปลว่าเราอาจจะโดนของเข้าให้แล้วนะครับ แต่อันนี้ก็ขึ้นอยู่กับเว็บปลายทางด้วย บางเว็บอาจจะรองรับการเข้าแบบ http ปกติด้วยก็ได้ ก็ให้เราลองเลือกใช้เป็น https ดูว่าถูก ถอด s ออกหรือไม่ครับ อธิบายภาษาไอที: ใครอ่านแค่ส่วนแรกของ SSLStrip ก็มึนแล้วข้ามไปข้อ 2 เลยก็ได้นะครับ, ส่วนทางแก้ไขในโลก computer security นักวิจัยด้านความปลอดภัยก็พยายามหากระบวนการเข้ามาแก้ปัญหาตรงนี้ชื่อว่า HTTP Strict Transport Security (ขอเรียกย่อ ๆ ว่า HSTS) ซึ่งกระบวนการนี้จะถูกใช้โดย web browser กับ web server ที่เวลาส่ง HTTP Response header ชื่อ strict-transport-security ตอบกลับมาให้รู้ว่า เมื่อ web browser จะเข้าใช้งานเว็บ domain นี้ ต่อไปอีกวินาที (max-age) จะกำหนดให้...

- จะต้องเข้าเว็บนั้น ๆ เป็น https ให้หมด! ห้ามเข้าเว็บชื่อนี้เป็น http เด็ดขาด! - เสริมอีกว่าถ้ามี error ในใบรับรองความปลอดภัย certificate (คำคีย์เวิร์ดสำคัญของเราวันนี้โผล่มาแล้วในที่สุด!) หรือการเชื่อมต่อใน SSL/TLS ก็จะให้ web browser ห้ามเข้าเว็บนั้นเด็ดขาด! เช่นกัน

HSTS ของเว็บเฟซบุ๊ก

เอาจริง ๆ HSTS เกิดมาเพื่อแก้ไขอีกปัญหานึงชื่อว่า mixed content ด้วยคือในเว็บที่เป็น https คนเขียนเว็บนั้นเผลอใส่รูปใส่ js css ใส่ลิ้งเป็น http ถ้าผู้ใช้งานเข้าเว็บแล้วมันถูกโหลดอัตโนมัติ ต่อให้เว็บเป็น https ข้อมูลพวก cookie ที่ใช้ยืนยันว่าเรากำลังล็อคอินเว็บอยู่อาจหลุดไปอยู่ในมือคนดักข้อมูลได้ (ถ้าไม่ได้ ตั้ง secure flag ตอน set-cookie ไว้)

เกร็ดเล็กน้อย ผู้อ่านที่เฉลียวใจนิดนึง อ่านมาถึงตรงนี้อาจสังเกตได้ว่า HSTS มีช่องโหว่เล็กน้อย คือ web browser จะทราบได้ว่าเว็บนั้น ๆ มีการเปิดใช้งาน HSTS รึเปล่า ขึ้นอยู่กับ HTTP Response จาก web server ที่ตอบกลับมาแล้ว ดังนั้นแปลว่า HTTP Request แรกสุดที่เราส่งไปเว็บนั้นผ่าน web browser หรือ ตอนที่เราส่งหลังจาก clear cache หรือระยะเวลาหมดอายุในครั้งแรกนั้น จะไม่มีการเปิดใช้ HSTS ทำให้ถ้าเราดวงจู๋ โดนดักข้อมูลตรงจุดนี้ละก่อน HSTS ก็ช่วยอะไรไม่ได้ครับ เพราะแฮกเกอร์ก็สามารถ strip HSTS header ตอนตอบกลับมาออกได้นะครับ ดังนั้น web browser หลัก ๆ อย่าง Firefox หรือ Chrome ก็เลย... เอาวะ มาแก้ปัญหานี้กันด้วยการ แทนที่ web browser จะรอให้ web server ตอบกลับมาว่ารองรับการใช้งาน HSTS ทำไมเราไม่ บอก web browser ไปเลยว่า ถ้าจะเข้าเว็บบางเว็บให้ต้องเข้าเป็น https เท่านั้น คือฝังกระบวนการ HSTS สำหรับบางเว็บใหญ่ ๆ ดัง ๆ ที่รู้กันอยู่แล้วว่าพวกนี้ใช้ https หมด ลงไปเลย แล้วเรียกกระบวนการฝัง HSTS นี้ว่า HSTS preload ครับ

แต่แล้ววันดี คืนดีก็มีคนมาคิดวิธี bypass HSTS ได้ในบางกรณี เช่นไม่ได้ใช้ออฟชั่นใน HSTS header ที่ให้รวมทุก sub-domain โดยการแกล้งทำ DNS spoofing จากเว็บจริงเช่น www.facebook.com ไปที่ sub-domain มั่ว ๆ ที่ไม่ได้ทำ HSTS หรืออาจไม่มีอยู่จริงเช่น wwww.facebook.com เพราะตัว HSTS มันระบุต่อ 1 sub-domain ปัจจุบันที่ request ไปเท่านั้น แล้วให้ทำ SSLStrip ต่อจากนี้แทนวิธีป้องฝั่ง user ก็คอยสังเกตว่ากำลังใช้ sub-domain ผิดปกติรึเปล่า อีกวิธีคือใช้ browser extension ชื่อ HTTPS Everywhere ช่วยบังคับให้เข้าเว็บที่รองรับทั้ง http/https แล้วจะเข้าได้แต่เป็น https ฝั่งผู้ดูแลระบบก็ต้องตั้งค่ากันอย่างรัดกุมว่าจะใช้ https + HSTS ในทุก sub-domain ถ้าทำได้นะครับ

2. SSL Interception Proxy

วิธีนี้เป็นวิธีที่ว่ากันว่า โครงการ single gateway ของไทยเค้าจะทำแหละครับ หลักการของเทคนิคนี้คือขั้นแรกต้องโจมตีด้วยการทำ MitM ปกติให้ได้ก่อน (ใครลืมแล้วเลื่อนขึ้นไปอ่านว่าทำยังไงได้บ้างนะครับ) ขึ้นอยู่กับเรามองว่าคนจะดักข้อมูลเป็นใคร ซึ่งถ้าเป็น ISP หรือคนดูแล web proxy server ในองค์กร ไม่ต้องทำอะไร นั่งเฉย ๆ ก็มีข้อมูลผู้ใช้งานวิ่งผ่านตัวเองเป็น passive MitM อยู่แล้วนะครับ เพียงแต่อ่านข้อมูลที่เข้ารหัสด้วย SSL/TLS ยังไม่ออกเท่านั้นเอง จะเข้าใจวิธีการโจมตีนี้ได้ต้องพอเข้าใจว่า https ทำงานยังไงนะครับ

https://alohalb.wordpress.com/2011/09/16/benchmarking_ssl_performance/

จากรูป 7 ขั้นตอนในการ เปิด SSL/TLS session ตอนเริ่มการทำงาน https คร่าว ๆ นะครับ ขอสรุปเฉพาะส่วน certificate ละกัน... - web server ส่งกุญแจเข้ารหัส public key มาให้คนเข้าเว็บ เรียกว่า x.509 certificate (และส่งให้ทุก ๆ คนเหมือนกัน เป็นข้อมูลเปิดเผย) ตัวนี้แหละคือ ใบรับรองของเว็บ ที่เป็น https

- web browser จะนำ ใบรับรองตัวนี้ไปเช็คในเครื่อง ว่าถูกรับรองโดยองค์กรที่ไว้ใจได้ (เรียกว่า trusted CA: Certificate Authority) หรือไม่ ถ้าใช่จะถือว่า เป็นใบรับรองที่เชื่อถือได้

- ถ้าใบรับรองนั้น trusted หมดทั้ง chain จนไปถึง root CA และการตั้งค่าต่าง ๆ ปกติดี web browser จะ ขึ้นเป็นกุญแจตามปกติให้เราครับ

- ปัญหาคือถ้าใบรับรอง certificate นั้นไม่ได้ถูกรับรอง (คือการ sign ด้วย private key) โดย CA ที่น่าเชื่อถือ จะถือว่าไม่น่าเชื่อครับ... คำถามคือ จะรู้ได้ไงว่า CA ไหนน่าเชื่อถือ? อันนี้ ในระบบปฏิบัติการทั้ง Windows/Linux/OSX มันจะมี list ของ CA ที่น่าเชื่อถือใส่ไว้ให้อยู่แล้วใน certificate store นะครับ ตัวอย่างของ Windows 8.1

certificate store ใน Windows 8.1

CA ในนี้เรียกว่า trusted root CA เป็น CA ที่อยู่สูงสุดในลำดับชั้นของความน่าเชื่อถือ (chain of trust) พวก web browser ส่วนมากยกเว้น firefox จะเช็คใบรับรอง certificate จากการเชื่อมต่อไปเว็บที่เป็น https กับ list ตรงนี้ (ส่วน firefox จะมี list ของ trusted root CA เป็นของตัวเอง แต่ CA เกือบทั้งหมดก็จะเหมือน ๆ กันครับ) โดย trusted root CA สามารถรับรอง CA อื่นให้มีสิทธิ์ไปรับรอง cert ให้ใครต่อก็ได้ แล้วยังถือว่าน่าเชื่อถืออยู่ ได้เรียก CA ที่ถูกรับรองโดย root CA ว่า intermediate CA เพื่อว่าเวลามีคนขอ cert เยอะ ๆ แล้วจะได้ช่วย ๆ กันออกได้ด้วย เกร็ดเล็กน้อยเวลาจะสังเกตว่า CA ไหนเป็น root CA คือค่า Issued To กับ Issued By ของใบรับรองจะเป็นองค์กรเดียวกันนะครับ (เหมือน self-signed เป๊ะ แต่ trusted root CA คือจะอยู่ใน certificate store นี้)

ผลของการที่ถ้า x.509 certificate ที่ส่งมาจาก เว็บ ไม่ได้ถูกรับรองโดย trusted CA คือ web browser จะแจ้งเตือนขึ้น error ว่าการเชื่อมต่อไม่ปลอดภัย มีโอกาสโดนดักข้อมูลได้...

ทำไมอย่างงั้นละ.. ในเมื่อการเข้าเว็บ https ด้วย certificate ใด ๆ ที่จะรับรองโดยใครมันก็มีการเข้ารหัสข้อมูลทั้งนั้นนี่หน่า? ไม่ได้มีผลต่อ ความปลอดภัย (security) เลยว่า การเข้ารหัสมันจะอ่อนแอลงตรงไหน??

X.509 certificate error ใน Google Chrome

คำตอบคือ มันมีปัญหาเรื่องความน่าเชื่อถือ (trust) ว่าการเข้ารหัสที่เรากำลังเชื่อมต่ออยู่นี้ เราเข้ารหัสคุยกับ web server ปลายทางนั้นอยู่จริง ๆ รึเปล่า? ไม่ใช่ว่าเป็นการเชื่อมต่อที่เข้ารหัส แต่เราดันเข้ารหัสคุยกับเครื่องของแฮกเกอร์ที่ทำ MitM ดักข้อมูลเราอยู่ซะงั้น...

เพราะว่าการที่มันมี certificate ที่ออกโดยใครก็ได้และไม่ได้ถูกรับรองโดย trusted CA ที่ชื่อว่า self-signed certificate ปัญหาคือการที่ใครก็สามารถออกได้ มันจึงไม่มีความน่าเชื่อถือ เช่น ใคร ๆ ก็ออก x.509 certificate ให้ www.facebook.com ได้ (เพียงแต่ จะไม่ได้ถูก Issued by โดย trusted CA)

https://blog.css-security.com/blog/apples-ssl-flaw-another-man-middle-attack

ผลคือคนที่ดักข้อมูล MitM ได้ สามารถที่จะ จำลองการเชื่อมต่อ https ทั้งสองฝั่ง..

2.1 จากทั้งฝั่งเหยื่อเข้าเว็บ https มาเครื่องที่กำลังดักข้อมูล ตรงนี้คนดักข้อมูลสามารถส่ง self-signed certificate ของ www.facebook.com ไปให้เหยื่อใช้เข้าเว็บที่เป็น https ได้ เชื่อจะเห็นว่าตัวเองกำลังเข้าเว็บเป็น https://www.facebook.com/ ปกติเลย มีการเข้ารหัส *แต่* จะมี error บอกว่าการเชื่อมต่ออาจไม่ปลอดภัยเพราะใบรับรองไม่น่าเชื่อถือนั้นเอง 2.2 / 2.3 จากฝั่งเครื่องที่ดักข้อมูลเชื่อมต่อ https ของจริงปกติไปยังเว็บเป้าหมายจริง ๆ 2.4 เอาผลที่เว็บของจริง https://www.facebook.com/ ตอบกลับมา มาเข้ารหัสด้วย SSL/TLS session + private key ที่สร้างสำหรับ self-signed certificate ที่ส่งให้ใน 2.1 ส่งกลับไปหาเหยื่อ

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

สรุป https แบบ error สีแดง เทียบ https ไม่มีเออเร่อกุญแจสีเขียว

จากเหตุการณ์นี้ทำให้เราเห็นว่าการใช้ ใบรับรองที่ไม่น่าเชื่อถือ self-signed certificate ที่ web browser แจ้งเตือน error กุญแจสีแดง ๆ ว่า “การเชื่อมต่อของคุณไม่เป็นส่วนตัว” นั้นผลคือ ..

ทำให้ ผู้ใช้งานเว็บทั่วไป ไม่สามารถแยกแยะได้ว่า เว็บที่ตนเองกำลังใช้งานอยู่นั้น กำลังใช้ self-signed certificate กุญแจสีแดง ที่ผู้ดูแล web server นั้นเป็นคนออกเองจริง ๆ อย่างถูกต้อง *หรือ* กำลังใช้ self-signed certificate ที่ออกโดยแฮกเกอร์ ที่กำลังทำ MitM ดักข้อมูลที่เป็น HTTPS ทั้งสองทางของเราอยู่กันแน่

เพราะมันก็ขึ้น error แบบเดียวกันเป๊ะ ว่า certificate ไม่ได้ถูกรับรองโดย trusted CA (หรือถ้าใครมีความพยายามมากพอ อาจจะคอยนั่งจำ certificate fingerprint ไว้เวลาเข้าเว็บ self-signed ก็คอยกดดูเองเรื่อย ๆ ว่ายังเป็น fingerprint อันเดิม? ลำบากสุด ๆ ไปเลยครับ) แต่ในทางกลับกันถ้า เว็บนั้นใช้ certificate ที่ออกโดย trusted CA แล้ว แสดงว่าเว็บนั้นมีความน่าเชื่อถือเพราะ trusted CA มีความน่าเชื่อถือมากพอ เป็นบริษัทที่น่าไว้ใจมากพอว่าจะไม่เป็นคนดักข้อมูลเรา เนื่องจากถูกตรวจสอบอย่างแพงและเข้มข้นจากเจ้าของ certificate store ต่าง ๆ เช่น Microsoft, Mozilla, Apple .. (อื่น ๆ อีกขึ้นกับว่าจะอยากเป็น trusted root CA กับเจ้าไหนบ้าง) ไม่ได้จะเป็นกันง่าย ๆ

trusted CA จะเป็นผู้ตรวจสอบข้อมูลจากผู้ขอรับรอง certificate นั้นว่าเป็นเจ้าของชื่อเว็บ domain นั้นจริง ๆ ก่อนที่จะทำการรับรองให้ครับ (ตอนนี้มีวิธีอัตโนมัติกันบ้างแล้ว แต่ยิ่งของ่ายความน่าเชื่อถือก็ยิ่งน้อย)

ในอดีตเคยมีการจับได้ว่ามี trusted root CA เจ้านึงชื่อ DigiNotar โดนแฮก และออกใบรับรองปลอม ให้ gmail นำมาดักข้อมูลผู้ใช้งานในอิหร่านได้ เป็นแสน ๆ คน .. ผลที่ตามมาคือบริษัทล้มละลายเจ๊งทันทีครับ โดนค่าปรับ โดนฟ้องอ่วม .. ทุก certificate store เพิกถอน ออกอัพเดทเอา DigiNotar ออกจากรายชื่อ trusted root CA ของตัวเองอย่างรวดเร็ว

X.509 Certificate ของเว็บเฟซบุ๊ก

จากรูปเป็น X.509 certificate ของ *.facebook.com ที่ถูกรับรองโดย DigiCert SHA2 CA ที่เป็น intermediate CA และตัว DigiCert SHA2 ก็ถูกรับรองโดย DigiCert ที่เป็น Root CA อีกที จะเห็นว่า chain of trust ลำดับชั้นของความน่าเชื่อถือถูกการันตรีมาเป็นทอด ๆ จาก Root CA สู่ Intermediate CA สู่ public key certificate ของเว็บที่จะเอามาให้เราใช้ ทำให้เรามั่นใจว่า ใบรับรองอันนี้ส่งมาจาก server ที่น่าเชื่อถือได้ว่าเป็นเฟซบุ๊กจริง ๆ เพราะ server คนอื่นเช่นของคนดักข้อมูลจะไม่มี private key ที่ไว้ถอดรหัส key ที่ใช้เข้ารหัสข้อมูลใน https นะครับ

ปัญหาอีกอย่างก็คือการรับรอง certificate ของเว็บมันมี ค่าใช้จ่าย ครับยิ่งมีหลาย sub-domain หรือจะทำ wildcard certificate แบบเฟซบุ๊กก็มีค่าใช้จ่ายเพิ่มขึ้นอีก ที่จะต้องจ่ายตังให้ CA ที่จะมายืนยันความเป็นเจ้าของ ก่อนออกใบรับรองของเซิร์ฟเวอร์เรา.. ทำให้เว็บมหาวิทยาลัย หรือองค์กรบางแห่ง ไม่ได้ใช้ trusted certificate ในการให้บริการเว็บด้วย https ดังที่น้องเค้ามาถามไว้... โดยเฉพาะอย่างยิ่งระบบใน internal network ที่ไม่ได้เข้าผ่าน internet มักจะใช้ self-signed certificate กัน ก็น่าเห็นใจที่บางองค์กรหรือมหาวิทยาลัยมี domain/server มากมายจะให้ซื้อใบรับรองจริงใช้ก็เสียงบ เป็นกิจวัตรทุกปีแน่ ๆ คนทำงานราชการก็คงรู้อยู่ว่าเบิกงบอะไรสักอย่างไม่ใช่เรื่องง่าย ๆ

ข่าวดีคือตอนนี้ในปัจจุบันมีการให้บริการจาก trusted CA ที่สนับสนุนโดย Mozilla/Cisco/Akamai เพื่อจะรับรอง certificate ให้ domain ที่ใครสักคนเป็นเจ้าของได้ฟรี ๆ ในโครงการชื่อ let’s encrypt นะครับ ใครสนใจก็ลองไปกูเกิลหาวิธีทำดูง่ายมาก ๆ สำหรับ apache/nginx แทบลงจะอัตโนมัติให้ทุกอย่างไม่ต้องรู้ ไม่ต้องตั้งค่าอะไรเลย ก็มี https สีเขียว ๆ ให้ใช้ได้ละครับ พร้อมทั้งยังใช้การตั้งค่าต่าง ๆ ของ SSL/TLS ไว้เป็น best practice เป็นค่าเริ่มต้นที่เมื่อสแกนตรวจสอบความปลอดภัย https จากเว็บ Qualys SSL Labs แล้วได้คะแนน A ทันทีเลยด้วยครับ

CREDIT: https://www.facebook.com/longhackz/