การรักษาความปลอดภัยที่จริงจัง: Microsoft Office 365 ถูกโจมตีด้วยการเข้ารหัสที่อ่อนแอ

ตอนนี้เราไม่ค่อยแน่ใจว่าจะเรียกมันว่าอะไร ดังนั้นเราจึงเรียกมันในพาดหัวโดยใช้ชื่อลูกผสม Microsoft Office 365.

(ชื่อ “Office” เป็นคำนามรวมสำหรับแอพประมวลผลคำ สเปรดชีต การนำเสนอ และการทำงานร่วมกันของ Microsoft ถูกฆ่าตาย ในเดือนหรือสองเดือนถัดไป ให้กลายเป็น “Microsoft 365”)

เรามั่นใจว่าผู้คนจะใช้ชื่อแอปแต่ละชื่อต่อไป (คำ, Excel, พาวเวอร์พอยท์ และเพื่อนๆ) และชื่อเล่นของห้องชุด Office เป็นเวลาหลายปีแม้ว่าผู้ที่มาใหม่ในซอฟต์แวร์อาจจะรู้ว่าเป็น 365หลังจากวางคำนำหน้า Microsoft ที่แพร่หลาย

ดังที่คุณทราบ แอป Office แบบสแตนด์อโลน (แอปที่คุณติดตั้งในเครื่องจริง ดังนั้นคุณจึงไม่ต้องทำงานออนไลน์เพื่อทำงานของคุณ) มีตัวเลือกในการเข้ารหัสเอกสารที่บันทึกไว้

สิ่งนี้ควรเพิ่มระดับการรักษาความปลอดภัยเพิ่มเติมในกรณีที่คุณแชร์ไฟล์เหล่านั้นในภายหลัง ไม่ว่าจะโดยบังเอิญหรือโดยการออกแบบ กับบุคคลที่ไม่ควรได้รับมัน ซึ่งเป็นสิ่งที่ทำได้ง่ายอย่างน่าประหลาดใจเมื่อแชร์ไฟล์แนบผ่านอีเมลโดยไม่ได้ตั้งใจ

เว้นแต่และจนกว่าคุณจะให้รหัสผ่านกับผู้รับที่พวกเขาต้องการเพื่อปลดล็อกไฟล์ มันก็แค่กะหล่ำปลีหั่นฝอยสำหรับพวกเขาเท่านั้น

แน่นอน หากคุณใส่รหัสผ่านในส่วนเนื้อหาของอีเมล คุณจะไม่ได้รับอะไรเลย แต่ถ้าคุณใช้ความระมัดระวังเล็กน้อยในการแบ่งปันรหัสผ่านผ่านช่องทางอื่น แสดงว่าคุณได้ซื้อความปลอดภัยและความปลอดภัยเพิ่มเติมจากพวกอันธพาล , สอดแนมและไม่เคยทำอะไรเลยในการเข้าถึงเนื้อหาที่เป็นความลับได้อย่างง่ายดาย

OME ภายใต้สปอตไลท์

หรือมีคุณ?

ตามที่ นักวิจัย ที่ WithSecure บริษัทรักษาความปลอดภัยทางไซเบอร์ของฟินแลนด์ ข้อมูลของคุณอาจได้รับการปกป้องน้อยกว่าที่คุณคาดหวังอย่างสมเหตุสมผล

คุณลักษณะที่ผู้ทดสอบใช้คือสิ่งที่พวกเขาเรียกว่า การเข้ารหัสข้อความ Office 365,หรือ OME สั้น ๆ.

เราไม่ได้ทำซ้ำการทดลองของพวกเขาที่นี่ ด้วยเหตุผลง่ายๆ ที่ Office หลัก ขออภัย ผลิตภัณฑ์ 365 ไม่ทำงานบน Linux ซึ่งเราใช้สำหรับการทำงาน เครื่องมือ Office เวอร์ชันบนเว็บไม่มีฟีเจอร์ที่ตั้งค่าเป็นแอปแบบเต็ม ดังนั้นผลลัพธ์ใดๆ ที่เราอาจได้รับจะไม่สอดคล้องกับวิธีที่ผู้ใช้ทางธุรกิจส่วนใหญ่ของ Office, ah, 365 กำหนดค่า Word, Excel, Outlook และเพื่อนๆ บนแล็ปท็อป Windows

