İlk SSH bağlantısında, herhangi bir VPS veya bulut sağlayıcısında MITM saldırısını engellemek

 (joachimschipper.nl)
1 puan yazan GN⁺ 4 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • ssh-init-vm, yeni bir VM’ye ilk SSH bağlantısında ortadaki adam saldırısını engellemek için cloud-init ile geçici bir SSH ana makine özel anahtarı enjekte eder ve uzun ömürlü ana makine anahtarı oluşturulup alınana kadar yalnızca buna güvenilmesini sağlar
  • Hetzner Cloud gibi özel bağlantı koruma özelliği olmayan VPS veya bulutlarda da çalışır; gereken tek şey yaygın biçimde desteklenen cloud-inittir
  • Yaygın Trust On First Use yaklaşımında ssh içindeki “The authenticity of host [...] can't be established” sorusuna yes yazılırsa, bir saldırgan trafiği proxy'leyebilir veya kullanıcıya kendi VM’siymiş gibi görünen bir makine sunabilir
  • Uzun ömürlü SSH ana makine özel anahtarını doğrudan cloud-init userdata içine koymak, ilk bağlantının doğrulanmasına yardımcı olur; ancak hassas anahtar materyali metadata servisi, SSRF, bulut sağlayıcısının sistemleri veya yönetici iş istasyonu üzerinden açığa çıkabilir
  • ssh-init-vm, geçici anahtarı geçici bir dizinde tutar ve ~/.ssh/known_hosts içine koymaz; ayrıca VM çıktısını olduğu gibi kaydetmez, uzun ömürlü anahtarı yazmak için OpenSSH’nin host key rotation mekanizmasına dayanır

cloud-init userdata ifşası sorunu

  • cloud-init ile uzun ömürlü SSH ana makine özel anahtarı enjekte edilirse, açık anahtar ~/.ssh/known_hosts içine konarak ilk bağlantı doğrulanabilir; ancak özel anahtar birden fazla yoldan sızabilir
  • VM içindeki rastgele bir süreç, genellikle okunabilir olan metadata servisi üzerinden userdata’yı alabilir; Hetzner VM’lerinde http://169.254.169.254/hetzner/v1/userdata adresinde cloud-init içeriği görülebilir
  • Saldırgan, SSRF yoluyla bir sürecin metadata’yı sızdırmasını sağlayabilir; bu tür engellemeler, özel koruma özelliği olan ortamlarda bile her zaman uygulanmış olmaz
  • cloud-init userdata, bulut sağlayıcısının diğer sistemlerinde de açığa çıkabilir; Hetzner, sunucu oluşturma API belgelerinde “passwords or other sensitive information” saklamamayı açıkça belirtir
  • Yönetici iş istasyonu da cloud-init userdata’nın kaldığı veya içinden geçtiği bir yer olabilir; bu nedenle uzun ömürlü özel anahtar koyma yaklaşımı, anahtar geçerli olduğu sürece ifşa riski yaratır

Güvenlik analizi ve tehdit modeli

  • Varsayım, OpenSSH protokolüne ve uygulamasına güvenildiği ve yöneticinin saldırıyı tespit etme becerisine dayanılmadığıdır

  • Ağ saldırganına karşı koruma

    • Korunan varlıklar, yönetici iş istasyonunun bütünlüğü ve VM’dir
    • Saldırgan, ağı tamamen kontrol eden bir ortadaki adamdır ve script başarıyla ya da başarısızlıkla sonlandıktan sonra herhangi bir anda cloud-init userdata’yı öğrenebilir
    • Koruma, saldırgan anahtar materyalini hâlâ değerliyken öğrenemediği için geçerlidir
    • Script, geçici SSH ana makine anahtarının yanlışlıkla kullanılmasını önlemek için onu geçici bir dizinde tutar ve geçici SSH ana makine anahtarını ~/.ssh/known_hosts içine koymaz

  • Yönetici iş istasyonu ele geçirilmişse

    • Koruma, VM ve VM’nin uzun ömürlü SSH ana makine özel anahtarıyla sınırlıdır
    • Saldırganın ağı ve yönetici iş istasyonunu tamamen kontrol ettiği, ancak gerçek VM’ye erişmediği varsayılır
    • Uzun ömürlü SSH ana makine özel anahtarı hiçbir zaman yönetici iş istasyonunda bulunmamıştır; saldırgan da gerçek VM’ye erişmediği için VM’nin uzun ömürlü ana makine anahtarını elde edemez
    • Saldırgan gerçek VM’ye erişirse, ssh root@<VM> cat /etc/ssh/ssh_host_* gibi bir yöntemle SSH ana makine anahtarlarını öğrenebilmesi büyük olasılıktır

  • VM veya sağlayıcı ele geçirilmişse

    • Koruma yalnızca yönetici iş istasyonunun bütünlüğüyle sınırlıdır
    • Saldırgan ağı tamamen kontrol eder ve ayrıca VM’yi veya sağlayıcıyı da tamamen kontrol edebilir
    • Bu durumda da OpenSSH’nin güvenli olduğu varsayımı sayesinde yönetici iş istasyonunun bütünlüğü korunur
    • Ek savunma olarak script, VM çıktısını doğrudan ~/.ssh/known_hosts içine yazmaz; bunun yerine OpenSSH anahtar rotasyonuna dayanarak uzun ömürlü SSH ana makine anahtarını ekler
    • Bu yaklaşım, ele geçirilmiş bir hostun known_hosts ayrıştırıcısına kötü amaçlı veri yedirmesini engeller ve yalnızca VM’nin gerçekten kontrol ettiği anahtarların ~/.ssh/known_hosts içine yazılmasını sağlar
    • HashKnownHosts gibi OpenSSH seçenekleri ve gelecekteki ilgili seçenekler de doğru şekilde işlenebilir

