Üç Dolarlık Hesap, 40 Milyon Dolarlık Soygun

Bir barmen ve uluslararası bir suç örgütü, aynı açığı birbirinden habersiz buldu. Aralarındaki teknik bilgi farkı uçurum kadardı, fakat buldukları çatlak aynıydı.

Wangaratta, 2011

Avustralya’nın Victoria eyaletinde, Melbourne’ün üç saat kuzeyinde Wangaratta diye küçük bir kasabada, 2011 yılının bir gecesi, kasabanın barlarından birinde çalışan 29 yaşındaki Dan Saunders para çekmek için dışarı çıkıyor.

ATM’ye kartını takıyor… Bakiye: 3$

Buna rağmen yüz dolar çekmeyi deniyor. Ekranda hata mesajı çıkıyor. Ve makine parayı veriyor.

Çoğu insan burada omuz silker, “herhalde sistemsel bir hata” der, geçer. Saunders geçmiyor. Ertesi gün tekrar deniyor, sonra biraz daha yüksek bir tutarla, sonra bir daha. Teknik hiçbir bilgisi yok, yazılımcı değil, güvenlikçi değil, bankacı hiç değil. Sadece deneyip duruyor ve bir kalıp yakalıyor: belirli saatlerde kredi kartından hesabına yaptığı transferler ATM tarafında “olmuş” sayılıyor, ama bankanın merkezî kaydına henüz düşmüyor.

Yani makine “evet” diyor, defter henüz hiçbir şey demiyor.

Bu boşluk dört buçuk ay sürüyor ve Saunders bu sürede 1,6 milyon Avustralya doları çekiyor. Sonunda onu durduran şey bankanın güvenlik sistemi olmuyor — kendi vicdanı oluyor, bir televizyon programına çıkıp anlatıyor.

Hikâyenin en can sıkıcı yeri de burası: banka sonunda “yetişiyor”. Mutabakat devreye giriyor, offline pencerede yapılan işlemler geri alınıyor, hesap yeniden üç dolara dönüyor. Kontrol mekanizması zaten vardı. Sadece dört buçuk ay geç çalıştı.

Yirmi Ülke, On Saat

İki yıl sonra aynı kör noktayı çok daha profesyonel eller buluyor.

19 Şubat 2013 öğleden sonra. Yirmiden fazla ülkede, birbirini tanımayan yüzlerce kişi aynı anda sokağa çıkıyor. Ellerinde manyetik şeritli kartlar var, bir kısmı eski otel kartı, bir kısmı boşalmış hediye kartı, üzerlerine yeni veri yazılmış. Her biri bir ATM’den diğerine koşuyor, makinenin tek seferde verdiği maksimumu çekiyor, sıradakine geçiyor.

On saat sonra ortada 40 milyon dolar yok. Aralık ayındaki provada iki buçuk saatte 5 milyon dolar çekilmişti.

Sokaktaki bu insanların çoğu ne olup bittiğini bilmiyor; onlar operasyonun görünen yüzü. Asıl iş aylar önce, çok daha küçük bir ekip tarafından yapılmıştı.

O ekip bankalara saldırmadı. Bankaların arkasındaki aracı/processor firmalara saldırdı BAE’deki RAKBANK ve Umman’daki Bank of Muscat adına ön ödemeli kart işlemlerini yürüten şirketlere. İçeri girdikten sonra üç şey yaptılar: kartların çekim limitlerini kaldırdılar, bakiyeleri değiştirdiler ve saldırıyı fark ettirecek güvenlik uyarılarını susturdular.

Sonra kart verilerini dünyaya dağıtıp bir tarih verdiler.

Bu kalıbın suç dünyasındaki adı “Unlimited Operation”. İsim yerinde: saldırı ATM’yi kırmıyor, kasayı patlatmıyor, kimseyi kandırmıyor. Sadece “bu karttan ne kadar çekilebilir?” sorusuna cevap veren yerin cevabını değiştiriyor.

Ortak Payda

İki olayın yüzeyi bambaşka: biri bir barmenin tesadüfü, diğeri organize suç. Ama alttaki hata aynı:

Kararı veren yer ile o kararı doğrulayan yer, zaman ya da sorumluluk olarak birbirinden kopmuştu.

