Clear
Lead Graphic Papers

ระวังภัย ช่องโหว่ “Master Key” ในระบบปฏิบัติการ Android

วันที่ประกาศ: 17 กรกฏาคม 2556
ปรับปรุงล่าสุด: 17 กรกฏาคม 2556
เรื่อง: ระวังภัย ช่องโหว่ “Master Key” ในระบบปฏิบัติการ Android

ประเภทภัยคุกคาม: Intrusion

Share on Facebook Share on Twitter Share on Google+

เมื่อช่วงต้นเดือนกรกฎาคม 2556 นักวิจัยจากบริษัท Bluebox Security ได้เปิดเผยข้อมูลช่องโหว่ในกระบวนการตรวจสอบแอปพลิเคชันของระบบปฏิบัติการ Android ซึ่งช่องโหว่ดังกล่าวนี้มีผลกระทบกับอุปกรณ์ที่ใช้งานระบบปฏิบัติการ Android ตั้งแต่เวอร์ชั่น 1.6 จนถึง 4.2.2 ซึ่งคิดเป็นจำนวนกว่า 99% ของเครื่องที่มีการใช้งานอยู่ในปัจจุบัน (ประมาณ 900 ล้านเครื่อง) [1]

โดยปกติแล้วแอปพลิเคชันของระบบปฏิบัติการ Android (ไฟล์นามสกุล .apk) ที่ผู้ใช้จะนำมาติดตั้งลงในเครื่องได้ จะต้องผ่านกระบวนการ Sign โดยใช้ Digital certificate ของผู้พัฒนา ซึ่งหลังจากที่ผ่านกระบวนการ Sign แล้ว ไฟล์ .apk นั้นก็จะมีข้อมูลที่เรียกว่า Signature ที่เอาไว้ใช้ยืนยันว่าข้อมูลทั้งหมดที่อยู่ในไฟล์ .apk นั้นมาจากผู้พัฒนาตัวจริง ไม่ได้ถูกดัดแปลงแก้ไขโดยบุคคลอื่นในภายหลัง [2]

เมื่อผู้ใช้ทำการติดตั้งแอปพลิเคชันจากไฟล์ .apk ระบบจะตรวจสอบว่าในเครื่องนั้นมีแอปพลิเคชันตัวเดียวกันถูกติดตั้งอยู่แล้วหรือเปล่า หากพบว่ามีอยู่แล้ว ก็จะทำการตรวจสอบว่าแอปพลิเคชันตัวที่จะติดตั้งนั้นมาจากผู้พัฒนาคนเดียวกันกับแอปพลิเคชันตัวที่เคยติดตั้งอยู่ในเครื่อง ซึ่งทำได้โดยการเปรียบเทียบ Signature ว่าตรงกันหรือไม่ หากไม่ตรงกันก็จะไม่ยอมให้ผู้ใช้ติดตั้งแอปพลิเคชันดังกล่าว โดยตัวอย่างในรูปที่ 1 แสดงการติดตั้งแอปพลิเคชันชื่อ Falcon Pro เวอร์ชั่นที่ถูกดัดแปลง ลงในเครื่องที่ติดตั้งแอปพลิเคชันตัวจริงจากผู้พัฒนาไว้ก่อนแล้ว ซึ่งระบบจะไม่ยอมให้ติดตั้งแอปพลิเคชันตัวใหม่ลงในเครื่อง

Application not installed
รูปที่ 1 ตัวอย่างหน้าจอการแจ้งเตือนไม่ยอมให้ติดตั้งแอปพลิเคชันที่มี Signature ไม่ถูกต้อง

ในแอปพลิเคชันที่มาจากผู้พัฒนารายเดียวกันจะมี Signature ที่ตรงกัน ทำให้ผู้ใช้สามารถติดตั้งหรืออัพเดตแอปพลิเคชันได้อย่างไม่มีปัญหา แต่หากแอปพลิเคชันดังกล่าวถูกบุคคลอื่นนำไฟล์ .apk ไปเปลี่ยนแปลง เช่น แก้ไขข้อมูลใน Source Code แล้ว Repack ไฟล์ .apk นั้นกลับเข้ามาใหม่ ในกระบวนการ Repack จะต้องมีการ Sign Signature ให้กับแอปพลิเคชัน ซึ่งผู้ที่แก้ไขไฟล์ .apk นั้นอาจจะต้องสร้าง Certificate ขึ้นมาใหม่ ทำให้ Signature ของไฟล์ .apk ที่ถูกแก้ไขนั้นไม่ตรงกับสิ่งที่อยู่ในแอปพลิเคชันของผู้พัฒนาตัวจริง

