Clear
Lead Graphic Papers

Risk on LINE

ผู้เขียน: ไพชยนต์ วิมุกตะนันทน์
วันที่เผยแพร่: 27 ธันวาคม 2556
ปรับปรุงล่าสุด: 27 ธันวาคม 2556

Share on Facebook Share on Twitter Share on Google+

ในนาทีนี้ สำหรับชาวไทย คงไม่มีใครไม่รู้จักแอพยอดฮิตที่ชื่อ LINE อย่างน้อยถึงไม่ใช่ผู้ที่ใช้งานสมาร์ทโฟน ก็ต้องเคยได้ยินเรื่องเกี่ยวกับแอพตัวนี้กันมาบ้างแล้ว โดยเฉพาะผู้ที่ติดตามข่าวสารทางสื่อมวลชนต่างๆ อาจจะเคยได้ยินว่า เจ้าหน้าที่บ้านเมือง มีความสนใจในการ “ขอความร่วมมือ” จากบริษัท NAVER ซึ่งเป็นเจ้าของโปรแกรมนี้ ในการให้ข้อมูลเกี่ยวกับผู้ใช้งาน LINE ในบางกรณี ซึ่งผลของมันก็คงเป็นที่ทราบกันตามที่ปรากฏในสื่อต่างๆ ไปแล้ว จึงขอไม่กล่าวซ้ำในที่นี้อีก

อันว่าโปรแกรมประเภท Instant Messaging ทั้งหลายนี้ เช่น LINE, WeChat หรือ WhatsApp ถึงแม้จะมีความสามารถปลีกย่อยเพิ่มเติมอย่างไร โดนรูปแบบของการสื่อสารแล้ว ก็มีลักษณะการทำงานเหมือนๆ กัน นั่นคือ เป็นการรับส่งข้อความระหว่างแอพพลิเคชันบนสมาร์ทโฟนกับเครื่องบริการ (Server) ที่อยู่ที่ใดที่หนึ่ง ในรูปแบบ Client-Server ความจริงเคยมีผู้คิดทำ Instant Messaging (ต่อไปนี้ขอเรียกว่า IM) แบบ Peer-to-Peer หมายถึง แอพพลิเคชันสามารถรับส่งข้อความระหว่างกันได้โดยตรงโดยไม่ผ่านคนกลางใดๆ อยู่เหมือนกัน แต่ยังมีปัญหาบางอย่างเช่นหากผู้รับไม่ได้ออนไลน์อยู่ในเวลานั้น ข้อความที่ส่งไปจะไปพักอยู่ที่ใด หรือข้อความจะหายไปเลย กลายเป็นข้อความที่ส่งไม่ถึง? หรือจะแจ้งให้ผู้ส่งทราบว่าข้อความไม่สามารถส่งไปถึงผู้รับได้? ซึ่งก็ล้วนแต่เป็นเรื่องนี่น่าคิดทั้งนั้น

ในมุมมองของผู้ที่มีความสนใจเรื่อง Security นั้น โปรแกรมประเภท IM ก่อให้เกิดคำถามหลายอย่างซึ่งเกี่ยวกับความมั่นคงปลอดภัย หรือบางครั้งก็เกี่ยวกับความปลอดภัยในชีวิตและทรัพย์สินของผู้ใช้งานเลยทีเดียว คำถามที่ว่านี้อย่างเช่น ข้อความที่เราส่งไปนั้นจะมีใครเห็นได้บ้าง ข้อความจะถูกเปลี่ยนแปลงระหว่างทางได้หรือไม่ ข้อความที่ส่งไปแล้วจะถูกเก็บไว้ที่ใด เก็บไว้นานเท่าใด คำถามเหล่านี้ไม่ได้เกิดแค่กับ IM ยุคใหม่บนโทรศัพท์มือถือเท่านั้น แต่เกิดได้กับทุกโปรแกรมที่มีลักษณะเดียวกัน แม้แต่ในโปรแกรมยุคก่อนสมาร์ทโฟนเช่น ICQ หรือ MSN Messenger ที่เคยเป็นเจ้าตลาดอยู่ในโลกของ PC

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

แต่การเข้าถึงข้อความที่รับส่งกันผ่าน IM นั้น ไม่ใช่แค่การเข้าถึงเครื่องบริการเท่านั้น ยังมีวิธีอื่นๆ อีกที่สามารถทำได้ เช่นการดักรับข้อมูลกลางทาง โดยใช้เทคนิคทางระบบเครือข่ายทั้งหลาย แต่ในยุคนี้ โปรแกรมที่มีการรับส่งข้อมูลทางระบบเครือข่ายสาธารณะ ก็มีการใช้งาน SSL/TLS [1] ซึ่งเป็นการเข้ารหัสลับข้อความกันเป็นปกติอยู่แล้ว ในกรณีนี้ มุมมองด้านเทคนิคก็ต้องถือว่ามีความมั่นคงปลอดภัยตามสมควร ตราบใดที่กระบวนการตรวจสอบใบรับรอง (Digital Certificate) ของการเข้ารหัสลับไม่มีความบกพร่อง และโปรแกรมมีการใช้การเข้ารหัสลับตลอดเวลา

อย่างไรก็ตาม เมื่อมาลองพิจารณาดูในความเป็นจริง การใช้ SSL/TLS ในโปรแกรมต่างๆ โดยเฉพาะ “แอพ” ในโทรศัพท์มือถือก็ยังเป็นสิ่งที่น่าสนใจอยู่ไม่น้อย เพราะธรรมชาติของแอพนั้น ต้องการให้ผู้ใช้งานใช้ได้อย่างสะดวกที่สุด ปล่อยให้การดำเนินการทั้งหมดเป็นหน้าที่ของแอพ ดังนั้นผู้ใช้งานจะแน่ใจได้อย่างไรว่าแอพนั้นสื่อสารผ่านช่องทางที่มีการรักษาความมั่นคงปลอดภัยของข้อความหรือเข้ารหัสลับตลอดเวลา หรือในกรณีที่แอพพบความผิดปกติในกลไกของ SSL/TLS เช่น พบกับใบรับรองอิเล็กทรอนิกส์ (Digital Certificate) ของเครื่อบริการที่ผิดปกติ เช่นกรณีที่ถูกโจมตีด้วยวิธี Man-in-the-middle [2] แอพจะปฏิบัติตัวอย่างไร ในกรณีนี้ไม่เหมือนกับเว็บบราวเซอร์ ที่มีวิธีการแสดงผลให้ผู้ใช้ได้ทราบอย่างชัดเจนอยู่แล้ว

เพื่อให้ทราบถึงกลไกการทำงานของแอพเหล่านี้ ไทยเซิร์ตได้ทดลองกับแอพที่นิยมใช้กัน 3 ตัว คือ LINE, WhatsApp และ WeChat ในช่วงเดือนพฤศจิกายนที่ผ่านมา ซึ่งก็พบว่ามีการใช้งาน SSL/TLS กันตามที่คาด แต่สำหรับแอพที่อาจจะเรียกได้ว่า เป็นที่สุดในบ้านเราอย่าง LINE ที่ได้กล่าวถึงไว้ข้างต้นนั้น ก็มีข้อสังเกตที่หลายๆ คนอาจจะเคยได้ยินมาแล้วเกี่ยวกับการเข้ารหัสลับข้อมูล นั่นคือ มีผู้ค้นพบว่า LINE ในรุ่นที่ต่ำกว่า 3.9.2 (ขณะที่ทดสอบเป็นรุ่น 3.8.8) จะไม่ใช้ SSL/TLS ในการสื่อสารผ่าน Mobile Broadband (GPRS, EDGE หรือ 3G, 4G) แต่ในเวลาที่สื่อสารผ่านเครือข่าย WIFI ก็จะมีการใช้การเข้ารหัสลับตามที่ควรจะเป็น ทั้งนี้อาจจะเข้าใจได้ว่า เครือข่าย WIFI ส่วนมากที่ใช้งานกัน โดยเฉพาะ Public Hotspot ต่างๆ สามารถถูกดักรับข้อมูลได้ง่าย จึงจำเป็นต้องมีการป้องกันเอาไว้ด้วยการเข้ารหัสลับ แต่บน Mobile Broadband โดยเฉพาะ 3G และ 4G ยังไม่พบวิธีที่จะดักรับข้อมูล “กลางอากาศ” ได้ (ระบบ 3G ในบ้านเรา มีพื้นฐานจากระบบ UMTS ที่ใช้ KASUMI Encryption ในปัจจุบัน ยังไม่พบการ Crack ที่สามารถใช้งานได้จริง [3]) ยกเว้นการใช้งานในระบบ GPRS ที่อาจใช้วิธีสร้าง Rogue cell tower เพื่อดักข้อมูลในลักษณะคล้าย Rogue AP [4] ของเครือข่าย WIFI ดังที่เคยมีการสาธิตในงาน DEF CON มาแล้ว เมื่อปี 2010 [5] จึงมีความจำเป็นน้อยกว่าในเรื่องการเข้ารหัสลับข้อมูล

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

