S3 Ep105: WONTFIX! “Güvenlik kusuru olmayan” MS Office kripto hatası [Ses + Metin]

Herhangi bir noktaya atlamak için aşağıdaki ses dalgalarına tıklayın ve sürükleyin. Ayrıca doğrudan dinle Soundcloud'da.

DOUG.  Nefes kesen ihlaller, şifresi çözülebilir şifreleme ve bolca yamalar.

Bunların hepsi Naked Security podcast'inde.

[MÜZİKAL MODEM]

Podcast'e hoş geldiniz millet.

Ben Doug Aamoth; o Paul Ducklin'dir.

Paul, bugün nasılsınız efendim?

---

ÖRDEK.  Doug… Biliyorum, çünkü bana önceden ne olduğunu söyledin. Teknoloji Tarihinde Bu Hafta, ve bu BÜYÜK!

---

DOUG.  TAMAM!

Bu hafta, 18 Ekim 1958'de, rüzgar direncini simüle etmek için yapılmış bir osiloskop ve bir bilgisayar, özel alüminyum kontrolörlerle eşleştirildi ve oyun İki Kişilik Tenis doğdu.

Brookhaven Ulusal Laboratuvarı'ndaki üç günlük bir sergide gösterilen İki Kişilik Tenis, özellikle lise öğrencileri arasında son derece popüler olduğunu kanıtladı.

Bunu dinliyorsan, Wikipedia'ya gitmeli ve “İki Kişilik Tenis” konusuna bakmalısın.

1958'de yapılmış bir şey için orada bir video var…

…Sanırım benimle aynı fikirdesin Paul, oldukça inanılmazdı.

---

ÖRDEK.  Bugün oynamayı *çok isterim*!

Ve Asteroids ve Battle Zone ve 1980'lerin özel olarak hatırlanan oyunları gibi…

…çünkü o bir osiloskop: vektör grafikleri!

Pikselleşme yok, çizginin 90 derece, 30 derece veya 45 derece olmasına bağlı olarak fark yok.

Ve kontrolörlerdeki rölelerden gelen sesli geri bildirim… bu harika!

Bunun 1958 olması inanılmaz.

Bir öncekine geri dönmek Teknoloji Tarihinde Bu Hafta, transistör devriminin zirvesindeydi.

Görünüşe göre, hesaplama yarısı, termiyonik valflerin (vakum tüpleri) ve rölelerin bir karışımıydı.

Ve ekran devresi tamamen transistör tabanlıydı, Doug

Yani tüm teknolojilerin karışımındaydı: röleler, valfler ve transistörler, hepsi çığır açan tek bir video oyununda.

---

DOUG.  Çok havalı.

Wikipedia'da kontrol edin: İki Kişilik Tenis.

Şimdi ilk hikayemize geçelim.

Paul, harika bir şiir yazmakta çok usta olduğunu biliyorum...

…Müsaade ederseniz, bu ilk hikayeyi tanıtmak için çok kısa bir şiir yazdım.

---

ÖRDEK.  Yani bu iki satır olacak, öyle mi? [GÜLER]

---

DOUG.  Biraz böyle gider.

Mac için Yakınlaştır/Alma kaçırıldı.

[ÇOK UZUN SESSİZLİK]

Şiiri bitir.

---

ÖRDEK.  Ah, pardon!

Başlığın bu olduğunu ve şiiri şimdi yazacağını sanıyordum.

---

DOUG.  Yani şiir bu.

---

ÖRDEK.  Tamam.

[Duygusuz] Güzel, Doug.

---

DOUG.  [İRONİK] Teşekkürler.

---

ÖRDEK.  Ritim muhteşemdi!

Ama bütün şiirler kafiyeli olmak zorunda değil...

---

DOUG.  Bu doğru.

---

ÖRDEK.  Sadece serbest ayet diyeceğiz, değil mi?

---

DOUG.  Tamam lütfen.

---

ÖRDEK.  Ne yazık ki, bu Mac için Zoom'a ücretsiz bir arka kapıydı.

[SUÇLU HİSSET] Üzgünüm, bu pek iyi bir bölüm değildi, Doug.

[GÜLER] Başkasının sahasına basarsınız, sık sık yetersiz kalırsınız…

---

DOUG.  Hayır o iyi!

Bu hafta şiirleri deniyordum; sen segues deniyorsun.

Arada bir konfor alanlarımızdan çıkmamız gerekiyor.