นักวิจัยจาก Bluebox Security ค้นพบวิธีแก้ไขไฟล์ .apk โดยคง Signature ของเดิมไว้ ซึ่งช่องโหว่ดังกล่าวนี้ทำให้ผู้ไม่หวังดีสามารถแก้ไขโค้ดของไฟล์ .apk แล้ว Repack เข้าไปใหม่โดยที่ยังคง Signature เดิมไว้ได้ ทำให้เมื่อผู้ใช้ติดตั้งแอปพลิเคชันดังกล่าวลงในเครื่องที่เคยติดตั้งแอปพลิเคชันนี้ได้แล้ว ระบบจะไม่แจ้งว่า Signature ไม่ถูกต้อง ซึ่งทำให้ผู้ไม่หวังดีสามารถนำเอาแอปพลิเคชันใดๆ มาดัดแปลงให้เป็นมัลแวร์ได้ โดยระบบจะไม่สามารถรู้ได้เลยว่าแอปพลิเคชันนั้นไม่ใช่ตัวจริงที่มาจากผู้พัฒนา

สาเหตุของช่องโหว่

แอปพลิเคชันของระบบปฏิบัติการ Android จะอยู่ในรูปแบบไฟล์ .apk (Android Package) ซึ่งโดยแท้จริงแล้วเป็นไฟล์ประเภท Zip ที่สามารถใช้โปรแกรมประเภท Archiver ทั่วไปทำการ Extract ไฟล์ที่อยู่ข้างในออกมาดูได้

ในไฟล์ .apk เกือบทุกไฟล์จะมีไดเรกทอรีชื่อ META-INF ซึ่งภายในจะมีไฟล์ MANIFEST.MF ที่เก็บข้อมูล Checksum แบบ SHA1-Digest ของไฟล์ทุกไฟล์ที่อยู่ใน Package นั้น ดังรูปที่ 2 เมื่อผู้ใช้ทำการติดตั้งแอปพลิเคชันจากไฟล์ .apk ตัวระบบปฏิบัติการ Android จะตรวจสอบค่า Checksum ของแต่ละไฟล์ เทียบกับข้อมูลในไฟล์ MANIFEST.MF หากพบว่าไฟล์ใดไฟล์หนึ่งมีค่า Checksum ไม่ตรง ก็จะไม่อนุญาตให้ติดตั้งไฟล์ .apk ดังกล่าวลงในเครื่อง

Android MANIFEST.MF
รูปที่ 2 ตัวอย่างข้อมูลในไฟล์ MANIFEST.MF (ที่มา NakedSecurity [3])

นักวิจัยจาก Bluebox Security พบว่าระบบการตรวจสอบนี้จะทำงานผิดพลาดหากพบว่าไฟล์ .apk นั้นมีข้อมูลไฟล์ชื่อเดียวกันซ้ำกัน 2 ไฟล์ ซึ่งถึงแม้ว่าโปรแกรมประเภท Archiver โดยทั่วไปจะไม่อนุญาตให้มีเหตุการณ์แบบนี้เกิดขึ้นได้ แต่เนื่องจากโครงสร้างของไฟล์ประเภท Zip นั้นไม่มีระบบการป้องกันในเรื่องของชื่อไฟล์ซ้ำ ทำให้การเข้าไปแก้ไขข้อมูลในไฟล์ Zip โดยตรง หรือเขียนโปรแกรมขึ้นมาเพื่อใส่ไฟล์ที่มีชื่อเดียวกันและอยู่ใน Path เดียวกันลงไปในไฟล์ Zip นั้นสามารถทำได้ [4] ดังรูปที่ 3

Malicious APK file
รูปที่ 3 ตัวอย่างการแก้ไขไฟล์ .apk โดยใส่ไฟล์ที่มีชื่อซ้ำกัน (ที่มา NakedSecurity [3])

เมื่อผู้ใช้ทำการติดตั้งไฟล์ .apk ที่ถูกแก้ไขให้มีไฟล์ที่มีชื่อซ้ำกัน 2 ไฟล์ ตัวติดตั้งของระบบปฏิบัติการ Android จะตรวจสอบข้อมูล Checksum ของไฟล์แรก แต่จะ Extract และติดตั้งข้อมูลจากไฟล์ที่สอง

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

หลังจากที่ทาง Bluebox Security ได้เผยแพร่ข้อมูลช่องโหว่ไปได้ไม่นาน นักวิจัยชาวจีนที่ใช้ชื่อทีมว่า “Android Security Squard” ก็ได้ค้นพบช่องโหว่ลักษณะคล้ายกันนี้ในไฟล์ classes.dex ซึ่งพบว่าในโครงสร้างของไฟล์ classes.dex นั้น หากแก้ไขข้อมูลในส่วน extra field ให้มีค่าเป็น 0xFFFD จะสามารถหลอกการทำงานของระบบตรวจสอบความถูกต้องของไฟล์ ให้ไปโหลดไฟล์ classes.dex ตัวที่ถูกแก้ไขมาใช้แทนไฟล์ที่ถูกต้องได้ [3] ดังแสดงในรูปที่ 4

Malicious classes.dex
รูปที่ 4 ตัวอย่างการแก้ไขไฟล์ class.dex เพื่อใส่ (ที่มา sina [5])

วิธีการโจมตี

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

แอปพลิเคชันเถื่อน

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

Social Engineer

การหลอกให้ผู้ใช้ติดตั้งแอปพลิเคชันด้วยวิธี Social Engineer เริ่มจะมีแนวโน้มเพิ่มมากขึ้น เพราะตัวอย่างกรณีมัลแวร์ที่แก้ไขหน้าเว็บไซต์ธนาคารออนไลน์ [6] เพื่อหลอกให้ผู้ใช้ติดตั้งแอนตี้ไวรัสปลอม [7] ที่มีผู้ตกเป็นเหยื่ออยู่หลายรายนั้นก็แสดงให้เห็นแล้วว่าวิธีนี้ใช้ได้ผล และในอนาคตน่าจะมีการโจมตีในลักษณะนี้ออกมาอีกเรื่อยๆ

Drive-by-download

ในช่วง 1-2 ปีที่ผ่านมา มีข่าวการเจาะเว็บไซต์เพื่อฝังมัลแวร์ที่โจมตีอุปกรณ์ที่ใช้งานระบบปฏิบัติการ Android ออกมาให้เห็นกันอยู่เรื่อยๆ โดยจะมีวิธีการโจมตีคือหลังจากที่ผู้ใช้เข้าไปยังเว็บไซต์ที่ถูกเจาะ จะมีการดาวน์โหลดไฟล์ .apk ที่เป็นมัลแวร์ลงมาในเครื่องของผู้ใช้โดยอัตโนมัติ โดยจะมีการตั้งชื่อไฟล์หลอกล่อให้ผู้ใช้หลงเชื่อ เช่น Updater.apk เป็นต้น แต่ในการจะติดมัลแวร์นี้ได้ผู้ใช้ต้องเป็นคนกดอนุญาตให้ติดตั้งโปรแกรมเสียก่อน [8] [9]

อย่างไรก็ตาม ในระบบปฏิบัติการ Android รุ่นเก่าๆ (เช่น 2.1) จะมีช่องโหว่ในแอปพลิเคชัน Browser ที่มากับตัวเครื่อง (CVE-2010-1807) ซึ่งเป็นช่องโหว่ของเอนจิน Webkit ที่ใช้ในการแสดงผลหน้าเว็บไซต์ ซึ่งทำให้ผู้ไม่หวังดีสามารถสั่งประมวลผลคำสั่งใดๆ ก็ตามบนเครื่องของผู้ใช้ได้เมื่อผู้ใช้เข้าไปยังเว็บไซต์ที่มีการโจมตีผ่านช่องโหว่ดังกล่าวผ่านเบราว์เซอร์ของ Android [10] นั่นทำให้ผู้ใช้สามารถติดมัลแวร์ได้ทันที่ที่เข้าเว็บไซต์ โดยไม่จำเป็นต้องกดยอมรับการติดตั้งแอปพลิเคชันแต่อย่างใด การโจมตีผ่านช่องโหว่นี้เคยเกิดขึ้นแล้วเมื่อเดือนมีนาคม 2555 โดยผู้ไม่หวังดีจะส่ง SMS ที่มีลิงก์สำหรับเปิดเว็บไซต์มาที่เครื่องของเหยื่อ โดยทันทีที่เหยื่อกดเข้าไปในลิงก์นั้นก็จะติดมัลแวร์ในทันที [11]

