กล้องรักษาความปลอดภัย Hanwha Vision ถูกจัดส่งพร้อม GitHub admin token อยู่ในหน้าเข้าสู่ระบบเว็บ UI

 (hhh.hn)
1 คะแนน โดย GN⁺ 2 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • พบ GitHub token เดียวกันอยู่ในไฟล์เว็บ UI สำหรับจัดการของเฟิร์มแวร์กล้อง Hanwha Vision ราว 30 ไฟล์ และโทเค็นนี้มีสิทธิ์ผู้ดูแลระบบเหนือรีโพซิทอรีหลายร้อยแห่งในองค์กร
  • fwupgrader ของเฟิร์มแวร์กู้คืนคีย์ AES ด้วยการ XOR กับตารางคงที่ที่ฮาร์ดโค้ดไว้ แล้วใช้ openssl ถอดรหัส root file system โดย คีย์และ IV ถูกใช้ร่วมกันในกลุ่มรุ่นเดียวกัน
  • เนื่องจากตัวแปรสำหรับการ build ของ Vite ถูกตั้งให้เป็น process.env ทั้งหมด ตัวแปรสภาพแวดล้อมของงาน CI จึงถูกบันทึกลงในผลลัพธ์ และทำให้ GITHUB_NPM_TOKEN รวมถึงการตั้งค่าภายในหลายรายการถูกฝังอยู่ในเฟิร์มแวร์กล้อง
  • มีการตรวจสอบเฟิร์มแวร์ประมาณ 500 รายการด้วยวิธีเดียวกันและ แตกไฟล์ได้ 62% โดยเฟิร์มแวร์ 3 รายการที่พบ GitHub token ล้วนมีโทเค็นเดียวกันทั้งหมด
  • Hanwha เพิกถอนโทเค็นภายใน 12 ชั่วโมงหลังได้รับรายงาน แต่การตั้งค่าที่ฝัง CI environment ทั้งหมดลงใน client artifact แบบนี้อาจเปิดเผยข้อมูลรับรองและข้อมูลโครงสร้างพื้นฐานภายในออกไปในตัวผลิตภัณฑ์

การได้มาของเฟิร์มแวร์และชั้นการเข้ารหัสแรก

  • เว็บไซต์ Hanwha Vision เผยแพร่ firmware image แยกตามรุ่นกล้อง ทำให้สามารถดาวน์โหลดไฟล์มาวิเคราะห์ได้
  • เมื่อตรวจสอบ image ด้วย binwalk ก็พบ tarball แยกต่างหากที่บรรจุองค์ประกอบ AI สำหรับกล้อง และ fwimage.tgz ที่ถูกเข้ารหัส
  • ตามการวิเคราะห์การถอดรหัสเฟิร์มแวร์ Hanwha ของ Matt Brown มีการใช้รหัสผ่านที่ประกอบจาก HTW และหมายเลขรุ่น
    • ในตัวอย่างที่วิเคราะห์ HTWXNP-9300RW ใช้งานได้
  • ภายใน tarball ที่คลายออกมาแล้ว ยังมี fwimage.tgz อีกไฟล์ที่ถูกเข้ารหัสด้วยวิธีอื่น จึงไม่สามารถใช้ขั้นตอนถอดรหัสเดิมซ้ำได้ตรง ๆ

กู้คืนวิธีถอดรหัสจาก fwupgrader

  • มีการวิเคราะห์ไบนารี fwupgrader ที่อยู่ใน tarball ภายนอกด้วย Ghidra และ Claude Code เพื่อดึง root file system จริงออกมา
  • fwupgrader มีการทำ obfuscation เพื่อซ่อนวิธีถอดรหัส
    • คีย์ AES ถูกประกอบขึ้นระหว่างรันไทม์หลัง XOR กับตารางคีย์คงที่ขนาดเล็กภายในไบนารี
    • IV อยู่ในไบนารีแบบข้อความปกติ
    • ชิ้นส่วนคำสั่ง openssl ก็ถูกทำ XOR obfuscation แบบเดียวกัน
  • คำสั่งที่กู้คืนได้มีรูปแบบดังนี้ โดยใช้ SHA-256 และ AES-256-CBC 
    openssl enc -md sha256 -aes-256-cbc -d \  
  -K <KEY> -iv <IV> -in <INPUT> -out <OUTPUT>
  • คีย์และ IV ถูกฮาร์ดโค้ดไว้และใช้ร่วมกันในกลุ่มรุ่นเดียวกัน 
    KEY = dfa049bb922e63e2decc764af5628068e5b7a2662e479a615b14643e567579b0  
