Bảo mật nghiêm trọng: Microsoft Office 365 bị tấn công qua mã hóa yếu

Chúng tôi không chắc nên gọi nó là gì ngay bây giờ, vì vậy chúng tôi đã gọi nó trong tiêu đề bằng tên kết hợp Microsoft Office 365.

(Tên “Office” là danh từ chung cho các ứng dụng xử lý văn bản, bảng tính, bản trình bày và cộng tác của Microsoft đang được giết chết trong một hoặc hai tháng tới, đơn giản trở thành “Microsoft 365”.)

Chúng tôi chắc chắn rằng mọi người sẽ tiếp tục sử dụng các tên ứng dụng riêng lẻ (Từ, Excel, PowerPoint và bạn bè) và biệt danh của suite Office trong nhiều năm, mặc dù những người mới sử dụng phần mềm có thể sẽ biết nó là 365, sau khi bỏ tiền tố Microsoft phổ biến.

Như bạn có thể biết, các ứng dụng Office độc ​​lập (những ứng dụng bạn thực sự cài đặt cục bộ để bạn không phải trực tuyến để làm việc với nội dung của mình) bao gồm tùy chọn riêng của chúng để mã hóa các tài liệu đã lưu.

Điều này được cho là sẽ thêm một lớp bảo mật bổ sung trong trường hợp sau đó bạn chia sẻ bất kỳ tệp nào trong số đó, do ngẫu nhiên hoặc do thiết kế, với người không được cho là nhận chúng - một điều đáng ngạc nhiên là rất dễ thực hiện khi nhầm lẫn khi chia sẻ tệp đính kèm qua email.

Trừ khi và cho đến khi bạn cung cấp cho người nhận mật khẩu mà họ cần để mở khóa tệp, nếu không thì đối với họ chỉ là quá nhiều bắp cải vụn.

Tất nhiên, nếu bạn đưa mật khẩu vào nội dung email, bạn sẽ chẳng thu được gì, nhưng nếu bạn thậm chí hơi thận trọng khi chia sẻ mật khẩu qua một kênh khác, bạn đã mua cho mình một số an toàn và bảo mật bổ sung để chống lại những kẻ lừa đảo , snoops và ne'er-do-well dễ dàng truy cập vào nội dung bí mật.

OME dưới ánh đèn sân khấu

Hay có bạn?

Theo nhà nghiên cứu tại công ty an ninh mạng WithSecure của Phần Lan, dữ liệu của bạn có thể được bảo vệ ít hơn nhiều mà bạn có thể mong đợi một cách hợp lý.

Tính năng mà những người thử nghiệm đã sử dụng là những gì họ gọi là Mã hóa Thư Office 365, hoặc là OME cho ngắn gọn

Chúng tôi đã không tái tạo các thử nghiệm của họ ở đây, vì lý do đơn giản là Office cốt lõi, xin lỗi, các sản phẩm 365 không chạy nguyên bản trên Linux mà chúng tôi sử dụng cho công việc. Các phiên bản dựa trên web của các công cụ Office không có bộ tính năng tương tự như các ứng dụng đầy đủ, vì vậy bất kỳ kết quả nào chúng tôi có thể nhận được không chắc sẽ phù hợp với cách hầu hết người dùng Office doanh nghiệp, ah, 365 đã định cấu hình Word, Excel, Outlook và bạn bè trên máy tính xách tay Windows của họ.

Như các nhà nghiên cứu mô tả nó:

Tính năng này được quảng cáo là cho phép các tổ chức gửi và nhận thư email được mã hóa giữa những người bên trong và bên ngoài tổ chức của bạn một cách an toàn.

Nhưng họ cũng chỉ ra rằng:

Rất tiếc, các tin nhắn OME được mã hóa trong chế độ hoạt động của Sổ mã điện tử (ECB) không an toàn.

ECB giải thích

Giải thích.