Gerçek bir ortadaki adam saldırısının başarılı olması için gereken koşullar

  • Ortadaki adam saldırısının başarılı olup olmayacağı; kullanıcının tüm bağlantıların en baştan yanlış makineye gittiğini gerçekten fark edip etmemesine, parola girmeyi reddedip etmemesine ve ssh agent ya da X11 forwarding ayarlayıp ayarlamamasına bağlıdır
  • ssh-mitm temel alınarak basitleştirilmiş koşullarda, saldırgan gerçek hedef host yerine saldırganın kontrol ettiği bir makineye erişim verip kullanıcıyı kandırabiliyorsa başarı olasılığı yüksektir
  • Saldırgan, kullanıcıyı kandırarak gerçek hosta giriş yapmaya yarayan bilgileri elde ederse de başarılı olur
    • Kullanıcı saldırganın makinesine parola ile giriş yaparsa saldırgan başarılı olabilir
    • Kullanıcı herhangi bir kimlik doğrulama yöntemiyle giriş yaptıktan sonra istemde parola girerse saldırgan başarılı olabilir
    • Kullanıcı herhangi bir kimlik doğrulama yöntemiyle giriş yapıp ssh-agent bağlantısını iletirse saldırgan başarılı olabilir
  • Bu koşullar yoksa saldırganın kullanıcıyı kandırmak için gerçek host erişimine ihtiyacı vardır; ancak kullanıcının girdileri tek başına gerçek hosta giriş yapmaya yetmeyeceğinden saldırının başarısız olma ihtimali yüksektir
  • Kullanıcı X11 bağlantısını iletirse, saldırgan kimlik doğrulama yönteminden bağımsız olarak yönetici iş istasyonuna saldırmada da başarılı olabilir

İlgili okumalar

