WhiteHat News #ID:2112
VIP Members
-
16/06/2015
-
83
-
672 bài viết
Các cuộc họp trực tuyến trên Zoom được mã hóa yếu và truyền khóa qua Trung Quốc
Khi nghiên cứu mã hóa bảo vệ các cuộc họp trong ứng dụng Zoom, các nhà nghiên cứu tại Citizen Lab của Đại học Toronto đã phát hiện ra rằng chương trình mã hóa của Zoom có nhiều điểm yếu cùng nhiều vấn đề về hạ tầng, bao gồm cả việc truyền khóa mã hóa cuộc họp qua Trung Quốc.
Dưới đây là những phát hiện chính của nghiên cứu:
- Tài liệu của Zoom tuyên bố rằng ứng dụng sử dụng mã hóa AES-256 cho các cuộc họp. Tuy nhiên, các nhà nghiên cứu thấy rằng trong mỗi cuộc họp Zoom, một khóa AES-128 duy nhất được sử dụng ở chế độ ECB (chế độ mã hóa từng khối byte độc lập) để mã hóa và giải mã âm thanh và video. Việc sử dụng chế độ ECB không được khuyến khích vì các mẫu (pattern) ở dạng plaintext được giữ nguyên trong quá trình mã hóa.
- Các khóa AES-128, mà các nhà nghiên cứu đã xác minh là đủ để giải mã các gói tin Zoom bị chặn trên Internet dường như được tạo ra từ các máy chủ Zoom và trong một số trường hợp, được gửi đến người tham gia cuộc họp qua máy chủ ở Trung Quốc, ngay cả khi tất cả người tham gia họp và công ty của người đăng ký Zoom đều ở bên ngoài Trung Quốc.
- Zoom, một công ty có trụ sở tại Thung lũng Silicon, dường như sở hữu ba công ty ở Trung Quốc với ít nhất 700 nhân viên được trả lương để phát triển phần mềm Zoom. Đây rõ ràng là một nỗ lực để khai thác lao động giá rẻ: Zoom không phải trả mức lương ở Mỹ nhưng lại bán cho khách hàng Mỹ, qua đó tăng lợi nhuận biên. Tuy nhiên, điều này có thể khiến Zoom phải thỏa hiệp với áp lực từ chính quyền Trung Quốc.
Công ty Mỹ có trái tim ở Trung Quốc?
Zoom là một ứng dụng viễn thông có mức độ phổ biến tăng lên đáng kể thời gian gần đây do phần lớn thế giới đang làm việc tại nhà trước sự lây lan của dịch bệnh COVID-19.
Logo của Zoom ở phía trên tên của công ty phát triển Trung Quốc Ruanshi Software (Suzhou) Ltd.
Mặc dù Zoom có trụ sở chính tại Mỹ và được niêm yết trên sàn giao dịch chứng khoán NASDAQ, ứng dụng chính của Zoom dường như được phát triển bởi ba công ty ở Trung Quốc. Hai trong số ba công ty này thuộc sở hữu của Zoom đều có tên là Ruanshi Software, trong khi công ty còn lại thuộc sở hữu của một thực thể có tên American Cloud Video Software Technology Co., Ltd. Các bài tuyển dụng cho Ruanshi Software ở Tô Châu bao gồm các vị trí mở cho lập trình viên C++, nhà phát triển ứng dụng Android và iOS...
Hồ sơ nộp lên Ủy ban Giao dịch và Chứng khoán Mỹ (SEC) gần đây của Zoom cho thấy công ty sử dụng ít nhất 700 nhân viên tại Trung Quốc làm công việc nghiên cứu và phát triển. Hồ sơ cũng ngụ ý rằng 81% doanh thu của Zoom đến từ Bắc Mỹ. Thực hiện công việc phát triển ở Trung Quốc giúp Zoom tiết kiệm tiền lương phải trả cho Thung lũng Silicon, giảm chi phí và tăng tỷ suất lợi nhuận. Tuy nhiên, việc này cũng có thể khiến Zoom phải thỏa hiệp với các áp lực từ chính quyền Trung Quốc. Dù tên miền chính của Zoom (zoom.us) đã bị chặn ở Trung Quốc vào tháng 11 năm 2019, vẫn có một số công ty Trung Quốc bán ứng dụng Zoom ở Trung Quốc (ví dụ: zoom.cn, zoomvip.cn, zoomcloud.cn).
Vấn đề mã hóa được đưa ra ánh sáng
Tài liệu mô tả của Zoom có một số tuyên bố không rõ ràng về mã hóa mà nền tảng này cung cấp. Một số tài liệu của Zoom (cũng như chính ứng dụng Zoom) tuyên bố Zoom cung cấp một tính năng giúp các cuộc họp được mã hóa đầu cuối (end-to-end).
Thông báo trên ứng dụng Zoom tuyên bố một cuộc gọi được mã hóa end-to-end
Thông thường, cộng đồng an ninh máy tính hiểu thuật ngữ mã hóa đầu cuối end-to-end có nghĩa là chỉ các bên tham gia giao tiếp mới có thể truy cập (bên trung gian chuyển tiếp liên lạc cũng không thể truy cập). Tài liệu khác của Zoom nói rằng phần mềm họp trực tuyến Zoom cho Windows, MacOS và Linux, theo mặc định, sử dụng TLS 1.2 tiêu chuẩn công nghiệp để mã hóa truyền tin, dù bài đăng trên blog tháng 9/2014 ngụ ý rằng phần mềm này không sử dụng TLS.
Zoom tuyên bố sử dụng mã hóa TLS và AES
Để giải quyết sự nhầm lẫn này, Zoom đã phát hành một bài đăng trên blog vào tháng 4/2020 mô tả sơ đồ mã hóa của mình. Bài đăng làm rõ rằng Zoom hiện không triển khai mã hóa đầu cuối end-to-end như hầu hết mọi người vẫn hiểu thuật ngữ này. Định nghĩa của Zoom về end-to-end dường như không giống với các tiêu chuẩn thông thường. Vì Zoom không thực hiện mã hóa đầu cuối thực sự nên về mặt lý thuyết họ có khả năng để giải mã và giám sát các cuộc gọi Zoom. Tuy nhiên, Zoom đề cập rằng họ chưa xây dựng bất kỳ cơ chế nào để can thiệp các cuộc họp của khách hàng: “Zoom chưa bao giờ xây dựng một cơ chế để giải mã các cuộc họp trực tiếp, chúng tôi cũng không có ý định chèn nhân viên hoặc người khác vào các cuộc họp mà không hiển thị tên trong danh sách người tham gia”.
Tuy nhiên, bài viết trên blog của không cung cấp chi tiết về cách thức mã hóa của họ hoạt động hoặc làm rõ họ sử dụng TLS hay AES-256. Vì vậy các nhà nghiên cứu đã quyết định tìm hiểu cách mã hóa các cuộc họp của Zoom.
Zoom trở thành mục tiêu tình báo
Thành công của Zoom khiến các cuộc hội thoại của nó được nhiều chính phủ quan tâm. Và điều này có thể làm cho Zoom trở thành mục tiêu ưu tiên cao cho việc thu thập thông tin tình báo tín hiệu (SIGINT) và các hoạt động xâm nhập nhắm mục tiêu khác.
Ngoài ra, như nhóm bảo vệ quyền kỹ thuật số Access Now đã chỉ ra trong một thư ngỏ kêu gọi báo cáo minh bạch, Zoom không tiết lộ công khai thông tin như thống kê yêu cầu dữ liệu của chính phủ và những gì Zoom đã thực hiện để đáp ứng các yêu cầu này. Các chính sách của Zoom liên quan đến thông báo cho người dùng về những vi phạm dữ liệu hoặc bàn giao dữ liệu cho chính phủ cũng chưa được biết đến, tuy nhiên công ty đã hứa sẽ báo cáo về những thông tin này trong vòng 90 ngày kể từ ngày 2/4.
Máy chủ Trung Quốc và vấn đề bảo mật
Thay vì sử dụng giao thức chuẩn để gửi âm thanh và video, Zoom thực thi giao thức truyền tin của riêng họ, dường như là một phần mở rộng của tiêu chuẩn RTP hiện có.
Giao thức truyền tin của Zoom bổ sung phương thức mã hóa riêng vào RTP. Theo mặc định, tất cả âm thanh và video của người tham gia cuộc họp Zoom dường như được mã hóa và giải mã bằng một khóa AES-128 được chia sẻ giữa những người tham gia. Khóa AES dường như được tạo và phân phối cho những người tham gia cuộc họp bằng các máy chủ Zoom. Mã hóa và giải mã của Zoom sử dụng AES trong chế độ ECB. Đây không phải là một ý tưởng hay vì các nguyên mẫu vẫn ở dạng plaintext. Các giao thức tiêu chuẩn công nghiệp để mã hóa phương tiện truyền phát trực tuyến (như tiêu chuẩn SRTP) khuyến nghị sử dụng AES trong Chế độ Segmented Integer Counter (Số nguyên phân đoạn) hoặc chế độ f8, vốn không có điểm yếu giống như chế độ ECB.
Cấu trúc liên kết cuộc gọi Zoom trong nghiên cứu
Trong quá trình thử nghiệm cuộc họp Zoom với hai người dùng, một ở Mỹ và một ở Canada, các nhà nghiên cứu thấy rằng khóa AES-128 để mã hóa và giải mã hội nghị được gửi đến một trong những người tham gia qua TLS từ máy chủ Zoom được đặt ở Bắc Kinh, 52.81.151.250. Quét thử cho thấy tổng cộng năm máy chủ ở Trung Quốc và 68 ở Mỹ dường như chạy cùng phần mềm máy chủ Zoom như máy chủ ở Bắc Kinh. Các nhà nghiên cứu nghi ngờ rằng các khóa có thể được phân phối thông qua các máy chủ này. Một công ty chủ yếu phục vụ khách hàng Bắc Mỹ đôi khi phân phối khóa mã hóa thông qua các máy chủ ở Trung Quốc là rất đáng quan ngại vì có khả năng Zoom có thể có nghĩa vụ pháp lý phải tiết lộ các khóa này cho chính quyền ở Trung Quốc.
Nghiên cứu được thực hiện như thế nào?
Trước tiên, các nhà nghiên cứu đã quan sát lưu lượng truy cập Internet được liên kết với các cuộc họp Zoom sử dụng các máy khách Zoom trên Windows, MacOS và Linux. Sau đó, sử dụng Wireshark để ghi lại lưu lượng truy cập Internet khi tham gia vào các cuộc họp Zoom. Phần lớn lưu lượng truy cập Internet trong các cuộc họp Zoom của các nhà nghiên cứu được trao đổi giữa máy tính và máy chủ do Zoom sở hữu trên UDP cổng 8801. Kiểm tra thêm về lưu lượng UDP cho thấy Zoom rõ ràng đã thiết kế giao thức truyền tin của riêng họ dựa trên giao thức RTP nổi tiếng để truyền âm thanh và video.
Xác định video được mã hóa
Trên một số gói có tải trọng UDP bắt đầu bằng 0x05100100, RTP header (Giao thức truyền tin thời gian thực) thường được mã hóa type value (giá trị loại) 98. Trong các gói này, tải trọng RTP dường như chứa luồng video H.264 sử dụng định dạng trong RFC 6184. Trong định dạng này, tải trọng RTP là một chuỗi gồm một hoặc nhiều NALU (Đơn vị lớp mạng trừu tượng), chứa các thành phần của video (ví dụ: các loại khung video, siêu dữ liệu khác nhau trong cài đặt bộ giải mã, v.v.). Một số NALU đã bị phân mảnh bằng cách sử dụng lược đồ từ RFC cho Fragmentation Unit A” (FU-A) (Đơn vị phân mảnh). Các nhà nghiên cứu lắp chúng lại thành NALU không phân mảnh. Trên mỗi RFC, mỗi NALU có một type value cho biết nó đang chứa thành phần nào của video. Trong trường hợp của Zoom, tất cả các giá trị NALU được đặt về 0, vốn không hợp lệ trên mỗi RFC, vì vậy các nhà nghiên cứu nghi ngờ rằng tải trọng NALU là một định dạng được đặt trước cho Zoom.
NALU bao gồm một giá trị 4 byte big-endian dường như để mô tả độ dài (các giá trị 4 byte này đều nhỏ hơn nhưng gần bằng kích thước của các gói), theo sau là một số byte luôn luôn là bội số thấp nhất của 16 mà lớn hơn giá trị độ dài 4 byte (nghĩa là, nếu giá trị độ dài 4 byte nằm trong khoảng từ 145 đến 160 thì nó sẽ được theo sau bởi 160 byte). Điều này gợi ý việc sử dụng sơ đồ mã hóa AES, vốn hoạt động trên các khối 16 byte. Nếu độ dài của tin nhắn được mã hóa không phải là bội số của 16 byte thì phần đệm được thêm vào cuối tin nhắn để tăng độ dài lên bội số của 16. Kiểm tra kết xuất bộ nhớ của quy trình Zoom trong cuộc họp đã tiết lộ một khóa AES-128 trong bộ nhớ được liên kết với chuỗi conf.skey, mà các nhà nghiên cứu suy đoán là viết tắt của “conference secret key (khóa bí mật hội nghị)”.
Để trích xuất video cho từng người tham gia, trước tiên các nhà nghiên cứu đã nhóm các gói RTP theo giá trị SSRC (Mã định danh nguồn đồng bộ hóa) trong RTP header. Mỗi giá trị SSRC xác định một người tham gia. Với mỗi SSRC, các nhà nghiên cứu đã ghép lại các NALU phân đoạn H264 theo đúng thứ tự bằng cách sử dụng dấu thời gian và số thứ tự RTP, sau đó giải mã chúng bằng khóa AES-128 trong chế độ ECB, tiếp đến giải nén kết quả được giải mã (sử dụng giá trị độ dài 4 byte), và cuối cùng là ghi dữ liệu được giải mã vào đĩa trong tệp luồng H.264 thô. Tệp có thể được phát bằng lệnh VLC media player sau:
Xác định âm thanh được mã hóa
Các nhà nghiên cứu cũng nhận thấy các gói khác trong Wireshark bắt đầu với giá trị tiêu đề 0x050f0100 và RTP header trong các gói này thường chứa type value 112. Trong các gói này, dấu thời gian RTP được tăng thêm 640 giữa các gói tiếp theo. Các nhà nghiên cứu đã tìm thấy một bài nghiên cứu mô tả cách suy ra loại codec âm thanh RTP bằng cách xem các siêu dữ liệu khác nhau trong các gói RTP, bao gồm sự khác biệt giữa các dấu thời gian RTP trong các gói tiếp theo. Bài viết cung cấp một khả năng cho chênh lệch dấu thời gian là 640, đó là codec SILK do Skype phát triển, với tần số mẫu 16000Hz. Các nhà nghiên cứu cũng lưu ý rằng các tải trọng RTP trong các gói này dường như có định dạng mã hóa tương tự như các tải trọng NALU trong các gói video, mặc dù chúng dường như chứa một tiêu đề có độ dài 2 byte thay vì 4 byte.
Để trích xuất âm thanh cho từng người tham gia, trước tiên các nhà nghiên cứu nhóm các gói RTP theo SSRC, sau đó tạo ra một tệp SILK bắt đầu bằng các byte “#!SILK_V3” cho mỗi người tham gia (SSRC), rồi giải mã các byte theo giá trị độ dài 2 byte (sử dụng cùng khóa AES-128 trong chế độ ECB). Sau đó, các nhà nghiên cứu ghi các byte được giải mã, được thêm vào giá trị độ dài 2 byte (theo thứ tự byte little endian) từ tải trọng RTP và thu được bộ chuyển mã SILK và chuyển mã thành công từng tệp SILK thành MP3 chứa âm thanh từ một trong những người tham gia.
Xác định việc truyền khóa AES
Tiếp theo là tìm hiểu cách khóa mã hóa AES-128 (conf.skey) của cuộc họp được tạo ra. Các nhà nghiên cứu nhận thấy rằng trước lượng lưu lượng lớn trên UDP cổng 8801, đã có một số lưu lượng TLS giữa máy khách và các máy chủ Zoom. Các nhà nghiên cứu đã thiết lập mitmproxy để chặn lưu lượng TLS và cấu hình máy khách Zoom Linux để định tuyến lưu lượng TLS của nó thông qua mitmproxy. Máy khách Zoom xuất hiện cảnh báo rằng các chứng chỉ TLS giả được tạo bởi mitmproxy là không đáng tin cậy. Sau khi chọn tin tưởng các chứng chỉ, các nhà nghiên cứu đã thấy một loạt các tin nhắn được trao đổi giữa máy khách Zoom và máy chủ Zoom. Trong một tin nhắn, máy chủ Zoom đã gửi đi khóa mã hóa.
Một ví dụ về một conf.skey AES-128 được truyền từ máy chủ Zoom đến máy khách Zoom và được giải mã bằng mitmproxy.
Các nhà nghiên cứu không rõ liệu các máy chủ Zoom có sử dụng trình tạo số ngẫu nhiên an toàn bằng mật mã để tạo các khóa mã hóa cuộc họp hay không hoặc liệu các khóa có thể dự đoán được bằng cách nào đó hay không. Nhưng các nhà nghiên cứu xác nhận rằng tất cả những người tham gia cuộc họp Zoom có cùng giá trị conf.skey và rằng khóa này không thay đổi khi người dùng tham gia hoặc rời cuộc họp. Tuy nhiên, khóa sẽ thay đổi khi tất cả người dùng rời khỏi cuộc họp trong một khoảng thời gian; bất kỳ người dùng mới tham gia một cuộc họp trống sẽ dẫn đến việc tạo ra một giá trị conf.skey mới.
Kết luận: Zoom không phù hợp cho những gì bí mật
Sản phẩm của Zoom thân thiện với người dùng và đã nhanh chóng phát triển cơ sở người dùng của mình trong đại dịch COVID-19. Người dùng của Zoom tăng nhanh, cùng với cách mà hãng quảng cáo về khả năng mã hóa và bảo mật của phần mềm, đã thu hút nhiều cuộc hội thoại nhạy cảm. Sự phổ biến bất ngờ này có khả năng đưa sản phẩm vào tầm ngắm của các cơ quan tình báo chính phủ và tội phạm mạng.
Các khóa mã hóa nghi vấn được gửi tới Bắc Kinh
Thật không may cho những người hy vọng về quyền riêng tư, việc triển khai an ninh cuộc gọi trong Zoom có thể không phù hợp cho những trường hợp sử dụng đặc biệt. Các nhà nghiên cứu xác định rằng ứng dụng Zoom sử dụng các kỹ thuật mã hóa tiêu chuẩn phi công nghiệp với các điểm yếu có thể xác định được. Ngoài ra, trong nhiều cuộc gọi thử nghiệm ở Bắc Mỹ, theo các nhà nghiên cứu quan sát, các khóa để mã hóa và giải mã các cuộc họp được truyền đến các máy chủ ở Bắc Kinh, Trung Quốc.
Một ứng dụng có điểm yếu dễ nhận biết về mã hoá, tồn tại nhiều vấn đề bảo mật và có máy chủ đặt tại Trung Quốc? Đây rõ ràng là một mục tiêu không thể nằm ngoài tầm ngắm của những tin tặc do nhà nước bảo trợ, bao gồm cả Cộng hòa Nhân dân Trung Hoa.
Báo cáo được đưa ra trong bối cảnh có nhiều nghiên cứu và vụ kiện gần đây xác định các lo ngại về bảo mật và quyền riêng tư tiềm năng khác với ứng dụng Zoom. Ngoài ra, các nhóm vận động cũng chỉ ra rằng Zoom thiếu báo cáo minh bạch, một bước quan trọng để giải quyết các lo ngại phát sinh khi các công ty có quyền truy cập vào dữ liệu người dùng nhạy cảm. Zoom vừa tuyên bố (ngày 2 tháng 4 năm 2020) rằng sẽ phát hành một báo cáo như vậy trong vòng 90 ngày.
Do các vấn đề bảo mật đáng lo ngại này, các nhà nghiên cứu không khuyến khích sử dụng Zoom tại thời điểm này cho các trường hợp sử dụng đòi hỏi quyền riêng tư và bảo mật mạnh mẽ, bao gồm:
- Chính phủ
- Các doanh nghiệp quan tâm đến tội phạm mạng và gián điệp công nghiệp
- Nhà cung cấp chăm sóc sức khỏe xử lý thông tin bệnh nhân nhạy cảm
- Các nhà hoạt động, luật sư và nhà báo làm việc về các chủ đề nhạy cảm
Đối với những người sử dụng Zoom để giữ liên lạc với bạn bè, tổ chức các sự kiện xã hội hoặc tổ chức các khóa học hoặc bài giảng mà họ có thể tổ chức ở một địa điểm công cộng hoặc bán công khai, những phát hiện trên đây không mấy ảnh hưởng.
Theo các nhà nghiên cứu, đối với những người không có lựa chọn nào khác ngoài sử dụng Zoom, plugin trình duyệt có thể có một số thuộc tính bảo mật tốt hơn một chút vì việc truyền dữ liệu xảy ra qua TLS.
Sử dụng mật khẩu Zoom, tránh sử dụng Waiting Room
Các nhà nghiên cứu cũng đã đã xác định một vấn đề bảo mật nghiêm trọng với tính năng Waiting Room của Zoom. Lỗ hổng đã được báo cáo cho Zoom và hy vọng rằng công ty sẽ nhanh chóng hành động để vá và đưa ra tư vấn an ninh. Trong thời gian này, người dùng Zoom muốn bảo mật không nên sử dụng tính năng Waiting Room của Zoom. Thay vào đó, người dùng được khuyến cáo sử dụng tính năng mật khẩu Zoom, có vẻ như cung cấp mức độ bảo mật cao hơn so với Waiting Room.
Dưới đây là những phát hiện chính của nghiên cứu:
- Tài liệu của Zoom tuyên bố rằng ứng dụng sử dụng mã hóa AES-256 cho các cuộc họp. Tuy nhiên, các nhà nghiên cứu thấy rằng trong mỗi cuộc họp Zoom, một khóa AES-128 duy nhất được sử dụng ở chế độ ECB (chế độ mã hóa từng khối byte độc lập) để mã hóa và giải mã âm thanh và video. Việc sử dụng chế độ ECB không được khuyến khích vì các mẫu (pattern) ở dạng plaintext được giữ nguyên trong quá trình mã hóa.
- Các khóa AES-128, mà các nhà nghiên cứu đã xác minh là đủ để giải mã các gói tin Zoom bị chặn trên Internet dường như được tạo ra từ các máy chủ Zoom và trong một số trường hợp, được gửi đến người tham gia cuộc họp qua máy chủ ở Trung Quốc, ngay cả khi tất cả người tham gia họp và công ty của người đăng ký Zoom đều ở bên ngoài Trung Quốc.
- Zoom, một công ty có trụ sở tại Thung lũng Silicon, dường như sở hữu ba công ty ở Trung Quốc với ít nhất 700 nhân viên được trả lương để phát triển phần mềm Zoom. Đây rõ ràng là một nỗ lực để khai thác lao động giá rẻ: Zoom không phải trả mức lương ở Mỹ nhưng lại bán cho khách hàng Mỹ, qua đó tăng lợi nhuận biên. Tuy nhiên, điều này có thể khiến Zoom phải thỏa hiệp với áp lực từ chính quyền Trung Quốc.
Công ty Mỹ có trái tim ở Trung Quốc?
Zoom là một ứng dụng viễn thông có mức độ phổ biến tăng lên đáng kể thời gian gần đây do phần lớn thế giới đang làm việc tại nhà trước sự lây lan của dịch bệnh COVID-19.
Logo của Zoom ở phía trên tên của công ty phát triển Trung Quốc Ruanshi Software (Suzhou) Ltd.
Mặc dù Zoom có trụ sở chính tại Mỹ và được niêm yết trên sàn giao dịch chứng khoán NASDAQ, ứng dụng chính của Zoom dường như được phát triển bởi ba công ty ở Trung Quốc. Hai trong số ba công ty này thuộc sở hữu của Zoom đều có tên là Ruanshi Software, trong khi công ty còn lại thuộc sở hữu của một thực thể có tên American Cloud Video Software Technology Co., Ltd. Các bài tuyển dụng cho Ruanshi Software ở Tô Châu bao gồm các vị trí mở cho lập trình viên C++, nhà phát triển ứng dụng Android và iOS...
Hồ sơ nộp lên Ủy ban Giao dịch và Chứng khoán Mỹ (SEC) gần đây của Zoom cho thấy công ty sử dụng ít nhất 700 nhân viên tại Trung Quốc làm công việc nghiên cứu và phát triển. Hồ sơ cũng ngụ ý rằng 81% doanh thu của Zoom đến từ Bắc Mỹ. Thực hiện công việc phát triển ở Trung Quốc giúp Zoom tiết kiệm tiền lương phải trả cho Thung lũng Silicon, giảm chi phí và tăng tỷ suất lợi nhuận. Tuy nhiên, việc này cũng có thể khiến Zoom phải thỏa hiệp với các áp lực từ chính quyền Trung Quốc. Dù tên miền chính của Zoom (zoom.us) đã bị chặn ở Trung Quốc vào tháng 11 năm 2019, vẫn có một số công ty Trung Quốc bán ứng dụng Zoom ở Trung Quốc (ví dụ: zoom.cn, zoomvip.cn, zoomcloud.cn).
Vấn đề mã hóa được đưa ra ánh sáng
Tài liệu mô tả của Zoom có một số tuyên bố không rõ ràng về mã hóa mà nền tảng này cung cấp. Một số tài liệu của Zoom (cũng như chính ứng dụng Zoom) tuyên bố Zoom cung cấp một tính năng giúp các cuộc họp được mã hóa đầu cuối (end-to-end).
Thông báo trên ứng dụng Zoom tuyên bố một cuộc gọi được mã hóa end-to-end
Thông thường, cộng đồng an ninh máy tính hiểu thuật ngữ mã hóa đầu cuối end-to-end có nghĩa là chỉ các bên tham gia giao tiếp mới có thể truy cập (bên trung gian chuyển tiếp liên lạc cũng không thể truy cập). Tài liệu khác của Zoom nói rằng phần mềm họp trực tuyến Zoom cho Windows, MacOS và Linux, theo mặc định, sử dụng TLS 1.2 tiêu chuẩn công nghiệp để mã hóa truyền tin, dù bài đăng trên blog tháng 9/2014 ngụ ý rằng phần mềm này không sử dụng TLS.
Zoom tuyên bố sử dụng mã hóa TLS và AES
Để giải quyết sự nhầm lẫn này, Zoom đã phát hành một bài đăng trên blog vào tháng 4/2020 mô tả sơ đồ mã hóa của mình. Bài đăng làm rõ rằng Zoom hiện không triển khai mã hóa đầu cuối end-to-end như hầu hết mọi người vẫn hiểu thuật ngữ này. Định nghĩa của Zoom về end-to-end dường như không giống với các tiêu chuẩn thông thường. Vì Zoom không thực hiện mã hóa đầu cuối thực sự nên về mặt lý thuyết họ có khả năng để giải mã và giám sát các cuộc gọi Zoom. Tuy nhiên, Zoom đề cập rằng họ chưa xây dựng bất kỳ cơ chế nào để can thiệp các cuộc họp của khách hàng: “Zoom chưa bao giờ xây dựng một cơ chế để giải mã các cuộc họp trực tiếp, chúng tôi cũng không có ý định chèn nhân viên hoặc người khác vào các cuộc họp mà không hiển thị tên trong danh sách người tham gia”.
Tuy nhiên, bài viết trên blog của không cung cấp chi tiết về cách thức mã hóa của họ hoạt động hoặc làm rõ họ sử dụng TLS hay AES-256. Vì vậy các nhà nghiên cứu đã quyết định tìm hiểu cách mã hóa các cuộc họp của Zoom.
Zoom trở thành mục tiêu tình báo
Thành công của Zoom khiến các cuộc hội thoại của nó được nhiều chính phủ quan tâm. Và điều này có thể làm cho Zoom trở thành mục tiêu ưu tiên cao cho việc thu thập thông tin tình báo tín hiệu (SIGINT) và các hoạt động xâm nhập nhắm mục tiêu khác.
Ngoài ra, như nhóm bảo vệ quyền kỹ thuật số Access Now đã chỉ ra trong một thư ngỏ kêu gọi báo cáo minh bạch, Zoom không tiết lộ công khai thông tin như thống kê yêu cầu dữ liệu của chính phủ và những gì Zoom đã thực hiện để đáp ứng các yêu cầu này. Các chính sách của Zoom liên quan đến thông báo cho người dùng về những vi phạm dữ liệu hoặc bàn giao dữ liệu cho chính phủ cũng chưa được biết đến, tuy nhiên công ty đã hứa sẽ báo cáo về những thông tin này trong vòng 90 ngày kể từ ngày 2/4.
Máy chủ Trung Quốc và vấn đề bảo mật
Thay vì sử dụng giao thức chuẩn để gửi âm thanh và video, Zoom thực thi giao thức truyền tin của riêng họ, dường như là một phần mở rộng của tiêu chuẩn RTP hiện có.
Giao thức truyền tin của Zoom bổ sung phương thức mã hóa riêng vào RTP. Theo mặc định, tất cả âm thanh và video của người tham gia cuộc họp Zoom dường như được mã hóa và giải mã bằng một khóa AES-128 được chia sẻ giữa những người tham gia. Khóa AES dường như được tạo và phân phối cho những người tham gia cuộc họp bằng các máy chủ Zoom. Mã hóa và giải mã của Zoom sử dụng AES trong chế độ ECB. Đây không phải là một ý tưởng hay vì các nguyên mẫu vẫn ở dạng plaintext. Các giao thức tiêu chuẩn công nghiệp để mã hóa phương tiện truyền phát trực tuyến (như tiêu chuẩn SRTP) khuyến nghị sử dụng AES trong Chế độ Segmented Integer Counter (Số nguyên phân đoạn) hoặc chế độ f8, vốn không có điểm yếu giống như chế độ ECB.
Cấu trúc liên kết cuộc gọi Zoom trong nghiên cứu
Trong quá trình thử nghiệm cuộc họp Zoom với hai người dùng, một ở Mỹ và một ở Canada, các nhà nghiên cứu thấy rằng khóa AES-128 để mã hóa và giải mã hội nghị được gửi đến một trong những người tham gia qua TLS từ máy chủ Zoom được đặt ở Bắc Kinh, 52.81.151.250. Quét thử cho thấy tổng cộng năm máy chủ ở Trung Quốc và 68 ở Mỹ dường như chạy cùng phần mềm máy chủ Zoom như máy chủ ở Bắc Kinh. Các nhà nghiên cứu nghi ngờ rằng các khóa có thể được phân phối thông qua các máy chủ này. Một công ty chủ yếu phục vụ khách hàng Bắc Mỹ đôi khi phân phối khóa mã hóa thông qua các máy chủ ở Trung Quốc là rất đáng quan ngại vì có khả năng Zoom có thể có nghĩa vụ pháp lý phải tiết lộ các khóa này cho chính quyền ở Trung Quốc.
Nghiên cứu được thực hiện như thế nào?
Trước tiên, các nhà nghiên cứu đã quan sát lưu lượng truy cập Internet được liên kết với các cuộc họp Zoom sử dụng các máy khách Zoom trên Windows, MacOS và Linux. Sau đó, sử dụng Wireshark để ghi lại lưu lượng truy cập Internet khi tham gia vào các cuộc họp Zoom. Phần lớn lưu lượng truy cập Internet trong các cuộc họp Zoom của các nhà nghiên cứu được trao đổi giữa máy tính và máy chủ do Zoom sở hữu trên UDP cổng 8801. Kiểm tra thêm về lưu lượng UDP cho thấy Zoom rõ ràng đã thiết kế giao thức truyền tin của riêng họ dựa trên giao thức RTP nổi tiếng để truyền âm thanh và video.
Xác định video được mã hóa
Trên một số gói có tải trọng UDP bắt đầu bằng 0x05100100, RTP header (Giao thức truyền tin thời gian thực) thường được mã hóa type value (giá trị loại) 98. Trong các gói này, tải trọng RTP dường như chứa luồng video H.264 sử dụng định dạng trong RFC 6184. Trong định dạng này, tải trọng RTP là một chuỗi gồm một hoặc nhiều NALU (Đơn vị lớp mạng trừu tượng), chứa các thành phần của video (ví dụ: các loại khung video, siêu dữ liệu khác nhau trong cài đặt bộ giải mã, v.v.). Một số NALU đã bị phân mảnh bằng cách sử dụng lược đồ từ RFC cho Fragmentation Unit A” (FU-A) (Đơn vị phân mảnh). Các nhà nghiên cứu lắp chúng lại thành NALU không phân mảnh. Trên mỗi RFC, mỗi NALU có một type value cho biết nó đang chứa thành phần nào của video. Trong trường hợp của Zoom, tất cả các giá trị NALU được đặt về 0, vốn không hợp lệ trên mỗi RFC, vì vậy các nhà nghiên cứu nghi ngờ rằng tải trọng NALU là một định dạng được đặt trước cho Zoom.
NALU bao gồm một giá trị 4 byte big-endian dường như để mô tả độ dài (các giá trị 4 byte này đều nhỏ hơn nhưng gần bằng kích thước của các gói), theo sau là một số byte luôn luôn là bội số thấp nhất của 16 mà lớn hơn giá trị độ dài 4 byte (nghĩa là, nếu giá trị độ dài 4 byte nằm trong khoảng từ 145 đến 160 thì nó sẽ được theo sau bởi 160 byte). Điều này gợi ý việc sử dụng sơ đồ mã hóa AES, vốn hoạt động trên các khối 16 byte. Nếu độ dài của tin nhắn được mã hóa không phải là bội số của 16 byte thì phần đệm được thêm vào cuối tin nhắn để tăng độ dài lên bội số của 16. Kiểm tra kết xuất bộ nhớ của quy trình Zoom trong cuộc họp đã tiết lộ một khóa AES-128 trong bộ nhớ được liên kết với chuỗi conf.skey, mà các nhà nghiên cứu suy đoán là viết tắt của “conference secret key (khóa bí mật hội nghị)”.
Để trích xuất video cho từng người tham gia, trước tiên các nhà nghiên cứu đã nhóm các gói RTP theo giá trị SSRC (Mã định danh nguồn đồng bộ hóa) trong RTP header. Mỗi giá trị SSRC xác định một người tham gia. Với mỗi SSRC, các nhà nghiên cứu đã ghép lại các NALU phân đoạn H264 theo đúng thứ tự bằng cách sử dụng dấu thời gian và số thứ tự RTP, sau đó giải mã chúng bằng khóa AES-128 trong chế độ ECB, tiếp đến giải nén kết quả được giải mã (sử dụng giá trị độ dài 4 byte), và cuối cùng là ghi dữ liệu được giải mã vào đĩa trong tệp luồng H.264 thô. Tệp có thể được phát bằng lệnh VLC media player sau:
$ vlc raw.h264 --demux h264
Xác định âm thanh được mã hóa
Các nhà nghiên cứu cũng nhận thấy các gói khác trong Wireshark bắt đầu với giá trị tiêu đề 0x050f0100 và RTP header trong các gói này thường chứa type value 112. Trong các gói này, dấu thời gian RTP được tăng thêm 640 giữa các gói tiếp theo. Các nhà nghiên cứu đã tìm thấy một bài nghiên cứu mô tả cách suy ra loại codec âm thanh RTP bằng cách xem các siêu dữ liệu khác nhau trong các gói RTP, bao gồm sự khác biệt giữa các dấu thời gian RTP trong các gói tiếp theo. Bài viết cung cấp một khả năng cho chênh lệch dấu thời gian là 640, đó là codec SILK do Skype phát triển, với tần số mẫu 16000Hz. Các nhà nghiên cứu cũng lưu ý rằng các tải trọng RTP trong các gói này dường như có định dạng mã hóa tương tự như các tải trọng NALU trong các gói video, mặc dù chúng dường như chứa một tiêu đề có độ dài 2 byte thay vì 4 byte.
Để trích xuất âm thanh cho từng người tham gia, trước tiên các nhà nghiên cứu nhóm các gói RTP theo SSRC, sau đó tạo ra một tệp SILK bắt đầu bằng các byte “#!SILK_V3” cho mỗi người tham gia (SSRC), rồi giải mã các byte theo giá trị độ dài 2 byte (sử dụng cùng khóa AES-128 trong chế độ ECB). Sau đó, các nhà nghiên cứu ghi các byte được giải mã, được thêm vào giá trị độ dài 2 byte (theo thứ tự byte little endian) từ tải trọng RTP và thu được bộ chuyển mã SILK và chuyển mã thành công từng tệp SILK thành MP3 chứa âm thanh từ một trong những người tham gia.
$ sh convert.sh raw.silk mp3
Một sơ đồ lớp giao thức cho thấy tính đóng gói hiện diện trên các gói Zoom video (bên trái) và âm thanh (bên phải).
Một sơ đồ lớp giao thức cho thấy tính đóng gói hiện diện trên các gói Zoom video (bên trái) và âm thanh (bên phải).
Xác định việc truyền khóa AES
Tiếp theo là tìm hiểu cách khóa mã hóa AES-128 (conf.skey) của cuộc họp được tạo ra. Các nhà nghiên cứu nhận thấy rằng trước lượng lưu lượng lớn trên UDP cổng 8801, đã có một số lưu lượng TLS giữa máy khách và các máy chủ Zoom. Các nhà nghiên cứu đã thiết lập mitmproxy để chặn lưu lượng TLS và cấu hình máy khách Zoom Linux để định tuyến lưu lượng TLS của nó thông qua mitmproxy. Máy khách Zoom xuất hiện cảnh báo rằng các chứng chỉ TLS giả được tạo bởi mitmproxy là không đáng tin cậy. Sau khi chọn tin tưởng các chứng chỉ, các nhà nghiên cứu đã thấy một loạt các tin nhắn được trao đổi giữa máy khách Zoom và máy chủ Zoom. Trong một tin nhắn, máy chủ Zoom đã gửi đi khóa mã hóa.
Một ví dụ về một conf.skey AES-128 được truyền từ máy chủ Zoom đến máy khách Zoom và được giải mã bằng mitmproxy.
Các nhà nghiên cứu không rõ liệu các máy chủ Zoom có sử dụng trình tạo số ngẫu nhiên an toàn bằng mật mã để tạo các khóa mã hóa cuộc họp hay không hoặc liệu các khóa có thể dự đoán được bằng cách nào đó hay không. Nhưng các nhà nghiên cứu xác nhận rằng tất cả những người tham gia cuộc họp Zoom có cùng giá trị conf.skey và rằng khóa này không thay đổi khi người dùng tham gia hoặc rời cuộc họp. Tuy nhiên, khóa sẽ thay đổi khi tất cả người dùng rời khỏi cuộc họp trong một khoảng thời gian; bất kỳ người dùng mới tham gia một cuộc họp trống sẽ dẫn đến việc tạo ra một giá trị conf.skey mới.
Kết luận: Zoom không phù hợp cho những gì bí mật
Sản phẩm của Zoom thân thiện với người dùng và đã nhanh chóng phát triển cơ sở người dùng của mình trong đại dịch COVID-19. Người dùng của Zoom tăng nhanh, cùng với cách mà hãng quảng cáo về khả năng mã hóa và bảo mật của phần mềm, đã thu hút nhiều cuộc hội thoại nhạy cảm. Sự phổ biến bất ngờ này có khả năng đưa sản phẩm vào tầm ngắm của các cơ quan tình báo chính phủ và tội phạm mạng.
Các khóa mã hóa nghi vấn được gửi tới Bắc Kinh
Thật không may cho những người hy vọng về quyền riêng tư, việc triển khai an ninh cuộc gọi trong Zoom có thể không phù hợp cho những trường hợp sử dụng đặc biệt. Các nhà nghiên cứu xác định rằng ứng dụng Zoom sử dụng các kỹ thuật mã hóa tiêu chuẩn phi công nghiệp với các điểm yếu có thể xác định được. Ngoài ra, trong nhiều cuộc gọi thử nghiệm ở Bắc Mỹ, theo các nhà nghiên cứu quan sát, các khóa để mã hóa và giải mã các cuộc họp được truyền đến các máy chủ ở Bắc Kinh, Trung Quốc.
Một ứng dụng có điểm yếu dễ nhận biết về mã hoá, tồn tại nhiều vấn đề bảo mật và có máy chủ đặt tại Trung Quốc? Đây rõ ràng là một mục tiêu không thể nằm ngoài tầm ngắm của những tin tặc do nhà nước bảo trợ, bao gồm cả Cộng hòa Nhân dân Trung Hoa.
Báo cáo được đưa ra trong bối cảnh có nhiều nghiên cứu và vụ kiện gần đây xác định các lo ngại về bảo mật và quyền riêng tư tiềm năng khác với ứng dụng Zoom. Ngoài ra, các nhóm vận động cũng chỉ ra rằng Zoom thiếu báo cáo minh bạch, một bước quan trọng để giải quyết các lo ngại phát sinh khi các công ty có quyền truy cập vào dữ liệu người dùng nhạy cảm. Zoom vừa tuyên bố (ngày 2 tháng 4 năm 2020) rằng sẽ phát hành một báo cáo như vậy trong vòng 90 ngày.
Do các vấn đề bảo mật đáng lo ngại này, các nhà nghiên cứu không khuyến khích sử dụng Zoom tại thời điểm này cho các trường hợp sử dụng đòi hỏi quyền riêng tư và bảo mật mạnh mẽ, bao gồm:
- Chính phủ
- Các doanh nghiệp quan tâm đến tội phạm mạng và gián điệp công nghiệp
- Nhà cung cấp chăm sóc sức khỏe xử lý thông tin bệnh nhân nhạy cảm
- Các nhà hoạt động, luật sư và nhà báo làm việc về các chủ đề nhạy cảm
Đối với những người sử dụng Zoom để giữ liên lạc với bạn bè, tổ chức các sự kiện xã hội hoặc tổ chức các khóa học hoặc bài giảng mà họ có thể tổ chức ở một địa điểm công cộng hoặc bán công khai, những phát hiện trên đây không mấy ảnh hưởng.
Theo các nhà nghiên cứu, đối với những người không có lựa chọn nào khác ngoài sử dụng Zoom, plugin trình duyệt có thể có một số thuộc tính bảo mật tốt hơn một chút vì việc truyền dữ liệu xảy ra qua TLS.
Sử dụng mật khẩu Zoom, tránh sử dụng Waiting Room
Các nhà nghiên cứu cũng đã đã xác định một vấn đề bảo mật nghiêm trọng với tính năng Waiting Room của Zoom. Lỗ hổng đã được báo cáo cho Zoom và hy vọng rằng công ty sẽ nhanh chóng hành động để vá và đưa ra tư vấn an ninh. Trong thời gian này, người dùng Zoom muốn bảo mật không nên sử dụng tính năng Waiting Room của Zoom. Thay vào đó, người dùng được khuyến cáo sử dụng tính năng mật khẩu Zoom, có vẻ như cung cấp mức độ bảo mật cao hơn so với Waiting Room.
Theo Citizen Lab
Chỉnh sửa lần cuối: