Xác thực chứng chỉ không đầy đủ cho phép chặn lưu lượng trong ứng dụng di động TP-Link Systems Inc.

Một lỗ hổng trong logic xác thực chứng chỉ có thể khiến các ứng dụng chấp nhận danh tính máy chủ không đáng tin cậy hoặc được xác thực không đúng trong quá trình giao tiếp TLS. Kẻ tấn công ở vị trí đặc quyền trong mạng có thể chặn hoặc sửa đổi lưu lượng nếu có thể đặt mình vào trong kênh liên lạc. Khai thác thành công có thể làm ảnh hưởng đến tính bảo mật, tính toàn vẹn và tính sẵn sàng của dữ liệu ứng dụng.

Nhà cung cấp xác định các ứng dụng Android sau bị ảnh hưởng khi phiên bản thấp hơn ranh giới tương ứng:

• Tapo App: < 3.14.111
• Kasa App: < 3.4.350
• Omada App: < 4.25.25
• Omada Guard: < 1.1.28
• Tether App: < 4.12.27
• Deco App: < 3.9.163
• Aginet App: < 2.13.6
• tpCamera App: < 3.2.17
• WiFi Toolkit: < 1.4.28
• Festa App: < 1.7.1
• Wi-Fi Navi: < 1.5.5
• KidShield: < 1.1.21
• TP-Partner App: < 2.0.1
• VIGI App: < 2.7.70

Hồ sơ chuẩn hóa đặt trạng thái mặc định của các sản phẩm là unaffected và đánh dấu các khoảng nêu trên là affected. Tài liệu của TP-Link cho biết các ứng dụng iOS không bị ảnh hưởng. Trạng thái của các nhánh hoặc nền tảng khác không được xác nhận ngoài phạm vi này.

Lỗi nằm trong logic xác thực chứng chỉ của các ứng dụng di động TP-Link Systems Inc. Khi thiết lập kết nối TLS, ứng dụng có thể chấp nhận danh tính máy chủ không đáng tin cậy hoặc được xác thực không đầy đủ. Kẻ tấn công phải có vị trí đặc quyền trong đường truyền mạng và có khả năng nằm trong kênh liên lạc để can thiệp lưu lượng; dữ liệu được cung cấp không xác định API xác thực, điều kiện chứng chỉ cụ thể hoặc thành phần triển khai chính xác gây ra lỗi.

Theo các đặc tính tấn công được cung cấp, lỗ hổng có thể bị khai thác qua mạng, không yêu cầu đặc quyền ứng dụng của kẻ tấn công và chỉ yêu cầu tương tác thụ động của người dùng. Phạm vi ảnh hưởng được xác định là các ứng dụng Android được liệt kê trong phần affected_summary; nhà cung cấp cho biết các ứng dụng iOS không bị ảnh hưởng.

Lỗ hổng có thể bị khai thác từ xa qua mạng khi kẻ tấn công chiếm được hoặc kiểm soát một vị trí đặc quyền trong đường truyền giữa ứng dụng và máy chủ. Hồ sơ cho biết không yêu cầu đặc quyền ứng dụng của kẻ tấn công, nhưng việc khai thác phụ thuộc vào khả năng đặt mình vào kênh liên lạc và người dùng sử dụng ứng dụng để tạo lưu lượng TLS. Tương tác người dùng được mô tả là thụ động, nghĩa là người dùng không nhất thiết phải thực hiện một hành động bảo mật cụ thể ngoài việc sử dụng ứng dụng.

Hồ sơ được cung cấp không ghi nhận public exploit. Trạng thái khai thác thực tế cũng không được xác lập trong hồ sơ, vì vậy không nên xem việc không có thông tin này là bằng chứng cho thấy chưa từng có khai thác.

Kẻ tấn công có vị trí đặc quyền trong mạng có thể làm ứng dụng chấp nhận danh tính máy chủ không đáng tin cậy trong phiên TLS, sau đó có khả năng chặn hoặc sửa đổi lưu lượng. Hậu quả kỹ thuật được nêu là có thể ảnh hưởng đến tính bảo mật, toàn vẹn và sẵn sàng của dữ liệu ứng dụng.