Kart ödemelerinde ideal zincir şu: ATM → şebeke → kartı veren banka → anlık bakiye kontrolü → onay/ret. Ama bu zincir her zaman çalışmaz. Banka sistemi bakımdaysa, hat koptuysa, gecikme olduysa ne olacak?

İşte burada stand-in processing devreye girer: bankanın yerine zincirdeki başka bir aktör, önceden tanımlı ve daha gevşek kurallarla işlemi onaylar. Kötü niyetli bir tasarım değil, tam tersine, sistemi ayakta tutmak için var. Banka çöktü diye milyonlarca kart ölmesin diye.

Ön ödemeli kartlarda bu devir çoğu zaman geçici bile değildir: limit ve bakiye kalıcı olarak processor tarafında tutulur, onayı baştan sona o verir.

Kırılma tam burada:

Saunders’ta kırılan zamandı. ATM tarafındaki onay anlıktı, merkezî mutabakat gecikmeliydi. Aradaki pencerede sistem, kendi kaydından emin olmadan para vermeye devam etti.

Unlimited Operation’da kırılan sorumluluktu. Banka, “bu karttan ne kadar çekilir” sorusunun cevabını başka bir şirkete bırakmıştı ve o cevabı kendi tarafında doğrulamıyordu. Saldırgan bankaya hiç dokunmadan, sadece cevabın üretildiği yeri ele geçirerek bankanın parasını aldı.

İkisinde de asıl açık şu: sistem, kendisine söyleneni doğrulamadan doğru kabul etti, çünkü doğrulayacak taraf ya henüz uyanmamıştı ya da işi başkasına devretmişti.

Çözüm Bulundu mu? Hem Evet Hem de Hayır…

2013 soygunundan sonra sektör hareketsiz kalmadı. Amerikan denetim otoriteleri (FFIEC) ortak bir uyarı yayınladı, FDIC bunu 2014'te resmî bir direktife çevirdi. Öneriler isabetliydi: ATM parametrelerinin yönetildiği panellere MFA zorunluluğu (saldırganların limit değiştirmek için girdiği tam nokta), PCI DSS uyumu, processor firmaların ve ATM hareketlerinin sürekli izlenmesi, düzenli risk değerlendirmesi.

Kâğıt üzerinde açık kapanmıştı.

Sonra 2016 ve 2017'de Virginia’da küçük bir banka, National Bank of Blacksburg, aynı kalıptaki iki saldırıda 2,4 milyon dolar kaybetti. İkisi de hafta sonuna denk getirilmişti.

Rehber yayınlanmıştı. Kalıp biliniyordu. Yine de oldu.

Neden Hâlâ Kapanmıyor?

Asıl mesele burası. Bu bir “kimse fark etmedi” hikâyesi değil; herkes fark etti, çözüm yazıldı, yayınlandı ve açık yine de tam kapanmadı. Sebepleri teknik değil, yapısal.

Fallback zaten gevşek olmak zorunda. Varlık sebebi iş sürekliliği: “ana sistem çökse de hizmet dursun istemiyoruz” demek. Bu yolu sıkılaştırdıkça amacını yok edersiniz. Yani mühendis her seferinde aynı ikilemle karşılaşır; güvenlik mi, ayakta kalmak mı? Fallback’te ikincisi kazanır. Bu bir hata değil, bilinçli tercih; sadece bedeli genelde hesaplanmaz.

Nadiren çalışan yol test edilmez. Ana yol her gün milyonlarca kez koşar, her hatası anında görülür. Fallback yılda birkaç saat çalışır: kimse onunla yaşamaz, dashboard’da yeri yoktur, test senaryosu listenin en altındadır ve oraya çoğu zaman hiç gelinmez. Sonuç acı bir ironi: en az test edilen yol, en kritik anda devreye giren yoldur.

Sorumluluk zincire yayılınca kimse sahiplenmez. 2013'te zincir şuydu: kartı veren banka → Visa/Mastercard → processor → ATM operatörü. Herkes bir sonrakinin işini doğru yaptığını varsaydı. Oysa saldırgan sözleşme okumaz, en zayıf halkaya gider. Kırılan processor’du, parayı kaybeden banka oldu.

