วันอาทิตย์, พฤษภาคม 01, 2559

อุ่นใจกับ ความปลอดภัยในการสื่อสารผ่านเน็ต

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

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

ข้อเขียนของ ART SURIYAWONGKUL นี้อาจจะยาวและมีเนื้อหาหนักในทางวิชาการเท็คโนโลยี่สักหน่อย แต่เชื่อว่าไม่เกินกว่าความมุ่งมั่นรักษาสิทธิพลเมืองจะทำให้อ่านแล้วเกิดความกระจ่างได้ไม่ยาก (ขอบคุณ Pipob Udomittipong ที่แนะนำ)

พร้อมกันนี้เราขอแสดงความยินดีกับเพื่อนผู้ใช้แรงงานทั้งหลาย ไม่ว่าจะเป็นแรงงานประเภทใด เพื่อภราดรภาพในโอกาสวัน 'เมย์เดย์' ของปี ๒๕๕๙ นี้


เข้าใจความปลอดภัยในการสื่อสารผ่านเน็ต

ไม่กี่วันก่อนเดินทาง มีคนโทรมาปรึกษา ว่าโทรศัพท์ของเขามันทำงานแปลกๆ มีใครมาทำอะไรกับโทรศัพท์เขาไหม เขาห่วงเรื่องความปลอดภัย คุยไปสักพัก เขาบอกว่าอธิบายเป็นคำพูดแล้วเราไม่เข้าใจ เดี๋ยวจะส่งภาพหน้าจอมาให้ทาง MMS ให้เรากดดูให้หน่อย

แน่นอนว่าไม่กดดูครับ

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

ทำไมถึงไม่กดดู?

จริงๆ ตอนนั้นไม่ได้คิดอะไร แค่รู้สึกว่าไม่ควรจะกดดูอะไรแปลกๆ จากคนที่เราไม่มั่นใจ จนมานึกได้วันนี้ ว่าดีแล้วที่ไม่ได้กดดู

MMS เป็นช่องทางหนึ่งในการโจมตีโทรศัพท์ Android การโจมตีทางนี้เป็นที่รู้จักกันเนื่องจากบั๊กที่ชื่อว่า Stagefright ซึ่งถูกค้นพบเมื่อปีที่แล้ว (2015) แต่จริงๆ มันมีรูนี้มานานมากแล้วโดยไม่มีใครรู้

การโจมตีในบางกรณีต้องให้ผู้ใช้กดดูข้อความ แต่บางครั้งก็ไม่จำเป็น แค่รับ MMS ก็โดนแล้ว 

Zimperium ซึ่งเป็นสมาพันธ์ของผู้ผลิตโทรศัพท์ที่แลกเปลี่ยนเรื่องความปลอดภัย ประมาณการว่า 50% ของโทรศัพท์ที่มีรูรั่วนี้ สามารถถูกโจมตีได้โดยผู้ใช้ไม่ต้องกดดูข้อความ

ดูวิธีการปิดรับ MMS https://www.blognone.com/node/70782

นอกจากช่องทาง MMS แล้ว การโจมตีผ่านรูรั่ว Stagefright ยังทำได้ผ่านการส่งไฟล์ mp4 ที่ถูกแก้ไขให้ไปกระตุ้นรูรั่ว (ดูคลิป 2 อันตามลิงก์) https://thehackernews.com/2015/07/h...

เมื่อถูกโจมตีในกรณีของ Stagefright ผู้โจมตีสามารถส่งคำสั่งต่างๆ มารันบนเครื่องที่ถูกโจมตีได้จากระยะไกล ซึ่งก็รวมไปถึงการดูข้อมูลต่างๆ ได้ด้วย (อันนี้จะขึ้นกับว่า แอปแต่ละแอปเก็บข้อมูลในเครื่องยังไงด้วย แต่รวมๆ ก็คือ มันไม่ปลอดภัยแล้ว)

แล้วยังไง?

ตอนนี้มีคนเป็นห่วงกันเยอะว่า การใช้โซเชียลมีเดียไม่ปลอดภัยแล้วใช่ไหม คุยกันสองคนก็มีคนที่สามรู้ได้ แถมกฎหมายก็กำลังจะแก้ให้โทษหนักขึ้นอีก ฯลฯ

เรามาทำความเข้าใจกับการสื่อสารในระบบเครือข่ายก่อน

คร่าวๆ คือ ข้อมูลในระบบคอมพิวเตอร์ เราแบ่งเป็นสองแบบ

1.    ข้อมูลระหว่างพัก (data at rest)
2.    ข้อมูลระหว่างเดินทาง (data in transit)

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

สมมติว่าเราแชตกันผ่านแอปหรือเมลหรือเว็บอะไรสักอย่าง ผังแบบง่ายที่สุดมันจะเป็นแบบนี้
// รูปที่ 1 //

[ A ]<===>[ P ]<===>[ B ]
ข้อมูลที่อยู่ในกล่อง [ X ] คือข้อมูลระหว่างพัก (data at rest) คือข้อมูลมันอยู่นิ่งๆ ในอุปกรณ์หรือเซิร์ฟเวอร์ รอส่งต่อ ([ A ] และ [ B ] คืออุปกรณ์ปลายทาง ส่วน [ P ] คือผู้ให้บริการหรือตัวกลางในการสื่อสาร)

ส่วนข้อมูลใน === คือข้อมูลระหว่างเดินทาง (data in transit) ข้อมูลที่อยู่ในท่อ ในสายเคเบิล ในคลื่นไวไฟ คือข้อมูลมันกำลังวิ่งอยู่

สมมติ A จะสวัสดีโย่ B ข้อมูล (โย่) จะมีที่อยู่ในแต่ละช่วงเวลาของการเดินทางทำนองนี้
// รูปที่ 2 //

[A(โย่)]<======>[P    ]<======>[B    ]
[A    ]<=(โย่)=>[P    ]<======>[B    ]
[A    ]<======>[P(โย่)]<======>[B    ]
[A    ]<======>[P    ]<=(โย่)=>[B    ]
[A    ]<======>[P    ]<======>[B(โย่)]
(ในความเป็นจริง ข้อมูลมันไม่ได้ "เคลื่อนที่" แบบนี้ในรูปที่ 2 นี้ซะทีเดียวกัน จริงๆ ข้อมูลมันถูก "ทำสำเนา" คือ (โย่) มันจะไปอยู่ในทุกที่แหละ ถึง B ได้รับแล้ว แต่ก็จะยังอยู่ในเครื่องของ A และของผู้ให้บริการ และอาจจะยังตกค้างอยู่ในท่อชั่วระยะเวลาหนึ่ง แต่เพื่อความสะดวกในการอธิบาย ติ๊ต่างว่าข้อมูลมัน "เคลื่อนที่" ละกันนะ)

การดักรับข้อมูลและการเข้ารหัสข้อมูล

การ "ดักฟัง" หรือการ "ดักรับข้อมูล" คือการดักข้อมูลที่อยู่ระหว่างเดินทางซึ่งเป็นวิธีหนึ่งในการได้มาซึ่งข้อมูล

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

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

แต่พอคนต้องการให้การสื่อสารมันปลอดภัยขึ้น ด้วยเหตุลต่างๆ เช่น การซื้อขายสินค้า หรือติดต่อธุรกิจ เรื่องส่วนตัว ก็มีการพัฒนาให้การสื่อสารบนอินเทอร์เน็ตมันปลอดภัยขึ้น ด้วยการเข้ารหัสการสื่อสาร
ตัวอย่างการเข้ารหัสการสื่อสารที่นิยมสำหรับอินเทอร์เน็ต เช่นโปรโตคอล Secure Sockets Layer (SSL) (ล้าสมัยแล้ว) และ Transport Layer Security (TLS) ซึ่งใช้กับทั้งการรับส่งข้อมูลหน้าเว็บและอีเมล

เว็บไซต์ที่รับส่งข้อมูลระหว่างเว็บเซิร์ฟเวอร์กับอุปกรณ์ปลายทางที่ใช้โปรโตคอล SSL หรือ TLS จะสังเกตได้จากที่ตอนนั้น url นั้นจะเป็น https:// (ถ้าเป็น http:// ที่ไม่มี s จะเป็นการส่งข้อมูลปกติ ไม่มีการเข้ารหัส)