ตามที่นักวิจัยอธิบายว่า:

คุณลักษณะนี้มีการโฆษณาเพื่อให้องค์กรสามารถส่งและรับข้อความอีเมลที่เข้ารหัสระหว่างบุคคลภายในและภายนอกองค์กรของคุณในลักษณะที่ปลอดภัย

แต่พวกเขายังชี้ให้เห็นว่า:

ขออภัย ข้อความ OME ถูกเข้ารหัสในโหมดการทำงานสมุดรหัสอิเล็กทรอนิกส์ (ECB) ที่ไม่ปลอดภัย

ECB อธิบาย

อธิบาย.

อัลกอริธึมการเข้ารหัสจำนวนมาก โดยเฉพาะอย่างยิ่ง มาตรฐานการเข้ารหัสขั้นสูง หรือ AES ที่ OME ใช้ เรียกว่า บล็อกการเข้ารหัสซึ่งสลับกลุ่มข้อมูลขนาดใหญ่ในแต่ละครั้ง แทนที่จะประมวลผลแต่ละบิตหรือไบต์ตามลำดับ

โดยทั่วไป สิ่งนี้ควรจะช่วยทั้งประสิทธิภาพและความปลอดภัย เนื่องจากการเข้ารหัสมีข้อมูลที่ป้อนเข้ามากขึ้นเพื่อผสมสับละเอียดและละลายในแต่ละครั้งของด้ามจับข้อเหวี่ยงเข้ารหัสที่ขับเคลื่อนอัลกอริธึม และในแต่ละรอบจะทำให้คุณได้ไกลยิ่งขึ้น ผ่านข้อมูลที่คุณต้องการเข้ารหัส

ตัวอย่างเช่น อัลกอริธึม AES หลัก ใช้ไบต์ข้อความธรรมดาอินพุต 16 ไบต์ (128 บิต) ในแต่ละครั้ง และช่วงชิงข้อมูลนั้นภายใต้คีย์การเข้ารหัสเพื่อสร้างไบต์เอาต์พุตไซเฟอร์เท็กซ์ที่เข้ารหัส 16 ไบต์

(อย่าสับสน ขนาดบล็อก กับ ขนาดกุญแจ – คีย์เข้ารหัส AES สามารถเป็น 128 บิต, 192 บิต หรือ 256 บิตได้ ขึ้นอยู่กับว่าคุณต้องการให้คาดเดาได้ยากเพียงใด แต่ขนาดคีย์ทั้งสามขนาดทำงานบนบล็อก 128 บิตในแต่ละครั้งที่อัลกอริธึม "cranked")

สิ่งนี้หมายความว่าหากคุณเลือกคีย์ AES (โดยไม่คำนึงถึงความยาว) แล้วใช้การเข้ารหัส AES กับกลุ่มข้อมูลโดยตรง...

…แล้ว ทุกครั้งที่คุณได้รับก้อนข้อมูลเดียวกัน คุณจะได้ก้อนผลลัพธ์ที่เหมือนกัน.

ราวกับหนังสือรหัสเล่มใหญ่จริงๆ

นั่นเป็นสาเหตุที่เรียกโหมดการทำงานโดยตรงนี้ว่า ECB, ย่อจาก หนังสือรหัสอิเล็กทรอนิกส์เพราะมันเหมือนกับการมีหนังสือรหัสขนาดใหญ่ที่สามารถใช้เป็นตารางค้นหาสำหรับการเข้ารหัสและถอดรหัส

("codebook" ฉบับสมบูรณ์ไม่สามารถสร้างได้ในชีวิตจริง เพราะคุณต้องจัดเก็บฐานข้อมูลที่ประกอบด้วย 2¹²⁸ รายการขนาด 16 ไบต์ สำหรับแต่ละคีย์ที่เป็นไปได้.)

น่าเสียดาย โดยเฉพาะอย่างยิ่งในข้อมูลที่จัดรูปแบบด้วยคอมพิวเตอร์ การทำซ้ำของข้อมูลบางส่วนมักจะหลีกเลี่ยงไม่ได้ เนื่องจากรูปแบบไฟล์ที่ใช้

ตัวอย่างเช่น ไฟล์ที่แบ่งส่วนข้อมูลออกเป็นประจำเพื่อให้อยู่ในขอบเขต 512 ไบต์ (ขนาดเซกเตอร์ทั่วไปเมื่อเขียนลงดิสก์) หรือขอบเขต 4096 ไบต์ (ขนาดหน่วยการจัดสรรทั่วไปเมื่อจองหน่วยความจำ) มักจะสร้างไฟล์ที่มี รันยาวเป็นศูนย์ไบต์

ในทำนองเดียวกัน เอกสารข้อความที่มีต้นแบบจำนวนมาก เช่น ส่วนหัวและส่วนท้ายของทุกหน้า หรือการกล่าวถึงชื่อเต็มของบริษัทซ้ำแล้วซ้ำเล่า ก็จะมีการทำซ้ำจำนวนมากเช่นเดียวกัน

ทุกครั้งที่เกิดข้อความธรรมดาซ้ำๆ กันในขอบเขต 16 ไบต์ในกระบวนการเข้ารหัส AES-ECB ดังนั้นมันจะปรากฏในเอาต์พุตที่เข้ารหัส เป็นข้อความที่เหมือนกันทุกประการ.

ดังนั้น แม้ว่าคุณจะไม่สามารถถอดรหัสไฟล์ ciphertext แบบฟอร์นม์ได้ คุณอาจทำการอนุมานที่ทำลายความปลอดภัยได้ทันที ต้องขอบคุณรูปแบบในอินพุต (ซึ่งคุณอาจทราบหรือสามารถอนุมานได้ หรือเดา) จะถูกเก็บรักษาไว้ในผลลัพธ์

นี่คือตัวอย่างจากบทความที่เราตีพิมพ์เมื่อเกือบ XNUMX ปีที่แล้ว เมื่อเราอธิบายว่าทำไม Adobe จึงใช้การเข้ารหัสโหมด ECB ที่โด่งดังในขณะนี้เพื่อ "แฮช" รหัสผ่านของผู้ใช้ ไม่ใช่ความคิดที่ดี:

สังเกตว่าพิกเซลที่เป็นสีขาวทึบในอินพุตสร้างรูปแบบซ้ำๆ ในเอาต์พุตได้อย่างไร และส่วนสีน้ำเงินยังคงค่อนข้างสม่ำเสมอ เพื่อให้โครงสร้างของข้อมูลดั้งเดิมชัดเจน

ในตัวอย่างนี้ แต่ละพิกเซลในไฟล์ต้นฉบับใช้พื้นที่ 4 ไบต์พอดี ดังนั้นแต่ละพิกเซลที่รัน 4 พิกเซลจากซ้ายไปขวาในข้อมูลอินพุตจะมีความยาว 16 ไบต์ ซึ่งจัดตำแหน่งให้ตรงกับบล็อกการเข้ารหัส AES 16 ไบต์แต่ละบล็อก จึงเน้นย้ำ "ผลกระทบ ECB"

---

จับคู่รูปแบบข้อความเข้ารหัส

ที่แย่ไปกว่านั้น ถ้าคุณมีเอกสารสองฉบับที่คุณรู้ว่าเข้ารหัสด้วยคีย์เดียวกัน และคุณเพิ่งจะมีข้อความธรรมดาของหนึ่งในนั้น คุณสามารถดูผ่านข้อความเข้ารหัสที่คุณ ไม่ได้ ถอดรหัสและพยายามจับคู่ส่วนของมันกับรูปแบบในข้อความเข้ารหัสที่คุณ สามารถ ถอดรหัส

จำไว้ว่าคุณไม่จำเป็นต้องใช้กุญแจเพื่อ “ถอดรหัส” เอกสารแรกถ้าคุณมีเอกสารนั้นในรูปแบบถอดรหัส – เป็นที่ทราบกันดีอยู่แล้วว่า การโจมตีแบบรู้เท่าทัน.

แม้ว่าจะมีข้อความไร้เดียงสาที่เห็นได้ชัดว่าไม่ใช่ข้อมูลลับเพียงไม่กี่คู่ แต่ความรู้ที่ฝ่ายตรงข้ามสามารถดึงออกมาด้วยวิธีนี้อาจเป็นเหมืองทองคำสำหรับสายลับทรัพย์สินทางปัญญา วิศวกรสังคม ผู้ตรวจสอบทางนิติเวช และอื่นๆ