1 yorum

 
GN⁺ 4 시간 전
Lobste.rs yorumları

  • Otomatikleştirilebildiği için harika. Elle yapılan yöntemde, sunucunun SSH parmak izini bulut sağlayıcısının konsolundan ayrı bir kanal üzerinden doğruluyordum
    Yönettiğim bulut instance sayısı çok olmadığı için, provizyonlamada birkaç manuel adım olmasının sakıncası yok

    • O yöntem de işe yarıyor. Sadece kullandığım sağlayıcı o kısmı bağlamamıştı ve ben de aynı anda yapılandırma otomasyon betikleri yazıyordum

  • DNS bölgesini otomatikleştirdiyseniz başka bir yaklaşım da mümkün: kapsamı çok dar olan tek kullanımlık bir token oluşturup, örneğin yalnızca my-server-hostname.example.net için tek bir kayıt oluşturmaya izin vermek
    Bu token'ı cloud-init ile sunucuya verip, sunucunun açık SSH anahtarını DNS'teki SSHFP kaydı olarak yayımlamasını sağlayabilirsiniz. Ardından SSH istemcisi SSHFP kaydını otomatik doğrulayabilir; bunun için DNS bölgesinin DNSSEC ile imzalanmış olması gerekir
    Bu akış, sunucunun özel SSH host anahtarını elinde tutmasını sağlarken anahtar rotasyonunu da önler. Çoğu DNS sağlayıcısı bu kadar ayrıntılı tek kullanımlık erişim token'larını desteklemez, ancak token'ı doğruladıktan sonra kalıcı ve kapsamı sınırlandırılmamış token'la onun yerine API çağrısı yapan basit bir iç web servisi kurulabilir. SSH sunucusu bu kalıcı token'a erişemez

    • Yaratıcı bir yaklaşım ve özel servis için tek kullanımlık token ile oldukça esnek olduğu için iyi çalışacak gibi görünüyor
      Yine de DNSSEC alanına yazmaktansa SSH sertifikaları üretmeyi tercih ederdim; o noktadan sonra da mesele hangi çözümün hangi ortama daha uygun olduğu haline geliyor
      Bu kadar esnek token'lar üretebilen bir yazılım ya da sağlayıcı biliyor musunuz, yoksa bunun bir kısmını kendiniz mi geliştirmeniz gerekir merak ediyorum

  • Oldukça temiz görünüyor. Ancak yazının tarihindeki ay ve gün yer değiştirmiş gibi

    • OpenSSH ile uğraşmak her zaman keyifli ve ay/gün gösterimini düzelttim

  • Geçmişte aynı SSH tavuk-yumurta problemini incelemek için deneysel bir servis yapmıştım
    İstek üzerine SSHFP DNS kaydı oluşturuyor; ilgilenirseniz https://github.com/tedb/sshfp adresine bakabilirsiniz

  • VM sağlayıcıları arasında az çok tutarlı olan 169.254.169.254 metadata servisini ele almanız hoşuma gitti. cloud-init kaynağındaki çeşitli cloudinit/source/DataSource*.py girdilerine bakınca bunu görebilirsiniz
    Ben şahsen cloud-init'in tasarımı ve sınırları yüzünden ona karşı giderek daha fazla bıkkınlık hissediyorum. Yerel QEMU sanal makineleri, uzak makineler, container'lar ve fiziksel donanım genelinde sistem yapılandırmasını birleştirmekle ilgileniyorum
    arch-boxes project, ArchLinux cloud-init image'ının nasıl üretildiğini gösteriyor ve son derece basit bir shell script koleksiyonu. Bu yöntemi guestfish veya µvm ile uygularsanız, OCI uyumlu image'lar, QEMU veya bulut sağlayıcıları için disk image'ları ve yeni fiziksel makine provizyonlaması için tam olarak aynı script'leri kullanabilirsiniz
    Birkaç QEMU bayrağıyla birlikte, cloud-init bağımlılığı olmadan aynı yaklaşımı yeniden üretebilirsiniz. Bildiğim kadarıyla systemd.system-credentials ile geçici host anahtarları aktarılamıyor; yalnızca ssh.authorized_keys.root gibi ~/.ssh/authorized_keys için kimlik bilgileri var
    Bunun yerine initrd aşamasında ya da systemd-firstboot.service ile birlikte çalışan bir unit dosyası yazabilirsiniz. Bu unit dosyası image içine önceden konabilir veya systemd.extra-unit.* kimlik bilgileriyle geçici olarak enjekte edilip systemd.wants=… kernel komut satırı seçeneğiyle etkinleştirilebilir. QEMU'da metadata servisinin varlığını -netdev user,id=metadata,net=169.254.0.0/16,dhcpstart=169.254.0.15,guestfwd=tcp:169.254.169.254:80-cmd:… girdisiyle taklit edebilirsiniz. Ancak oluşturulan arayüzü etkinleştirmeniz gerekebilir; bunu da yine geçici bir unit dosyasıyla yapmak daha iyi olabilir
    Bu şekilde, farklı türde “makinelerde” tutarlı sistem yapılandırması yaparken, görece düşük karmaşıklıkla oldukça fazla esneklik elde edersiniz. Aslında yalnızca bu iş açısından bakarsak, image oluşturma aracının sabit host anahtarları içeren makine image'ları üretmesi ve ilk yeniden başlatma ya da kapanışta çalışan özel bir host anahtarı rotasyon betiğini bir SystemD servisi olarak kurması en iyi yaklaşım gibi görünüyor

    • ArchLinux'ta /etc/mkinitcpio.conf içinde systemd HOOKunu etkinleştirirseniz, initrd'de yapılacak işler için SystemD unit dosyaları yazabilirsiniz; hatta fiilen yazmanız gerekir
      Gerçekte kullanınca, {/etc,/usr/lib}/initcpio/hooks yazmaktan sadece çok az daha zahmetli oluyor
      Ama initrd içinde systemd-networking ve systemd-resolved'ı açmak oldukça kolay olduğu için, initrd sistem başlatma sorumluluğunu alabilir ve kök dosya sistemine geçmeden önce işleri planlayabilir
      Elbette dizüstü gibi fiziksel donanımlarda Wi-Fi bağlantısı için NetworkManager benzeri bir şeye ihtiyaç duyulacağından çok uygun olmayabilir; ama QEMU VM'ler ve barındırılan VM'ler için gayet uygun ve sistem başlangıç görevlerinin çoğu doğal olarak bu alana uyuyor
      Amaç, cloud-init'e bağımlı olmadan, tek bir bulut sağlayıcısına kilitlenmeden, fiziksel makineler, container'lar, yerel VM'ler ve barındırılan VM'ler arasında tutarlılık sağlamak ve bağımlılıkları fiilen SystemD seviyesine kadar azaltmak
    • İstediğiniz işlevleri gerektiği kadar genişletebileceğiniz çok küçük bir araç olarak https://github.com/the-maldridge/shinit/ gibi bir şey de işe yarayabilir