IV  = 53f926801b81454a4f889c9a390db6e6

GitHub admin token ที่อยู่ในเฟิร์มแวร์

  • เมื่อตรวจสอบ root file system ที่แตกออกมาด้วย trufflehog ก็พบ GitHub token เดียวกันซ้ำอยู่ในไฟล์ประมาณ 30 ไฟล์
  • โทเค็นนี้มีสิทธิ์ผู้ดูแลระบบต่อรีโพซิทอรีหลายร้อยแห่งใน GitHub organization ของ Hanwha
  • UI ของกล้องถูก build ด้วย Vite และพบว่าตัวแปร build ตัวหนึ่งถูกตั้งให้รับ process.env ทั้งหมด ส่งผลให้ environment ทั้งชุดของงาน CI ถูกบันทึกลงในไฟล์ผลลัพธ์ 
    var W = {  
  DATAPORT: "9090",  
  GIT_LFS_SKIP_SMUDGE: "1",  
  npm_command: "run-script",  
  KUBERNETES_SERVICE_PORT_HTTPS: "443",  
  GITHUB_NPM_TOKEN: "<snip>:ghp_…REDACTED…",  
  npm_config_userconfig: "/home/docker/.npmrc",  
  // etc  
}
  • เนื่องจากไม่มีตัวกล้องจริง จึงไม่สามารถยืนยันการทำงานได้
    • มีความเป็นไปได้ว่าโทเค็นถูกส่งผ่านเครือข่ายไปยังผู้ใช้ที่เข้าถึง UI สำหรับผู้ดูแลระบบ
    • หรืออาจเป็นไปได้ว่าไฟล์มีอยู่เพียงบนดิสก์และไม่ได้ถูกเสิร์ฟใช้งานจริง

ที่อยู่ DoD ที่อยู่ใน CI environment

  • ใน environment variables ที่รั่วไหลออกมายังมี IP address ที่ถูกจัดสรรให้กระทรวงกลาโหมสหรัฐฯ รวมอยู่ด้วย
  • ยังไม่ชัดเจนว่าที่อยู่เหล่านี้ถูกนำมาใช้แบบตามสะดวกสำหรับบริการภายในที่ไม่สื่อสารกับภายนอก หรือเกี่ยวข้องกับความสัมพันธ์ระหว่าง Hanwha กับกระทรวงกลาโหมสหรัฐฯ
  • Hanwha Vision เป็นบริษัทด้านวิดีโอเฝ้าระวังที่ก่อตั้งในชื่อ Samsung Techwin และเป็นบริษัทย่อยของ Hanwha Group
    • ผลิตภัณฑ์ในอดีตมีทั้งปืนใหญ่อัตตาจร K9 Thunder, รถเกราะลำเลียงกระสุน K10, ระบบย่อยของ K2 Black Panther และหุ่นยนต์เฝ้าระวัง SGR-A1
    • SGR-A1 เป็นหุ่นยนต์เฝ้าระวังติดอาวุธ
  • เป็นไปได้ว่า CI ถูกจัดให้โดยองค์กรส่วนกลางของ Hanwha และมีการแชร์ตัวแปรที่เกี่ยวข้องตามความต้องการของบริษัทในเครืออย่าง Hanwha Aerospace หรือ Hanwha Defense USA แต่สิ่งนี้ยังเป็นเพียงข้อสันนิษฐานที่ไม่ได้รับการยืนยัน

การตรวจสอบเฟิร์มแวร์ทั้งหมด

  • เพื่อดูว่านี่เป็นเพียงกรณีเดี่ยวที่เกิดขึ้นโดยบังเอิญ หรือยังมีโทเค็นอื่นอีกหรือไม่ จึงมีการรวบรวมเฟิร์มแวร์กล้องที่ดาวน์โหลดได้จากเว็บไซต์ Hanwha
  • จากกล้องประมาณ 600 รุ่น มีการเก็บ เฟิร์มแวร์ราว 500 รายการ สำหรับรุ่นที่มีการเผยแพร่เฟิร์มแวร์
  • ด้วยวิธีเดียวกันนี้ สามารถแตกไฟล์ได้ 62% และยังไม่ทราบสาเหตุที่เหลือล้มเหลว
  • เฟิร์มแวร์ที่มี GitHub token อยู่มี 3 รายการ และทั้งหมดมี โทเค็นเดียวกัน