---

ÖRDEK.  Bunun, son yapı yapıldığında derlenmesi gereken, ancak yanlışlıkla içeride bırakılan kod olduğunu varsayıyorum.

Yalnızca Zoom for Mac sürümü içindir ve yamalanmıştır, bu nedenle güncel olduğunuzdan emin olun.

Temel olarak, bazı durumlarda, bir video akışı başladığında veya kamera uygulamanın kendisi tarafından etkinleştirildiğinde, yanlışlıkla programda hata ayıklamak isteyebileceğinizi düşünür.

Çünkü, hey, belki bir geliştiriciydin! [GÜLER]

Açıkçası, sürüm sürümlerinde bunun olması gerekmiyor.

Bu da yerel ağ arabiriminde açık bırakılmış bir TCP hata ayıklama bağlantı noktası olduğu anlamına geliyordu.

Bu, paketleri o bağlantı noktasına iletebilecek herhangi birinin, muhtemelen yerel olarak bağlı herhangi bir kullanıcı olabileceği anlamına geliyordu, bu nedenle bir yönetici veya hatta siz… hatta bir misafir kullanıcı olması bile yeterli olurdu.

Bu nedenle, bilgisayarınızda dışarıdan paket alabilen ve bunları yerel arayüze enjekte edebilen bir tür proxy kötü amaçlı yazılıma sahip bir saldırgan, temel olarak programın bağırsaklarına komutlar verebilir.

Hata ayıklama arabirimlerinin izin verdiği tipik şeyler şunlardır: biraz bellek boşaltmak; sırları çıkarmak; programın davranışını değiştirmek; kullanıcının görememesi için normal arayüzden geçmeden yapılandırma ayarlarını yapın; tüm sesi kimseye söylemeden, kayıt uyarısını açmadan yakalayın; tüm bu tür şeyler.

İyi haber şu ki Zoom bunu kendi kendine buldu ve oldukça hızlı bir şekilde yamaladılar.

Ancak, sık sık söylediğimiz gibi, [GÜLER] “Kupa ve dudak arasında çok fazla kayma var.”

---

DOUG.  Pekala, çok iyi.

Yama treninde kalalım ve bir sonraki istasyona geçelim.

Ve bu hikaye… belki de en son Salı Yaması'nın bu hikayesinin en ilginç kısmı, Microsoft'un *içermediği*?

---

ÖRDEK.  Ne yazık ki, herkesin muhtemelen beklediği yamalar - ve yakın tarihli bir podcast'te spekülasyon yaptık, “Eh, görünüşe göre Microsoft bizi Salı Yamasına kadar bir hafta daha bekletecek ve bant dışı “erken yayın” yapmayacak. ”, son belleğin bu iki Exchange sıfır günüdür.

E00F olarak bilinen şey veya Değişim Çift Sıfır Gün Kusuru benim terminolojimde veya ProxyNotShell Twittersphere'de belki biraz kafa karıştırıcı bir şekilde biliniyor.

Bu ayın Salı Yaması'ndaki büyük hikaye buydu: bu iki hata olağanüstü bir şekilde düzeltilmedi.

Ve bu yüzden bunun ne zaman olacağını bilmiyoruz.

Herhangi bir azaltma uyguladığınızdan emin olmanız gerekir.

Sanırım daha önce söylediğimiz gibi, Microsoft önerdikleri önceki hafifletmelerin... belki yeterince iyi olmadığını bulmaya devam etti ve melodilerini değiştirmeye ve hikayeyi uyarlamaya devam ettiler.

Bu nedenle, şüpheniz varsa, nudesecurity.sophos.com'a geri dönebilir, ifadeyi arayabilirsiniz. ProxyNotShell (hepsi bir kelime) ve sonra gidip söyleyeceklerimizi okuyun.

Ayrıca Microsoft'un iyileştirmesinin en son sürümüne de bağlantı verebilirsiniz…

…çünkü Patch Salı'daki her şey arasında en ilginç olanı buydu, dediğiniz gibi: çünkü orada değildi.

---

DOUG.  Tamam, şimdi vitesleri bir çok sinir bozucu hikaye.

Bu, siber güvenliği ihlal edildiğini fark etmeyecek kadar kötü olan büyük bir şirket için bir tokat!

---

