Định giám sát chú chó của tôi, ai ngờ lại thành giám sát TP-Link

• Tôi mua camera Tapo để quan sát chú chó trong nhà, nhưng ngoài dự kiến lại dẫn tới việc phân tích ngược cách thiết bị và ứng dụng TP-Link hoạt động
• Để phân tích quy trình onboarding và cấu trúc giao tiếp API được mã hóa, tác giả đã dùng nhiều kỹ thuật như MITM, giải biên dịch APK, tạo script giải mã
• Thông qua việc phát hiện mật khẩu quản trị ban đầu và quá trình suy ra khóa phiên, tác giả đã giải mã được các thông điệp được mã hóa và xác định vấn đề đồng bộ thiếu tin cậy giữa thiết bị và tài khoản đám mây
• Sau khi phân tích toàn bộ luồng onboarding, tác giả đã tự động hóa bằng script Bash các bước gọi API chính, tạo tài khoản, đổi mật khẩu và kết nối Wi‑Fi
• Bài viết chỉ ra lỗ hổng trong thiết kế bảo mật firmware Tapo, cách triển khai mã hóa kém tinh vi và việc đồng bộ tài khoản không ổn định — những đặc trưng thường thấy ở thiết bị IoT giá rẻ

---

Tổng quan dự án

• Tác giả đã mua và sử dụng camera Tapo giá rẻ để theo dõi chú chó trong nhà
• Trong quá trình sử dụng, do việc thiết lập bất tiện và thiếu thông tin trên mạng, tác giả có động lực đào sâu vào cách sản phẩm vận hành
• Khi gặp các vấn đề ngoài dự kiến như tích hợp với frigate, kích hoạt 2way audio, tác giả bắt đầu quan tâm tới phương pháp onboarding trực tiếp không cần tích hợp đám mây

Phân tích cấu trúc onboarding và xác thực

• Để phân tích quy trình kết nối của camera Tapo, tác giả đã dùng MITM proxy và công cụ hook động frida để chặn lưu lượng giữa ứng dụng và camera
  • Do các ứng dụng mới thường có cơ chế chống vượt qua như bỏ qua proxy, certificate pinning, nên phương pháp dùng công cụ động tỏ ra hiệu quả
• Sau khi thiết lập được cơ chế vượt qua này, tác giả đã xác nhận chính xác quy trình đăng nhập bằng tài khoản quản trị mặc định trong luồng onboarding của camera
• Tác giả phát hiện API đăng nhập mặc định hoạt động bằng mật khẩu mặc định riêng của thiết bị, tách biệt với mật khẩu tài khoản đám mây

Cấu trúc mã hóa và quá trình tìm mật khẩu mặc định

• Thông qua giải biên dịch APK (dùng JADX) và phân tích mã, tác giả đã lấy được mật khẩu mặc định của tài khoản admin là TPL075526460603
• Ngay cả khi đổi mật khẩu đám mây, các camera đã liên kết từ trước vẫn không nhận ra thay đổi này, cho thấy việc đồng bộ mật khẩu giữa ứng dụng và camera là không chính xác
• Sau khi tìm ra mật khẩu mặc định, tác giả đã hiện thực logic suy ra khóa phiên (lsk, ivb), từ đó có thể giải mã các thông điệp API được mã hóa theo thời gian thực

Script mitmproxy và phân tích API

• Tham khảo dự án mã nguồn mở PyTapo, tác giả đã phân tích chi tiết luồng API của quy trình onboarding Tapo thực tế
• Thông qua script tapo_decrypt_pretty.py, tác giả có thể:
  • phát hiện bắt tay đăng nhập
  • trích xuất khóa phiên
  • giải mã API được mã hóa, xuất kết quả dễ đọc và lưu JSON
• Từ toàn bộ nhật ký gọi API trong quá trình onboarding, tác giả chỉ chọn ra các bước chính có ý nghĩa để tạo workflow tự động hóa
  • lấy danh sách Wi‑Fi (scanApList)
  • kích hoạt tài khoản RTSP/ONVIF
  • đổi mật khẩu quản trị
  • kết nối Wi‑Fi

Tự động hóa và kết quả