Nhiều thuật toán mã hóa, đặc biệt là Advanced Encryption Standard hoặc AES, mà OME sử dụng, được gọi là mật mã khối, xáo trộn các khối dữ liệu lớn tại một thời điểm, thay vì xử lý các bit hoặc byte riêng lẻ theo trình tự.

Nói chung, điều này được cho là sẽ giúp cả hiệu quả và bảo mật, bởi vì mật mã có nhiều dữ liệu đầu vào hơn để trộn-mince-shred-and-liquidise ở mỗi lượt của tay quay mật mã thúc đẩy thuật toán và mỗi lượt giúp bạn tiến xa hơn thông qua dữ liệu bạn muốn mã hóa.

Ví dụ, thuật toán AES cốt lõi tiêu thụ 16 byte văn bản rõ đầu vào (128 bit) cùng một lúc và xáo trộn dữ liệu đó dưới một khóa mã hóa để tạo ra 16 byte đầu ra bản mã được mã hóa.

(Đừng nhầm lẫn kích thước khối với kích thước chính - Các khóa mã hóa AES có thể dài 128 bit, 192 bit hoặc 256 bit, tùy thuộc vào mức độ bạn không muốn chúng đoán được, nhưng cả ba kích thước khóa đều hoạt động trên các khối 128 bit mỗi khi thuật toán được “quay”.)

Điều này có nghĩa là nếu bạn chọn một khóa AES (bất kể độ dài) và sau đó sử dụng mật mã AES trực tiếp trên một phần dữ liệu…

…sau đó mỗi khi bạn nhận được cùng một đoạn đầu vào, bạn sẽ nhận được cùng một đoạn đầu ra.

Giống như một cuốn sách mã thực sự lớn

Đó là lý do tại sao phương thức hoạt động trực tiếp này được gọi là ECB, viết tắt của sổ mã điện tử, bởi vì nó giống như có một cuốn sách mã khổng lồ có thể được sử dụng như một bảng tra cứu để mã hóa và giải mã.

(Một “sổ mã” đầy đủ không bao giờ có thể được xây dựng trong cuộc sống thực, bởi vì bạn cần lưu trữ một cơ sở dữ liệu bao gồm 2¹²⁸ Các mục 16 byte cho mỗi chìa khóa có thể.)

Thật không may, đặc biệt là trong dữ liệu được định dạng bằng máy tính, việc lặp lại một số phần dữ liệu nhất định thường là không thể tránh khỏi, nhờ vào định dạng tệp được sử dụng.

Ví dụ: các tệp thường xuyên chèn các phần dữ liệu để chúng xếp hàng trên ranh giới 512 byte (kích thước khu vực phổ biến khi ghi vào đĩa) hoặc đến ranh giới 4096 byte (kích thước đơn vị cấp phát phổ biến khi dự trữ bộ nhớ) thường sẽ tạo ra các tệp có chạy dài không byte.

Tương tự như vậy, các tài liệu văn bản chứa nhiều bản soạn sẵn, chẳng hạn như đầu trang và chân trang trên mỗi trang, hoặc đề cập nhiều lần đến tên công ty đầy đủ, sẽ chứa nhiều lần lặp lại.

Mỗi khi một đoạn văn bản rõ lặp lại chỉ xảy ra xếp hàng trên ranh giới 16 byte trong quy trình mã hóa AES-ECB, do đó nó sẽ xuất hiện trong quá trình mã hóa giống hệt như cùng một bản mã.

Vì vậy, ngay cả khi bạn không thể giải mã theo bước tiến của tệp bản mã, bạn vẫn có thể đưa ra các suy luận ngay lập tức, mang tính bảo mật cao từ nó, nhờ vào thực tế là các mẫu trong đầu vào (mà bạn có thể biết hoặc có thể suy ra, hoặc đoán) được giữ nguyên trong đầu ra.