ÖRDEK.  Evet, bu, çoğu kişinin muhtemelen SHEIN ("she-in") olarak bileceği ve tek kelimeyle büyük harflerle yazılmış bir markadır. (İhlal sırasında şirket Zoetop olarak biliniyordu.)

Ve onlar "hızlı moda" denilen şey.

Bilirsiniz, yüksek yığarlar ve ucuza satarlar ve tasarımlarını nereden aldıkları konusunda tartışma olmadan olmaz.

Ve bir çevrimiçi perakendeci olarak, çevrimiçi perakendecilik siber güvenlik ayrıntılarının alt düzeyde olmasını bekleyebilirsiniz.

Ama dediğiniz gibi yapmadılar!

Ve ABD'deki New York Eyaleti Başsavcılığı, bu ihlalin kurbanları arasında yer alan New York sakinlerine yapılan muameleden memnun olmadığına karar verdi.

Bu yüzden bu şirkete karşı yasal işlem başlattılar… ve bu mutlak bir gaflar, hatalar ve nihayetinde örtbas etme ayiniydi - tek kelimeyle, Douglas, sahtekârlık.

Fark etmedikleri bir ihlali vardı.

Bu, en azından geçmişte, hayal kırıklığı yaratacak kadar yaygındı: şirketler, bir kredi kartı işleyicisi veya bir banka kendileriyle iletişime geçip, “Biliyor musunuz, çok fazla şey yaşadık” diyene kadar, ihlal edildiğinin farkına varmazlardı. Bu ay müşterilerden gelen dolandırıcılık şikayetleri. ”

“Ve geri dönüp CPP dedikleri şeye baktığımızda, ortak satın alma noktası, her kurbanın bir şeyler satın aldığı tek tüccar sensin. Sızıntının sizden geldiğini düşünüyoruz.”

Ve bu durumda, daha da kötüydü.

Görünüşe göre başka bir ödeme işlemcisi geldi ve "Ah, bu arada, sizden çalınmış olarak sunulan, satılık bir dizi kredi kartı numarası bulduk" dedi.

Yani ya toplu olarak ya da parça parça bir ihlal olduğuna dair açık kanıtları vardı.

---

DOUG.  Elbette, bu şirket bundan haberdar olduğunda, durumu düzeltmek için hızla harekete geçtiler, değil mi?

---

ÖRDEK.  Eh, bu senin nasıl olduğuna bağlı... [GÜLER] Her zamanki gibi gülmemeliyim Doug.

Bu, "düzeltmek" ile ne demek istediğinize bağlı.

---

DOUG.  [Gülüyor] Aman Tanrım!

---

ÖRDEK.  Öyle görünüyor ki, sorunla * başa çıktılar… gerçekten de, gerçekten iyi örtbas ettikleri kısımlar vardı.

Görünüşe göre.

Görünüşe göre birdenbire “Hata, PCI DSS uyumlu olsak iyi olur” kararı aldılar.

Açıkça öyle değillerdi, çünkü görünüşe göre başarısız işlemlerin kredi kartı ayrıntılarını içeren hata ayıklama günlüklerini tutuyorlardı… diske yazmamanız gereken her şeyi yazıyorlardı.

Ve sonra bunun olduğunu anladılar, ancak bu verileri kendi ağlarında nereye bıraktıklarını bulamadılar!

Yani, belli ki PCI DSS uyumlu olmadıklarını biliyorlardı.

Görünüşe göre, kendilerini PCI DSS uyumlu hale getirmeye başladılar, görünüşe göre 2019'a kadar elde ettikleri bir şey. (İhlal 2018'de gerçekleşti.)

Ancak bir denetime, adli soruşturmaya başvurmaları gerektiği söylenince…

…New York Başsavcısı'na göre, müfettişin yoluna kasıtlı olarak girdiler.

Temelde, müfettişlerin sistemi tamir ettikten, kaynakladıktan ve cilaladıktan *sonra* olduğu gibi görmelerine izin verdiler ve "Oh hayır, yedekleri göremiyorsunuz" dediler, ki bu bana oldukça yaramaz geliyor. .

---

DOUG.  Hı-hı.

---

ÖRDEK.  Ayrıca, ihlali müşterilerine açıklama biçimleri de New York Eyaleti'nden büyük tepki çekti.

Özellikle, çok zayıf karma şifreler de dahil olmak üzere 39,000,000 kullanıcının ayrıntılarının bir şekilde çalındığı oldukça açık görünüyor: iki basamaklı bir tuz ve bir tur MD5.

Bırak 1998'i, 2018'de yeterince iyi değil!

Bu yüzden, bu kadar çok sayıda kullanıcı için bir sorun olduğunu biliyorlardı, ancak görünüşe göre, hesaplarını gerçekten kullanan ve sipariş veren 6,000,000 kullanıcıyla iletişim kurmaya karar verdiler.

Sonra dediler ki, "Eh, en azından bu insanlarla temasa geçtik."

Ve *sonra* 6,000,000 milyon kullanıcının tamamıyla gerçekten iletişim kurmadıkları ortaya çıktı!

Kanada, Amerika Birleşik Devletleri veya Avrupa'da yaşayan altı milyon kişiyle az önce temas kurmuşlardı.

Yani, dünyanın herhangi bir yerinden iseniz, kötü şans!

Tahmin edebileceğiniz gibi, bu yetkililerle, düzenleyiciyle iyi gitmedi.

Ve itiraf etmeliyim ki… beni şaşırtacak şekilde Doug, 1.9 milyon dolar para cezasına çarptırıldılar.

Hangi, bu kadar büyük bir şirket için…

---

DOUG.  Evet!

---

ÖRDEK.  …ve bu kadar korkunç hatalar yapmak ve sonra olanlar hakkında tamamen dürüst ve dürüst olmamak ve ihlal hakkında yalan söylediği için New York Başsavcısı tarafından bu sözlerle azarlanmak?

Daha ciddi bir akıbete uğrayacaklarını hayal ediyordum.

Belki de sadece biraz para bularak ödenemeyecek bir şey dahil.

Oh, ve yaptıkları diğer şey, şifreleri risk altında olan kullanıcılar olduğu açıkken… çünkü iki basamaklı bir tuz olduğu gerçeği nedeniyle derinden kırılabilirlerdi, yani önceden hesaplanmış 100 sözlük oluşturabilirsiniz. …

---

DOUG.  Bu yaygın mı?

Sadece iki basamaklı bir tuz gerçekten düşük görünüyor!

---

ÖRDEK.  Hayır, genellikle 128 bit (16 bayt) ve hatta 32 bayt istersiniz.

Açıkça söylemek gerekirse, kırma hızında zaten önemli bir fark yaratmaz, çünkü (karmanın blok boyutuna bağlı olarak) karışıma yalnızca iki ekstra rakam ekliyorsunuz.

Yani karmaların gerçek hesaplanması artık daha uzun sürmüyor.

2016 yılına kadar, “hashcat” programını çalıştıran sekiz GPU'lu bilgisayarları kullanan kişilerin saniyede 200 milyar MD5 yapabileceğini düşünüyorum.

O zamanlar! (Bu miktar şimdi beş ya da on kat daha fazla.)

Çok ama çok kırılabilir.

Ama aslında insanlarla iletişime geçip "Şifreniz risk altında çünkü hash'i sızdırdık ve çok iyi bir şifre değildi, değiştirmelisiniz" demektense, [GÜLMEYE] dediler ki...

…çok cılız sözlerdi, değil mi?

---

DOUG.  "Parolanızın güvenlik düzeyi düşük ve belki de risk altında. Lütfen giriş şifrenizi değiştirin.”

Ardından, “Şifreniz 365 günden fazla bir süredir güncellenmedi. Güvenliğiniz için lütfen şimdi güncelleyin.”

---

ÖRDEK.  Evet, “Şifrenizin güvenlik seviyesi düşük…”

---

DOUG.  "BİZİM YÜZÜMÜZDEN!"

---

ÖRDEK.  Bu sadece patronluk yapmak değil, değil mi?

Bu benim gözümde kurbanı suçlamanın sınırında ya da ötesinde.

Her neyse, bu bana doğru şeyi yapmak istemeyen şirketler için çok güçlü bir teşvik gibi gelmedi.

---

DOUG.  Pekala, yorumlarda sesini kes, ne düşündüğünü duymak isteriz!

O makalenin adı: Moda markası SHEIN, veri ihlali hakkında yalan söylediği için 1.9 milyon dolar para cezasına çarptırıldı.

Ve başka bir sinir bozucu hikayeye…

..,başka bir gün, güvenilmeyen girdilerin işlenmesiyle ilgili başka bir uyarıcı hikaye!

---

ÖRDEK.  Aaargh, bunun ne olacağını biliyorum, Doug.

İşte Apache Commons Metni böcek, değil mi?

---

DOUG.  Bu!

---

ÖRDEK.  Açık olmak gerekirse, bu Apache Web Sunucusu değil.

Apache, bir dizi ürüne ve ücretsiz araçlara sahip bir yazılım temelidir… ve gerçekten çok faydalıdırlar, açık kaynaktırlar ve harikadırlar.

Ancak ekosistemlerinin Java kısmında (Apache Web Sunucusu httpd Java'da yazılmamış, bu yüzden şimdilik bunu görmezden gelelim – Apache'yi Apache Web Sunucusu ile karıştırmayın)…

…geçen yıl, Apache'nin Java kitaplıklarında benzer üç sorun yaşadık.

biz vardı rezil Log4Shell böcek sözde Log4J (Java için Günlüğe Kaydetme) kitaplığında.

O zaman bizde de buna benzer bir bug vardı, neydi o?… Apache Commons YapılandırmasıINI dosyaları ve XML dosyaları gibi her türlü yapılandırma dosyasını standart bir şekilde yönetmek için bir araç takımıdır.

Ve şimdi daha da düşük seviyeli bir kütüphanede Apache Commons Metni.

Java'da genellikle "string enterpolasyonu" olarak bilinen şeydeki hata.

Diğer dillerdeki programcılar… PowerShell veya Bash gibi şeyler kullanıyorsanız, bunu “string ikamesi” olarak bileceksiniz.

Karakterlerle dolu bir cümleyi sihirli bir şekilde bir tür mini programa dönüştürebileceğiniz yerdir.

Bash kabuğunu daha önce kullandıysanız, komutu yazarsanız bunu bileceksiniz. echo USER, dizeyi yankılayacak veya yazdıracak USER ve göreceksiniz, ekranda KULLANICI.

Ama komutu çalıştırırsanız echo $USER, o zaman bu, USER tarafından takip edilen bir dolar işaretinin yankılanması anlamına gelmez.

Bunun anlamı, "Bu sihirli dizeyi şu anda oturum açmış olan kullanıcının adıyla değiştirin ve onun yerine yazdırın."

Yani bilgisayarımda, eğer echo USER, alırsın USER, ama eğer sen echo $USER, kelimeyi anladın duck yerine.

Ve bazı Java dize ikameleri bundan çok, çok, çok daha ileri gider… Log4Shell'i düzeltme Noel 2021'de hatırlayacak!

Daha sonra bu dize işleme kitaplığıyla işleyeceğiniz dizelerin içine yerleştirebileceğiniz her türden akıllı küçük program vardır.

Yani bariz olanı var: kullanıcı adını okumak için ${env: (“çevreyi okumak” için) user}… dalgalı parantezler kullanıyorsunuz.

Bu dolar işareti; dalgalı braket; bazı sihirli komut; sihirli kısım olan dalgalı parantez.

Ve ne yazık ki, bu kütüphanede, aşağıdaki gibi sihirli komutların kontrolsüz varsayılan kullanılabilirliği vardı: ${url:...}, dizi işleme kitaplığını kandırarak internete erişmenizi, bir şey indirmenizi ve dize yerine o web sunucusundan geri aldıklarını yazdırmanızı sağlar. ${url:...}.

Bu tam olarak kod yerleştirme olmasa da, yalnızca ham HTML olduğundan, yine de insanların günlük dosyalarına veya web sayfalarına her türlü çöpü ve tuhaf ve harika güvenilmeyen şeyi koyabileceğiniz anlamına gelir.

Var ${dns:...}, bu, ağ içinde bir iş mantığı sunucusu olabilecek birinin sunucusunu kandırabileceğiniz anlamına gelir…

…adlandırılmış bir sunucu için DNS araması yapması için onu kandırabilirsiniz.

Ve bu etki alanına bir dolandırıcı olarak sahipseniz, o etki alanıyla ilgili DNS sunucusunun da sahibi ve işletmecisisiniz.

Peki, DNS araması gerçekleştiğinde, tahmin et ne oldu?

Bu arama *sunucunuzda* sona erer ve birinin iş ağının içini haritalandırmanıza yardımcı olabilir… sadece web sunucusu değil, aynı zamanda ağdaki daha derin şeyler.

Ve son olarak ve en endişe verici olanı, en azından Java'nın eski sürümlerinde... [GÜLER] buraya neyin geldiğini biliyorsun, Doug!

Komuta ${script:...}.

"Hey, sana biraz JavaScript vermeme izin ver ve bunu benim için çalıştırmama izin ver."

Ve muhtemelen “Ne?! Bekle, bu Java'da bir hata. JavaScript'in bununla ne ilgisi var?”

Pekala, nispeten yakın zamana kadar… ve unutmayın, birçok işletme hala Java Development Kit'in daha eski, hala desteklenen sürümlerini kullanıyor.

Yakın zamana kadar Java… [GÜLER] (yine gülmemeliyim)… Java Geliştirme Kiti kendi içinde Java ile yazılmış tam, çalışan bir JavaScript motoru içeriyordu.

Şimdi, Java ve JavaScript arasında dört harf "Java" dışında hiçbir ilişki yoktur, ancak şunu koyabilirsiniz: ${script:javascript:...}ve seçtiğiniz kodu çalıştırın.

Ve can sıkıcı bir şekilde, Java çalışma zamanı içindeki JavaScript motorunda yapabileceğiniz şeylerden biri JavaScript motoruna "Hey, bu şeyi Java aracılığıyla çalıştırmak istiyorum" demek.

Böylece Java'nın JavaScript'e *giriş yapmasını ve JavaScript'in de esasen Java'ya *çıkış* çağrısı yapmasını sağlayabilirsiniz.

Ardından Java'dan "Hey, bu sistem komutunu çalıştırın" diyebilirsiniz.

Ve Çıplak Güvenlik makalesine giderseniz, [COUGHS APOLOGETICALLY] bir hesap patlatmak için bir şüpheli komutu kullandığımı göreceksiniz, Doug!

Elbette bir HP RPN hesap makinesi, çünkü hesap makinesini patlatan benim…

---

DOUG.  Öyle olmalı, evet!

---

ÖRDEK.  …bu bir HP-10.

Yani risk kadar olmasa da Log4Shell kadar harika, bu kitaplığı kullanırsanız gerçekten göz ardı edemezsiniz.

Çıplak Güvenlik makalesinde Commons Text kitaplığına sahip olup olmadığınızı nasıl öğreneceğinize dair bazı talimatlarımız var… ve buna sahip olabilirsiniz, tıpkı birçok kişinin Log4J ile yaptığı gibi, farkında olmadan, çünkü bir uygulama ile birlikte gelmiş olabilir.

Ayrıca, uyguladığınız herhangi bir azaltmanın işe yarayıp yaramadığını test etmek için kullanabileceğiniz bazı örnek kodlarımız da var.

---

DOUG.  Pekala, Çıplak Güvenlik'e gidin.

O makalenin adı: Apache Commons Metninde tehlikeli delik – Log4Shell gibi.

Ve bir soruyla bitiriyoruz: "Şifreli mesajlar yalnızca bir tür şifreli olduğunda ne olur?"

---

ÖRDEK.  Ah, sanırım geçenlerde Finli şirket WithSecure'daki siber güvenlik araştırmacıları tarafından hazırlanan resmi bir hata raporundan bahsediyorsunuz…

…Microsoft Office'te sunulan yerleşik şifreleme veya daha doğrusu Office 365 Message Encryption veya OME adlı bir özellik hakkında.

Bunun gibi küçük bir özelliğin uygulamada yerleşik olması oldukça kullanışlı.

---

DOUG.  Evet, kulağa basit ve kullanışlı geliyor!

---

ÖRDEK.  Evet, hariç… oh, canım!

Görünüşe göre bunun nedeni tamamen geriye dönük uyumluluk, Doug…

… Microsoft, bu özelliğin, yerleşik şifre çözme yeteneklerine sahip olan Office 2010'u hala kullanan kişilere kadar çalışmasını istiyor.

Temel olarak, bu OME'nin dosyayı şifreleme işlemi, en son ve en büyük NIST standardize şifreleme algoritması olan AES'yi kullanıyor gibi görünüyor.

Ancak yanlış sözde şifreleme modunda AES kullanır.

ECB olarak bilinen şeyi kullanır veya elektronik kod kitabı modu.

Ve bu, ham AES'ye atıfta bulunma şeklinizdir.

AES bir seferde 16 baytı şifreler… bu arada, AES-16, AES-128 veya AES-192 kullansanız da 256 baytı şifreler.

Blok boyutunu ve anahtar boyutunu karıştırmayın – blok boyutu, kriptografik motordaki krank kolunu her çevirdiğinizde çalkalanan ve şifrelenen bayt sayısı her zaman 128 bis veya 16 bayttır.

Her neyse, elektronik kod çizelgesi modunda, sadece 16 baytlık girdi alırsınız, belirli bir şifreleme anahtarı altında krank kolunu bir kez çevirirsiniz ve ham ve yeniden işlenmemiş çıktıyı alırsınız.

Ve bununla ilgili sorun şu ki, aynı 16 baytlık sınırda hizalanmış bir belgede aynı girişi her aldığınızda…

…çıktıda tam olarak aynı verileri alırsınız.

Böylece, girdideki örüntüler, tıpkı bir dizide olduğu gibi çıktıda ortaya çıkar. Sezar şifre veya bir Vigenere şifre:

Şimdi, bu, şifreyi kırabileceğiniz anlamına gelmiyor, çünkü hala 128 bit genişliğindeki parçalarla uğraşıyorsunuz.

Elektronik kod defteri kipiyle ilgili sorun, tam olarak, düz metinden şifreli metne kalıp sızdırması nedeniyle ortaya çıkar.

Bilinen düz metin saldırıları, belirli bir giriş dizesinin belirli bir şekilde şifrelendiğini bildiğinizde mümkündür ve bir belgede (başlık veya şirket adı gibi) tekrarlanan metinler için bu kalıplar yansıtılır.

Ve bu, Microsoft'a bir hata olarak bildirilmiş olsa da, görünüşe göre şirket, bir güvenlik düzeltmesi için "barı karşılamadığı" için düzeltmeyeceğine karar verdi.

Ve görünen o ki sebep, "Pekala, Office 2010'u hâlâ kullanan insanlara bir kötülük yapmış olacağız."

---

DOUG.  Of!

---

ÖRDEK.  Evet!

---

DOUG.  Ve bu notta, bu hafta için bu hikayeyle ilgili bir okuyucu yorumumuz var.

Çıplak Güvenlik Okuyucusu Bill kısmen şunları söylüyor:

Bu bana İkinci Dünya Savaşı sırasında Bletchley Park kod kırıcılarının kullandığı 'beşikleri' hatırlatıyor. Naziler mesajları genellikle aynı kapanış cümlesiyle sonlandırdı ve böylece kod kırıcılar, muhtemelen neyi temsil ettiklerini bilerek bu kapanış şifreli karakter kümesinden geri dönebildiler. 80 yıl sonra aynı hataları tekrarlıyormuşuz gibi görünmesi hayal kırıklığı yaratıyor.

---

ÖRDEK.  80 yıl!

Evet, gerçekten hayal kırıklığı yaratıyor.

Anladığım kadarıyla, Müttefik kod kırıcıların, özellikle Nazi tarafından şifrelenmiş metinler için kullanabileceği diğer beşikler de belgenin *başlangıcıyla ilgilendi.

Bunun Alman hava raporları için bir şey olduğuna inanıyorum… Hava raporlarını tam olarak verdiklerinden emin olmak için izledikleri dini bir format vardı.

Ve tahmin edebileceğiniz gibi, geceleri havadan bombalama içeren bir savaş sırasında hava durumu raporları gerçekten önemli şeylerdi!

Görünüşe göre bunlar, zaman zaman biraz kriptografik “gevşetici” olarak adlandırabileceğiniz veya ilk etapta içeri girmek için kullanabileceğiniz bir takoz olarak kullanılabilecek çok, çok katı bir model izledi.

İşte bu, Bill'in de belirttiği gibi… işte bu yüzden elektronik kod çizelgesi modunda AES veya herhangi bir şifre, tüm belgeleri şifrelemek için tatmin edici değil!

---

DOUG.  Pekala, bunu gönderdiğin için teşekkürler Bill.

İletmek istediğiniz ilginç bir hikayeniz, yorumunuz veya sorunuz varsa, podcast'te okumayı çok isteriz.

Tips@sophos.com adresine e-posta gönderebilir, makalelerimizden herhangi biri hakkında yorum yapabilir veya sosyal medyadan bize ulaşabilirsiniz: @nakedsecurity.

Bugünkü programımız bu; dinlediğiniz için çok teşekkürler.

Paul Ducklin için, ben Doug Aamoth, bir dahaki sefere kadar size hatırlatıyorum…

---

HER İKİSİ DE.  Güvende kalın!