ทีมตอบสนองเหตุฉุกเฉินทางคอมพิวเตอร์ระดับชาติของญี่ปุ่น JPCERT/CC ได้เชื่อมโยงการเพิ่มขึ้นของการรั่วไหลของข้อมูลบนเว็บช่วงล่าสุดกับสาเหตุหลักสองประการ ได้แก่ การใช้ API ของแอปมือถือในทางที่ผิด และช่องโหว่ซอฟต์แวร์ที่รู้จักกันดี รวมถึงบั๊ก SQL injection ใน Metabase ที่ถูกโจมตี เรื่องนี้เป็นเครื่องเตือนใจที่มีประโยชน์ว่าการรั่วไหลของข้อมูลบนเว็บในญี่ปุ่นและจุดอ่อนของ API มือถือมักเป็นปัญหาในฝั่งเซิร์ฟเวอร์ ในระบบที่ผู้ใช้มองไม่เห็นหรือควบคุมไม่ได้

สิ่งที่ JPCERT/CC ค้นพบเบื้องหลังการรั่วไหลของข้อมูลในญี่ปุ่น

ตามรายงาน JPCERT/CC เชื่อมโยงการพุ่งขึ้นของการรั่วไหลของข้อมูลในญี่ปุ่นช่วงล่าสุดกับการใช้ API ของแอปพลิเคชันมือถือในทางที่ผิด และกับช่องโหว่ที่เปิดเผยต่อสาธารณะอยู่แล้ว หนึ่งในตัวอย่างที่ระบุชื่อคือช่องโหว่ SQL injection ใน Metabase ซึ่งผู้โจมตีได้ใช้ประโยชน์

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

SQL injection และ API มือถือที่เปิดเผยรั่วไหลข้อมูลส่วนบุคคลได้อย่างไร

คำศัพท์ทางเทคนิคสองคำขับเคลื่อนเรื่องนี้ ดังนั้นการนิยามให้ชัดเจนจึงมีประโยชน์

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

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

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

ผู้ใช้และบริการในญี่ปุ่นควรตรวจสอบอะไรตอนนี้

สำหรับองค์กร การเน้นย้ำของรายงานต่อช่องโหว่ที่รู้จักชี้ไปที่รายการตรวจสอบพื้นฐาน:

  • ยืนยันว่าการติดตั้ง Metabase ใดๆ ได้รับการอัปเดตเป็นเวอร์ชันที่แก้ไขบั๊ก SQL injection ที่ถูกโจมตี
  • ตรวจสอบ API ของแอปมือถือเพื่อให้แน่ใจว่าทุกคำขอได้รับการยืนยันตัวตน และผู้ใช้สามารถเรียกดูได้เฉพาะบันทึกของตนเอง
  • ปฏิบัติต่อช่องโหว่ที่เปิดเผยต่อสาธารณะเป็นเรื่องเร่งด่วน เนื่องจากผู้โจมตีกำลังใช้มันอยู่แล้ว

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

วิธีจำกัดความเสี่ยงของคุณหลังการรั่วไหล

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

สิ่งที่ช่วยได้คือการจำกัดความเสียหายเมื่อการรั่วไหลเกิดขึ้น:

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

สิ่งนี้หมายความว่าอย่างไรสำหรับคุณ

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

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

ประเด็นสำคัญ

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