การรายงานและการตอบสนอง

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

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

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

 
GN⁺ 2 시간 전
ความคิดเห็นจาก Hacker News

  • กำลังมองหากล้อง white-label IP camera หรือผลิตภัณฑ์แบบเกือบ plug-and-play ที่ผู้ผลิตยังซัพพอร์ตอยู่ แต่สามารถถอด rootfs ออกได้เมื่อจำเป็น
    เมื่อก่อนมีแต่ dev kit ราคาแพงที่ไม่มีแม้แต่เคส แต่ตอนนี้ดูเหมือนจะมีตัวเลือกอย่าง GoodCam

    • ถึงจะไม่ใช่เฟิร์มแวร์แบบเปิด แต่ถ้าใช้ ONVIF บนเครือข่ายที่แยกออกมาก็ใกล้เคียงมาก
      กล้อง ONVIF ใช้ร่วมกับ network video recorder (NVR) ได้แทบทั้งหมด และก็มี NVR โอเพนซอร์สอยู่หลายตัว
      ถ้าไม่เปิดให้กล้อง PoE ราคาถูกออกสู่อินเทอร์เน็ตโดยตรง ความปลอดภัยของเฟิร์มแวร์จากผู้ผลิตก็สำคัญน้อยลง แต่ต้องจัด VLAN และการแยกเครือข่ายให้รัดกุมมาก
    • สร้าง Wyrecam ขึ้นมาเพื่อแก้ปัญหานี้ และรองรับ Ingenic T31 ของ Wyze v3
      ความเสถียรพอๆ กับ Apple HomeKit ซึ่งก็ไม่ได้ยอดเยี่ยมนัก
    • Thingino มีรายชื่อกล้องที่รองรับชัดเจน และถ้าเป็นรุ่นที่รองรับ การแฟลช SD card การติดตั้งก็ง่าย
      อัปเกรด Sonoff Slim Gen2 สองตัวได้โดยไม่มีปัญหา
    • กล้องบางรุ่นสามารถแทนที่เฟิร์มแวร์เดิมด้วย Thingino ได้ และ รายการฮาร์ดแวร์ที่ OpenIPC รองรับ ก็น่าดูเช่นกัน
    • หน้าร้านเหมือนจะใช้งานไม่ได้ โดยขึ้นข้อผิดพลาด Stránka nenalezena, There's been a glitch...

  • ดูเหมือนว่าปัญหาที่ใหญ่กว่าคือมี ที่อยู่ IP ของกระทรวงกลาโหมสหรัฐฯ ฝังอยู่ในเฟิร์มแวร์ ทำให้รู้สึกว่าอยากหลีกเลี่ยงผลิตภัณฑ์รักษาความปลอดภัยจากเกาหลี

    • บางบริษัทก็ blackhole ช่วง IP ทั้งหมดของกระทรวงกลาโหมสหรัฐฯ แล้วใช้เป็นที่อยู่ภายใน ดังนั้นอาจเป็นกรณีนั้น แต่ก็ยังแปลกมากอยู่ดี
    • ดูเหมือนกองทัพเรือแคนาดาก็เพิ่งตัดสินใจคล้ายกันในโครงการใหญ่: ผลการค้นหา
    • กระทรวงกลาโหมสหรัฐฯ มี พื้นที่ที่อยู่ IP มากมหาศาล จึงมีโอกาสพอสมควรที่จะชนกันโดยบังเอิญ
    • ผลิตภัณฑ์ IoT จากเกาหลีก็เหมือนกัน และแนวทางด้านความปลอดภัยของสินค้าที่เคยจับมานั้นอยู่ในระดับเหลือเชื่อ
    • ผลิตภัณฑ์ในประเทศตัวเองก็มักเละเทะจากช่องโหว่ด้านความปลอดภัยและวิศวกรรมที่หละหลวมเหมือนกัน

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

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

  • ขั้นต่ำที่สุดคือต้องแยกกล้องไปไว้ใน VLAN แยกต่างหาก และบล็อกการเข้าถึงอินเทอร์เน็ตของ VLAN นั้นทั้งหมด

  • เคยตรวจดูแล้วพบว่า OBD-II dongle หลายตัวถูกส่งมาพร้อม MAC address เดียวกัน และผลคือสามารถเข้าถึงข้อมูลทั้งหมดของหลายเว็บไซต์ได้
    ปัญหาแบบนี้ต่อให้อยากเลี่ยงก็ยังเกิดขึ้นเรื่อยๆ

    • สงสัยว่า MAC address เดียวกันนำไปสู่สิทธิ์เข้าถึงทั้งหมดได้อย่างไร
      ถ้าเว็บไซต์ใช้ MAC address ที่ไคลเอนต์ส่งมาเป็นวิธียืนยันตัวตน นั่นก็คือความล้มเหลวด้านความปลอดภัยของ IoT แบบคลาสสิก

  • น่าจะเอาคำว่า security ออกจากชื่อสินค้าแล้วเรียกมันว่ากล้องเฉยๆ จะดีกว่า

  • รำคาญที่บล็อกนี้ใช้ ไอคอนลิงก์ภายนอก ผิด

    • ตัวเลือก a[href*="://"]::after ตั้งสมมติฐานว่าลิงก์ภายในเป็น path แบบ relative เช่น href="/about" แต่เว็บไซต์นี้ใช้ absolute URL อย่าง [https://hhh.hn/about](https://hhh.hn/about) แม้แต่กับลิงก์นำทาง เลยทำให้ทุกลิงก์มีไอคอนติดหมด
      แก้ได้โดยยกเว้นลิงก์ที่ขึ้นต้นด้วยที่อยู่ของเว็บไซต์: a[href*="://"]:not([href^="https://hhh.hn";])::after

  • ไฟตกแต่งภายในที่เพิ่งซื้อมาไม่นานนี้ควบคุมไม่ได้เลยถ้าไม่มีแอปเฉพาะ
    ลองดึง APK จาก Google Store มาวิเคราะห์ดู พบว่ามี API key ของ backend และ Shopify เป็นต้น ใส่มาแทบครบ แต่ยังไม่ได้ลองเอาไปทำอะไร

    • public key มักไม่ได้ให้สิทธิ์เข้าถึงพิเศษอะไร
      ถ้าเป็นนักพัฒนาที่ใส่ใจความปลอดภัย ก็น่าจะใช้ App Attest หรือฟังก์ชันเทียบเท่าของ Google Store
    • นึกเหตุผลที่สมเหตุสมผลไม่ออกเลยว่าทำไมแอปไฟต้องมี สิทธิ์เข้าถึง Shopify API
      แต่ในฐานะคนที่เคยให้คำปรึกษาร้านค้า Shopify ก็ไม่แปลกใจ เพราะคุณภาพโค้ดจากที่ปรึกษาหรือนักออกแบบราคาถูกมักย่ำแย่มาก
    • เพื่อความปลอดภัย ควรซื้ออุปกรณ์สมาร์ตที่ ควบคุมภายในเครื่องได้ อย่าง Zigbee หรือ Z-Wave เท่านั้น แม้จะไม่ใช่ตัวเลือกที่ดีที่สุดเสมอไปในแง่หน้าตา
    • ถ้าเปิดเผยข้อมูลพวกนี้ออกไป ผู้ขายอาจตอบโต้ทางกฎหมายได้เลยจึงเสี่ยงมาก
      เคยมีบริษัทที่ช่วยคุ้มครองนักวิจัยจากผลทางกฎหมาย แต่จำชื่อไม่ได้
    • สุดท้ายแล้วก็ควบคุมได้โดยไม่ต้องใช้แอปเฉพาะ หวังว่าจะมีการ reverse engineer โปรโตคอลแล้วเผยแพร่วิธีทำ

  • เพราะ LLM ทำให้ code obfuscation แทบหมดความหมายไปแล้ว
    การทำให้โค้ดอ่านยากเดิมทีแค่ทำให้งานน่าเบื่อขึ้นเพื่อขัดขวาง แต่ AI ไม่ได้เดือดร้อนกับความพยายามแบบนั้น

    • การทำให้โค้ดอ่านยากมีผลแค่กับผู้โจมตีระดับตื้นๆ ที่ทนความน่าเบื่อไม่ได้
      ส่วนหน่วยงานระดับรัฐหรือกลุ่มแฮ็กเกอร์อาชญากรก็พร้อมรับภาระนั้นอยู่แล้ว
    • ถ้ามองในแง่ดี แม้แต่ local LLM ตัวเล็กๆ ก็ช่วยปรับปรุง โค้ดคุณภาพต่ำ แบบนี้ได้ง่าย

  • เคยเห็นระบบแบบนี้ใน งานแสดงอุตสาหกรรมป้องกันประเทศของสหรัฐฯ จึงมีโอกาสสูงว่ามันถูกใช้งานจริงอยู่ที่ไหนสักแห่ง