Bankam oltalama karşıtı eğitimi durmadan baltalıyor
(moritz-mander.de)- Banka, güven vermeyen oltalama e-postalarına benzeyen etkinlik tanıtım mailleri gönderiyor
- Metin içindeki bağlantılar ve site alan adı bankayla ilgisiz görünüyor; kişisel bilgi girişi istendiği için oltalama olup olmadığını anlamak zorlaşıyor
- Gerçekliği doğrulandıktan sonra bile bunun resmî bir etkinlik olduğunun anlaşılması, kafa karışıklığını ve güvensizliği artırıyor
- Bu davranış, oltalama eğitiminin amacını zedeliyor ve bankanın hukuki sorumluluk üstlenme riskini büyütüyor
- Sorunun çözümü için güvenilir alan adlarının kullanılması ve sürecin uygulama içinde kurgulanması gereği vurgulanıyor
Giriş
Bankamın oltalama karşıtı eğitimi bizzat baltaladığı bir durum yaşadım. Bankanın gönderdiği etkinlik e-postası, oltalama dolandırıcılığından neredeyse ayırt edilemeyecek kadar şüpheli özellikler taşıyordu. Resmî banka alan adı dışında bir yerde kişisel bilgi girmenizi istiyor; ayrıca yurt içi ve yurt dışındaki bankalar ile kamu kurumlarının güvenlik uygulamaları ve eğitim gerçekliğindeki sorunlara işaret ediyor.
1. Bölüm: Şüpheli e-postanın gelişi
- Bankadan “Wero-Win-Wochen(ödüllü etkinlik)” konulu bir e-posta alındı
- E-posta duyurusu, haftada en fazla 7.000 avro kazanma bilgisiyle etkinliğe katılımı teşvik ediyor
- Mailde Sparkasse (Almanya’daki bölgesel tasarruf bankaları ağı) ve Wero (yeni Avrupa dijital ödeme sistemi) anılıyor
- E-postadaki bağlantı “gewinnen-mit-wero.de” adresine gidiyor; bu da bankanın resmî alan adıyla farklı
- İçerik ve üslup sıradan bir oltalama e-postasına benziyor; yalnızca gönderen adresi Sparkasse’nin resmî adresi
- Etkinliğin gerçekten var olup olmadığını bankanın resmî sitesinden doğrulamak gerekti
Sparkasse nedir?
- Bölge temelli tasarruf bankalarıdır ve her bölge kendi başına bağımsız çalışır
- Avrupa’nın en büyük finansal hizmet gruplarından biridir
Wero nedir?
- Avrupa Ödemeler Girişimi (EPI) tarafından oluşturulan yeni bir dijital ödeme sistemidir
- Yerel ödeme sistemlerini birleştirme amacıyla geliştirildi (başlangıçta P2P ödemelere odaklı)
- PayPal’a benzer, ancak yapı olarak bankalara dağılmıştır
2. Bölüm: Durumun kötüleşmesi – şüpheli web sitesi
- E-postadaki bağlantıya tıklayınca açılan etkinlik katılım sitesi, tasarım ve yapı açısından birçok yönden bir oltalama sitesine çok benziyor
- Sparkasse şubelerine dair bir ifade ya da bankalar arasında herhangi bir ayrım yok (her bankanın bağımsız yapısı yok sayılıyor)
- Alan adının kendisi resmî banka alan adıyla ilgisiz ve herkesin kaydedebileceği genel bir isim kullanıyor
- SSL sertifikası olarak da ücretsiz Let’s Encrypt kullanılıyor, bu da güven algısını düşürüyor
- Etkinliğin bağlamı ya da dayanağı yeterince açıklanmıyor; sadece “para alma fırsatı” öne çıkarılıyor
- Katılım için ad, doğum tarihi, IBAN, e-posta adresi gibi kişisel/finansal bilgilerin girilmesi isteniyor
- Normalde modern dijital finans etkinlikleri, yalnızca uygulama içinden katılıma göre tasarlanırken bu yaklaşım bununla çelişiyor
Bunun sonucu olarak finans kurumları, kullanıcı güvenlik eğitimini bilerek anlamsızlaştırıyormuş gibi bir tablo ortaya çıkarıyor.
Güvenlik eğitiminin etkisinin zayıflaması sorunu
- Gerçek bankalar bile oltalama e-postaları/sitelerine benzeyen yöntemler kullandığında, kullanıcılar oltalama tespiti eğitimine güvenmemeye başlıyor
- “Bu spam gibi görünüyor ama aslında meşru olabilir” düşüncesi yayılıyor
- Geçmişte de ilgili banka, şüpheli ifadeler ve alan adları içeren resmî SMS’ler göndermişti (ör. paperless.io bağlantı yönlendirmesi)
- Destek merkezi bile bunun neden spam gibi görünebileceğini anlayamıyor
3. Bölüm: Çözüm ne olabilir?
- En güvenli yöntem, etkinliğe katılım sürecini doğrudan uygulama içinde uygulamaktır
- Bu kaçınılmaz değilse, güvenilirliğin korunması için resmî alan adı (ör. sparkasse.de) veya her şubenin alt alan adları kullanılmalı
- Alman hükümeti de benzer olayların ardından gov.de dijital marka politikası getirerek hizmet güvenilirliğini güçlendirdi
4. Bölüm: Dikkatsizliğin hukuki soruna dönüşme ihtimali
- Son dönemde oltalama mağdurlarına banka tarafından tazminat ödenmesine ilişkin emsal kararlar artıyor
- Mahkemeler, kişisel bilgi sızıntısında “ihmal” bulunup bulunmadığını değerlendirirken kullanıcı kusurlu değilse sorumluluğu bankaya yüklüyor
- Eğer bugünküne benzer e-posta/site yapısıyla bir oltalama saldırısı yürütülse, mağdurun yeterince dikkatli davranmadığını bankanın kanıtlaması zor olur
- Gerçek banka e-postaları/siteleri ile oltalama girişimleri birbirine fazla benzediği için hukuki risk büyüyor
Sonuç
- Teknik güvenlik gelişiyor olsa da, kullanıcı deneyimi güvenliği (USABLE SECURITY) tarafında hâlâ açıklar var
- Bu tür örnekler, oltalama karşıtı eğitimin kendisine duyulan güveni zedeliyor; bankaların hukuki yükünü ve tüm finans sektörüne olumsuz etkiyi artırıyor
- Sorun, tek tek verilen geri bildirimlerle çözülmesi zor olan yapısal bir sistem sorunu
- Avrupa’nın en büyük finans gruplarından birinde bile yaşanması, konunun daha ciddiye alınması gerektiğini gösteriyor
- Yazı şu dersle bitiyor: “Güvenlik eğitimini baltalamayın. Tam tersine, biraz daha özen gösterin.”
2 yorum
Déjà vu hissi bir yanılsama değil gibi görünüyor 🤣
Hacker News görüşü
Bankam, hesabımda şüpheli bir hareket algılanırsa beni arayan bir dolandırıcılık tespit sistemi kullanıyor ve sonra benden belirli bir numarayı geri aramamı istiyor; sorun şu ki her seferinde farklı bir geri arama numarası veriyor. O numarayı internette aradığınızda tek bir sonuç çıkıyor; o da dolandırıcılık tespit sisteminin resmî sayfası ve hiçbir telefon çağrısına güvenmemeniz gerektiğini söylüyor. Bu tavsiye yerinde, ama ironik biçimde kendi meşru aramalarını da yok sayın demek oluyor.
Kartımda dolandırıcılık tespit sistemini tetiklediğim tek bir deneyim yaşadım. O sırada bankadan “kartınız şüpheli kullanım nedeniyle bloke edilmiştir, lütfen şu numarayı arayın” diye bir SMS aldım. O numara da rastgele atanmış, listelenmeyen bir numaraydı. Bunu görmezden gelmememin tek sebebi, hemen öncesinde yeni bir web sitesinde ödeme yapmış olmamdı. Bu yüzden doğrudan yerel banka şubemi arayıp bunun gerçek bir durum olup olmadığını doğruladım ve gerçekten öyle olduğu söylendi. Bu sürecin ne kadar berbat olduğuna dair şikâyet yağdırmamak için kendimi zor tuttum.
Görünüşe göre bankada kullanıcı deneyimi (UX) akışının tamamından sorumlu biri yok. Benim bankam da benzer şekilde tuhaf çalışıyor. Örneğin eşime her para transferi yaptığımda dolandırıcılığı önlemek için bana bir dizi soru soruyor; soruları yanıtladıktan sonra da “sık transfer yaptığınız için 2FA kodu ya da ek doğrulama istemeyeceğiz” diye bir mesaj gösteriyor. Bu kadar mantıksız UX, muhtemelen bütün akışı sahiplenen tek bir kişi ya da ekip olmamasından kaynaklanıyor.
Bankalar kendi koydukları kurallara uymuyor. Bir keresinde, bir ay önce talep ettiğim sigorta değişikliğiyle ilgili bankadan arandım ve benden güvenlik dongle’ıyla kimliğimi doğrulamam istendi. Böyle olunca insanların dolandırılmasına şaşmamak gerek.
Çalıştığım banka, “$x tutarında bir çek keşide ettiniz mi?” diye SMS göndererek anormallik olup olmadığını kontrol ediyor. Sorun şu ki en yaygın çek dolandırıcılığı, çek tutarını aynı bırakıp yalnızca lehtarı değiştiren “check washing”. Böyle olunca tutar doğru olduğu için meşru bir işlem gibi görünüyor ama gerçekte kime ödendiği doğrulanamıyor.
Bankanın genel çağrı merkezini arayıp uzun süre bekledikten sonra bir temsilciye ulaşsanız bile, numara aslında doğru olsa da o numarayı tanımadıklarını söylüyorlar. Daha da sinir bozucu olan, müşterisi olmadığım bir bankada durum daha beter: web sitesindeki numarayı aradığınızda doğrudan otomatik yanıt sistemine bağlanıyorsunuz ve hesap numaranız yoksa hiçbir yere ulaşamıyorsunuz; yani biriyle gerçekten konuşabilmek için aranabilecek başka bir numara bulmanız gerekiyor.
Benim bankam (USAA), daha önce önerdiğim bazı şeyleri gerçekten hayata geçirmişti. Ama yakın zamanda bana özel e-posta adresime normal görünümlü bir e-posta geldi ve alan adı alışılmıştan farklıydı; üstelik ben de tam o sırada bir işlem yapmıştım, bu yüzden daha da şüpheliydi. Hemen bankayı arayıp dolandırıcılık departmanındaki bir görevliyle görüştüm ve “ya iç sisteminiz hack’lendi ya da müşterileri phishing’e alıştıra alıştıra duyarsızlaştırıyorsunuz” diye durumu anlatarak ticket açmasını istedim. Görevli, o alan adının USAA’ya ait olmadığını ve yalnızca usaa.com kullandıklarını söyledi, sonra da hiçbir açıklama yapmadan hesabımı kilitledi. Sonunda tekrar arayıp hesabımı açtırdım; görevli ticket oluşturduğunu söyledi. Bundan sonra ne olacağını görmek gerekecek.
Bankacılıktaki kullanıcı deneyimiyle ilgili teknik ve pazarlama uygulamaları rezalet. Kullandığım tüm Hint bankalarının giriş formları:
15 karakterden fazla yasak mı? Benim bankamda parola tam olarak 6 haneli sayı olmak zorunda; harf bile değil, sadece rakam. Parola yöneticisi kullanamıyorsunuz, kopyala/yapıştır da engelli. Rakam kutularını fareyle tek tek tıklamanız gerekiyor. “Güvenlik” takıntısı yüzünden ikinci faktör doğrulama da önce fiziksel token’dan uygulamaya, en sonunda da SMS’e döndü. Ve burası küçük bir kasaba bankası değil, Fransa’nın en büyük bankası.
Birkaç hafta önce, Hindistan’daki bir kamu bankasının uygulamasının kullanıcı sadece Firefox kurdu diye uygulamayı tamamen engellediğini gösteren bir ekran görüntüsü Reddit’te tartışma yaratmıştı. Bankalarla devlet siteleri kullanıcılara aşırı derecede düşmanca davranıyor. Eskiden bunu teknolojiye aşina olmayan kullanıcıları koruma çabası sanırdım; artık bunun, aslında güvenli ve kullanışlı çerçeveleri düzgün şekilde benimsememek için üretilmiş bir bahane olduğunu düşünüyorum.
Bazı Hint kamu bankası uygulamaları, kamera ve tüm dosya sistemi gibi gerekli olmayan izinler verilmeden hiç çalışmıyor. Ama kendi bankamda OP’nin anlattığı türden spam almadım. Yine de yaygın algı, alt kademe çalışanların hesap bilgilerini dolandırıcılara düzenli olarak sızdırdığı yönünde.
Benim bankam 180 günde bir parola değiştirmeyi zorunlu kılıyor; parola yalnızca 6 ila 11 karakter arasında olabiliyor ve kullanılabilecek karakterler de sınırlı. Bu yüzden giriş yapmaya çalışınca yine parola değiştir deniyor, Firefox’un otomatik ürettiği parolalar da banka kurallarına uymuyor; sonuç olarak terminal açıp koşullara uyan rastgele bir parola elle üretmek zorunda kalıyorum.
Client-side parola hash’i kullanmanın neden sorun olduğunu pek anlamıyorum.
Ev alım satımında bu sorun daha da kötüleşiyor. Çeşitli alt organizasyonlar, her biri farklı alan adları kullanınca işler iyice karmaşıklaşıyor. Ben de tıbbi cihaz geri çağırmasıyla ilgili bir konuda şüpheli bir alan adına güvenmek zorunda kalmıştım. Oysa bunu çözmek için web sitesine güvenilir iş ortağı alan adlarının basit bir listesini koymak yeterli olurdu. Benim kişisel güvenlik protokolüm, .gov sitesinden finans kurumunun iletişim bilgilerini aramak, o alan adına gidip müşteri hizmetleri numarasını bulmak ve gerçekten güvenilir alan adlarının hangileri olduğunu telefonla doğrulatmak. Müşteri hizmetlerindeki çalışanlar genelde bana tuhaf tuhaf bakıyordu. Hatta bir gün bir temsilci, “LinkedIn’de görevlinin <Bank Name> şirketinde çalıştığı görünüyorsa onun gerçek olduğunu anlayabilirsiniz” bile dedi.
Bana “LinkedIn’de <Bank Name> iş yeri olarak görünüyorsa güvenebilirsiniz” dendiğinde, “Bana 2 dakika verin, profilime ben de aynısını yazarım; o zaman kişisel bilgilerimi bana da verir misiniz?” diye sormuştum.
Ev satın alırken bunun hiç karmaşık olmadığı bir deneyim de yaşadım. Mortgage işini bir broker üzerinden yürüttüm ve bire bir tek bir kişiyle muhatap oldum.
Karar verme yetkisi olan saf insanlar, bu riskleri genellikle ancak kendileri ya da yakın çevreleri dolandırıcılık veya hukuki sorun yaşadıktan sonra fark ediyor. ABD’de de 2012’den önce pek çok şirket böyle insanlar tarafından yönetiliyordu; ama white-hat/black-hat hack kültürü hızla yayılınca bu tür sorunlar nispeten hızlı biçimde çözüldü.
Eskiden bilgi güvenliği kültürü güçlü olan bir finans şirketinde çalışıyordum. Şirket satın alındıktan sonra, merkezdeki yöneticiler adına dış tedarikçilerden sürekli çeşitli talep e-postaları gelmeye başladı. Ama bizim eski güvenlik politikamıza göre bu tür e-postaların işleme alınması yasaktı. Slack’te herkes bunun muhtemelen gerçek bir e-posta olduğunu ama politika gereği yine de phishing olarak raporlamamız gerektiğini savundu. Sonuçta kötü niyetli bir itaatsizlikti, ama aslında yapılması gereken de buydu. Daha sonra merkezdeki bir yönetici, “böyle e-postalar gelecek, lütfen şöyle tepki verin” diye önceden bilgilendirme e-postaları göndermeye başladı. O zaman da arkadaşlarla “peki bu ön bilgilendirme e-postasının gerçek olduğunu nereden bileceğiz?” tartışması yeniden başladı. Sonunda herkes yoruldu ve merkezin daha gevşek güvenlik alışkanlıklarını kabullenmek zorunda kaldı.
Bu tür organizasyonlarda, doğru kararları verebilecek yetenekli insanların gerçekten karar verme yetkisine sahip konumlara gelmesini zorlaştıran sosyal bir yapı olduğunu düşünüyorum. İyi politika oluşturmak için sağa sola sık sık “hayır” demeniz gerekir; bu süreçte en zor kısım da terfi ve işe alım gücü olan kişileri memnun etmektir.
Kâğıt üstünde CISO, EVP, SVP, güvenlik direktörü gibi üst düzey unvanlar dolu olmasına rağmen neden böyle saçma kararlar alındığını gerçekten anlamıyorum. Böyle durumlarda beceriksizlikle kötü niyeti ayırmak zor oluyor. Buna “saflık” demek ise sanki müşteriyi küçümseyen davranışları mazur gösteriyor gibi. Güvenliğe yatırım yapmak da para, yapmamak da kayıp; ama en azından şimdilik kullanıcı kaybetmenin maliyeti, işi güvenli ve doğru yapmanın maliyetinden daha düşük olduğu için bu düzen sürüyor gibi görünüyor. Sonuçta herkes için üzücü bir tablo.
Bankam bana sık sık rastgele pazarlama aramaları yapıyordu ve tekliflerini anlatmadan önce doğum tarihimi ve annemin kızlık soyadını soruyorlardı. Ben de tersine, “Önce sizin gerçekten banka olduğunuzu kanıtlayın” dediğimde hep afallıyorlardı.
Tanımadığım bir aramada benden kişisel bilgi doğrulamam istendiğinde her zaman “Sizin kim olduğunuzu bilmediğim için kişisel bilgi veremem” diyorum. Bunun üzerine yarısı doğrudan kapatıyor, kalanı da hemen satış konuşmasına geçiyor.
Sağlık sektöründe de sık sık aynı şeyi yaşıyorum. Uzman doktor ofisi beni arar aramaz doğum tarihimi soruyor, ben reddedince de çok şaşırıyorlar. Ben de aynı fikirdeyim: aramayı yapan taraf onlarsa, önce kim olduklarını onlar kanıtlamalı.
Benim bankam sonunda bunu anladı ve artık uygulama içinde, ilgili temsilcinin gerçekten satış görüşmesi yaptığı ve tam olarak hangi çalışan olduğu doğrulanabilen bir sistem getirdi.
“O zaman çözüm alt alan adı kaydetmek” fikrinin ortaya çıkma sebebi, BT’de birilerinin alt alan adı gibi yetkileri dağıtmanın riskli olduğunu bilip bunu reddetmesi. Sonra şirketteki diğer departmanlar, özellikle pazarlama, bunu aşmak için kendi alan adlarını bağımsız şekilde kaydediyor. Google gibi şirketlerin bunu nasıl çözdüğünü merak ediyorum. google.com alt alan adının ele geçirilmesi çok cazip bir hedef ama Google da pratikte epey sık alt alan adı kullanıyor. İlgili bir örnek için bu gist bağlantısına bakılabilir.
Çoğu zaman iş BT’ye kadar bile gitmiyor. Pazarlama, organizasyonel olarak BT’den ayrı ve BT’ye iş açmak istemiyor. BT verimsiz ve yavaş işleyen ticket sistemleri kullanıyor, bazen de gereksiz görüş bildiriyor; bu yüzden pazarlama tarafı onları ayak bağı olarak görüyor. Sonuç olarak pazarlama kampanyaları SaaS servislerine ya da dış ajanslara devrediliyor; bunların da kurumsal BT ile neredeyse hiç bağı olmuyor. Pazarlamadaki kişiler alt alan adının ne olduğunu bile bilmiyor; işleri Google araması yapmak ya da linke tıklamak. Zaten kimse URL metnine bakmadığı için alt alan adının neden önemli olduğu konusunda bir farkındalık da yok. Gerçek kullanıcıların internette nasıl davrandığına bakınca, geleneksel phishing karşıtı eğitimin büyük ölçüde anlamsız olduğu ortaya çıkıyor. “Alan adını dikkatlice oku” demektense “Google’da ara ve üst sonuçlara tıkla” daha gerçekçi bir korunma yöntemi gibi duruyor.
Google da bu konuda aynı derecede sinir bozucu. Bilgilendirme e-postaları phishing sanılabilecek biçimde geliyor; ayrıca yalnızca google.com değil, goo.gl, foobar.google gibi çeşitli tuhaf alan adlarını da kullanıyorlar. Eskisi gibi her şeye safça güvenilen dönem artık bitti.
Bence 4. madde asıl mesele. Bankaların müşterilere phishing gibi görünen e-postalar göndermesi ağır ihmal sayılmalı ve hukuki sorumluluk doğurmalı.
Bu, Conway yasasının gerçek hayatta birebir görünmesi gibi. Pazarlama departmanının kendi BT’si var ve çekirdek web sitesini yöneten BT’den ayrı çalışıyor; bu yüzden aynı web alan adı üzerinde birlikte geliştirme yapamıyorlar ve sonuçta ayrı site, ayrı deneyim olarak yayına çıkıyorlar.
Bir arkadaşımın çalıştığı şirkette CISO tüm çalışanlara güvenlik bülteni gönderiyormuş; ama bu e-postalar şirket içi alan adından değil, harici bir alan adından geliyor ve bağlantılar da şirketin kendi sitesi yerine dışarıda barındırılan bir platforma gidiyormuş. Bu yüzden sürekli phishing e-postası gibi görünüyormuş. Özellikle ödüllü kampanya olduğunda daha da sahte duruyormuş; zaten şirketin itibarı düşünüldüğünde öyle cömert ödüller inandırıcı da değilmiş.