Đây là một ví dụ dựa trên một bài báo mà chúng tôi đã xuất bản gần chín năm trước khi chúng tôi giải thích lý do tại sao việc sử dụng mã hóa chế độ ECB khét tiếng hiện nay của Adobe để "băm" mật khẩu của người dùng là Không phải là một ý tưởng tốt:

Lưu ý cách các pixel có màu trắng đồng nhất trong đầu vào tạo ra một mẫu lặp đi lặp lại trong đầu ra một cách đáng tin cậy và các phần màu xanh lam vẫn hơi đều đặn, để cấu trúc của dữ liệu ban đầu là rõ ràng.

Trong ví dụ này, mỗi pixel trong tệp gốc chiếm đúng 4 byte, do đó, mỗi lần chạy 4 pixel từ trái sang phải trong dữ liệu đầu vào dài 16 byte, căn chỉnh chính xác với từng khối mã hóa AES 16 byte, do đó làm nổi bật "Hiệu ứng ECB".

---

Phù hợp với các mẫu bản mã

Thậm chí tệ hơn, nếu bạn có hai tài liệu mà bạn biết được mã hóa bằng cùng một khóa và bạn chỉ tình cờ có bản rõ của một trong số chúng, thì bạn có thể xem qua bản mã mà bạn không thể giải mã và cố gắng khớp các phần của nó với các mẫu trong bản mã mà bạn có thể giải mã.

Hãy nhớ rằng bạn không cần chìa khóa để “giải mã” tài liệu đầu tiên nếu bạn đã có nó ở dạng giải mã - điều này được biết đến, không có gì đáng ngạc nhiên, như một tấn công văn bản rõ ràng đã biết.

Ngay cả khi chỉ có một số trùng khớp của văn bản có vẻ vô tội mà bản thân nó không phải là dữ liệu bí mật, thì kiến ​​thức mà kẻ thù có thể trích xuất theo cách này có thể là một mỏ vàng cho các điệp viên sở hữu trí tuệ, kỹ sư xã hội, nhà điều tra pháp y, v.v.

Ví dụ: ngay cả khi bạn không biết chi tiết của tài liệu đề cập đến điều gì, bằng cách đối sánh các đoạn văn bản rõ đã biết trên nhiều tệp, bạn có thể xác định rằng một bộ sưu tập tài liệu dường như ngẫu nhiên:

• Tất cả đều được gửi đến cùng một người nhận, nếu có một câu chào thông thường ở đầu mỗi người.
• Tham khảo cùng một dự án, nếu có một chuỗi văn bản nhận dạng duy nhất liên tục xuất hiện.
• Có cùng phân loại bảo mật, nếu bạn muốn tập trung vào những thứ rõ ràng là "bí mật" hơn những thứ còn lại.

Phải làm gì?

Không sử dụng chế độ ECB!

Nếu bạn đang sử dụng mật mã khối, hãy chọn chế độ vận hành mật mã khối rằng:

• Bao gồm những gì được gọi là IV hoặc vectơ khởi tạo, được chọn ngẫu nhiên và duy nhất cho mỗi tin nhắn.
• Cố ý sắp xếp quá trình mã hóa để các đầu vào lặp đi lặp lại xuất hiện khác nhau mọi lúc.

Nếu bạn đang sử dụng AES, chế độ bạn có thể muốn chọn những ngày này là AES-GCM (Chế độ bộ đếm Galois), không chỉ sử dụng IV để tạo luồng dữ liệu mã hóa khác nhau mọi lúc, ngay cả khi khóa vẫn giữ nguyên, mà còn tính toán những gì được gọi là Mã xác thực tin nhắn (MAC), hoặc tổng kiểm tra mật mã, đồng thời với việc xáo trộn hoặc giải mã dữ liệu.

AES-GCM không chỉ có nghĩa là bạn tránh được các mẫu bản mã lặp lại mà còn giúp bạn luôn kết thúc với một “tổng kiểm tra” sẽ cho bạn biết liệu dữ liệu bạn vừa giải mã có bị giả mạo trong quá trình thực hiện hay không.