Fake OTA Update

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

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

การปลอมแปลง Certificate เพื่อปล่อยอัพเดตแบบปลอมๆ นั้นไม่ใช่เรื่องใหม่ เพราะในเดือนมิถุนายน 2555 มีมัลแวร์ชื่อ Flame ใช้วิธีการปลอมแปลง Certificate ของ Microsoft เพื่อเผยแพร่ Windows Update ปลอมไปยังเครื่องในเครือข่าย [12]

Play Store

Play Store ดูจะเป็นที่ที่ปลอดภัยที่สุดสำหรับการดาวน์โหลดแอปพลิเคชันมาติดตั้ง ถึงแม้ปัจจุบันทาง Google จะแจ้งว่าได้ปรับปรุง Play Store ให้มีการตรวจสอบและป้องกันแอปพลิเคชันที่โจมตีผ่านช่องโหว่นี้แล้ว [13] แต่ก็ยังมีผู้ไม่หวังดีพยายามหาวิธีที่จะหลบเลี่ยงระบบตรวจสอบเพื่อส่งแอปพลิเคชันที่เป็นมัลแวร์เข้ามาใน Play Store อยู่เรื่อยๆ และจากการที่มีข่าวมัลแวร์ใน Play Store ออกมาอยู่เป็นระยะๆ ก็อาจทำให้เราไม่สามารถไว้วางใจแอปพลิเคชันจาก Play Store ได้อย่าง 100% นัก

การป้องกันและแก้ไขปัญหา

ทาง Bluebox Security ได้แจ้งช่องโหว่นี้ไปยัง Google ตั้งแต่เดือนกุมภาพันธ์ 2556 แล้ว ซึ่งหลังจากนั้นทาง Google ได้ประสานงานได้ยังผู้ผลิตอุปกรณ์ที่ใช้งานระบบปฏิบัติการ Android เพื่อให้ออกอัพเดตที่แก้ไขปัญหานี้

อย่างไรก็ตาม ในปัจจุบัน (ขณะที่เขียนบทความนี้) มีอุปกรณ์ที่ใช้งานระบบปฏิบัติการ Android เพียงแค่ 2 รุ่นที่ได้รับการอัพเดตแก้ไขช่องโหว่อย่างเป็นทางการ นั่นคือ Samsung Galaxy S4 และ HTC One ที่ใช้งานเฟิร์มแวร์ Android เวอร์ชั่น 4.2.2 [14] ในขณะที่อุปกรณ์ที่มาจากผู้ผลิตรายอื่นๆ หรือแม้กระทั่ง Nexus ที่ใช้ซอฟต์แวร์จากทาง Google เอง ก็ยังไม่ได้มีซอฟต์แวร์อัพเดตหรือแพทช์ออกมาแต่อย่างใด

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

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

ทางฝั่งผู้พัฒนา Custom Rom อย่าง CyanogenMod นั้นได้มีการแก้ไขช่องโหว่ดังกล่าวใน CyanogenMod เวอร์ชั่น 10.1.1 แล้ว [16] ซึ่งผู้ที่ใช้งานอุปกรณ์ที่ไม่ได้รับการอัพเดตจากผู้ผลิตอาจลองพิจารณาใช้ Custom Rom ดังกล่าวเพื่อเพิ่มความปลอดภัยได้ อย่างไรก็ตาม ผู้ใช้ทั่วไปอาจไม่สามารถติดตั้ง Custom Rom กันได้ทุกคน เพราะมีขั้นตอนวิธีที่ค่อนข้างซับซ้อนและอาจเสี่ยงต่อการที่ข้อมูลสูญหายหรืออาจทำให้เครื่องใช้งานไม่ได้โดยถาวรหากมีการทำงานผิดพลาดในขั้นตอนการติดตั้ง นอกจากนี้การใช้งาน Custom Rom อาจทำให้ฟังก์ชันการใช้งานของซอฟต์แวร์ไม่สมบูรณ์หรือทำงานผิดไปจาก Rom ของผู้ผลิต และที่สำคัญ อุปกรณ์หลายรุ่นไม่สามารถติดตั้ง Custom Rom ได้เพราะไม่มีผู้พัฒนา Rom สำหรับอุปกรณ์ยี่ห้อหรือรุ่นนั้นๆ

การติดตั้งแอปพลิเคชันจาก Play Store เพียงอย่างเดียว ก็อาจจะช่วยลดความเสี่ยงได้ในระดับหนึ่ง แต่ก็เป็นเพียงการแก้ไขปัญหาที่ปลายเหตุ อีกทั้งผู้ใช้งานบางกลุ่มอาจมีความจำเป็นที่ต้องติดตั้งแอปพลิเคชันจากไฟล์ .apk เช่น แอปพลิเคชันที่ต้องการใช้งานไม่มีอยู่ใน Play Store (เช่นแอปพลิเคชันเฉพาะที่ใช้งานภายในองค์กร) ต้องการทดลองแอปพลิเคชันที่เป็นรุ่น Beta หรือบางทีแอปพลิเคชันที่มีการซื้อขายอย่างถูกลิขสิทธิ์ก็ได้มาเป็นไฟล์ .apk (เช่น เกมในชุด Humble Bundle for Android หรือซื้อจาก Store อื่นที่ไม่ใช่ Play Store) ซึ่งนั่นก็เป็นความเสี่ยงที่ผู้ใช้ต้องแบกรับจากการที่ใช้ระบบปฏิบัติการที่ไม่ได้รับการอัพเดต

ทาง Bluebox Security ได้ปล่อยให้ดาวน์โหลดแอปพลิเคชัน Bluebox Security Scanner ใน Play Store [17] เพื่อใช้ในการตรวจอุปกรณ์ที่ใช้งานอยู่ว่าได้มีการแพทช์ช่องโหว่แล้วหรือยัง และยังสามารถสแกนแอปพลิเคชันที่ติดตั้งอยู่ในเครื่องได้ว่ามีแอปพลิเคชันไหนที่เป็นมัลแวร์ที่โจมตีผ่านช่องโหว่นี้ ดังรูปที่ 5 ซึ่งผู้ใช้งานสามารถดาวน์โหลดมาตรวจสอบเครื่องของตัวเองได้ฟรี นอกจากนี้การติดตั้งซอฟต์แวร์แอนตี้ไวรัสก็อาจช่วยป้องกันได้ในระดับหนึ่ง

Bluebox Security Scanner

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

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

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

อ้างอิง

  1. http://bluebox.com/corporate-blog/bluebox-uncovers-android-master-key/
  2. http://developer.android.com/tools/publishing/app-signing.html
  3. http://nakedsecurity.sophos.com/2013/07/10/anatomy-of-a-security-hole-googles-android-master-key-debacle-explained/
  4. http://threatpost.com/second-android-master-key-attack-surfaces/101297
  5. http://blog.sina.com.cn/s/blog_be6dacae0101bksm.html
  6. https://www.thaicert.or.th/alerts/user/2013/al2013us008.html
  7. https://www.thaicert.or.th/alerts/user/2013/al2013us007.html
  8. http://www.zdnet.com/blog/security/a-first-hacked-sites-with-android-drive-by-download-malware/11810
  9. http://blog.avast.com/2013/03/11/mobile-drive-by-malware-example/
  10. http://www.exploit-db.com/exploits/15548/
  11. http://www.h-online.com/security/news/item/Android-smartphones-infected-via-drive-by-exploit-Update-1446992.html
  12. https://thaicert.or.th/papers/technical/2012/pa2012te009.html
  13. https://www.cio.com.au/article/466577/vulnerability_allows_attackers_modify_android_apps_without_breaking_their_signatures/
  14. http://www.androidpolice.com/2013/07/08/infamous-master-key-exploit-was-quietly-patched-by-google-in-february-cyanogenmod-following-suit-today-oems-at-some-point/
  15. http://www.theverge.com/2011/05/10/google-promises-android-devices-updates-18-months/
  16. http://www.cyanogenmod.org/blog/cyanogenmod-10-1-1-release/comment-page-1#comment-56919
  17. https://play.google.com/store/apps/details?id=com.bluebox.labs.onerootscanner
Clear