İzleme batch çalışıyordu. Saunders’ın dört buçuk ayının tek sebebi bu. Mutabakat vardı, çalıştı, işlemleri geri de aldı — sadece geç. Batch mutabakat muhasebe için yeterlidir, güvenlik için değil; çünkü hırsız iki kontrol arasındaki pencerede yaşar.

Saldırgan saati de biliyor. Blacksburg’un hafta sonuna denk gelmesi tesadüf değil. Sistem 7/24 çalışır, insan çalışmaz. Alarm üretilse bile ona bakacak kişi pazartesi işe gelir. Yani açık sadece kodda değil, vardiya çizelgesinde.

Ve en rahatsız edici olanı:

Bulmanın eşiği düşük, kapatmanın eşiği yüksek. Bu açığı bulmak için ne gerekiyordu? Saunders örneğinde sıfır teknik bilgi, bir hata mesajına rağmen paranın çıkması ve “acaba bir daha olur mu” merakı. Kapatmak için ne gerekiyor? Real-time mutabakat altyapısı, tedarikçi denetim programı, 7/24 izleme ekibi, MFA, düzenli fallback tatbikatı ve bunları finanse edecek bir bütçe kalemi.

Bir tarafta merak var, diğer tarafta bütçe. Merakın maliyeti yok. Bu asimetri kapanmadıkça açık da kapanmayacak.

Peki Yaklaşım Nasıl Olmalı?

Bu aslında bir bankacılık hikâyesi değil, bir tasarım alışkanlığı hikâyesi. Ve o alışkanlığın eksik kaldığı yer bugün kurduğumuz sistemlerde aynen tekrar ediyor.

Fallback’i ayrı bir sistem gibi ele alın. Çoğu tasarımda önce ana akış kurulur, sonra sona bir “ya olmazsa” dalı eklenir. O dal mimari toplantısında konuşulmaz, code review’da hızlı geçilir, test planının en altında kalır. Oysa çalışacağı an, sistemin en kırılgan olduğu andır. Kendi testleri, kendi logları, kendi alarmları olmalı ve arada bir gerçekten denenmeli. Ana sistemi bilerek kapatıp ne olduğunu izlemeden, o yolun çalıştığını bilemezsiniz.

Belirsizlikte fail-open değil, fail-closed. Sistemler emin olamadıklarında bir yöne düşer ve o yönü tasarımcı seçer, çoğu zaman farkında bile olmadan. Config okunamadığında koda gömülü default’a düşmek, doğrulama servisi cevap vermediğinde işlemi geçirmek, limit sorgusu timeout aldığında “limit yok” saymak, hepsi aynı tercih. Emin olamayan sistem geçmemeli, durup sormalı. Bu bazen downtime demek, ama downtime’ın maliyeti hesaplanabilir; sessizce açık kalmanın maliyeti hesaplanamaz.

Aynı işlem iki kez olmasın. Saunders’ın bulduğu şey, bugün her dağıtık sistemin temel problemi: bir tarafta karar verilmiş, diğer tarafta henüz yazılmamış. Bağlantı koptuğunda, timeout olduğunda, istek retry edildiğinde bu pencere açılır. Çözüm on yıllardır aynı: her işleme benzersiz bir key verip karşı tarafın aynı key’i ikinci kez işlememesini garanti etmek. Sistemin “bunu yaptım mı?” sorusunu kendi hafızasına değil, kaydın tutulduğu yere sorması.

Devretmek doğrulamayı bitirmez. Bugün hiçbir sistem tek başına çalışmıyor: kimlik doğrulama bir sağlayıcıda, ödeme başka serviste, veri üçüncü yerde. Her devir bir sözleşmeyle yapılıyor ve sözleşme imzalandığı anda çoğu ekip kontrolü bırakıyor. Ama sorumluluk devredilebilir, sonuç devredilemez. Dışarıdan gelen kritik cevabı en azından tutarlılık açısından kendi tarafınızda bir kez daha süzün.

