IPv6 ve Extension Headers Güvenliği

IPv6 Protokolü

 

1998 yılında yayınlanan ilk RFC’sinin (https://www.rfc-editor.org/rfc/rfc2460)  üzerinden uzun bir süre geçmesine rağmen IPv6 geçişleri halen istenilen düzeyde değil. Ancak IANA’nın havuzdaki son IPv4 adres bloğunu 2011’de kullanılabilir duruma getirmesi sonrası tüm dünyada IPv6’ya geçiş çalışmalarının hızlandığını görüyoruz. 32 bit uzunluğundaki bir IPv4 adresi, 4 milyar civarında farklı değer alsa da public adresler aslında çoktan tükenmiş durumda. IPv4 ise operatörlerin aynı public adresi birden çok müşterisine paylaştırdığı CGNAT vb. yapılar sayesinde ömrünün son demlerini yaşamaya devam ediyor. 

 

Günümüzde neredeyse tüm işletim sistemleri ve çoğu cihaz IPv6’ya hazır durumda. Hatta operatörünüz henüz IPv6’ya geçmediyse bile emin olun evdeki yerel ağınızda cihazlarınız hali hazırda en azından kendi aralarında IPv6 konuşmaya başlamış durumdalar😊 Wireshark benzeri bir araçla IPv6 filtresini kullanarak sizler de bunu teyit edebilirsiniz.

 

Şekil 1: Yerel Ağ'da IPv6 konuşan cihazlar.

 

128 bitlik uzunluğu ile 39 basamaklı bir sayıya denk gelen devasa adres uzayı IPv6 için son derece yeterli gözüküyor. Ancak IPv6 protokolündeki tek fark bu sayısal değişiklik değil. Header yapısına baktığımızda (Şekil 2) IPv4’e göre son derece sade bir yapı dikkatimizi çekiyor. IPv4’te 20-60 bayt arasında değişebilen header uzunluğu artık sabit şekilde 40 bayt olarak tanımlanmış. Bu da paketleri işleyen yönlendirici cihazlar için performans kazanımı demek. 

 

Şekil 2: IPv6 Header

 

Header bilgilerine baktığımızda bütünlük kontrolünü sağlayan Header Checksum değerini görmüyoruz. Bu değerler TCP gibi üst katmanlarda hali hazırda hesaplandığından yine performans temelli sebeplerle Ipv6 başlığında artık yer almıyor. Yine IPv4’te yer alan Fragment Offset, Options, Padding, Identification vb. header bilgileri de artık yer almıyor. Bunların birçoğu yazımızda uzun uzadıya değineceğimiz Extension Headers alanına taşınmış durumda. 

 

IPv6 protokolündeki önemli bir diğer değişiklik ise artık cihazlarımızın IPv6 adresi alabilmeleri için DHCP benzeri bir yapıya ihtiyaç duymaması. En çok kullanılan SLAAC (Stateless Address Auto-configuration) yöntemi ile, modem servis sağlayıcıdan aldığı ve genelde uzunluğu 64 bit olan prefix adresini yerel ağımıza anons ediyor ve cihazlarımız da kalan 64 bitlik adresi farklı yöntemlerle oluşturarak kendi adreslerini atamış oluyorlar.  Bu şekilde ayrı bir DHCP sunucuya ve NAT yapısına ihtiyaç duymadan tek IP ile cihazımız dünya üzerindeki diğer cihazlarla bağlantı kurabiliyor. NAT yapısının olmaması da uçtan uca şifreleme sağlayan IPSEC gibi güvenlik algoritmalarını daha kullanışlı hale getiriyor. 

 

Extension Header Yapısı

 

IPv4 header’ında yer alan çoğu alanın artık IPv6’da ana başlık bilgisinden ayrı olarak Extension Headers alanları ile taşındığından bahsetmiştik. OPTIONS veri alanı aksi belirtilmedikçe her yönlendirici tarafından işlenmek zorundaydı. Bu alanın kaldırılması ile yine performans artırımı hedeflenmiş.  Ancak sadelik ve performans odaklı bu tasarım maalesef farklı bazı karışıklıklara ve nihayetinde başka güvenlik açıklarına yol açıyor.

 

IPv6 protokolündeki önemli extension header’lar Tablo 1’de gözükmekte. Standartlar paket içerisinde yer alan ext. Header’ların sırasını da bu şekilde öneriyor. 

 

Tablo 1: IPv6 Extension Header Bilgileri

 

 

Şekil 3’te görülebileceği gibi birden çok Extension Header’ın aynı pakette olması, hatta aynı paket içerisinde aynı header’dan birden fazla kullanılması bile mümkün. Bir sonraki header bilgisi Next Header alanında yazılarak sonraki headerın nasıl okunması gerektiğini söylüyor. 

 

Şekil 3: Extension Headers Yerleşimi

 

 

Maalesef IPv6 header’ındaki basitlik ve sadeliği Extension Header’larda göremiyoruz. Hatta Extension Header tanımları RFC dokümanının neredeyse yarısını oluşturuyor! Karmaşık yapıları ve biraraya geldiklerinde farklı güvenlik açıklıklarına sebep olma ihtimalleri nedeniyle bu yapılılar üzerinde uzunca duracağız. Ama öncelikle bir sonraki başlıkta genel bir güvenlik değerlendirmesi yapalım.

 

IPv6 Güvenliği

 

IPv6 Adreslerini Taramak

 

IPv6’ının IPv4’ten alınan dersler ışığında bazı farklılıkları olduğunu görüyoruz. Ancak bazı farklılıkların bambaşka güvenlik problemlerine yol açması da maalesef ayrı bir ironi. Önemli gördüğümüz güvenlik zafiyetlerini bu başlık altında listelemek istedik.

 

Adres uzayımızın artık devasa bir büyüklükte olduğunu biliyoruz.  Saldırganın, sızmaya çalıştığı ağdaki ilk hareketi muhtemelen keşif amaçlı cihaz-port listesini çıkarmak olacaktır. Ipv4 için bu oldukça kolay, örneğin evlerimizdeki modemlerin çoğunun kullandığı 192.168.1.0/24 ağındaki maksimum 254 cihazı basit bir nmap komutu ile saniyeler içerisinde çıkarabiliriz. IPv6’da tabiki bu durum değişiyor ve trilyonlarca olası IPv6 adresi ile karşı karşıya kalıyoruz. Tüm olası adreslere ping atarak veya açık portları tarayarak canlı cihazları çıkartmaya çalışmak ilk bakışta mümkün gözükmüyor. Zmap, Masscan gibi araçlarla neredeyse tüm interneti dakikalar içinde taramak mümkünken, IPv6’da sadece 64 bitlik bir prefix’e ait bir bloğu taramak yıllar sürecektir. Bu durum belki de yanlış bir şekilde IPv6 adresi alan bir cihazın saldırganlar tarafından asla bulunamayacağını akla getiriyor olabilir. Ancak durum gerçekte öyle mi hep beraber inceleyelim. 

 

IPv6 adresi atanan herhangi bir cihaz diğer komşu cihazlardan kendisine gelebilecek istekler için bir multicast grubuna katılır (solicited-node multicast). Kendisine gelen tüm NS (neighbor solicitation) mesajlarına NA (neighbor advertisement) mesajları ile cevap vermek zorundadır.  Yani aşağıdaki ekran görüntüsündeki gibi tüm cihazları barındıran multicast adresi olarak tanımlı ff01::1’e kendi kaynak IP’mizden ping attığımızda ağdaki tüm cihazların cevap vermesini bekleriz, bu da IPv6 adreslerini bulmak için en kısa yol diyebiliriz. 

 

Şekil 4: Yerel Ağ'daki cihazları bulmak

 

 

Lokal bir ağda işimiz bu derece kolay. Peki internet üzerinden diğer IPv6 adreslerini bulmak için nasıl bir yol izlenebilir, sonuçta bir önceki yöntem işe yaramayacaktır. Bu sorunun cevabını da IPv6 adreslerinin nasıl atandığını biraz daha detaylı inceleyerek verebiliriz. Yazımızın başında da belirttiğimiz gibi DHCP IPv6 adreslerinin atanmasında çok tercih edilen bir yöntem değil. Çoğu operatör SLAAC (Stateless Address Auto-configuration) yöntemini tercih ediyor. İstemciler bu şekilde kendi adreslerini kendi atayabiliyorlar ve ortamda atanmış IP adreslerini tutan bir cihaz ya da tablo gerekmiyor. 

 

Bu yöntem çok basit bir şekilde şu adımlardan oluşuyor. Modem şebeke tarafından kendisine gönderilen 64 bitlik prefix adresini Router Adv. paketleri (RA) ile lokal ağa yayınlıyor. İstemci de MAC adresinden türettiği 64 bitlik adresi bu prefix’e ekleyerek kendine ait tekil 128 bitlik IPv6 adresini oluşturmuş oluyor. 

 

Şekil 5: SLAAC ile IPv6 adresi ataması

 

EUI-64 yöntemi ile elde edilen bir IPv6 adresi gerçekten 2^128 farklı değere mi sahiptir? Şimdi basit bir hesap yapalım. İstemci ilk 64 biti modem tarafından (ki bunu da operatörün gönderdiğini biliyoruz) yayınlanan anons ile sabitledi. Bir operatörün sahip olduğu tüm prefixler aslında herkesin ulaşabileceği açık bir bilgi. Yani buradaki 64 biti sabit kabul etmemizde bir sakınca yok. Diğer 64 bit’in aslında 48 biti MAC adresine ait, diğer bitler yine sabit. Bu 48 bitlik MAC değerinin ilk 24 biti OUI (Organizationally Unique Identitifier) yani üretici bilgisi içeriyor ve internetten kolayca bulunabilecek açık bir bilgi. Diğer 24 bitin ise rasgele üretildiğini söyleyebiliriz. 

 

Bu durumda şöyle bir senaryo düşünelim. Belli bir operatörden hizmet alan ve sanal bir sunucu olduğunu bildiğimiz istemcileri taramak isteyelim. Böyle bir taramayı IPv4 için yapmamız mümkün değil, zira doğrudan IP – platform ilişkisini kuramayız. İlk yapmamız gereken işlem çok kullanılan sanallaştırma platformlarının OUI değerlerini öğrenip (örneğin VMware Horizon OUI: 00:0C:29) operatör prefixleri ile beraber bir tabloda tutmak. Sonrasında istemcinin MAC adresinin son 24 bitini taramamız yeterli. Bu arama uzayımız da IPv6’nın devasa IP sayısından çok daha küçük bir değer olduğundan günler aylar yerine belki de dakikalar sürecektir.

 

Bunun kullanıcı açısından en büyük problemi de MAC adresi sabit bir değer olduğundan IP adresinin prefix değişmediği sürece sabit kalması. Bu da kullanıcı takibi gibi bir takım mahremiyet ihlallerini beraberinde getiriyor. Bu sebeple EUI-64 yönteminin kullanılması günümüzde önerilmiyor, “privacy extensions” adı verilen yöntemle istemcinin kendi 64 bitlik adresini tamamen rasgele bir şekilde üretmesi isteniyor. Yine de olay tamamen işletim sistemi ve onun üzerindeki konfigürasyona bağımlı olduğundan çoğu güncel işletim sisteminin dahi bu şekilde IP adresi atadığını ve hatta bunlarla internete çıktığını görüyoruz. Bununla ilgili yapılan bir çalışmada (Scanning the IPv6 Internet: Towards a Comprehensive Hitlist) araştırmacılar 4 haftada anons edilen tüm prefixlerin %72’sine denk gelen 150 milyon tekil IPv6 adresini çıkarabilmişler. Dolayısı ile IPv6’nın devasa adres uzayına güvenerek tehlikelerden korunduğumuzu düşünmek tamamen yanlış diyebiliriz.

 

Extension Header Yapısı ve Zafiyetler

 

RH0 Saldırıları

 

Routing Header değineceğimiz ilk başlık türü. RH0 ve RH2 olmak üzere iki farklı tipi bulunuyor. RH0, paketin hedefine varana kadar geçmesi istenen adreslerin belirtildiği bir başlık. RH2 ise mobil cihazlar için tanımlı ve RH0 aksine tek bir IP adresi belirtilebiliyor. RH0 Header’ının 2007 yılında yayınlanan RFC 5095 ile kullanımı yasaklanmış durumda (https://www.rfc-editor.org/rfc/rfc5095.txt). Şimdi neden yasaklandığını hep beraber anlamaya çalışalım.

 

Aşağıdaki IPv6 Routing Header paketlerinde basit bir şekilde paketlerin nasıl işlendiğini görüyoruz. Burada kaynak adresimiz 2001:87f:3651::1 ve nihai hedef adresimiz 2001:87f:3651::51. Bu durumda paketimizin ilk olarak 2001:87f:3651::11 noktasından geçmesini istiyorsak IPv6 header’ında hedef olarak 2001:87f:3651::11 adresini ve geçmesi gereken adreslerle birlikte nihai hedefi de Routing Header bilgisi içerisine koyuyoruz.

 

Şekil 6:RH0 Yapısı

 

 

Buradaki iki büyük problemden ilkine göz atalım. Standartlar bize ziyaret edilmesi gereken adreslerle ilgili çok bir şey söylemiyor. Yani aynı adresin iki defa yazılması RFC açısından uygun. Bu durumda paketi istediğimiz kadar döndürüp hop limit tükenene kadar ilgili paketin loop’a girerek gereksiz trafik yaratmasına sebep olabiliriz. Örneğin aşağıdaki SCAPY kodu ile iki uç arasında paketin dönüp dolaşmasını sağlayabiliriz, bu durumda 10 Mbit bir upload genişliğiniz olduğunda 32 saniye boyunca yaklaşık 40 MB’lık bir trafik oluşacaktır.  Bu paketler hop limit tükendiğinde o andaki uç nokta tarafından düşürülecek ve daha fazla işlenmeyecektir, ancak hop limitin sadece IPv6 uçlarda azaltıldığı IPv6-IPv4 arası tünelleme yapıldığında IPv4 uç noktalarında hop limitin değişmediğini, TTL değerinin düşürüldüğünü biliyoruz. Bu da saldırının son derece güçlendirilebildiği ve DOS saldırılarına sebep olabilecek senaryolar da üretilebileceğini gösteriyor.

 

Şekil 7: RH0 paketleri ile boomerang saldırıları

 

 

İkinci ve belki de daha büyük bir problem de RH0 başlıklarında olası firewall atlatma senaryolarının uygulanabilmesi.  Aşağıdaki senaryoda DMZ üzerinde izinli bir sunucuya giden paket, RH0 opsiyonları ile bir sonraki hedef olarak iç ağdaki başka bir sunucunun IP’sine gönderiliyor. Bu durumda firewall’un nasıl davranacağını test eden araştırmacılar, farklı marka ve modellerin bazılarında paketlerin geçtiğini görmüş. Hatta CISCO bir cihaz özelinde yapılan testlerde, cihazın dış IP’sine giden paketi RH0 ile iç bacaktaki bir IP’ye yönlendirilebilmişler. Cihaz bu duruma çökerek cevap vermiş, tek bir paket ile çöken bu cihazın omurga cihazlardan biri olduğunu düşünün! Neyseki Cisco hızlı bir şekilde ilgili zafiyeti kapatmış durumda.  https://www.cisco.com/c/en/us/support/docs/csa/cisco-sa-20070124-IOS-IPv6.html

 

Bu iki büyük problemin yayınından sonra RFC 5095 (https://www.rfc-editor.org/rfc/rfc5095.html)  ile RH0 header’ının kullanımı kaldırıldı. Ancak bu basit tekniğin ve olası sonuçlarının ilk standart yayınlandıktan 9 sene sonra fark edilmesi de bir o kadar ürkütücü.

 

Şekil 8: RH0 paketleri ile firewall atlatılması

 

 

Fragmentation Header Zafiyetleri

 

Yazımızın son bölümünde IPv6’daki fragmentation yapısına ve bu yapıyı kötüye kullanan saldırı yöntemlerine odaklanacağız. Fragmentation kabaca paketlerin MTU (Max Transmission Unit) değerini aşması halinde parçalanması işlemidir. IPv4’te paket hedefe varana kadar herhangi bir yönlendirici paketleri fragmante edebilir. IPv6’da performans kazanımı elde etmek için fragmente işi yönlendiricilerde değil sadece uç noktalarda yapılmaktadır.

 

Fragmente işlemi IPv4 protokolü için de bazı tehlikeli senaryolara sahipti. Fragmente işleminin nasıl olduğunu ve sömürülebilecek bu senaryoları önce IPv4 üzerinde görmemiz konuyu anlamamız için daha iyi olacaktır.

 

Şekil 9’daki örnekte gördüğümüz üzere 4000 baytlık bir IPv4 paketini karşı tarafa yollarken maksimum 1500 baytlık paketler halinde bölüp göndeririz. İlk pakette mf=1 (mf=more fragment) bize paketin parçalandığını, offset=0 değeri de bunun ilk paket olduğunu gösteriyor. İkinci paketteki mf=1 değeri parçalama işleminin henüz bitmediğini offset=185 değeri de paketi tekrar inşa ederken bu paketi 185x8= 1480. bayt itibari ile yerleştireceğimizi söylüyor. 1500 baytlık pakette offset değerinin neden 1480 olduğunu merak ediyorsanız, 20 baytlık değerin header bilgisi olduğunu ekleyelim. Son paket de mf=0 değeri ile daha fazla parçalama yapılmayacağını, offset=370 değeri de 370x8=2960. bayt itibari ile payload’daki verinin yerleşmesi gerektiğini gösteriyor. Böylece karşı taraf kolay bir şekilde asıl paketi inşa edebiliyor. 

 

Şekil 9: IPv4 Fragmentation İşlemi
 

 

Standartlar bizlere 1500 baytı geçen paketlerin mutlaka bölünmesi gerektiğini söylerken, daha küçük paket boyları için bölünmemesi gerektiğini söylemiyor! Yani istersek 100 baytlık bir veriyi iki adet 50 baytlık paketle göndermemiz mümkün. Peki ihtiyacımız olmadığı halde header bilgilerini taşıyan kısmı bölmek istersek? Bu şekilde bazı bilgileri router ve firewall’lardan saklamamız mümkün olur mu?

 

Şöyle bir senaryo düşünelim, Şekil 10’da gözüktüğü gibi kabaca IP başlığı ve TCP başlığından oluşan ufak bir paketimiz olsun. Bu paketi TCP başlığındaki Seq Number alanından itibaren bölelim. 

 

Şekil 10: TCP başlığı Fragmente

 

 

Bu durumda ilk paketimizde Şekil 11’de görüldüğü gibi TCP ile ilgili kaynak ve hedef port ve Seq Number bilgisi yer alacaktır. 

 

Diyelim ki dışarıdan gelen TCP Syn paketlerini kabul etmediğimiz bir kuralımız var. Aşağıdaki iki paketin geçtiği yönlendirici ya da güvenlik duvarı nasıl davranmalı? Gelen tüm paketleri birleştirip kararı sonrasında veriyorsa bir sıkıntı olmayacaktır (statefull firewall). Ancak çoğu yönlendirici performans kayıpları yaşamamak adına TCP bilgisinin ilk pakette olacağını düşünerek kararı ilk paket için verir, sonraki paketlerde kuralı işletmez. Zira o paketler geçse bile ilk paket bir kurala denk geldiğinde düşürülürse bütün paketin tekrar bir araya getirilmesi mümkün olmayacağından paket hedef cihaz tarafından da düşürülecektir.

 

Bu sebeple bazı yönlendiriciler ilk pakette SYN ve ACK değerlerini görmediğinden pakete müsaade edecektir. Bu da kuralın atlatılması anlamına gelir!

 

Şekil 11: TCP fragmente paketler

 

 

Tiny Fragment satırları dediğimiz bu eski yöntem 1995 yılında çıkan bir RFC 1858 (https://datatracker.ietf.org/doc/html/rfc1858)  ile şu şekilde önlendi. Eğer fragmante edilmiş paketin fragment offset değeri FO=1 ve paket de TCP ise paket düşürülür. Bu şekilde paket arka tarafta asla bir araya getirilemeyecektir. Şık bir çözüm ancak bu basit ve etkili kural ne yazık ki IPv6 paketlerindeki karmaşık extension headers yapısı sebebiyle çalışmıyor. Yazımızın başında tek bir IPv6 paketinde birden çok extension header bulunabileceğini belirtmiştik. Fragmentation başlığı sonrası bir Destination Options başlığı yer almasında standartlara aykırı bir durum yok. Dolayısı ile FO=1 değerini alan IPv6 paketleri illegaldir sonucuna varmamız mümkün değil, bu sebeple IPv4 için çalışan kural burada artık çalışmıyor. 

 

Maalesef daha da kötü senaryolar üretilebiliriz. Örneğin Destination Options başlığı 2040 bayt büyüklüğüne ulaşabiliyor, dolayısı ile bir destination options header’ını 8 baytlık 255 parçaya bölebiliriz. Bu durumda TCP başlığı 255. paket sonrasında yer alacak (Şekil 12) ve deep paket inspection yapmayan cihazlarda bu paket kurallara takılmayacaktır.

 

Şekil 12:255 pakette yer alan bir TCP başlığı

 

 

Fragmentation konusunda bir diğer tehlike de offset değerleri ile oynarak elde edilen manipülatif paketlerin karşı uçta birleştirilirken bazı önemli parametrelerin değiştirilebilmesi. Fragmentation overlapping olarak bilinen bu saldırı türünü yine Ipv4 üzerinden basit bir örnekle açıklamak daha iyi olacaktır.

 

Bu sefer ilk gönderdiğimiz pakette TCP header bilgisinin tamamı yer alsın. Şekil 13’de gördüğümüz üzere ilk pakette herhangi bir şüpheli durum yok. Yönlendirici SYN=0, ACK=1 değerlerini gördüğünde paketin içeriden çıkan bir isteğin cevabı olduğunu düşünüp izin verecektir. Ancak ikinci paketteki offset değerine dikkat edelim. FO=1 bize ilk paketin 1x8 baytından itibaren ikinci paketi yerleştirmemiz gerektiğini söylüyor. Bu durumda ilk paketteki kaynak, hedef port ve SEQ number bilgileri korunan bilgiler. Bundan sonrası ise farklı işletim sistemi ve implementasyonlara göre değişiyor. Çoğunlukla yönlendiriciler sonradan gelen paketi ilkinin üzerine yazıyor. Bu sebeple ilk paketteki ACK number ile başlayan alan ve sonrasına ikinci paketteki değerler yazılarak tüm paket tekrar inşa ediliyor. Bu durumda da paketimizin son halinde SYN=1 ve ACK=0 değerlerini görüyoruz ve uç noktaya TCP seviyesinde erişim sağlamış olduk!

 

Şekil 13: IPv4 offset saldırıları

 

 

Bunun çözümü tiny fragment saldırılarında olduğu gibi offset değeri 1 olan TCP paketlerini düşürmek. Yani çözüm hali hazırda mevcut. Ancak IPv6 için ilgili önlemin çalışmadığını belirtmiştik. Yine basit bir örnek üzerinden bunu görmeye çalışalım. 

 

Şekil 14’de görüldüğü üzere ilk paketimiz IPv6 header + Fragmentation Header + 80 bayt uzunluğunda Destination Options Header ve TCP header’ından oluşsun. İkinci paketteki fragmentation header içerisindeki offset değerimiz de FO=10 olsun. Bildiğimiz gibi bu ilk paketteki 80. (10x8) bayt sonrasına bu paketteki TCP’yi yapıştır demek. Ancak gördüğümüz gibi ilk paketteki TCP ile ikinci paketteki TCP header’ı çakıştı. Ve bu durum IPv4’teki senaryodan daha ciddi çünkü sadece SYN, ACK vb. değerlerle değil kaynak ve hedef portun da üzerine yazabiliyoruz!

 

Şekil 14: IPv6 offset saldırıları

 

 

Bu basit ama ciddi zafiyet overlapping fragmentleri yasaklayan RFC 5722 (https://datatracker.ietf.org/doc/html/rfc5722)  ile çözüldü. Fragmente edilmiş paketler tekrar inşa edilirken çakışan baytlar varsa tüm paketin düşürülmesi zorunlu oldu. 2014 yılında gelen RFC7112 (https://www.rfc-editor.org/rfc/rfc7112)  ile de tüm header zincirinin ilk fragmentte yer almasının şart olması ve header yapısının parçalanamayacağı zorunluluğu geldi. Tüm header bilgisinin uzunluğu 1280 bayt ile sınırlandırarak MTU boyunu geçmemesi de sağlandı Ancak tüm cihazlarda bu standardın implement edilmesinin birkaç yılı bulabileceğini düşündüğümüzde aslında yıllar boyu süren belki de sömürülen önemli zafiyetlerle karşı karşıya kaldığımızı görüyoruz.

 

RFC 5722 ve 7112 implement edilmiş cihazların bu tür saldırılara karşı dayanıklı olduğunu biliyoruz. Yazımızın son bölümünde tüm standartlara uyan ancak NH (NextHeader) değerlerinin manipülasyonu ile bazı IPS cihazlarını atlatan yine basit bir örneğe yer vereceğiz. Antonios Atlantis tarafından 2014 yılında yapılan bir çalışmada, Şekil 15’te gözüken IPv6 paketinin hangi hostlardan geçebileceği test edildi.

 

Ana paketimiz IPv6 header bilgisi sonrası sırası ile Routing Header + Destination Options ve bir üst katman TCP header bilgisi ve payload içeren bir paket olsun. TCP verisini fragmente ettiğimizi düşünelim. RFC 7112 gereği artık fragmente ettiğimiz ilk pakette header bilgisinin tamamını koymamız gerekiyor. 2. Pakette ise TCP payload verisinin geri kalanı yer alacak. 2. paketteki Fragmentation Header bilgisindeki NH=60 olması gereken veriyi 6 olarak değiştirelim. NH=6 değeri de hatalı bir şekilde bir sonraki header başlığının Dest. OPT. değil TCP olduğunu belirtiyor.

 

Şekil 15: Next Header manipulasyonu

 

 

Burada standartlara uymayan bir yapımız yok. Bu paketin tekrar inşası sırasında RFC gereği offset değeri 0 olan ilk paketteki Next Header bilgilerinin temel alınması gerekiyor. Dolayısı ile paket düzgün bir şekilde tekrar inşa edilmeli. Araştırmacılar çeşitli işletim sistemlerinde bu paketin normal bir şekilde inşa edildiğini teyit etmişler. Ancak denedikleri bir IPS sisteminde (HP Tipping Point 3.6.1.4036), cihazın hatalı bir şekilde DST options alanını TCP olarak parse etmeye çalıştığını, dolayısı ile port vb. değerlerin anlamlandırılamadığını görmüşler. Bunun bir atlatmaya sebep olup olmayacağını denemek için de basit bir XSS payload’u uç noktaya göndermişler. Şekil 16’daki ekran görüntüsünden görüldüğü üzere, paket herhangi bir alarm üretmeden geçmiş. Wireshark aracının da paketi yanlış parse ettiği, port bilgisini 256 gösterdiğini fark etmişsinizdir. Bu sebeple IPS cihazı da paketin http olup olmadığını bile anlamlandıramayıp bir alarm üretmemiş gözüküyor. 

 

Şekil 16: IPS atlatma

 

 

Son örneğimizde görüldüğü gibi Layer 3 seviyesindeki bir zafiyet yukarıdaki tüm katmanları engelliyor. Sonuç olarak karmaşık extension headers yapısı IPv6 özelinde birtakım sorunlara yol açmış gözüküyor. Sıkça güncellenen standartlar ile bu yapıların bazılarının kullanımı kaldırılırken bazılarında da düzeltmeye gidildiğini gördük. İçinde bulunduğumuz sen sonrası hayatımıza iyiden iyiye girecek olan IPv6 protokolünü ve olası zafiyetleri örneklerle açıklamaya çalıştık. Kurum ve kişilerin ilgili konfigürasyonlara ve cihazlarının RFC uyumluluğuna dikkat edilmesini tekrardan öneririz.

 

Referanslar

 

[1] Attacking IPv6 Implementation Using Fragmentation, Antonios Atlasis ,BlackHat 2012

[2] Fragmentation (Overlapping) AttacksOne Year Later, Antonios Atlasis, IPv6 Security Summit 2013

[3] Evasion of High-End IDPS Devices at the IPv6 Era, Antonios Atlasis, Enno Rey, Rafael Schaefer, BlackHat 2014

[4] IPv6 Security: Attacks and Countermeasures in a Nutshell, Johanna Ullrich Et al., USENIX Workshop on Offensive Technologies, WOOT 2014

[5] IPv6 Routing Header Security, Philippe BIONDI, Arnaud EBALARD, CANSECWEST 2007

[6] Mechanism to prevent the abuse of IPv6 fragmentation in OpenFlow networks, Ayman Al-Ani Et al, PLoS One. 2020 May 11;

[7] IPv6- A Literature Review, Lokesh Kumar, International Journal of Advance Engineering and Research Development, Volume 6, Issue 02, 2019