• Tác giả đã xây dựng script Bash (tapo_onboard.sh) để tự động thực thi toàn bộ quy trình onboarding ở trên
  • đăng nhập admin mặc định
  • chọn và kết nối Wi‑Fi
  • gỡ logo khỏi feed camera
  • cho phép sử dụng RTSP/ONVIF
  • đặt lại mật khẩu quản trị
• Từ cấu trúc firmware của camera, tác giả phát hiện các đặc điểm và điểm yếu sau
  • một số API dùng băm SHA-256, nhưng một số khác vẫn giữ cách mã hóa cũ như MD5
  • tồn tại 2 khóa công khai, nhưng không rõ trong tình huống nào cần dùng khóa nào
  • đồng bộ mật khẩu giữa ứng dụng và thiết bị rất thiếu ổn định

Kết luận và cảm nhận

• Tác giả cảm thấy cấu trúc bảo mật của firmware và API camera Tapo mang tính vá víu và thiết kế chưa tinh vi
• Đây là một trải nghiệm gián tiếp cho thấy những lỗ hổng bảo mật và sự thiếu hoàn thiện của hệ thống onboarding trên các thiết bị IoT giá rẻ
• Mục tiêu cuối cùng của dự án là kiểm tra chú chó đã đạt được, và tác giả chủ yếu thấy chú chó đang ngủ trên sofa hoặc trên giường

[helio]

CVE-2022-37255 được chấm 7.5 điểm nhỉ

[GN⁺]

Ý kiến trên Hacker News

• Thật thú vị khi thấy có người dùng script Frida của tôi, có thể xem script đó tại đây, tôi rất vui vì có vẻ nó hoạt động tốt trong môi trường thực tế, nếu bạn có bổ sung hay chỉnh sửa gì thì tôi rất muốn nghe

  • Tôi nghĩ HTTP Toolkit là một công cụ thực sự rất tốt, đúng là thành quả xuất sắc của Tim
  • Trong số các công cụ tôi từng dùng thì Http toolkit là tốt nhất, tôi đã thử mitmproxy, proxyman, charles proxy nhưng httptoolkit vẫn là tốt nhất, lại còn mã nguồn mở

• Nhân tiện, để dùng âm thanh hai chiều trong frigate thì cần áp dụng cấu hình go2rtc tapo:// cho luồng chính thay vì rtsp:// thông thường, TP-Link chỉ cung cấp âm thanh hai chiều qua API riêng của họ, nhưng cấu hình này lại làm ONVIF (điều khiển pan/tilt camera bằng công cụ mã nguồn mở) không hoạt động nên khá phiền, nếu muốn dùng cả hai thì phải lặp đi lặp lại quy trình khá cực đoan: dừng đọc luồng tapo:// → chạy client onvif/điều chỉnh pan·tilt → thoát onvif → khởi động lại tapo://

• Tôi nghĩ bảo mật IoT nói chung là một mớ hỗn độn, điều đặc biệt đáng lo là router tiêu dùng là những hộp đen không thể kiểm toán nhưng lại xử lý toàn bộ lưu lượng mạng, đa số mọi người thậm chí không biết firmware router của họ đã nhiều năm không được cập nhật và đã có các lỗ hổng được biết đến từ trước, tôi cho rằng mô hình tin cậy của chuỗi cung ứng phần cứng mạng đã hỏng hoàn toàn

  • Tôi đồng ý là bảo mật IoT rất tệ, với tôi thì chỉ cần thiết bị IoT kết nối ổn là được, đôi khi tôi còn muốn dùng cả exploit để vượt qua các ràng buộc chỉ-hoạt-động-online, nhưng cũng có những trường hợp sử dụng thật sự cần IoT gắn với cloud, nên tôi nghĩ khi thiết lập ban đầu thiết bị phải hỏi người dùng muốn cách nào và chỉ hoạt động theo chế độ đã chọn, nếu cần cloud MFA thì có thể chọn như vậy, còn nếu chỉ muốn điều khiển bằng lập trình thì nên có thể để nó ở trạng thái offline
  • Giữa người dùng và đích đến có vô số router mà bạn không thể giám sát hết, các thiết bị đầu cuối vốn đã giả định router có thể bị xâm nhập nên truyền mọi dữ liệu dưới dạng đã được xác minh và mã hóa, vì vậy trừ khi router bị dùng cho việc xấu như DDoS hay đào tiền mã hóa thì bản thân bảo mật của router không quá nhiều ý nghĩa
  • Hầu hết mọi người dùng router do ISP cung cấp và cấu hình sẵn, nên cảm giác chẳng khác nào nối một hộp đen vào một hộp đen khác, tôi khá ngạc nhiên khi nhiều lần thấy việc kết nối Wi‑Fi chỉ đơn giản là nhận SSID và mật khẩu do ISP chỉ định, điều đó cho thấy người dùng đang trao quá nhiều quyền cho ISP
  • Đúng là hàng tiêu dùng phổ thông thì như vậy, nhưng nếu lên phần cứng prosumer như Ubiquiti hay Mikrotik thì có thể có cập nhật bảo mật nhanh và hỗ trợ firmware ổn định hơn