Ölçmediğiniz kontrol, kontrol değildir. Mimari şemalarda kutular vardır: “manuel onay”, “ikinci seviye kontrol”, “risk incelemesi”. Kutu çizildiği anda herkes çalıştığını varsayar. Peki o kuyruğa günde dört yüz kayıt düşüyorsa ve bakan kişinin başka on işi varsa? Kutu yerinde durur, işlevi kaybolur. Ölçüt basit: bir kontrol adımının red oranını takip etmiyorsanız, çalışıp çalışmadığını bilmiyorsunuz. Red oranı sıfıra yaklaşan onay adımı artık kapı değil, koridordur.

Doğrulama, muhasebe hızında değil saldırı hızında olmalı. Real-time kontrol pahalıdır, doğru. Ama sorulacak soru “ne kadara mal olur” değil, “bu pencerede ne kadar zarar birikebilir”. Pencereyi kapatmanın maliyeti sabittir; açık bırakmanın maliyeti değişken ve üst sınırsızdır.

Vardiyayı da tehdit modeline koyun. Alarm üretilip kimse bakmıyorsa, o alarm üretilmemiş sayılır. Ya izleme sistemin çalıştığı her saati kapsar, ya da sistem kimsenin bakmadığı saatlerde kendiliğinden daha temkinli davranır.

Sonuç

Bu iki hikâyeyi yan yana koymamın sebebi aralarındaki mesafe.

Bir tarafta yirmi ülkeye yayılmış, processor firmaların iç sistemlerine sızacak kadar yetkin, güvenlik alarmlarını susturacak kadar sistemi tanıyan bir organizasyon. Diğer tarafta hesabında üç dolar olan, merakına yenilmiş bir barmen.

İkisi de aynı çatlağı buldu.

Bir tasarım hatasının ne kadar temel olduğunu ölçmenin en iyi yolu, onu bulmak için gereken bilgiye bakmaktır. Burada o bilgi neredeyse sıfırdı.

Ve bugün, on beş yıl sonra, bu açık hâlâ tam kapanmış değil. Çünkü kapanması için gereken şey bir yama değil, süreklilik isteyen bir disiplin.

Kurduğumuz sistemlerde de aynı yerdeyiz. Ana akışı özenle tasarlıyoruz, defalarca test ediyoruz, dashboard’a bağlıyoruz. Sonra bir de “ya olmazsa” diye bir dal yazıyoruz: bir catch bloğu, bir default değer, bir onay kuyruğu, bir manuel süreç.

O dal, sistemin en kritik anında çalışacak olan daldır. Ve genellikle en az baktığımız yerdir.

Yedeğin yedeği yok. O yüzden yedek, aslı kadar sağlam olmak zorunda.

Kaynakça

1. U.S. Department of Justice, EDNY — “Unlimited Operation” iddianamesi (2013): https://www.justice.gov/usao/nye/pr/2013/2013nov12.html
2. American Banker — Data Breaches Back in Spotlight After $45M ATM Heist (2013): https://www.americanbanker.com/news/data-breaches-back-in-spotlight-after-45m-atm-heist
3. NBC News — Bank heist impressed cyber crime experts (2013): https://www.nbcnews.com/technology/bank-heist-impressed-cyber-crime-experts-1C9881411
4. Marketplace — ATM heist reveals vulnerabilities in global security (2013): https://www.marketplace.org/story/2013/05/10/atm-heist-reveals-vulnerabilities-global-security
5. FDIC — FIL-10–2014, ATM and Card Authorization Systems: https://www.fdic.gov/news/financial-institution-letters/2014/fil14010.pdf
6. Baird Holm LLP — “Unlimited Operations”: FFIEC Guidance against a 21st Century Bank Heist: https://www.bairdholm.com/blog/unlimited-operations-ffiec-guidance-against-a-21st-century-bank-heist/
7. CBS News — FBI warns of “unlimited” ATM cash-out scheme (Blacksburg dahil): https://www.cbsnews.com/amp/news/fbi-reportedly-warns-of-unlimited-atm-cash-out-scheme
8. VICE — This Australian Bartender Found an ATM Glitch and Blew $1.6 Million: https://www.vice.com/en/article/this-australian-bartender-dan-saunders-found-an-atm-bank-glitch-hack-and-blew-16-million-dollars/
9. USPTO — System and method for stand-in processing (US 10872323): https://image-ppubs.uspto.gov/dirsearch-public/print/downloadPdf/10872323