พบแพ็กเกจ npm ชื่อ Lotusbail ที่ขโมยข้อความและรายชื่อติดต่อ WhatsApp

 (koi.ai)
1 คะแนน โดย GN⁺ 2025-12-24 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • แพ็กเกจ Lotusbail เป็นฟอร์กของไลบรารี WhatsApp Web API ที่ถูกต้องตามกฎหมายอย่าง Baileys และเป็น แพ็กเกจที่ฝังมัลแวร์ ซึ่งมียอดดาวน์โหลดบน npm มากกว่า 56,000 ครั้งตลอด 6 เดือน
  • มันให้ฟังก์ชัน API ที่ทำงานได้ตามปกติ ขณะเดียวกันก็ขโมย ข้อมูลยืนยันตัวตน WhatsApp, ข้อความ, รายชื่อติดต่อ, ไฟล์มีเดีย และส่งไปยังเซิร์ฟเวอร์ของผู้โจมตี
  • ข้อมูลถูกส่งผ่านกระบวนการเข้ารหัสและทำให้อ่านยากหลายชั้น เช่น RSA, AES, Base-91, LZString ทำให้ หลบเลี่ยงการเฝ้าระวังด้านความปลอดภัย ได้
  • แพ็กเกจนี้ติดตั้ง แบ็กดอร์ ที่เชื่อมอุปกรณ์ของผู้โจมตีเข้ากับบัญชี WhatsApp ของผู้ใช้แบบถาวรผ่าน pairing code ที่ฮาร์ดโค้ดไว้
  • กรณีนี้แสดงให้เห็นถึง ความซับซ้อนที่เพิ่มขึ้นของการโจมตีซัพพลายเชน และตอกย้ำ ความจำเป็นของการเฝ้าระวังความปลอดภัยแบบอิงพฤติกรรม ซึ่งการวิเคราะห์แบบสแตติกเพียงอย่างเดียวไม่สามารถตรวจจับได้

ภาพรวมของแพ็กเกจ Lotusbail

  • lotusbail เป็นฟอร์กของ @whiskeysockets/baileys ที่ถูกต้องตามกฎหมาย และให้ความสามารถของ WhatsApp Web API ได้เหมือนเดิม
    • การรับส่งข้อความทำงานได้ปกติ ทำให้นักพัฒนามีโอกาสติดตั้งโดยไม่สงสัย
    • แพ็กเกจนี้ถูกเผยแพร่บน npm มาเป็นเวลา 6 เดือน และ ณ เวลาที่เขียนยังคงสามารถดาวน์โหลดได้
  • เบื้องหลังฟังก์ชันจริงมีพฤติกรรมอันตรายซ่อนอยู่ เช่น การขโมยข้อมูลรับรอง WhatsApp, การดักข้อความ, การเก็บรายชื่อติดต่อ, การติดตั้งแบ็กดอร์

ข้อมูลที่ถูกขโมย

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

วิธีการทำงาน

ฟังก์ชันบังหน้าที่ใช้งานได้จริง

  • โดยทั่วไปแพ็กเกจ npm ที่เป็นอันตรายมักทำงานผิดปกติหรือมีโค้ดน่าสงสัยจนระบุได้ง่าย แต่ Lotusbail ปลอมตัวเป็น API ที่ทำงานได้ตามปกติ
  • มันอิงจากไลบรารี Baileys ที่ถูกต้องตามกฎหมาย และ มีการติดตั้งฟังก์ชันรับส่งข้อความอย่างครบถ้วน
  • ด้วยเหตุนี้จึงมีการใช้ เทคนิควิศวกรรมสังคม ที่ทำให้นักพัฒนาไม่สงสัยพฤติกรรมอันตรายใน “โค้ดที่ทำงานได้ปกติ”