• Tôi thấy bài blog này được viết cực kỳ tốt, dạo này nhiều bài kiểu này là do LLM tạo ra và đọc rất khó chịu, còn bài này gây ấn tượng vì cân bằng rất tốt giữa tính kỹ thuật và sự dễ đọc, (tôi biết ảnh bìa là do AI tạo nhưng điều đó không liên quan đến bản chất bài viết)

  • Quan điểm của tôi là dùng uBlock Origin để chặn các tệp media dung lượng lớn theo mặc định nhằm tiết kiệm tài nguyên, ảnh bìa vốn dĩ thường bị chặn ngay từ đầu và gần như không có ích gì, nên tôi thấy khá tiếc khi ngày nay người ta còn tốn tài nguyên để tạo ra chúng

• Tôi tò mò không biết các công cụ như Frida, mitmproxy còn dùng được lâu dài với ứng dụng Android hay không, tôi muốn biết sang năm khi yêu cầu chữ ký được áp dụng thì sẽ ra sao

  • Nhìn chung vẫn sẽ làm được, nhưng với các ứng dụng yêu cầu attestation thì sẽ khó hơn rất nhiều, ngay bây giờ những thiết bị như Pixel cho phép OEM unlock và root vẫn có thể tiếp tục được dùng cho mục đích developer, chỉ là trong trường hợp đó thiết bị sẽ bị đánh dấu là đã unlock và trượt Google attestation, cũng có thể giải nén ứng dụng, inject Frida rồi sideload bằng tài khoản nhà phát triển như trên iOS, nhưng cách này cũng vẫn sẽ thất bại trước attestation và dễ bị anti-tampering/anti-debugging tấn công
  • Thực ra tôi dự đoán những thay đổi đó sẽ không ảnh hưởng trực tiếp nhiều, vì reverse engineering chủ yếu vẫn diễn ra trên thiết bị đã root và emulator, hiếm hơn là trường hợp inject Frida vào APK theo kiểu gadget trên thiết bị không root, khi đó mọi thứ sẽ khó hơn nhưng tôi vẫn nghĩ sẽ còn con đường build và cài APK ở chế độ nhà phát triển, nếu chặn hoàn toàn điều đó thì phát triển ứng dụng Android sẽ trở nên bất khả thi, nên có lẽ sideload sẽ bị chặn trên thiết bị người dùng phổ thông còn các cách như thêm chứng chỉ nhà phát triển thì vẫn được mở, rốt cuộc thứ khó nhất sẽ là phân phối ứng dụng thực tế còn phát triển/reverse engineering có lẽ vẫn làm được, tuy vậy việc mở rộng device attestation mới là mối đe dọa lớn hơn, ngày càng nhiều ứng dụng có thể sẽ mạnh tay kiểm tra xem thiết bị có phải unmodified device hay không trên máy đã root/không chính thức, hiện tại chuyện này chủ yếu mới có ở các ứng dụng tài chính lớn, số người thực sự phải lo (ví dụ người dùng GrapheneOS) vẫn còn ít và nó cũng tốn chi phí như phải dựng thêm server nên chưa dễ phổ biến ngay, nhưng sau này có thể sẽ thay đổi
  • Trên thực tế ngay bây giờ việc dùng Frida cũng đã không hề dễ, vì muốn dùng Frida thường phải root, mà bản thân việc root ngày càng bất khả thi trên nhiều mẫu máy, lại còn có các SDK phát hiện root cực mạnh và biện pháp đối phó Play Integrity