Hãy nhớ rằng kẻ gian không biết bản mã thực sự có nghĩa là gì, tuy nhiên có thể lừa bạn tin tưởng vào một bản giải mã không chính xác mà không bao giờ biết (hoặc quan tâm) đến loại kết quả đầu ra không chính xác nào.

MAC được tính toán trong quá trình giải mã, dựa trên cùng một khóa và IV, sẽ giúp đảm bảo rằng bạn biết rằng bản mã bạn nhận được là hợp lệ và do đó bạn gần như chắc chắn đã giải mã được những gì ban đầu được đưa vào ở đầu kia.

Ngoài ra, hãy sử dụng một mật mã dòng tạo ra luồng khóa byte-by-byte giả ngẫu nhiên cho phép bạn mã hóa dữ liệu mà không cần phải xử lý 16 byte (hoặc bất kỳ kích thước khối nào có thể là) tại một thời điểm.

AES-GCM về cơ bản chuyển đổi AES thành mật mã luồng và thêm xác thực dưới dạng MAC, nhưng nếu bạn đang tìm kiếm một mật mã luồng chuyên dụng được thiết kế đặc biệt để hoạt động theo cách đó, chúng tôi đề xuất Daniel Bernstein's ChaCha20-Poly1305 (phần Poly1305 là MAC), như chi tiết trong RFC 8439.

Dưới đây, chúng tôi đã hiển thị những gì chúng tôi nhận được khi sử dụng AES-128-GCM và ChaCha20-Poly1305 (chúng tôi đã loại bỏ mã MAC ở đây), cùng với một “hình ảnh” bao gồm 95,040 byte RGBA (330 × 72 ở 4 byte trên mỗi pixel) từ Trình tạo giả ngẫu nhiên hạt nhân Linux.

Hãy nhớ rằng chỉ vì dữ liệu trông không có cấu trúc không có nghĩa là nó thực sự ngẫu nhiên, nhưng nếu nó trông không ngẫu nhiên, nhưng nó tuyên bố là đã được mã hóa, bạn cũng có thể cho rằng có một số cấu trúc bị bỏ lại và mã hóa là nghi ngờ:

Điều gì sẽ xảy ra tiếp theo?

Theo WithSecure, Microsoft không có kế hoạch sửa “lỗ hổng bảo mật” này, rõ ràng là vì lý do tương thích ngược với Office 2010…

Các phiên bản cũ của Office (2010) yêu cầu AES 128 ECB và tài liệu Office vẫn được các ứng dụng Office bảo vệ theo cách này.

…và…

