TP-Link Tapo C200: khóa hardcode, tràn bộ đệm và quyền riêng tư trong kỷ nguyên reverse engineering dựa trên AI

 (evilsocket.net)
1 điểm bởi GN⁺ 2025-12-21 | 1 bình luận | Chia sẻ qua WhatsApp
  • Kết quả phân tích firmware của camera IP TP-Link Tapo C200 giá rẻ bằng reverse engineering dựa trên AI cho thấy nhiều lỗ hổng bảo mật đã được phát hiện
  • Firmware chứa khóa riêng SSL được hardcode, cho phép giải mã lưu lượng HTTPS trong cùng một mạng
  • Trong quá trình phân tích, các công cụ AI (Grok, GhidraMCP, Cline, v.v.) đã được dùng để tự động hóa việc nắm bắt cấu trúc firmware và phân tích ý nghĩa của các hàm
  • Các lỗ hổng chính được phát hiện gồm tràn bộ đệm (CVE-2025-8065), tràn số nguyên (CVE-2025-14299), chiếm quyền WiFi (CVE-2025-14300), v.v.; một số có thể bị tấn công từ xa mà không cần xác thực
  • Trường hợp này được đánh giá là ví dụ cho thấy AI vừa nâng cao hiệu quả nghiên cứu bảo mật, vừa phơi bày các điểm yếu mang tính cấu trúc của thiết bị IoT

Thu thập và giải mã firmware

  • Reverse engineering ứng dụng Tapo trên Android để phát hiện bucket S3 công khai của TP-Link, từ đó có thể tải firmware của mọi thiết bị mà không cần xác thực
    • Lệnh ví dụ: aws s3 ls s3://download.tplinkcloud.com/ --no-sign-request --recursive
  • Thực hiện giải mã firmware bằng công cụ tp-link-decrypt
    • Có thể trích xuất khóa RSA từ mã nguồn GPL được TP-Link công bố
  • Firmware sau khi giải mã có cấu trúc gồm bootloader, kernel, hệ thống tệp gốc SquashFS

Reverse engineering dựa trên AI

  • Tự động hóa phân tích firmware bằng Ghidra, GhidraMCP, Cline, Anthropic Opus/Sonnet 4, v.v.
  • AI giải thích vai trò của các hàm và đổi tên biến theo ngữ nghĩa để cải thiện khả năng đọc mã
  • Qua quá trình này, có thể ánh xạ các thành phần như trình xử lý HTTP, giao thức discovery, routine mã hóa
  • Xác nhận rằng khóa riêng SSL trong firmware không được tạo khi khởi động mà được nhúng sẵn
    • Kẻ tấn công trong cùng mạng có thể giải mã lưu lượng HTTPS

Các lỗ hổng chính

  • CVE-2025-8065 (tràn bộ nhớ ở trình phân tích ONVIF SOAP XML)

    • Máy chủ /bin/main trên cổng 2020 không kiểm tra biên đối với số lượng phần tử XML
    • Khi gửi lượng lớn yêu cầu XML có thể gây tràn bộ nhớ và làm camera bị crash
    • Điểm CVSS v4.0: 7.1 (High)

  • CVE-2025-14299 (tràn số nguyên ở Content-Length của HTTPS)

    • Máy chủ HTTPS trên cổng 443 xử lý header Content-Length bằng atoi() mà không kiểm tra
    • Trên hệ thống 32-bit có thể xảy ra crash do tràn số
    • Điểm CVSS v4.0: 7.1 (High)

  • CVE-2025-14300 (chiếm quyền WiFi)

    • API connectAp có thể truy cập mà không cần xác thực và vẫn hoạt động ngay cả sau khi hoàn tất thiết lập
    • Kẻ tấn công có thể buộc camera kết nối vào mạng do mình kiểm soát để chặn lưu lượng video
    • Điểm CVSS v4.0: 8.7 (High)

  • API quét WiFi không cần xác thực (scanApList)

    • Trả về SSID, BSSID, cường độ tín hiệu, cấu hình bảo mật của WiFi lân cận
    • Có thể theo dõi vị trí GPS chính xác bằng Apple BSSID Locator, v.v.
    • Kẻ tấn công từ xa có thể xác định vị trí thực của camera

Quy trình công bố và phản ứng

  • Ngày 22 tháng 7 năm 2025, báo cáo ban đầu được gửi tới đội bảo mật của TP-Link, kèm PoC và video
  • Sau 150 ngày (19 tháng 12), thông tin được công bố và sau đó TP-Link đã phát hành cảnh báo bảo mật
  • TP-Link có quyền tự cấp CVE (CNA), nên có thể tự kiểm soát quy trình báo cáo và công bố đối với lỗ hổng trong sản phẩm của mình
  • Trên website của mình, hãng dùng số lượng CVE thấp hơn đối thủ làm chỉ số marketing, làm dấy lên chỉ trích về xung đột lợi ích

Kết luận

  • Các công cụ AI tối đa hóa hiệu quả reverse engineering và nâng cao khả năng tiếp cận nghiên cứu bảo mật
  • Tuy nhiên, khóa hardcode, API không cần xác thực, cấu trúc parser yếu cho thấy sự thiếu vắng bảo mật căn bản trong thiết bị IoT
  • Trường hợp TP-Link là ví dụ tiêu biểu cho bài toán cân bằng giữa nghiên cứu bảo mật trong thời đại AI và trách nhiệm của nhà sản xuất

Bài viết liên quan

1 bình luận

 
GN⁺ 2025-12-21
Ý kiến trên Hacker News

  • Thật đáng tiếc khi những bài như thế này lại trộn lẫn các ca thất bại thực sự với những vấn đề mà ngay cả FAANG cũng khó giải quyết để rồi chỉ trích chung chung
    Đặc biệt, việc phê phán đoạn “kho firmware của TP-Link nằm trong một bucket S3 công khai không cần xác thực” là một cách tiếp cận sai
    Ngược lại, tôi nghĩ đây là một ví dụ tốt về việc tránh security through obscurity
    Những bài viết như vậy thậm chí có thể khiến ban lãnh đạo đưa ra chỉ đạo sai lầm kiểu “siết chặt khóa”

    • Bản thân bài viết khá dễ đọc, nhưng có cảm giác giọng văn như do LLM viết
      Bài do AI viết thường thiếu những sắc thái tinh tế và có xu hướng khẳng định quá mức rằng mọi thứ đều mới mẻ quá, hoặc tốt hẳn/xấu hẳn
      Không phải bài tệ, nhưng cần đọc cẩn thận. Dạo này phần lớn bài lên HN có vẻ đều được AI hỗ trợ
    • Có người đùa rằng khi nghe câu “kho firmware đang để công khai” thì “thôi đừng nhắc đến Linux nữa”
    • Những blog reverse engineering kiểu này đơn giản là một cách kể chuyện thú vị và mang tính giáo dục
      Tôi cũng từng viết nhiều bài như vậy, và bài lần này thực sự hấp dẫn
      Thực ra chuyện “lấy firmware bằng cách nào” là phần ít quan trọng nhất trong câu chuyện này
    • Tôi hoàn toàn không cảm thấy có sắc thái tiêu cực nào ở đoạn nói firmware được công khai. Không biết có ai thực sự cảm thấy như vậy không
    • Tôi nghĩ firmware luôn nên được công khai. Đó mới là hướng đi đúng

  • Rất có thể phần lớn các mẫu camera khác cũng chia sẻ những lỗ hổng bảo mật tương tự
    Theo trang cộng đồng TP-Link, firmware mới nhất của C200 được hiển thị là 1.4.4, nhưng bài báo lại nhắc đến 1.4.2
    Tức là đã có một số bản cập nhật, nhưng có vẻ bản vá bảo mật vẫn chưa được áp dụng

    • Trước đây khi phân tích sản phẩm Zyxel, tôi cũng đi đến cùng kết luận
      Nhiều nhà sản xuất vận hành theo mô hình bán cùng một phần cứng chung dưới các thương hiệu khác nhau
      Bài phân tích liên quan: Part 1, Part 2
    • Những camera như vậy phù hợp cho kết nối cục bộ, nhưng với người dùng phổ thông thì vẫn còn vấn đề về tính dễ dùng

  • Đây là lý do phân đoạn mạng IoT là điều bắt buộc
    Mọi camera thông minh và thiết bị IoT nên được đặt trong một VLAN riêng, và quyền truy cập Internet phải bị giới hạn qua firewall
    Cấu hình được khuyến nghị cho người dùng camera TP-Link:

    1. Tắt UPnP trên router
    2. Tách thiết bị IoT bằng VLAN
    3. Chỉ cho phép outbound tới những endpoint cần thiết
    4. Nếu có thể, thay bằng firmware mở
    5. Kiểm tra cập nhật định kỳ
      Vấn đề khóa hardcode đặc biệt nghiêm trọng và ảnh hưởng đến cả dòng sản phẩm
    • Tôi từng kiểm tra mạng gia đình cho một người bạn, và có thể truy cập toàn bộ mạng nội bộ thông qua hệ thống intercom PoE
      Anh ấy không tách thiết bị IoT bằng VLAN, cũng không có hệ thống cảnh báo nào
      Cuối cùng hôm đó anh ấy đã tự học được tầm quan trọng của việc tách VLAN và giới hạn truy cập
      Có lẽ rất nhiều người cũng đang để lộ mạng nội bộ theo cách tương tự
    • Cũng có người hỏi liệu có hướng dẫn nào giải thích thiết lập VLAN từng bước hay không. Về mặt kỹ thuật là làm được, nhưng cần quy trình cụ thể

  • Thingino được nói là có hỗ trợ C200

    • Nhưng trên thực tế chỉ hỗ trợ một phần trong 5 phiên bản của C200
      Để kiểm tra chính xác chipset, cần tham khảo OpenIPC
    • Firmware do cộng đồng Thingino tạo ra thực sự rất ấn tượng
      Nếu bạn có camera tương thích thì rất đáng để thử

  • Tôi dùng tất cả camera trong một VLAN bị chặn Internet
    Có thể truy cập cục bộ qua HomeKit nên vẫn hoạt động tốt mà không cần ứng dụng riêng

  • Mức độ yếu kém bảo mật kiểu này khiến người ta có cảm giác như là cố ý
    Thật khó hiểu khi bán ra hàng triệu thiết bị mà vẫn không kiểm tra những lỗ hổng cơ bản
    Tôi cho rằng phần lớn camera Wi-Fi giá dưới $150 đều sẽ có vấn đề tương tự
    Nếu thực sự muốn dùng an toàn, có lẽ chỉ còn cách tự làm một adapter Wi‑Fi ↔ Ethernet không độc quyền

    • Camera này đang được bán trên trang chính thức với giá $17.99
      Trừ chi phí phần cứng, đóng gói, logistics, kiểm thử, hoàn trả, v.v. thì phần còn lại chỉ là lợi nhuận dưới $5 mỗi thiết bị
      Bỏ thêm $100,000 cho chi phí phát triển đồng nghĩa với việc đốt đi 20,000 thiết bị
      Với một công ty có nhiều dòng sản phẩm như TP-Link, chi phí này sẽ phình thành hàng chục triệu đô mỗi năm
      Rốt cuộc đây là cấu trúc chỉ phát hành với mức phát triển tối thiểu
    • Một số camera dùng nguồn USB có hỗ trợ USB network adapter
      Người rành kỹ thuật có thể dùng firmware Thingino để dựng môi trường chỉ chạy nội bộ
    • Những camera như thế này tuyệt đối không nên đặt trên mạng không đáng tin cậy. Đây là nguyên tắc quá hiển nhiên
    • Tôi hoàn toàn đồng ý với nhận định rằng “mọi camera Wi‑Fi đều có những vấn đề tương tự”

  • Tôi không biết kho firmware S3 của TP-Link sẽ còn mở đến bao giờ
    Dữ liệu vào khoảng 990GiB, sẽ tốt nếu ai đó sao lưu lại dưới dạng archive hoặc torrent

  • Tôi chỉ dùng camera này cho các mục đích không quan trọng với Unifi + ONVIF
    Tôi đặt nó trong một VLAN riêng và chặn Internet, may là nó vẫn hoạt động bình thường

  • Khi tìm hiểu về camera, tôi đã tham khảo trang drmnsamoliu.github.io

  • Tôi từng reverse luồng video của một drone đồ chơi bằng Ghidra và AWS Amazon Q
    Có lẽ nếu dùng GhidraMCP thì còn nhanh hơn nhiều