นอกจากนี้ จากการทดลอง ยังพบอีกว่า LINE ใช้วิธีสื่อสารที่คล้ายกับ HTTP ในการสื่อสารระหว่างแอพกับเครื่องบริการ โดยมีการใช้ Session key ในการทำ Authentication ซึ่งก็เป็นรูปแบบเดียวกับ Web application ทั่วไป ซึ่ง Session key ที่กล่าวนี้จากการทดลองดูเหมือนจะไม่มีการหมดอายุ ซึ่งหากถูกขโมย (เช่น ด้วยวิธีการดักข้อมูล) ผู้ไม่หวังดีก็สามารถเอาไปใช้สวมรอยได้ตามใจชอบ โดยเจ้าของ Key ที่ถูกขโมยไม่มีทางรู้ตัวได้เลย และบริษัท NAVER ก็ไม่มีทางตรวจสอบ หรือป้องกันได้ง่ายๆ เพราะระบบของ LINE ยอมให้ผู้ใช้งานเข้าถึงได้ทั้งผ่าน HTTP และ HTTPS (SSL/TLS) [6] ได้พร้อมๆ กันอยู่แล้ว

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

Pa2013te015-1.jpg
รูปที่ 1 แสดงการใช้ Python ส่งคำสั่งเลียนแบบ LINE โดยใช้ Session key ที่ถูกต้อง พบว่าสามารถรับข้อความได้จริง

บทสรุป

แอพประเภท IM บนโทรศัพท์มือถือ ได้รับความนิยมอย่างรวดเร็วเนื่องจากความสะดวกในการใช้งาน ลูกเล่นในการส่งข้อความ และค่าใช้จ่ายในการส่งข้อความที่มีอัตราที่ต่ำกว่า SMS มาก แต่สิ่งที่ต้องทำความเข้าใจอย่างหนึ่งก็คือ แอพเหล่านี้ไม่ได้มีจุดประสงค์ในด้านการเป็น Secure Communication Platform เช่นเดียวกับ Email ที่จำเป็นต้องใช้ End-to-end Encryption เช่น PGP [7] หรือ S/MIME เข้าช่วยเพื่อให้เกิดความมั่นคงปลอดภัยมากขึ้น การใช้ SSL/TLS ในแอพ ไม่ได้เป็นการรับประกันความมั่นคงปลอดภัย 100% แต่เป็นการลดความเสี่ยงที่จะมีผู้ที่ไม่ใช่ผู้ส่ง ผู้รับ และเจ้าของแอพ จะมาเข้าถึงข้อความได้เท่านั้น นอกจากนี้ ก็ยังขึ้นอยู่กับว่า ตัวแอพเอง จะมีการใช้งาน SSL/TLS อย่างถูกต้องแค่ไหนด้วย เช่น มีโอกาสหรือไม่ที่แอพจะมีการตรวจสอบ Digital Certificate ผิดพลาด ทำให้การโจมตีแบบ Man-in-the-middle สามารถทำได้สำเร็จ จน Session key ตกอยู่ในมือผู้ไม่หวังดี หรือมีการใช้ Encryption spec ที่ต่ำจนเกินไป หรือมีช่องโหว่ จนถูก Crack ออก ซึ่งในฐานะของผู้ใช้งานธรรมดา ย่อมไม่มีโอกาสที่จะรู้รายละเอียดเหล่านี้ได้เลย ดังนั้นการใช้งานแอพประเภทนี้ จึงควรระลึกอยู่เสมอว่า ความมั่นคงปลอดภัยของการสื่อสารนั้นอยู่ในมือของผู้สร้างแอพ 100% โดยผู้ใช้งานไม่สามารถควบคุมได้เลย ยิ่งไปกว่านั้น สำหรับผู้ใช้งานที่นิยมติดตั้งแอพประเภทนอกระบบทั้งหลาย คือติดตั้งโดยไม่ผ่านระบบ Play Store หรือ App Store ผู้เผยแพร่แอพนอกระบบเหล่านั้น อาจคิดไม่ซื่อ ลักลอบฝัง Backdoor หรือลดความสามารถด้านความมั่นคงปลอดภัยของแอพนั้นๆ ลง โดยผู้ใช้งานไม่สามารถรู้ได้เลย และอาจตกเป็นเหยื่อของผู้ไม่หวังดีได้

อ้างอิง

  1. https://www.etda.or.th/etda_website/mains/display/744
  2. https://www.thaicert.or.th/papers/general/2011/pa2011ge001.html
  3. http://en.wikipedia.org/wiki/KASUMI
  4. https://www.etda.or.th/etda_website/content/1489.html
  5. http://www.wired.com/threatlevel/2010/07/intercepting-cell-phone-calls
  6. https://www.etda.or.th/etda_website/tha/mains/display/229
  7. https://www.etda.or.th/etda_website/mains/display/1671
Clear