Báo cáo của [các nhà nghiên cứu WithSecure '] không được coi là đáp ứng tiêu chuẩn phục vụ bảo mật, cũng không bị coi là vi phạm. Không có thay đổi mã nào được thực hiện và vì vậy không có CVE nào được cấp cho báo cáo này.

Tóm lại, nếu bạn hiện đang dựa vào OME, bạn có thể muốn xem xét thay thế nó bằng công cụ mã hóa của bên thứ ba cho các tin nhắn nhạy cảm mã hóa dữ liệu của bạn độc lập với các ứng dụng đã tạo ra các tin nhắn đó và do đó hoạt động độc lập với mã hóa nội bộ mã trong phạm vi Office.

Bằng cách đó, bạn có thể chọn một mật mã hiện đại và một chế độ vận hành mật mã hiện đại mà không cần phải quay lại mã giải mã cũ được tích hợp trong Office 2010.

---

CÁCH CHÚNG TÔI LÀM HÌNH ẢNH TRONG BÀI VIẾT Bắt đầu với sop330.png, bạn có thể tạo cho mình bằng cách cắt biểu trưng SOPHOS đã được làm sạch khỏi hình ảnh trên cùng, xóa ranh giới màu xanh lam 2 pixel và lưu ở định dạng PNG.  Hình ảnh phải có kích thước 330x72 pixel.
 Chuyển đổi sang RGBA bằng ImageMagick: $ convert sop330.png sop.rgba Đầu ra là 330x72 pixel x 4 byte / pixel = 95,040 byte.
 === Mã hóa bằng cách sử dụng Lua và thư viện LuaOSSL (Python có liên kết OpenSSL rất giống nhau): - tải dữ liệu> fdat = misc.filetostr ('sop.rgba')> fdat: len () 95040 - tạo đối tượng mật mã> aes = openssl.cipher.new ('AES-128-ECB')> gcm = openssl.cipher.new ('AES-128-GCM')> cha = openssl.cipher.new ('ChaCha20-Poly1305') - khởi tạo mật khẩu và IV - AES-128-ECB cần mật khẩu 128 bit, nhưng không có IV - AES-128-GCM cần mật khẩu 128 bit và IV 12 byte - ChaCha20 cần mật khẩu 256 bit và a 12-byte IV> aes: encode ('THEPASSWORDIS123')> gcm: encode ('THEPASSWORDIS123', 'andkrokeutiv')> cha: encode ('THEPASSWORDIS123THEPASSWORDIS123', 'qlxmtosh476g') - mã hóa dữ liệu tệp với ba ciphers > aesout = aes: final (fdat)> gcmout = gcm: final (fdat)> chaout = cha: final (fdat) - một mật mã dòng tạo ra đầu ra từng byte, - vì vậy bản mã phải có cùng độ dài với bản rõ > gcmout: len () 95040> chaout: len () 95040 - chúng tôi sẽ không sử dụng mã MAC từ GCM và Poly1305 ở đây, - nhưng mỗi mật mã tạo ra một "tổng kiểm tra" 128 bit (16 byte) - được sử dụng để xác thực quá trình giải mã sau khi hoàn thành, - để phát hiện xem liệu bản mã đầu vào có bị hỏng hoặc bị tấn công hay không - (MAC phụ thuộc vào khóa, vì vậy một kẻ tấn công không thể giả mạo nó)> base.hex (gcm: getTag (16)) a70f204605cd5bd18c9e4da36cbc9e74> base.hex (cha: getTag (16)) a55b97d5e9f3cb9a3be2fa4f040b56ef - tạo trực tiếp từ 95040 "/ dev" misc.filetostr ('/ dev / random', # fdat) - lưu tất cả - lưu ý rằng chúng tôi cắt ngắn đầu ra mật mã khối AES-ECB thành độ dài hình ảnh chính xác được yêu cầu, bởi vì - ECB cần đệm để khớp với kích thước đầu vào với kích thước khối> misc.strtofile (aesout: sub (1, # fdat), 'aes.rgba')> misc.strtofile (gcmout, 'gcm.rgba')> misc.strtofile (chaout, 'cha. rgba ')> misc.strtofile (rndout,' rnd.rgba ') === Để tải các tệp trong trình xem ảnh thông thường, bạn có thể cần phải chuyển đổi dễ dàng chúng trở lại định dạng PNG: $ convert -depth 8 -size 330x72 aes .rgba aes.png $ convert -depth 8 -kích thước 330x72 gcm.rgba gcm.png $ convert -depth 8 -size 330x72 cha.rgba cha.png $ convert -depth 8 -size 330x72 rnd.rgba rnd.png === Cho rằng quá trình mã hóa xáo trộn tất cả bốn byte trong mỗi pixel RGBA , hình ảnh kết quả có độ trong suốt thay đổi (A = alpha, viết tắt của tranparency).
 Trình xem hình ảnh của bạn có thể quyết định hiển thị loại hình ảnh này với nền bàn cờ, trông giống như một phần của hình ảnh một cách khó hiểu, nhưng không phải vậy.  Do đó, chúng tôi đã sử dụng màu xanh dương Sophos từ hình ảnh gốc làm nền cho các tệp được mã hóa để giúp chúng dễ xem hơn.  Do đó, màu xanh lam tổng thể không phải là một phần của dữ liệu hình ảnh.