• Nhân tiện, các ví dụ liên quan còn có The Tapo C200 research project và PyTapo: thư viện Python cho camera Tapo

• Một tài liệu liên quan khác là (giải mã firmware TP-Link và phân tích bootloader camera cloud C210 V2) ở đây

• Tôi đoán lý do chú chó của OP chuyển từ trên giường xuống sàn có lẽ là vì lò sưởi (radiator) được bật, có vẻ sẽ cần thêm dữ liệu từ cảm biến

  • Hoặc đơn giản là nó thấy lạnh nên mới vậy

• Có cảm giác như giờ đây việc phát hiện mật khẩu quản trị hardcode không còn là chuyện gì ghê gớm nữa

  • Tôi hiểu đó chỉ là mật khẩu mặc định được hardcode chứ không phải backdoor vĩnh viễn, theo như bài viết nói thì trong quá trình onboarding người dùng sẽ đổi mật khẩu, hầu hết ứng dụng đều hoạt động kiểu này
  • Tôi nghĩ nếu trong quy trình bình thường sau khi cài đặt người dùng đã đổi mật khẩu thì cũng không thành vấn đề, điều tôi rút ra sau 5 năm cố gắng dựng càng nhiều thiết bị IoT/nhà thông minh càng tốt trong nhà là gần như mọi hãng đều chỉ bán những sản phẩm có chức năng đáng ngờ, và nếu không thống nhất một hãng thì việc xây dựng toàn bộ smart home là cực kỳ khó, mà hiện giờ ngay cả những hãng tạm ổn cũng không đáp ứng được hết các nhu cầu riêng lẻ, trên điện thoại tôi cài đủ loại ứng dụng như Ecobee, Lutron, Hue, nhiều hãng camera khác nhau, Meross, Smart Life..., trong số đó chỉ có Lutron và Hue là có thể điều khiển trực tiếp qua hub/HomeKit nên không cần mở app, Matter và Thread đã được tiêu chuẩn hóa từ lâu nhưng thị trường vẫn đầy các sản phẩm Wi‑Fi giá rẻ thay vì thiết bị tương thích đúng nghĩa, mà phần lớn lại dở và chỉ quản lý được qua app đồng thời dẫn người dùng vào dịch vụ cloud, chuyện tôi mua tới bốn chiếc camera cũng một phần là lỗi của tôi, nhưng thực ra mỗi hãng lại có điểm mạnh khác nhau nên việc người tiêu dùng phải mua chia ra nhiều nơi cũng là điều khó tránh
  • Tôi không nghĩ mật khẩu quản trị hardcode mà bắt buộc phải đổi trước khi dùng là vấn đề gì lớn
  • Thật ra có lẽ tôi chỉ đang bực mình với công nghệ này thôi, ở đây thì không thể xem là vấn đề
  • Cũng có quan điểm cho rằng chính smartphone mới là thiết bị gốc mang tính đối kháng, còn thiết bị mạng thì ít nhất ở đây vẫn có thể quan sát hoặc phát hiện được tình trạng

• Tôi muốn có một tài liệu tham khảo tổng hợp các mẫu camera tapo hỗ trợ RTSP, c210 hoạt động tạm ổn (không bắt được cloud capture) và tôi đang dùng nó tích hợp với frigate, hôm nay tôi mua c402 (loại ngoài trời) nhưng mẫu này lại không có camera account trong phần cài đặt nâng cao nên khá thất vọng, giá rẻ là điểm hấp dẫn nhưng tôi thấy tính nhất quán về tính năng còn kém, nếu có camera ngoài trời nào giá tốt, hỗ trợ luồng RTSP và còn gắn được solar panel thì rất mong được gợi ý

  • Ngay cả khi camera không hỗ trợ rtsp:// thì có lẽ vẫn dùng nguồn luồng go2rtc tapo:// được, tôi để cấu hình frigate của mình ở đây để tham khảo