• Tính bảo mật: dữ liệu truyền qua kết nối ứng dụng có thể bị tiết lộ.
• Tính toàn vẹn: lưu lượng hoặc dữ liệu ứng dụng có thể bị thay đổi trong quá trình truyền.
• Tính sẵn sàng: việc can thiệp vào lưu lượng có thể ảnh hưởng đến dữ liệu hoặc chức năng phụ thuộc vào kết nối.

Bằng chứng hiện có không xác định liệu thông tin xác thực, lệnh điều khiển thiết bị, phiên người dùng hay dữ liệu cụ thể nào luôn bị lộ. Vì vậy, tác động thực tế cần được đánh giá theo loại dữ liệu và chức năng của từng ứng dụng trong môi trường triển khai.

• Dữ liệu ứng dụng truyền qua TLS có thể bị đọc hoặc sửa đổi bởi kẻ tấn công có khả năng đứng trong đường truyền mạng.
• Việc này có thể làm mất tính bí mật và toàn vẹn của dữ liệu ứng dụng, đồng thời có thể ảnh hưởng đến khả năng sẵn sàng của dữ liệu hoặc chức năng phụ thuộc vào kết nối đó.
• Tổ chức sử dụng các ứng dụng Android bị ảnh hưởng cần ưu tiên kiểm kê phiên bản và xác nhận cập nhật trên các thiết bị được quản lý, vì một bản cập nhật chưa được áp dụng có thể để lại đường phơi nhiễm.
• Hồ sơ không nêu một nạn nhân, sự cố hoặc vụ rò rỉ cụ thể. Không nên suy diễn rằng đã xảy ra xâm nhập thực tế hoặc rằng dữ liệu của một tổ chức cụ thể đã bị đánh cắp.

1. Trên thiết bị Android, mở Google Play Store, kiểm tra bản cập nhật cho từng ứng dụng bị ảnh hưởng và cài đặt phiên bản mới nhất có sẵn. Sau khi cập nhật, xác nhận phiên bản đã cài đặt không còn thấp hơn ranh giới tương ứng trong affected_summary.
2. Đối chiếu kết quả cập nhật với hồ sơ MDM hoặc hệ thống quản lý ứng dụng để bảo đảm các thiết bị thuộc tổ chức đều đã hoàn tất cập nhật, không chỉ thiết bị được kiểm tra thủ công.
3. Nếu chưa thể cập nhật, coi các ứng dụng Android đang nằm dưới ranh giới affected là vẫn dễ bị tấn công khi kẻ tấn công có vị trí đặc quyền trong mạng. Tài liệu được kiểm tra không nêu biện pháp giảm thiểu thay thế cụ thể ngoài việc cập nhật ứng dụng.
4. Các ứng dụng iOS được nhà cung cấp xác định là không bị ảnh hưởng bởi lỗ hổng này; vẫn nên ghi lại nền tảng và phiên bản trong quá trình kiểm kê để tránh nhầm lẫn giữa các bản triển khai.

1. Kiểm kê các thiết bị Android đang cài đặt ứng dụng TP-Link Systems Inc. có tên trong phần affected_summary, bao gồm cả ứng dụng được triển khai qua MDM hoặc kho ứng dụng nội bộ.
2. Đọc phiên bản đang cài đặt của từng ứng dụng và đối chiếu với ranh giới affected tương ứng trong phần affected_summary.
3. Kiểm tra trạng thái cập nhật trên Google Play Store và xác nhận ứng dụng đã được cập nhật lên phiên bản không còn nằm dưới ranh giới bị ảnh hưởng.
4. Rà soát báo cáo tuân thủ ứng dụng trên MDM, EMM hoặc hệ thống quản lý thiết bị để tìm các thiết bị Android vẫn đang chạy phiên bản cũ.
5. Có thể xem xét telemetry mạng liên quan đến lỗi TLS hoặc thay đổi bất thường trong kết nối như một biện pháp phòng ngừa. Nhà cung cấp không công bố IOC, log event hoặc mẫu lưu lượng cụ thể cho lỗ hổng này; việc không thấy cảnh báo mạng không chứng minh ứng dụng an toàn.