การขโมยและส่งออกข้อมูล

  • แพ็กเกจนี้ทำงานในลักษณะครอบ WebSocket client ที่ใช้สื่อสารกับ WhatsApp
    • ระหว่างการยืนยันตัวตนจะดักจับข้อมูลรับรอง และเมื่อมีการรับหรือส่งข้อความก็จะคัดลอกเนื้อหาทั้งหมด
    • ฟังก์ชันปกติยังคงทำงานเหมือนเดิม เพียงแต่ข้อมูลทั้งหมดถูก ส่งซ้ำไปยังผู้โจมตี
  • ข้อมูลที่ขโมยถูกส่งออกโดยเข้ารหัสด้วย การติดตั้ง RSA แบบกำหนดเอง
    • มันแยกต่างหากจากการเข้ารหัสแบบ end-to-end ของ WhatsApp และถูกใช้เป็น การเข้ารหัสเพื่อหลบเลี่ยงการเฝ้าระวังเครือข่าย
  • ที่อยู่เซิร์ฟเวอร์ไม่ได้แสดงตรง ๆ ในโค้ด แต่ถูกซ่อนอยู่ใน สตริงการตั้งค่าที่เข้ารหัส
    • มีการทำให้อ่านยาก 4 ชั้น ได้แก่ การจัดการตัวแปร Unicode, การบีบอัดด้วย LZString, การเข้ารหัส Base-91, การเข้ารหัส AES

การติดตั้งแบ็กดอร์

  • มีการนำฟีเจอร์ device pairing code ของ WhatsApp มาใช้ในทางที่ผิดเพื่อเชื่อมอุปกรณ์ของผู้โจมตีกับบัญชีของผู้ใช้
    • ภายในแพ็กเกจมี pairing code ที่ฮาร์ดโค้ดไว้และเข้ารหัสด้วย AES
    • เมื่อผู้ใช้ทำการยืนยันตัวตน อุปกรณ์ของผู้โจมตีก็จะถูกเชื่อมต่อพร้อมกัน ทำให้ได้ สิทธิ์เข้าถึงบัญชีอย่างต่อเนื่อง
  • ผู้โจมตีสามารถ ควบคุมบัญชีทั้งหมด ได้ เช่น อ่านข้อความ ส่งข้อความ ดาวน์โหลดสื่อ และเข้าถึงรายชื่อติดต่อ
  • แม้จะลบแพ็กเกจ npm ออกแล้ว อุปกรณ์ของผู้โจมตีก็ยังคงเชื่อมต่ออยู่ และจะบล็อกได้ก็ต่อเมื่อ ยกเลิกการเชื่อมต่ออุปกรณ์ทั้งหมดจากการตั้งค่า WhatsApp ด้วยตนเอง

เทคนิคการหลบเลี่ยงการวิเคราะห์

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

