Series · 5 partsATM Security AssessmentPart 3 · You are here
- 1ATM Penetrasyon Testinde Güven Sınırları: OS ve XFS Katmanı
- 2ATM Firmware Boot Güven Zinciri: Donanım Güvenlik Sınırları
- 3Masaüstü Gizlendi. Çalıştırma Sınırı Gizlenmedi.You are here
- 4Cihaz API'si Standarttı. Yetkilendirme Varsayıldı.
- 5Bir ATM Sınırlandırıldı. Filo Güven Yolu Sınırlandırılmadı.
60 saniyede Kiosk kapsülleme
Tam ekran bir ATM uygulaması, bir sunum kararidir. Altındaki işletim sisteminin tek amaçlı bir cihaz haline geldiğinin kanıtı değildir. Gerçek sınır, platformun izin verdiği kod, kimlikler, dosyalar, servisler, etkileşim yolları ve bakım durumları kümesidir.
Kullanışlı pentest sorusu “Masaüstü görünür hale getirebilir miyim?” değil şudur:
Eğer halka açık oturum beklenmedik bir işletim sistemi fonksiyonuna ulaşırsa, bu fonksiyonu kod çalıştırma, yetki, gizli veri erişimi, cihaz otoritesi, kalıcılık veya görünmez bir değişiklik haline getirmekten engelleyen bağımsız kontrol nedir?
Bu metodoloji, zararsız test araçları ve tedarikçi onaylı laboratuvar durumlarını kullanır. Silahlı yükler (payload), kimlik bilgisi dökümü, yıkıcı politika değişiklikleri veya üretim ödeme verilerine erişim gerektirmez. Reddedilen bir süreç başlatma, engellenen bir dosya geçişi ve korelasyonlu off-host olayı genellikle dramatik bir kiosk kaçışından daha temiz bir şekilde sınırı kanıtlar.
Kabuk ve politika farklı kontrollerdir
Windows, Atanmış Erişim (Assigned Access) ve Shell Launcher gibi kiosk ve kısıtlanmış kullanıcı deneyimleri sağlar. Bu özellikler kullanıcı deneyimini daraltır ancak uygulama kontrolünden farklı bir problemi çözer. Bir kabuk giriş noktalarını gizleyebilirken, bir uygulama-kontrol politikası hangi ikili dosyaların (binaries), betiklerin, kurulum programlarının, kütüphanelerin, sürücülerin ve yorumlayıcıların çalıştırılabileceğini belirler.
Bir ATM her ikisine de ihtiyaç duyar. Ayrıca en az yetkili servis kimlikleri, korunabilir yazılabilir yollar, kısıtlanmış yönetim arayüzleri, kontrol edilen güncelleme kanalı ve uç nokta ihlalinden sonra bile ayakta kalan telemetriye de ihtiyaç duyar. Aksi takdirde bir kiosk, kullanıcı hiç görmediği bir yolu güvenerek mükemmel bir şekilde kilidini koruyabilir gibi görünebilir.
Sıfır aşama: Her işletim sistemi durumunu modelleyin
Terminalin meşru olarak girebileceği durumlarla başlayın: normal müşteri oturumu, başlatma, uygulama yeniden başlatma, bozulmuş bağlantı, nakit veya kağıt servisi, yetkili bakım, uzaktan destek, yazılım dağıtımı, işletim sistemi kurtarma ve hizmete geri dönüş.
Her durum için etkileşimli hesap, kabuk, izin verilen süreçler, etkili uygulama-kontrol politikası, servis kimlikleri, yazılabilir konumlar, ağ politikası, telemetri hedefi ve çıkış koşulunu belirleyin. Tehlikeli boşluk genellikle üretim kiosk profili değildir. Geçici olarak genel amaçlı bir kabuğu, daha geniş ağ erişimini veya yüksek yetkili bir hesabı geri yükleyen tanı veya kurtarma durumudur ve bu kısıtlamanın yeniden tesis edildiğinin kanıtlanmadığıdır.
Test etmeden önce durma koşullarını tanımlayın. Sentetik veri, hareketsiz dosyalar, onaylanmış hesaplar ve bir laboratuvar cihazı kullanın. Kimlik bilgilerini toplamayın, uç nokta koruma yığınını devre dışı bırakmayın veya yerel çalıştırmayı kanıtlamak için gerçek bir cihaz işlemini kullanmayın. Bulgu, haklısız yetki geçişidir.
Birinci aşama: Etkileşim maruziyetini çalıştırmadan ayırın
Her halka açık giriş yolunu kataloglayın: dokunma, fonksiyon tuşları, erişilebilirlik özellikleri, okuyucu olayları, yazıcı istemleri, harici bağlantılar, yardım akışları, dosya diyarları, hata yöneticileri ve uygulama yeniden başlatma davranışı. Ayrıca görseller, faturalar, dil paketleri, yapılandırma ve uzaktan sağlanan mesajlar gibi dolaylı içeriği gözden geçirin.
Maruz kalan bir işletim sistemi yüzeyi henüz kritik bir bulgu olan bir hipotezdir. Sadece organizasyonun kontrolündeki bir çökeltiye veya hareketsiz bir araca geçiş denemesi yapın. Hangi sürecin girişi işlediğini, hangi kimliği kullandığını, hangi politika kararının gerçekleştiğini ve olayın merkezi izleme sistemine ulaşıp ulaşmadığını kaydedin. Yetki kararı bilindiğinde durun.
Bu, raporun “masaüstü görünür” ile “sistem ihlal edildi” kavramlarını karışmasını engeller. Görünür bir diyar, kontrolsüz bir yorumlayıcıyı çağırabilir veya güvenilir bir çalıştırma yoluna yazıyorsa ciddi olabilir. Kod politikası, dosya izinleri, ağ politikası ve servis sınırları yetkili kaldığı sürece etkisi düşük olabilir. Kanıt karar verir.
İkinci aşama: Uygulama kontrolünü yetkili hale getirin
Uygulama kontrolü, terminali “her şey kötü olarak algılanmadıkça çalışır” durumundan “sadece politika tarafından seçilen kod çalışır” durumuna dönüştürmelidir. Sabit yüklu bir ATM’de güven kümesi dar olabilir ancak değerlendirme sadece çalıştırılabilir dosyaları içermemelidir.
Uygulamaları, kütüphaneleri, sürücüleri, betikleri, kurulum programlarını, yorumlayıcıları, eklentileri, COM bileşenlerini, zamanlanmış görevleri ve servis ikili dosyalarını envanterine alın. Her birinin nasıl tanımlandığını haritalayın: yayıncı, sertifika, katalog, hash, yönetilen kurulum programı, yol veya başka bir kural. Geniş bir yayıncı kuralı, temel seviyenin öngördüğünden çok daha fazla kodu güvenebilir. Bir yol kuralı, daha düşük yetkili bir kimliğin o yola yazabildiğinde güvensiz hale gelebilir.
Farklı durumları temsil eden hareketsiz test araçları kümesi kullanın: bilinmeyen ikili dosya, bilinmeyen betik, yeniden adlandırılmış dosya, onaylanmış ürünün dışında izin verilen yayıncı ve onaylanan kodun onaylanmayan yazılabilir bir konuma yerleştirilmesi. Beklenen çıktı bir karar matrisidir, çalıştırma değil. Uygulama kontrolünün sadece denetim modu olmadığını doğrulayın ve reddetmenin her birini politika versiyonu, dosya kimliği, çağrı yapan, terminal ve güvenilir zamanla korelasyonlayın.
Güncellemeden sonra, bakım sırasında ve kurtarmadan sonra aynı kümeyi test edin. Yerinde kalan ek bir politika veya acil durum istisnası güven kümesini sessizce genişletebilir. Her istisnanın sahibi, nedeni, hedef grubu, başlangıcı, süresi ve regresyon testi olmalıdır.
Üçüncü aşama: Süreç adlarına değil kimliğe uyun
Bir kiosk uygulaması genellikle donanıma veya işletim sistemi fonksiyonlarına erişmek için yetkili servislerden yararlanır. Bu, broker dar bir sözleşmeyi zorladığı sürece sağlam bir tasarımıdır. Süreç adları ve yerel bağlantılar yetkilendirme değildir.
Kiosk hesabının, uygulama sürecinin, broker’ın, servisin, güncelleştiricinin, izleme aracının ve uzaktan destek bileşeninin kimliğini ve yetkilerini kaydedin. Her birinin okuyabileceği, yazabileceği, başlatabileceği, yapılandırabileceği veya taklit edebileceği kaynakları belirleyin. Servis çalıştırılabilir ve yapılandırma izinlerini, isimli nesne izinlerini, yerel IPC yetkilendirmesini, token sınırlarını ve kurtarma kimliklerini gözden geçirin.
Laboratuvarda zararsız bağlam dışı istekler veya test ikizleri kullanın. Halka açık oturum süreci sadece yerel bir brokera erişebildiği için hassas bir yeteneği miras almamalıdır. Bir servis, herhangi bir yerel çağrıcinin onaylanan uygulamaya ait olduğunu varsaymak yerine, çağrıci kimliğini ve politika durumunu doğrulamalıdır. Dördüncü bölüm bu cihaz sınırını derinlemesine takip eder; burada amaç, bir UI katmanı hatasının otomatik olarak SYSTEM seviyesi yetkiye dönüşemeyeceğini kanıtlamaktır.
Dördüncü aşama: Yazılabilir yolları, gizli verileri ve kalıcılığı test edin
Her kimlik için bir yazma haritası oluşturun. Uygulama dizinlerini, veri klasörlerini, geçici konumları, günlükleri, güncelleme hazırlama alanlarını, servis yapılandırmasını, başlatma konumlarını, politika dosyalarını ve yetkili bir bileşen tarafından tüketilen herhangi bir yolu dahil edin.
Kritik koşul, düşük yetkili bir hesabın bir yere yazabilmesidir değil; daha güvenilir bir bileşenin daha sonra o içeriği yorumlayıp, yükleyip, çalıştırıp veya doğrulaması olmadan ayrı bir bütünlük kararı vermemesidir. Hareketsiz işaretler ve dosya hashleri ile test edin. Üretim ikili dosyalarını değiştirmeyin veya çalıştırılabilir içerik eklemeyin.
Gizli verileri başka bir yetki yolu olarak ele alın. Servis kimlik bilgilerinin, API malzemesinin, sertifikaların, kurtarma verilerinin ve yapılandırma gizli verilerinin nereden geldiğini, hangi kimliğin bunları alabileceğini, makineye bağlı olup olmadığını, nasıl döndüğünü ve kullanımın kaydedilip kaydedilmediğini belirleyin. Kanıt erişim kararlarını ve meta verilerini, asla gizli veriyi kaydetmelidir.
Kalıcılık testi de benzer şekilde politika düzeyinde durmalıdır. Onaylanmayan bir kimliğin başlatma koşulunu oluşturabilip oluşturamayacağını gösterin, ardından hareketsiz işareti kaldırın ve uzlaştırmayı doğrulayın. Başlatma politikasının yazılabilir bir nesneye güvendiğini kanıtlamak için bir arka kapı kurmaya gerek yoktur.
Beşinci aşama: Güncelleme ve istisna yönetimini doğrulayın
Güncelleme sistemi uygulama-kontrol sınırını kasıtlı olarak geçerek ilerler. Bu, güvenlik mimarisinin bir parçasıdır: paket oluşturma, imzalama, onaylama, hedefleme, hazırlama, kurulum, geri alma, politika yenileme ve nihai envanterin tümü sorumlu sahiplere ihtiyaç duyar.
İmzalanmamış, yanlış hedeflenmiş, süresi dolmuş veya politikaya uygun olmayan bir güncellemeyi reddetmek için tedarikçi test paketlerini veya meta verileri kullanın. Güncelleştiricinin yerel olarak yazılabilir herhangi bir dosyayı güvenilir koda dönüştüremeyeceğini doğrulayın. Onaylanmış bir paketin uygulama-kontrol politikasını değiştirme kaydının ötesinde sessizce genişletemeyeceğini doğrulayın.
Kurulumdan sonra, yerel versiyon, kod-politikası durumu, dağıtım kaydı, uç nokta telemetrisi ve varlık envanteri arasında anlaşmayı gerektirin. “İş başarılı” bir dağıtım sonucudur, ATM’nin güvenilir bir duruma döndüğünün kanıtı değildir.
Altıncı aşama: Tespiti ve kurtarmayı kanıtlayın
Her negatif kontrol, terminal kimliği, kullanıcı veya servis kimliği, dosya veya nesne kimliği, politika versiyonu, karar, işletim sistemi durumu ve güvenilir zamanı içeren off-host bir olay üretmelidir. Yerel uç nokta kendi güven kaybı hakkında delillerin tek sakini olamaz.
Sonra kapsüllemeyi tekrar edin. Operatör terminalin servis ve işlem yollarını kanıt izini kaybetmeden izole edebilir mi? Bir politika yanlış pozitif ile gerçek bir bütünlük başarısızlığını ayırt edebilirler mi? Bilinen iyi bir görüntüyü geri yükleyebilir, doğru kiosk ve uygulama-kontrol politikalarını yeniden uygulayabilir, maruz kalan yetkiyi dönderebilir ve başka bir müşteri oturumunu işlemek önce cihazı uzlaştırabilirler mi?
Kurtarma kapısı makine tarafından doğrulanabilir olmalıdır. Terminal sadece boot güveni, uygulama politikası, versiyonlar, kimlikler, izleme, ağ politikası ve operasyonel durumun anlaşması durumunda döner.
Delil matrisi
| Sinyal | Ne kanıtlar | Güvenli negatif kontrol | Savunucu doğrulama |
|---|---|---|---|
| Halka açık bir etkileşim beklenmedik bir OS yüzeyini açar | Kabuk bir giriş noktasını açar; etki henüz bilinmiyor | Sadece hareketsiz yerel bir araca veya kontrol edilen çökeltiye gezinin | İşleyici süreci, kimlik, kod-politikası sonucu, ağ sonucu ve uyarıyı korelasyonlayın |
| Bilinmeyen ikili dosya engellenir ancak betik, kütüphane, kurulum programı veya yorumlayıcı yolları yönetilmez | Uygulama kontrolü sadece çalıştırma modelinin bir kısmını kapsar | Her kod sınıfı için yük davranışı olmadan hareketsiz araçları sunun | Zorunlu politikayı, politika versiyonunu, çağrıyı, hash veya imzacıyı ve off-host reddetmeyi doğrulayın |
| Düşük yetkili bir kimlik içeriği daha sonra yetkili bir servis tarafından tüketilir | Dosya bütünlüğü yetki yükseltme yolu haline gelir | Çalıştırılamaz bir işareti yerleştirin ve yetkili tüketim kararını gözlemleyin | ACL’leri düzeltin, içerik bütünlüğünü doğrulayın ve sınırı regresyon-test edin |
| Bakım veya kurtarma süresi dolmadan daha geniş bir kod politikası kullanır | Geçici bir işletim sistemi durumu kalıcı bir istisya oluşturur | Normal ve servis durumları arasında aynı hareketsiz test kümesini karşılaştırın | Kapsamlı istisya, onaylama, süresi, politika geri alma ve uzlaştırmayı gerektirin |
| Güncelleme işi başarılı olurken yerel politika, versiyon ve envanter anlaşmazdır | Dağıtım başarısı güven olarak kabul edilir | Onaylanmış bir laboratuvar paketini uygulayın ve tüm gerçeklik kaynaklarını karşılaştırın | Kod politikası, versiyon, telemetri ve envanter anlaşmasına dayalı hizmete dönüşü kapataın |
| Çalıştırma reddi sadece yerel günlüklerde kalır | Uç nokta ihlali tespit delillerini silebilir | Laboratuvar terminalinde onaylanmış bir reddetmeyi tetikleyin | Aktör, terminal, politika, nesne, sonuç ve zamanı içeren off-host teslimatını gerektirin |
Bir bulgunun nasıl görüneceği
Laboratuvar kiosk hesabı, başlatmada yetkili bakım servisi tarafından tüketilen bir dizine hareketsiz bir işareti yazabilirdi. Uygulama kontrolü halka açık oturumda bilinmeyen bir çalıştırılabilir dosyayı reddetti ancak servisin veri-tüketim yolu bütünlük-kontrol edilmedi ve merkezi olay daha düşük yetkili yazarı belirlemedi. Yük, kimlik bilgisi, cihaz komutu, ödeme verisi veya kalıcılık mekanizması kullanılmadı. Sınır üretici kimliği ve içerik bütünlüğünden ziyade yol konumuna dayanmaktadır. Yazma erişimini kısıtlayın, tüketilen nesneyi doğrulayın, üreticiyi ve kararı off-host kaydedin ve normal, bakım ve kurtarma durumlarında aynı geçişi regresyon-test edin.
O bulgu yetki geçişini ve eksik değişmezliği adlandırır. “Kiosk kaçışı başarıldı” ne yapmaz.
Ne kanıt olarak isimlendirmem
- Gizli bir masaüstü veya devre dışı tuş kombinasyonu uygulama kontrolü olarak sunulması.
- Zorunlu reddetme olarak sunulan denetim-modu olayları.
- Betikler, kütüphaneler, sürücüler ve yorumlayıcılar için kapsama olmadan engellenmiş bir çalıştırılabilir dosya.
- Servisin tedarikçi tarafından sağlandığı çünkü güvenli olduğu olarak tanımlanan yetkili bir servis hesabı.
- Off-host test olayı ve yanıt yolu olmadan sağlıklı gösterilen bir EDR aracı.
- Son durum uzlaştırması olmadan başarılı bir güncelleme.
- Bulgunun ciddi görünmesini sağlamak için yerel gizli veriler veya müşteri verilerinin ekran görüntüsü.
Savunucu öncelik sırası
İlk olarak, kod politikasını yetkili hale getirin. Her çalıştırılabilir kod sınıfını ve her işletim sistemi durumunu kapsayın, ardından politikayı yerel zayıflamadan koruyun.
İkinci olarak, broker yetkisini azaltın. Kiosk ve servis kimliklerine sözleşmelerini gerektiren kaynakları ve cihaz işlemlerini verin; her yerel sınırda çağrıciyi doğrulayın.
Üçüncü olarak, yazılabilir-güvenilir geçişleri kaldırın. Yetkili bileşenler bütünlük ve üretici kontrolleri olmadan daha düşük güven içeriğini tüketmemelidir.
Dördüncü olarak, güncellemeleri ve istisnaları güvenlik değişiklikleri olarak yönetin. Bunları kapsayın, onaylayın, süresi dolmasını sağlayın ve ardından terminali uzlaştırın.
Beşinci olarak, önlem kadar sık kurtarmayı test edin. Bilinen iyi bir görüntü ve politika tabanı, organizasyonun denetim izini kaybetmeden geri yükleyip doğrulayabildiği sürece faydalıdır.
Kapanış düşüncesi
ATM masaüstünün gizlendiği için cihaz haline gelmez. Her kod yolu, kimlik, yazılabilir nesne, güncelleme ve kurtarma durumunun açık bir politika tarafından sınırlandığında ve bağımsız delil ürettiğinde cihaz benzeri hale gelir.
Güçlü bir değerlendirme bir kiosk kaçışını kabul edebilir ancak orada durmaz. Karar verici sonuç bir sonraki kontrolün ne yaptırmasıdır.
Kamu kaynakları ve standartlar bağlamı
- Microsoft — Windows kiosk yapılandırma
- Microsoft — Windows için Uygulama Kontrolü
- Microsoft — Uygulama Kontrolü politikası ve dosya kuralları
- NIST SP 800-115 — Bilgi Güvenliği Testi ve Değerlendirmesi Teknik Rehberi
- PCI Güvenlik Standartları Konseyi — ATM Güvenlik Kılavuzları
Tam kiosk ve uygulama-kontrol teknolojileri ATM nesli ve işletim sistemine göre değişir. Uygulanan kontrolü ve tedarikçi destekli yaşam döngüsünü test edin; genel bir masaüstü yapısından üretim davranışını çıkarım yapmayın.
Bu teknik not ne kadar güncel?
En son kaynak incelemesi, içerik güncellemesi veya yayın tarihi gösterilmektedir.
Birincil kamu kayıtları kontrol edildi. Ortama özgü davranış, ayrıca yeniden üretilmedikçe iddianın dışındadır.