ตัวอย่างเช่น แม้ว่าคุณจะไม่รู้ว่ารายละเอียดของเอกสารอ้างถึงอะไร โดยการจับคู่ข้อความธรรมดาที่ทราบกันในหลายไฟล์ คุณอาจระบุได้ว่าเป็นการรวบรวมเอกสารแบบสุ่มที่เห็นได้ชัด:

• ทั้งหมดถูกส่งไปยังผู้รับเดียวกัน หากมีคำทักทายทั่วไปที่ด้านบนของแต่ละคน
• อ้างถึงโครงการเดียวกัน หากมีสตริงข้อความระบุตัวตนที่ไม่ซ้ำที่โผล่ขึ้นมา
• มีการจัดประเภทความปลอดภัยเหมือนกัน หากคุณกระตือรือร้นที่จะจดจ่อกับสิ่งที่เห็นได้ชัดว่า "เป็นความลับ" มากกว่าที่เหลือ

จะทำอย่างไร?

อย่าใช้โหมด ECB!

หากคุณกำลังใช้รหัสบล็อก ให้เลือก a บล็อกโหมดการทำงานของรหัสลับ ที่:

• รวมถึงสิ่งที่เรียกว่า IV หรือเวกเตอร์การเริ่มต้น เลือกแบบสุ่มและไม่ซ้ำกันสำหรับแต่ละข้อความ
• ตั้งใจจัดกระบวนการเข้ารหัส เพื่อให้การป้อนข้อมูลซ้ำ ๆ ออกมาแตกต่างกันทุกครั้ง

หากคุณกำลังใช้ AES โหมดที่คุณอาจต้องการเลือกในปัจจุบันคือ AES-GCM (โหมด Galois Counter) ซึ่งไม่เพียงแต่ใช้ IV เพื่อสร้างกระแสข้อมูลการเข้ารหัสที่แตกต่างกันทุกครั้ง แม้ว่าคีย์จะยังเหมือนเดิม แต่ยังคำนวณสิ่งที่เรียกว่า รหัสยืนยันข้อความ (MAC) หรือผลรวมการตรวจสอบการเข้ารหัส ในเวลาเดียวกันกับการถอดรหัสหรือถอดรหัสข้อมูล

AES-GCM ไม่ได้หมายความเพียงแค่คุณหลีกเลี่ยงรูปแบบข้อความเข้ารหัสซ้ำๆ เท่านั้น แต่คุณยังลงเอยด้วย "เช็คซัม" ที่จะบอกคุณว่าข้อมูลที่คุณเพิ่งถอดรหัสถูกดัดแปลงไปตลอดทางหรือไม่

จำไว้ว่าคนโกงที่ไม่รู้ว่าจริงๆ แล้ว ciphertext หมายถึงอะไร อาจสามารถหลอกล่อให้คุณเชื่อการถอดรหัสที่ไม่แน่นอนโดยที่คุณไม่รู้ (หรือสนใจ) ว่าผลลัพธ์ที่ไม่ถูกต้องประเภทใดที่คุณลงเอยด้วย

MAC ที่คำนวณระหว่างกระบวนการถอดรหัสโดยใช้คีย์เดียวกันและ IV จะช่วยให้แน่ใจว่าคุณรู้ว่าข้อความเข้ารหัสที่คุณได้รับนั้นถูกต้อง ดังนั้นคุณจึงเกือบจะถอดรหัสสิ่งที่วางไว้ในตอนท้ายได้เกือบทั้งหมด

หรือใช้เฉพาะ รหัสสตรีม ที่สร้างคีย์สตรีมแบบไบต์ต่อไบต์แบบสุ่มหลอกที่ให้คุณเข้ารหัสข้อมูลโดยไม่ต้องประมวลผล 16 ไบต์ (หรือขนาดบล็อกใดก็ตาม) ในแต่ละครั้ง