บทสรุปและนัยสำคัญด้านความปลอดภัย

  • การโจมตีซัพพลายเชนกำลังมีความซับซ้อนมากขึ้น และกรณีที่ปลอมตัวเป็นโค้ดที่ทำงานปกติก็กำลังเพิ่มขึ้น
  • การตรวจสอบด้วย การวิเคราะห์แบบสแตติกและการตรวจสอบตามชื่อเสียง เพียงอย่างเดียวตรวจจับได้ยาก และจำเป็นต้องมี การวิเคราะห์พฤติกรรมระหว่างรันไทม์ (behavioral analysis)
  • กรณี Lotusbail เป็นตัวอย่างของการฉวยช่องโหว่ด้านความปลอดภัยจากความเชื่อว่า “โค้ดที่ทำงานได้ย่อมปลอดภัย” และแสดงให้เห็นถึง ความสำคัญของการสร้างระบบเฝ้าระวังพฤติกรรมขณะรันไทม์
  • ทีมวิจัย Koi Security ระบุภัยคุกคามที่เล็ดรอดจากกระบวนการตรวจสอบแบบเดิมได้ด้วยเทคนิคการตรวจจับที่อิงรันไทม์ดังกล่าว

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2025-12-24
ความคิดเห็นจาก Hacker News

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

    • เห็นด้วย และขอเสริมว่าแพ็กเกจนี้ไม่ใช่ wrapper ของ WhatsApp API ทางการ แต่เป็น WhatsApp Web client ที่ถูก reverse engineer
      ผู้ใช้เข้าถึงในลักษณะเดียวกับการเชื่อมต่อไคลเอนต์อีกตัวเข้ากับบัญชี WhatsApp ของตน จึงทำให้เข้าถึงข้อมูลทั้งหมดได้
      ถ้า WhatsApp มี API ทางการ ที่เหมาะสม เรื่องแบบนี้ก็น่าจะเกิดน้อยลง
      เอกสารที่เกี่ยวข้อง: Baileys Wiki
    • คิดว่า OS ควรเป็นตัวกลางจัดการการเข้าถึงข้อมูลระหว่างแอป และต้องให้แอป ขอสิทธิ์การใช้งาน จากผู้ใช้อย่างชัดเจน
    • มองว่าเหตุผลที่ WhatsApp ตั้งข้อจำกัดแบบนี้ไม่ใช่เพราะ ความปลอดภัย แต่เพื่อจำกัดการแข่งขัน
    • การล็อกแอปสุดท้ายแล้วก็เป็นเครื่องมือให้บริษัทได้ อำนาจควบคุมและรายได้ มากขึ้น
      สมัยก่อนมัลแวร์มีมากก็จริง แต่ก็มีอิสระและการทำงานร่วมกันได้มากกว่านี้ด้วย
    • มี การ์ตูน xkcd ที่เสียดสีสถานการณ์นี้ได้ดีมาก

  • การโจมตีแบบนี้ตอนนี้ถือเป็น ผลลัพธ์ที่คาดเดาได้ แล้ว
    package manager อย่าง NPM มีโครงสร้างที่ดึง dependency มาก่อน build ทันที จึง เปราะบางโดยพื้นฐาน
    ปัญหาคือวัฒนธรรมที่ข้ามระบบควบคุมเวอร์ชันไป แล้วรับ dependency จำนวนมากเข้ามาโดยแทบไม่ตรวจสอบ

    • ยิ่งทำยิ่งตระหนักว่า พวกเรานักพัฒนา อ่อนแอเรื่องความปลอดภัยมากจริงๆ
      ไม่ใช่แค่ NPM แต่ Cargo, Docker, CI/CD และ ecosystem อื่นๆ ก็มีปัญหาคล้ายกัน
      โครงสร้างแบบ “ติดตั้งตามชื่อแล้วจบ” ทำให้ต้องพึ่งพาความเชื่อใจมากเกินไป
      ก็ยังไม่มีทางออกที่ชัดเจน — จะเลิกทำงานร่วมกันก็ไม่ได้ และจะให้ปลอดภัยสมบูรณ์ก็เป็นไปไม่ได้
      สุดท้าย สัตว์ประหลาดมันเข้ามาอยู่ในบ้านแล้ว
    • เห็นด้วย แต่ปัญหานี้ไม่ได้มีแค่กับ package manager
      ต่อให้ระบุ git URL โดยตรง ผลลัพธ์ก็คงไม่ต่างกัน
      ท้ายที่สุดมันคือ ปัญหาเชิงโครงสร้างของการจัดการ dependency
    • แต่ละแพลตฟอร์มมี package manager มากเกินไป
      รู้สึกว่าควรมี package manager มาตรฐาน ที่ไม่ผูกกับภาษาใดภาษาหนึ่ง
      และต้องมีความสามารถอย่างการตรวจสอบลายเซ็น การรับประกันแหล่งที่มา และมาตรฐาน API
    • package manager ระดับระบบอย่าง apt หรือ rpm ก็ไม่ได้สมบูรณ์แบบ
      อย่างกรณี xz ก็มี แพ็กเกจที่ติดเชื้อ ถูกปล่อยออกไปตรงๆ
      แถม package manager ระดับระบบยังรองรับเวอร์ชันใหม่ช้าเกินไปจนไม่เหมาะกับงานพัฒนา
      นี่จึงเป็นเหตุผลว่าทำไมยังต้องมีเครื่องมืออย่าง npm, cargo และ pip
    • นี่ไม่ใช่กรณี dependency ถูกฝังสิ่งไม่พึงประสงค์ แต่เป็น แพ็กเกจอันตรายมาตั้งแต่แรก
      มันไม่ใช่ปัญหาของ package manager แต่เป็นโค้ดที่ไม่น่าเชื่อถือตั้งแต่ต้น

  • ตลกดีที่คนเขียนมัลแวร์ตั้งชื่อฟังก์ชันแบบ exfiltrateCredentials ตรงไปตรงมามาก
    ใส่ระบบตรวจจับ debugger มาแล้วแท้ๆ แต่กลับไม่ทำ obfuscation ของโค้ด เป็นความย้อนแย้งดี

    • จริงๆ แล้วโค้ดถูก obfuscate มา และผู้เขียนบทความเพียงเผยแพร่ เวอร์ชันที่กู้คืนเพื่อใช้สาธิต
    • ถ้าจะทดสอบ debugging trap 27 แบบ ก็คงต้องมี test coverage พอสมควร
      ยุคนี้แม้แต่การทดสอบมัลแวร์ก็กลายเป็นรูปแบบหนึ่งของงานพัฒนาไปแล้ว

  • คำว่า “dependency ที่นักพัฒนาติดตั้งโดยไม่คิดอะไร” ฟังแล้ว น่าขนลุก

    • นักพัฒนาส่วนใหญ่ก็รัน npm install กันตรงๆ
      ถ้าไม่ใช่องค์กรที่มี นโยบายความปลอดภัยเข้มงวด ก็แทบจะป้องกันได้ยากในทางปฏิบัติ
      สุดท้ายทางแก้อาจเป็นแค่ใช้ npm ให้น้อยลง
    • Docker image ก็ไม่ต่างกัน
      ถ้าระบุแบบอิงแท็ก ก็พร้อมเปิดช่องให้ การโจมตีซัพพลายเชน ได้ตลอด
      อุตสาหกรรมนี้ทำงานอยู่บน ความเชื่อใจแบบมองไม่เห็น มากกว่าที่คิดมาก
      ระบบ deploy อัตโนมัติไม่มีเวลาจะ “คิดอีกครั้ง” ด้วยซ้ำ
    • น่ากลัว แต่สำหรับนักพัฒนาส่วนใหญ่ มันคือ ความจริงของโลกนี้
    • มองว่าก็มี การพูดเกินจริง ปะปนอยู่บ้าง

  • อยากให้ JavaScript มีไลบรารีใหญ่ที่เชื่อถือได้แบบ Apache Commons
    แนะนำ Apache Commons

    • แต่ถึงจะเป็นไลบรารีใหญ่แค่ไหน ก็คงไม่รวม WhatsApp API ไว้อยู่ดี

  • แพ็กเกจ lotusbail เป็นแพ็กเกจ npm อันตรายที่ปลอมตัวเป็น WhatsApp Web API
    มันถูกเผยแพร่อยู่ 6 เดือน และทำการโจมตีหลายแบบ เช่น ขโมยข้อมูลรับรอง ดักข้อความ และติดตั้ง backdoor

  • นักพัฒนาที่ต้องพึ่งพา ecosystem ของ JS ในโลกจริงจำเป็นต้องมี กลยุทธ์ลดความเสี่ยง
    มีการพูดถึงการใช้ Docker หรือ VM เป็นวิธีหนึ่ง

    • ที่ทำงานก่อนหน้านี้ฉันดูแลทั้ง DevOps และความปลอดภัย
      เรา ทำทุกสภาพแวดล้อมพัฒนาให้เป็นคอนเทนเนอร์ และล็อก dependency ไว้ที่เวอร์ชันคงที่
      ห้ามติดตั้งแบบ global ห้ามอัปเดตอัตโนมัติ และต้องตรวจสอบด้วยตนเองเสมอ
      โปรเจกต์ที่อ่อนไหวจะให้ใช้ เวิร์กสเตชันเฉพาะทาง และรีเซ็ตเป็นระยะ
      มันน่ารำคาญ แต่ก็คือความปลอดภัยที่ทำได้จริง
      ไม่อย่างนั้นก็อาจต้องออกจาก ecosystem ของ JS ไปเลย
    • แต่กรณีนี้ผู้ใช้ ตั้งใจติดตั้งแพ็กเกจนั้นเอง จึงยากที่จะป้องกันด้วยมาตรการแบบนี้
      ควรมีความสามารถในระดับ OS หรือ Docker ที่ให้ ยืนยันการอนุญาตการเชื่อมต่อเครือข่าย ได้
    • ฉันใช้ Incus OS แล้วสร้างคอนเทนเนอร์ใหม่แยกตามแต่ละโปรเจกต์เพื่อพัฒนา
      แม้จะแชร์เคอร์เนลกัน แต่ก็เพียงพอสำหรับป้องกันการโจมตีจาก ecosystem ของ JS
      ถ้าวันไหนมีการโจมตีหนีออกจากคอนเทนเนอร์ผ่าน npm ค่อยย้ายไปใช้ VM
      ตอนแรกคิดว่าเป็นมาตรการเกินจำเป็น แต่ตอนนี้รู้สึกว่า เร็วและเสถียร มาก
    • ถ้าแจกจ่ายแพ็กเกจแบบนี้ ความเสี่ยงจะไม่หยุดแค่กับนักพัฒนา แต่ แพร่ไปถึงผู้ใช้ทุกคน ด้วย
    • บางบริษัทอนุญาตเฉพาะแพ็กเกจ npm ที่ มีอายุหลายเดือนขึ้นไป
      เพราะในช่วงเวลานั้นความเป็นอันตรายมักจะถูกเปิดเผยออกมาแล้ว

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

    • จริงๆ แล้ว WhatsApp ไม่มี API สาธารณะ
      ต้องลงทะเบียนกับ “WhatsApp Business Platform” เท่านั้นถึงจะเข้าถึง API ได้
      ถ้ามี API จริงๆ เรื่องแบบนี้ก็คงไม่เกิด
    • ถ้า API ทางการมีฟังก์ชันไม่พอ การ ทำขึ้นใหม่เอง ก็ไม่ใช่ปัญหาในตัวมันเอง
      แต่การส่งคีย์ลับตอนยืนยันตัวตนให้บุคคลที่สามนั้นอันตราย
      ปกติแล้วคนก็ติดตั้งแพ็กเกจแบบนี้เพื่อทำระบบอัตโนมัติกับบัญชีของตัวเอง

  • ทุกวันนี้มี บทความบล็อกจาก LLM ล้นไปหมด
    คุณภาพต่ำแต่ต้นทุนเป็นศูนย์ จึงคุ้มสำหรับนักการตลาด
    การเขียนแบบดั้งเดิมตอนนี้กลายเป็น ของเก่าแบบ legacy ไปแล้ว

    • แต่ก็น่าขำที่แม้แต่คอมเมนต์นี้ยัง ดูเหมือน LLM เขียน เลย

  • ดูเหมือนว่า การโจมตีซัพพลายเชน จะเพิ่มขึ้น นักพัฒนาควรรับมืออย่างไร?

    • ถ้าจะลดความเสี่ยง ต้อง เลิกใช้แพ็กเกจสุ่มๆ และในระดับรากฐานคือควรถอยออกจาก ecosystem อย่าง npm
    • แพ็กเกจที่มี URL เซิร์ฟเวอร์แบบ obfuscate หรือเข้ารหัส ถือเป็นสัญญาณเตือน
      ควรใช้การสแกนอัตโนมัติเพื่อตรวจจับรูปแบบนี้ และเพิ่มความเข้มงวดของกระบวนการตรวจสอบ
    • ควรกลับไปทำแบบปี 1999 คือ ตรวจสอบ dependency เองแล้ว vendor เข้ามาใช้
    • ทุกวันนี้ dependency เยอะเกินไป และแทบไม่มีใครอ่านโค้ด
      การทำคอนเทนเนอร์ การล็อก dependency การสแกนความปลอดภัย และการอัปเดตแบบหน่วงเวลาเป็นสิ่งจำเป็น
      การติดตั้ง npm แบบ global คือทางเลือกที่แย่ที่สุด
    • ถ้าจำเป็นต้องรันจริงๆ ก็ควรทำใน สภาพแวดล้อมที่แยกออกมาให้มากที่สุด
      ใช้คอนเทนเนอร์อย่าง rootless podman หรือ VM เพื่อลดความเสี่ยงให้มากที่สุด