การเข้ารหัสการสื่อสาร อย่าง HTTPS ทำให้การดักรับข้อมูลระหว่างเดินทางนั้นได้ประโยชน์น้อยลง คือยังดักรับได้เหมือนเดิม แต่ข้อมูลที่ได้ไปมันอ่านไม่ออก (ติดตั้งปลั๊กอิน HTTPS Everywhere https://www.eff.org/https-everywher... เพื่อช่วยให้เราเข้าเว็บไซต์ด้วย https ถ้าเว็บไซต์นั้นมีช่องทางนี้ ไม่ต้องพิมพ์ระบุเอง)
// รูปที่ 3 //

[A(โย่)]<======>[P    ]<======>[B    ]
[A    ]<=($&)=>[P    ]<======>[B    ]
[A    ]<======>[P(โย่)]<======>[B    ]
[A    ]<======>[P    ]<=(^#)=>[B    ]
[A    ]<======>[P    ]<======>[B(โย่)]
จะเห็นว่า การดูข้อมูลในท่อ === นั้น ทำได้ยากขึ้น (ต้องไปหาวิธีถอดรหัส เสียเวลา) แต่การดูข้อมูลในเครื่อง [ X ] นั้นยังทำได้

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

โปรดสังเกตว่า คำว่า “ส่ง” และ “รับ” ในที่นี้ หมายถึงการรับและส่งตลอดเส้นทางของข้อมูล ไม่ใช่แค่การส่งออกจาก A และการรับที่ B แต่ยังรวมถึงการรับและส่งต่อโดยตัวกลางอย่างผู้ให้บริการด้วย (เช่น จาก A ไปผู้ให้บริการ, จากผู้ให้บริการไป B, หรือระหว่างผู้ให้บริการระดับต่างๆ)

เราจะเห็นว่า ที่เครื่องเซิร์ฟเวอร์ของผู้ให้บริการ ก็จะมีข้อมูลที่ไม่ถูกเข้ารหัสเก็บอยู่เช่นกัน
ดังนั้นคนที่อยากดูข้อมูล ถ้าดูข้อมูลในท่อ === ไม่ได้ ก็ยังมีจุดให้ดูข้อมูลได้อีกอย่างน้อย 3 ที่คือ [ เครื่องผู้ส่ง ], [ เครื่องผู้ให้บริการ ], และ [ เครื่องผู้รับ ]

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

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

หรือบางครั้งก็อาจมีกรณีแบบ ตัวบริษัทไม่ได้รู้เห็น แต่พนักงานเอาข้อมูลออกมา (ทั้งๆ ที่ขัดนโยบายบริษัท)

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

ทั้งหลายทั้งปวง พอเป็นแบบนี้ คนก็เห็นว่า ก็ยังไม่ปลอดภัยอยู่ดี ถ้าจะเข้ารหัสเฉพาะต่อรับส่งข้อมูล ควรจะเข้ารหัสตัวข้อมูลเองด้วย เพื่อที่ว่าตัวกลางที่เราฝากข้อมูลไปกับเขา จะได้อ่านไม่ได้
// รูปที่ 4 //

[A(โย่)>(#$)]<======>[P    ]<======>[B         ]
[A         ]<=(#$)=>[P    ]<======>[B         ]
[A         ]<======>[P(#$)]<======>[B         ]
[A         ]<======>[P    ]<=(#$)=>[B         ]
[A         ]<======>[P    ]<======>[B(#$)>(โย่)]
จะเห็นว่าการเข้ารหัสแบบนี้ คือการเข้ารหัสข้อมูลอยู่ในเครื่องต้นทางเลย และจะไปถูกเปิดอ่านได้อีกทีที่ปลายทางเท่านั้น

เราเรียกการเข้ารหัสแบบตั้งแต่ต้นอย่างนี้ ว่า end-to-end encryption หมายถึงว่า จะมีเฉพาะปลายทางสุดสาย (end) ทั้งสองของการสื่อสารเท่านั้นที่เห็นข้อความต้นฉบับ คนที่อยู่ตรงกลางที่เหลือจะเห็นเฉพาะข้อมูลที่ถูกเข้ารหัสแล้ว

ในทางปฏิบัติ การสื่อสารอาจมีการเข้ารหัสหลายรอบที่ระดับต่างๆ กัน
// รูปที่ 5 //

[A(โย่)>(#$)]<======>[P    ]<======>[B         ]
[A         ]<=(%*)=>[P    ]<======>[B         ]
[A         ]<======>[P(#$)]<======>[B         ]
[A         ]<======>[P    ]<=(^&)=>[B         ]
[A         ]<======>[P    ]<======>[B(#$)>(โย่)]
ในรูปที่ 5 จะเห็นว่าเป็นการเอารูปที่ 3 และรูปที่ 4 มารวมกัน มีการเข้ารหัสทั้งที่ข้อมูลระหว่างพัก (ในเครื่อง) และเข้ารหัสซ้ำอีกทีที่ข้อมูลระหว่างเดินทาง (ในท่อ)

ตัวอย่างของการรับส่งข้อมูลอย่างในรูปที่ 5 คือการเข้ารหัสข้อความในอีเมลด้วย PGP ก่อน -- จาก (โย่) ไปเป็น (#$) -- จากนั้นจึงส่งข้อมูลที่เข้ารหัสแล้วไปยังเซิร์ฟเวอร์อีเมล ผ่านโปรโตคอล TLS เพื่อปกปิดรหัสผ่านอีเมลของเรา เซิร์ฟเวอร์อีเมลจะเก็บข้อมูลเอาไว้โดยที่ไม่เห็นข้อความต้นฉบับ จากนั้นก็จะส่งต่อไปยังผู้รับ แล้วผู้รับก็จะถอดรหัสที่ปลายทางอีกที

(คำถามคือ ทำไมต้องทำซ้ำแบบนี้ด้วย คำตอบคือ ข้อมูลในการสื่อสารทั้งหมด ไม่ได้มีเฉพาะข้อมูลที่เราจะส่งจริงๆ แต่อาจมีข้อมูลอื่นด้วย เช่น ชื่อผู้ใช้ รหัสผ่าน ในกรณีการส่งอีเมล เราอาจจะเข้ารหัสข้อความที่เราต้องการส่งแล้ว แต่ถ้าไม่เข้ารหัสช่องทางการสื่อสาร คนที่ดักรับข้อมูลแม้จะอ่านข้อความเราไม่ได้ แต่จะเห็นรหัสผ่านของเราได้ -- ในปี 2014 พบว่า ISP บางเจ้าในเมืองไทย มีการปฏิเสธการเชื่อมต่อแบบเข้ารหัสกับเซิร์ฟเวอร์อีเมล https://www.eff.org/deeplinks/2014/11/starttls-downgrade-attacks )

บริการแชตรุ่นหลังๆ อย่าง Signal, WhatsApp (เวอร์ชั่นใหม่-และต้องเป็นเวอร์ชั่นใหม่ทั้งสองข้างของการสื่อสาร) และ Telegram ก็จะใช้การเข้ารหัสแบบ end-to-end คือเข้ารหัสมาตั้งแต่ปลายทางของอุปกรณ์รับส่งเลย ไม่ใช่เข้ารหัสเฉพาะตรงท่อ (Facebook เข้ารหัสเฉพาะตรงท่อ, ส่วน LINE โดยปกติจะเข้ารหัสเฉพาะตรงท่อเช่นกัน เว้นว่าจะเลือก hidden chat จึงจะเป็นการเข้ารหัสที่ข้อความตั้งแต่ต้นทาง มีให้ใช้ตั้งแต่ LINE รุ่น 4.5)

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

เมื่อข้อมูลระหว่างเดินทางในท่อ === ก็ถูกเข้ารหัส ข้อมูลระหว่างพักในเซิร์ฟเวอร์ [ ผู้ให้บริการ ] ก็ถูกเข้ารหัส ก็เหลือจุดที่จะยังเข้าดูข้อมูลได้ คือเครื่องที่ปลายทางทั้งสองของการสื่อสาร นั่นคือเครื่อง [ A ] และเครื่อง [ B ]

นี่น่าจะสาเหตุหนึ่งที่ว่าทำไมตอนหลังๆ การโจมตีที่อุปกรณ์มือถือจึงมีเยอะขึ้น เพราะมันเป็นเป้าหมายที่จัดการได้ง่ายกว่า

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

ซอฟต์แวร์ Remote Control System (RCS): Galileo ของบริษัท Hacking Team ก็เป็นซอฟต์แวร์อันหนึ่งที่เจาะจงโจมตีอุปกรณ์ที่ปลายทั้งสองข้างของการสื่อสาร https://youtu.be/8GhEvuU8LjU
จากอีเมลภายในของบริษัท Hacking Team "ลูกค้า" จากประเทศไทย มีความสนใจถึงการดูข้อมูลใน iPhone ที่ไม่ได้เจลเบรก การดูข้อมูล Line, WhatsApp, WeChat, และ Instagram https://wikileaks.org/hackingteam/e...

มีเอกสารยืนยันหน่วยงานรัฐในประเทศไทยหลายแห่งสั่งซื้อผลิตภัณฑ์จาก Hacking Team แล้ว http://thaipublica.org/2015/07/hack... https://thainetizen.org/docs/right-... (หน้า 11 ย่อหน้าหมายเลข 40 และ 42 ) https://citizenlab.org/2014/02/mapp...

กลับมาที่บั๊กในโทรศัพท์

บั๊ก Stagefright นี้พบใน Android รุ่นตั้งแต่ 2.2 เรื่อยมาจนถึงรุ่น 5.1 (โทรศัพท์ Android ส่วนใหญ่ในตลาด ตอนนี้เป็นรุ่น 4.x)

เช็คว่าโทรศัพท์ของเราได้มีรูรั่วนี้หรือไม่ ด้วยแอป Stagefright Detector จาก Zimperium INC. https://play.google.com/store/apps/...

ถ้าเจอแล้วไงต่อ?

ถ้าที่ผ่านมาไม่เคยอัปโอเอสเลย ก็ลองอัปดูครับ Settings -> About Phone/Tablet -> System updates (อุปกรณ์แต่ละรุ่นอาจต่างกันนิดหน่อย)

แต่ถ้าไม่มีให้อัป ก็ทำใจครับ แต่อ่านต่อหน่อยนึง

แล้วถ้าไม่เจอล่ะ?

ก็รอดตัวไปสำหรับบั๊กตัวนี้ แต่ก็อาจจะมีบั๊กตัวอื่นรออยู่

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

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

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

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

สรุป

การรักษาความปลอดภัยทางคอมพิวเตอร์นั้น มีหลายส่วน ทั้งที่ตัวอุปกรณ์เอง สภาพแวดล้อมที่ใช้งาน และที่พฤติกรรมการใช้

ในส่วนของอุปกรณ์ พยายามอัปเดตโอเอสและซอฟต์แวร์ให้ทันสมัย เพื่อลดโอกาสโดนโจมตีจากรูรั่วพวกนี้

กรณีโทรศัพท์ที่ใช้มันไม่ยอมให้อัปเดตหรือกว่าจะอัปก็ช้ามาก ถ้าจำเป็นและพอจะทำได้ ก็ลองพิจารณาหาโทรศัพท์ใหม่

สำหรับสภาพแวดล้อมที่ใช้งาน เครื่องไหนที่เราไม่ไว้ใจ อย่าไปใช้ถ้าไม่จำเป็น อดใจไปใช้เครื่องตัวเองดีกว่า

ศึกษาเลือกแอปและบริการที่ปลอดภัยและเหมาะกับการใช้งาน เช่น ไม่ขอ Permission เกินจำเป็น มีระบบการรักษาความปลอดภัยที่ดี สำหรับแอปส่งข้อความอาจดูได้จาก Secure Messaging Scorecard https://www.eff.org/secure-messagin...

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

ในแง่การได้รับการคุ้มครองทางกฎหมาย การเลือกแอปหรือบริการอาจต้องดูด้วยว่า บริษัทผู้ให้บริการมีสำนักงานใหญ่และสำนักงานสาขาที่จะรับเรื่องการบังคับใช้กฎหมายอยู่ที่ประเทศไหนเป็นหลัก และพอถูกขอข้อมูลหรือขอความร่วมมือ บริษัทจัดการยังไง เช่นดูจาก “transparency report” ของบริษัทต่างๆ EFF สรุปของบริษัทผู้ให้บริการใหญ่ๆ มาให้ดูที่ https://www.eff.org/who-has-your-ba...

Facebook Government Requests Report https://govtrequests.facebook.com/
Twitter Transparency Report https://transparency.twitter.com/
     Microsoft Transparency Hub https://www.microsoft.com/about/csr..
     Google Transparency Report https://www.google.com/transparency...

     ถ้าจำเป็น การใช้ VPN และ Tor ก็ควรพิจารณาศึกษาเอาไว้ อย่างเฟซบุ๊กนี่สามารถเข้าถึงผ่าน Tor ด้วย “hidden service” ได้ด้วยที่ https://facebookcorewwwi.onion/

ในส่วนของพฤติกรรมการใช้

อย่างที่บอก ส่วนใหญ่ความผิดพลาดเกิดจากมนุษย์ทั้งนั้น เช่น ปกป้องกันตัวเองทางเทคนิคอย่างดี แต่ดันโพสต์ข้อมูลส่วนตัวลงเฟซบุ๊กเอง หรือเผลอให้ทวิตเตอร์มันเช็กอิน หรืออัปโหลดภาพที่มีตำแหน่ง GPS ฝังอยู่ในภาพ (EXIF)

ไม่คลิกลิงก์ที่มีที่มาแปลกๆ (ส่งจากคนไม่รู้จัก, ส่งจากคนรู้จัก แต่ด้วยคำเชิญชวนแหม่งๆ, url เป็น url ที่เราไม่แน่ใจว่ามาจากไหน หรือจะพาไปไหน เช่นพวก shorten url)

ไม่เล่นไฟล์มีเดียแปลกๆ (ไม่ว่าจะส่งมาทางใดก็ตาม MMS, Line ฯลฯ) เพื่อลดความเสี่ยงจากมิจฉาชีพ เบอร์โทรศัพท์ของเราก็ควรจะมีคนรู้เฉพาะเท่าที่จำเป็น หรือแยกเบอร์ส่วนตัวกับเบอร์งานออกจากกัน ไม่ใช้ปนกัน เพื่อลดความเสียหาย (sandboxing)

ตั้งรหัสล็อกเครื่องเสมอ ถ้าหลีกเลี่ยงได้ ก็ไม่ควรจะให้เครื่องมันจำรหัสผ่านอีเมลหรือโซเชียลมีเดียของเรา (มันสะดวกในการใช้ก็จริง แต่ก็ทำให้คนที่ unlock เครื่องเราได้ เข้าถึงข้อมูลการสื่อสารของเราได้ อันนี้ก็ต้องชั่งน้ำหนักเอาเอง)

เปิดใช้การยืนยันตัวตน 2 ชั้น (2-step authentication) ถ้าทำได้ (Facebook, Gmail, Microsoft Account พวกนี้มีให้ใช้) -- ดูเหตุผลว่าทำไม

การใช้ 2-step authen จะช่วยลดปัญหาการถูกขโมยรหัสผ่านจาก keylogger ได้ด้วย (เพราะรหัสอีกชุดนั้น ต่อให้ถูกบันทึก ก็ถูกใช้ได้แค่ครั้งเดียว) -- แต่ไม่ช่วยแก้ปัญหาการถูกขโมยทางการพิมพ์อื่นๆ

keylogger คือเครื่องบันทึกการพิมพ์บนคีย์บอร์ด ซึ่งจะขโมยรหัสผ่านและข้อมูลส่วนตัวอื่นๆ ของเราได้  เวลาพูดถึง keylogger อย่าคิดว่ามันจะมีเฉพาะฮาร์ดแวร์มาเสียบที่เครื่องเรา หรือต้องเป็นมัลแวร์ที่แอบมา ติดเครื่องเรา พวกซอฟต์แวร์ keyboard บน Android และ iOS นี่ก็เป็น keylogger เหมือนกัน เวลาใช้ต้องมั่นใจว่ามันมาจากผู้ผลิตที่เราไว้ใจได้จริงๆ

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

หมั่นสังเกตคำเตือนจากเว็บเบราวเซอร์และโอเอส เช่น ดูรูปกุญแจสีเขียว/สีแดงที่ช่อง url เพื่ออ่านคำเตือนเรื่องใบรับรองการเข้ารหัสของเว็บไซต์ (SSL/TLS encryption certificate) ว่าเป็นของจริงหรือไม่ เพื่อให้แน่ใจว่าเรากำลังสื่อสารกับเว็บไซต์ที่เรากำลังคิดว่าสื่อสารอยู่ด้วยจริงๆ

การสื่อสารแบบเข้ารหัสนั้น การันตีเฉพาะว่าระหว่างทางข้อมูลจะอ่านไม่ได้ แต่ไม่ได้การันตีว่าที่ปลายทางที่ข้อมูลจะถูกถอดรหัสนั้น จะเป็นคนที่เราคิดว่าเป็น (เราอาจจะคุยกับคนแอบอ้างอยู่) จึงมีการคิดค้นระบบออกใบรับรองขึ้นมา เพื่อรับรองว่าเซิร์ฟเวอร์ที่เราติดต่อด้วยนั้น เป็นเซิร์ฟเวอร์ที่อ้างจริงๆ ใบรับรองนี้เรียกกันว่า “SSL certificate” หรือ “encryption certificate”

คำสั่งกระทรวงไอซีที ที่ 163/2557 ที่ตั้งคณะทำงานทดสอบระบบเฝ้าติดตามสื่อออนไลน์ มาประสานงานกับผู้ให้บริการเน็ตและ Internet Gateway และทดสอบ “ระบบเฝ้าติดตามสื่อออนไลน์ที่มีการเข้ารหัสป้องกันข้อมูล” มีจุดมุ่งหมายในการจะเจาะการเข้ารหัสการสื่อสารด้วย SSL/TLS นี้ ซึ่งคาดกันว่าวิธีหนึ่งที่จะทำได้ คือด้วยการปลอมใบรับรอง เพื่อดูข้อมูลในแบบที่เรียกว่า “Man in the Middle Attack” หรือการปลอมตัวมาเนียนอยู่ตรงกลางของการสื่อสาร

คือแทนที่ สมมติ เราจะคุยกับเฟซบุ๊กตรงๆ ก็อาจมีเซิร์ฟเวอร์ของไอซีทีมาคั่นกลาง แล้วทำให้เราเข้าใจว่าเป็นเซิร์ฟเวอร์ของเฟซบุ๊ก (ด้วยความร่วมมือของ ISP) เราก็ส่งข้อมูลให้เซิร์ฟเวอร์นี้โดยไม่รู้ตัว เซิร์ฟเวอร์นี้ก็ส่งต่อข้อมูลให้เฟซบุ๊ก เพื่อให้เราไม่สังเกต ใช้งานได้ปกติ [A]<=========>[Facebook]<=>[B] [A]<=>[MICT]<=>[Facebook]<=>[B] แม้การสื่อสารระหว่างเรา [A] กับเซิร์ฟเวอร์ [MICT] จะเข้ารหัสก็จริง แต่ปลายทางที่จะถูกถอดรรัสมันก็คือเซิร์ฟเวอร์ [MICT] ด้วย ไม่ใช่ที่ [Facebook] แบบนี้ก็ไม่ปลอดภัยเช่นกัน 

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

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

จบที่ว่า ในทางปฏิบัตินั้น ไม่มีระบบสารสนเทศอะไรปลอดภัย 100% ไปตลอดกาล ความผิดพลาดมาจากมนุษย์เป็นส่วนใหญ่ ทั้งคนออกแบบระบบและคนใช้ระบบ แต่เราสามารถมีระบบสารสนเทศที่ “ปลอดภัยเพียงพอ” ได้ (เช่น รหัส OTP ที่เราใช้กับการซื้อของออนไลน์ อาจจะใช้เวลาแค่ 2 นาทีในการถอดรหัสแบบดื้อๆ หรือที่เรียกว่า brute force คือเดาไปเรื่อยๆ จนถูก แต่ถ้าระบบมันตั้งให้รหัสหมดอายุหลังจาก 30 วินาที แบบนี้ก็คือปลอดภัยพอแล้ว)

อย่ากลัวจนไม่ได้ทำงานทำการ 

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

ฝากลิงก์ไว้หน่อย
Surveillance Self-Defense การป้องกันตัวเองจากการถูกสอดส่อง https://ssd.eff.org/th/
·         Security in-a-Box แนะนำการรักษาความปลอดภัยทางดิจิทัล https://securityinabox.org/th
ใช้เน็ตปลอดภัยด้วย Tor https://thainetizen.org/tor/