AES-GCM จะแปลง AES ให้เป็น stream cipher เป็นหลักและเพิ่มการพิสูจน์ตัวตนในรูปแบบของ MAC แต่ถ้าคุณกำลังมองหา stream cipher ที่ออกแบบมาโดยเฉพาะเพื่อให้ทำงานในลักษณะนั้น เราขอแนะนำ Daniel Bernstein ชาช่า20-โพลี1305 (ส่วน Poly1305 คือ MAC) ตามรายละเอียดใน RFC 8439.

ด้านล่างนี้ เราได้แสดงสิ่งที่เราได้รับจาก AES-128-GCM และ ChaCha20-Poly1305 (เราทิ้งรหัส MAC ที่นี่) พร้อมกับ "รูปภาพ" ที่ประกอบด้วย 95,040 RGBA ไบต์ (330×72 ที่ 4 ไบต์ต่อพิกเซล) จาก ตัวสร้างสุ่มหลอกเคอร์เนล Linux

จำไว้ว่าเพียงเพราะข้อมูลดูเหมือนไม่มีโครงสร้างไม่ได้หมายความว่ามันเป็นแบบสุ่มจริง ๆ แต่ถ้ามันดูไม่สุ่ม แต่มันอ้างว่าถูกเข้ารหัส คุณก็อาจสันนิษฐานได้ว่ามีโครงสร้างบางอย่างที่ทิ้งไว้เบื้องหลัง และการเข้ารหัสคือ สงสัย:

จะเกิดอะไรขึ้นต่อไปหรือไม่

ตาม WithSecure, Microsoft ไม่ได้วางแผนที่จะแก้ไข “ช่องโหว่” นี้ ด้วยเหตุผลของความเข้ากันได้ย้อนหลังกับ Office 2010...

Office เวอร์ชันเก่า (2010) ต้องใช้ AES 128 ECB และเอกสาร Office ยังคงได้รับการปกป้องในลักษณะนี้โดยแอป Office

…และ…

รายงาน [WithSecure นักวิจัย'] ไม่ถือว่าตรงตามมาตรฐานการให้บริการด้านความปลอดภัย และไม่ถือว่าเป็นการละเมิด ไม่มีการเปลี่ยนแปลงรหัส ดังนั้นจึงไม่มีการออก CVE สำหรับรายงานนี้

กล่าวโดยย่อ หากคุณใช้ OME อยู่ในขณะนี้ คุณอาจต้องพิจารณาแทนที่ด้วยเครื่องมือเข้ารหัสของบุคคลที่สามสำหรับข้อความที่มีความละเอียดอ่อน ซึ่งเข้ารหัสข้อมูลของคุณโดยไม่ขึ้นกับแอปที่สร้างข้อความเหล่านั้น และทำงานโดยอิสระจากการเข้ารหัสภายใน รหัสในช่วง Office

ด้วยวิธีนี้ คุณสามารถเลือกรหัสลับที่ทันสมัยและโหมดการดำเนินการเข้ารหัสที่ทันสมัย ​​โดยไม่ต้องย้อนกลับไปที่รหัสถอดรหัสลับแบบเก่าที่สร้างขึ้นใน Office 2010

---

วิธีที่เราทำภาพในบทความ เริ่มต้นด้วย sop330.png ซึ่งคุณสามารถสร้างสำหรับตัวคุณเองได้โดยการครอบตัดโลโก้ SOPHOS ที่ล้างแล้วออกจากภาพบนสุด ลบขอบสีน้ำเงิน 2 พิกเซล และบันทึกในรูปแบบ PNG  รูปภาพควรมีขนาด 330x72 พิกเซล
 แปลงเป็น RGBA โดยใช้ ImageMagick: $ แปลง sop330.png sop.rgba เอาต์พุตคือ 330x72 พิกเซล x 4 ไบต์/พิกเซล = 95,040 ไบต์
 === เข้ารหัสโดยใช้ Lua และไลบรารี LuaOSSL (Python มีการโยง OpenSSL ที่คล้ายกันมาก): -- load data > fdat = misc.filetostr('sop.rgba') > fdat:len() 95040 -- สร้างวัตถุเข้ารหัส > aes = openssl.cipher.new('AES-128-ECB') > gcm = openssl.cipher.new('AES-128-GCM') > cha = openssl.cipher.new('ChaCha20-Poly1305') -- เริ่มต้นรหัสผ่านและ IVs -- AES-128-ECB ต้องการรหัสผ่าน 128 บิต แต่ไม่มี IV -- AES-128-GCM ต้องการรหัสผ่าน 128 บิตและ IV 12 ไบต์ -- ChaCha20 ต้องการรหัสผ่าน 256 บิตและ a 12-byte IV > aes:encrypt('THEPASSWORDIS123') > gcm:encrypt('THEPASSWORDIS123','andkrokeutiv') > cha:encrypt('THEPASSWORDIS123THEPASSWORDIS123','qlxmtosh476g') -- เข้ารหัสข้อมูลไฟล์ด้วยการเข้ารหัสสามตัว > aesout = aes:final(fdat) > gcmout = gcm:final(fdat) > chaout = cha:final(fdat) -- รหัสสตรีมสร้างเอาต์พุตแบบไบต์ต่อไบต์ -- ดังนั้นข้อความเข้ารหัสควรมีความยาวเท่ากับข้อความธรรมดา > gcmout:len() 95040 > chaout:len() 95040 -- เราจะไม่ใช้รหัส MAC จาก GCM และ Poly1305 ที่นี่ -- แต่ ตัวเลขแต่ละตัวจะสร้าง "checksum" แบบ 128 บิต (16 ไบต์) ซึ่งใช้เพื่อตรวจสอบสิทธิ์การถอดรหัสหลังจากเสร็จสิ้น เพื่อตรวจสอบว่าข้อความเข้ารหัสอินพุตเสียหายหรือถูกแฮ็กหรือไม่ (MAC ขึ้นอยู่กับคีย์ ดังนั้น ผู้โจมตีไม่สามารถปลอมแปลงได้) > base.hex(gcm:getTag(16)) a70f204605cd5bd18c9e4da36cbc9e74 > base.hex(cha:getTag(16)) a55b97d5e9f3cb9a3be2fa4f040b56efnd - สร้าง 95040 "ภาพ" ตรง misc.filetostr('/dev/random',#fdat) - บันทึกทั้งหมด - โปรดทราบว่าเราตัดทอน AES-ECB ให้ชัดเจน - บล็อกเอาต์พุตการเข้ารหัสตามความยาวที่ต้องการของรูปภาพ เนื่องจาก -- ECB จำเป็นต้องมีช่องว่างภายในเพื่อให้ตรงกับ ขนาดอินพุตที่มีขนาดบล็อก > misc.strtofile(aesout:sub(1,#fdat),'aes.rgba') > misc.strtofile(gcmout,'gcm.rgba') > misc.strtofile(chaout,'cha. rgba') > misc.strtofile(rndout,'rnd.rgba') === ในการโหลดไฟล์ในโปรแกรมดูรูปภาพปกติ คุณอาจต้องแปลงไฟล์กลับเป็นรูปแบบ PNG แบบไม่สูญเสียข้อมูล: $ convert -depth 8 -size 330x72 aes .rgba aes.png $ แปลง -ความลึก 8 -ขนาด 330x72 gcm.rgba gcm.png $ แปลง - ลึก 8 - ขนาด 330x72 cha.rgba cha.png $ แปลง - ลึก 8 - ขนาด 330x72 rnd.rgba rnd.png === เนื่องจากกระบวนการเข้ารหัสจะรบกวนทั้งสี่ไบต์ในแต่ละพิกเซล RGBA ภาพที่ได้มีความโปร่งใสแบบแปรผัน (A = alpha ย่อมาจาก tranparency)
 โปรแกรมดูรูปภาพของคุณอาจตัดสินใจแสดงรูปภาพประเภทนี้โดยมีพื้นหลังเป็นกระดานหมากรุก ซึ่งดูเหมือนเป็นส่วนหนึ่งของรูปภาพจนสับสน แต่ก็ไม่เป็นเช่นนั้น  ดังนั้นเราจึงใช้ Sophos blue จากภาพต้นฉบับเป็นพื้นหลังสำหรับไฟล์ที่เข้ารหัสเพื่อให้ดูได้ง่ายขึ้น  เฉดสีฟ้าโดยรวมจึงไม่เป็นส่วนหนึ่งของข้อมูลภาพ