IoT’nin HTTPS ile İmtihanı, API Security, SVG ile SSRF

HTTPS Kullanan IoT'nin Suçu Ne?

HTTPS kullanımı gün geçtikçe artıyor. “Alexa Top 1 Million” sitelerinin üçte birinin SSL kullandığını gözlemleniyor. Ancak bu tabloda genellikle gözden kaçan çok önemli bir ayrıntı var: Maalesef güvensiz bağlantıların, yani HTTP bağlantılarının çoğu IoT cihazları tarafından gerçekleştiriliyor.

Neo Smart'ın blogunda yayımlanan yazısı ile Mahmoud Al-Qudsi bu gerçeğin çok çarpıcı başka bir çehresi olan güvenli bağlantı kullanmak isteyen IoT cihazların tüm majör tarayıcılar tarafından nasıl cezalandırılıyor olduğuna dikkatlerimizi çekiyor.

HTTPS, bilindiği üzere trafiğinin araya giren üçüncü bir kişi tarafından okunmasını, değiştirilmesini engelleyen bir protokoldür.

Tweette kısaca özetlendiği gibi HTTPS kullanımı sadece trafiğin gizli olduğunu doğrular, mesajınızın alıcısına güvenebileceğinizi değil. Yani iletişimde, karşınızda bulunan tarafın gerçekten de sizin görüşmeyi murat ettiğiniz kişi olup olmadığını doğrulamak için sertifika otoriteleri devreye giriyor. Yani tarayıcıların tanıdığı sertifika otoriteleri tarafından güvenli iletişimin diğer tarafının, sizin görüşmek istediğiniz kişi olduğuna bir nevi kefil olunuyor.

Örneğin: IoT cihazlarımıza, 192.168.1.1 gibi private network kapsamında değerlendirilen bir IP ile erişimde bulunduğumuzda, şayet bu IoT cihazları “Self-Signed” yani güvenilir bir sertifika otoritesi tarafından değil de, yine kendileri tarafından imzalanan bir sertifikayı sunarak sizinle güvenli bağlantı kurmaya çalışıyorlar ise, tarayıcılar aşağıdaki gibi korkunç senaryolar içeren sayfalar ile siz, kullanıcıları karşılıyorlar.

Güvensiz bağlantılar konusunda kullanıcıyı adres çubuklarına iliştirdikleri küçük bir bildirim balonu ile uyarmayı tercih eden tarayıcıların, “Self-Signed” sertifikalar konusunda verdikleri bu aşırı tepki not edilmeye değer.

Sorunun kökeni 2013 yılındaki bir konsensüse dayanıyor.

1 Ocak 2013'de CA/B 'de alınan bir karara göre (CA/B tarayıcı üreticileri ve sertifika otoritelerinden meydana gelen bir topluluk), bundan böyle RFC1918'de tanımlanan IP adresleri ve yerel kaynaklar için sertifika imzalanmayacak idi.

DigiCert'in özetlediği şekilde bu IP adresleri ve yerel kaynaklar şunlardır:

• Non-public-domain adını bir suffix olarak kullanan alan adları, örneğin; myserver.local, machine.internal, gibi.
• Netbios name’leri ya da public domain suffix'i içermeyen kısa adlar. Örneğin myserver, Machine56, vb.
• RFC1918'de tanımlanmış IP4 adresleri:

• Ve RFC 4193'de tanımlanan IPv6 aralıkları.

HTTPS'in çare olduğu en büyük risk olan DNS Spoofing aslında kaynaklara doğrudan IP ile erişildiğinde ihtimal dahilinde olmuyor. Çünkü siz 192.168.1.1 'e eriştiğinizde, herhangi bir DNS sorgusu yapmadan ağınızdaki 192.168.1.1 numaralı makineye paket doğrudan gönderiliyor. Dolayısıyla yerel IP erişimlerinde Self-Signed sertifika gönderen siteler için yukarıdaki uyarılarla yanıt vermek ilginç bir hamle.

Bunun şimdilik bir çözümü yok. Belki IoT cihazların artmaya devam eden grafiği tarayıcı üreticilerini bu konuda kalıcı bir çözüm üretmeye zorlayabilir.

Bir “Work-Around” olarak, tarayıcı üreticileri cihazlarına erişilen yerel IP için bir subdomain tanımlayabilir ve bu subdomain için sertifika imzalatabilirler.

Örneğin; access.example.com 192.168.1.1

Konunun ayrıntıları için Mahmoud Al-Qudsi tarafından yazılan yazıya göz atabilirsiniz.

API Security Checklist

Uygulamamızın kapsamını genişletmek istediğimizde, ilk akla gelen yol API'lar. API yani Application Programming Interface sayesinde kaynaklarımızı kullanan müşterilerimiz veya hizmet alan kişiler kendi süreçleriyle, sistemlerimiz arasındaki iletişimi UI bağımlılığı olmadan otomatikleştirerek gerçekleştirebilirler.

Fakat önemli bir başlık olarak API'lerin güvenliği de en önemli konular arasında yer almalı. Çoğunlukla UI dizaynında hesaba katılan saldırı senaryoları API bazında göz ardı ediliyor ya da API'ları geliştiren geliştiriciler dizayndaki muhtemel risklerden maalesef habersizler. ShieldFY tarafından hazırlanan ve aralarında Türkçe'nin de bulunduğu pek çok dile çevrilen API Security Check List, API dizaynında, geliştirilmesinde ve güvenlik testlerinde izleyebileceğiniz bir yol haritası sunuyor.

Yetkilendirmeden, Erişime, Girdi kontrollerinden, çıktılarda dikkat edilecek hususlara, hatta API'ın release süreçlerine dair önemli notlar dahi bulunmakta.

Ayrıntılar için projenin Github sayfasını ziyaret edebilirsiniz.

SVG Server Side Request Forgery (SSRF)

Hackerone'da raporlanan zafiyetlerden biri gerçekten ilgi çekici. Bu yüzden Haftanın Hackleri yazımızın bu kısmında ayrıntılarını sizlerle paylaşmak istedik.

Sitelerdeki File Upload fonksiyonları, zararlı kodların yüklenmesi için saldırganların iştahını kabartan kısımlardan biri. Bu sebeple File Upload fonksiyonu görüldüğünde sadece saldırganlar değil, güvenlik testi yapanlarda bu fonksiyonlara özel bir dikkat ile eğilmeli.

Hackerone'da raporlanan zafiyete göre, Shopify 'da ürün eklerken, beraberinde ürüne ait resimleri de yükleyebilmek mümkün. Fakat bu esnada yapılan kontrol yeterli değil. JPG uzantısına sahip fotoğraflar yüklenilmesi zorunlu tutulsa da HTTP paketini manipüle eden biri kolaylıkla dosyanın uzantısını JPG olarak bırakıp, Content-Type değerini image/svg+xml olarak değiştirip, gerçek bir SVG içeriğini de gönderilebiliyor. Dolayısıyla sadece dosya uzantılarında yapılan bir kontrolün yeterli olmayacağı aşikar.

POST /admin/products/9577763394/images.json HTTP/1.1
. . .
..
.
Content-Type: multipart/form-data; boundary=---------------------------1184233411771235065729422741
Cookie: <REDACTED>
Connection: close


-----------------------------1184233411771235065729422741
Content-Disposition: form-data; name="image[attachment]"; filename="NagKSvgXlink2.png"
Content-Type: image/svg+xml

<?xml version="1.0" encoding="UTF-8" standalone="no"?><svg xmlns:svg="http://www.w3.org/2000/svg" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" width="200" height="200"><image height="200" width="200" xlink:href="http://<EXAMPLE_SERVER>/image.jpeg" /></svg>
-----------------------------1184233411771235065729422741
Content-Disposition: form-data; name="image[alt]"
-----------------------------1184233411771235065729422741--

Shopify her ne kadar bu isteğe 422 Unprocessable Entity ile karşılık verse de, SVG dosyasındaki EXAMPLE_SERVER olarak imlenen adrese istek yapıldığı araştırmacı tarafından tespit ediliyor.

Raporlayan kişi HTTP ve FTP protokollerine istek yapıldığını not ediyor, ancak XXE vb atakların mümkün olmadığını belirtiyor. Statik içerikten ötürü billion of Laugs olarak bilinen recursive çağrılarla sistemin servis dışı bırakılmasının mümkün olabileceğini belirtse de, bunun bounty kapsamı dışında olduğunu belirterek, çalışma dışında tutuyor.

Fakat ilginç bir ayrıntıya dikkat çekiyor:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<svg xmlns:svg="http://www.w3.org/2000/svg" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" width="200" height="200">
<image height="30" width="30" xlink:href="http://<EXAMPLE_SERVER>:81/example.png" />
<image height="30" width="30" xlink:href="http://<EXAMPLE_SERVER>:999/example.png" />
<text x="0" y="20" font-size="20">test</text>
</svg>

SVG dosyasında iki farklı image dosyasına referans verebilmek mümkün. İlk image linki geçerli bir image dosyası olduğuna dair yanıt aldığında, ikinci image tag’indeki adrese istek gönderiliyor. Peki bu ne demek?

Örneğin, eğer ilk image tag’iyle sistemde bulunan bir image dosyasına işaret edersek ve bu dosya varsa, bu defa bizim kontrolümüzdeki EXAMPLE_SERVER'a, yani ikinci linke istek yapılacak. Mesela ilk image tag’ında istek yapılan local path, /lib/plymouth/ubuntu_logo.png
Geçerli bir yanıt verirse ve saldırgan kontrolündeki ikinci linke istek yapılırsa, hedef sistemde Ubuntu yüklü olduğu tespit edilebilecek. Bu teknikle bir nevi sistemde fingerprinting yapılabileceğine vurgu yapılıyor.

500 USD ile ödüllendirilen zafiyetin ayrıntıları için tıklayınız.

RECON Candır!

Recon olarak kısalttığımız Reconnasiance, yani tanılama, keşif, askeri sahadan pentest alanına devşirdiğimiz bir kavram. Hedef hakkında olabildiğince bilgi toplamayı gereksinen, güvenlik testlerimizin ilk aşaması. Önemi bir yana, sıkıcı bir aşama olduğu, fakat tüm sıkıcılığına rağmen, sabrın sonu selamettir sözünü doğrularcasına, sonunda altın küpüne erişebileceğiniz önemli bir aşama!

Haftanın Hackleri'ne konu ettiğimiz bu öykü ise Yahoo'da 900 USD'lik bir XSS keşfeden araştırmacıya ait.

Th3G3nt3lman mahlası ile Medium'daki BugBountyWriteUp sayfasında hikayesini anlatan araştırmacı, daha hikayesinin başında çok önemli bir bypass trick'i değil, recon 'u ciddiye alarak nasıl başarıya ulaştığını anlatacağını belirtiyor.

Yahoo'ya özel bir alaka gösteren araştırmacı, recon aşamasında Yahoo'ya ait olan şöyle bir subdomain keşfediyor:

http://bf1-adxdb-001.data.bf1.yahoo.com

Yahoo'da zafiyet bulmakla iştigal eden pek çok bounty hunter gibi o da “The requested URL was not found on this server” uyarısı ile karşılaşıyor.

Azimli araştırmacı, URL üzerinde dosya ve dizin tespiti için araştırmalarını sürdürüyor ve bu araştırmaları neticesinde, about.php adında bir dosya tespit ediyor. Bu sayfadan aldığı response ile webpagetest 'in bir sürümüne ulaştığını fark eden araştırmacı, araştırmalarını sürdürüyor ve yine aynı subdomain üzerinde nginx.conf dosyasına ulaşıyor.

Kaynak bulma işlemine devam eden araştırmacı, bir süre sonra testdb.php isimli bir dosya ile karşılaşıyor. Dosyaya erişim sağlamak istediğinde ise aşağıdaki hata mesajı ile karşılaştığını belirtiyor:

Fatal error: Call to undefined function mysqli_connect() in /home/y/share/htdocs/testdb.php on line 8 [/testdb.php/]

Knoxss aracının da yardımı ile, URL'in path kısmından bu sayfaya XSS enjekte edebildiğini belirten araştırmacı, raporladığı zafiyetten 900 USD ödül kazanıyor.

Writeup'daki en güzel kısım ise, araştırmacının yazı sonunda öğüt niteliğinde zikrettiği, bu çalışmasından çıkardığı dersler:

• Not Found ya da Forbidden uyarılarını görünce asla pest etme! Bir directory enumaration tool'u kullanarak, daha fazla endpoint'e ulaşmaya çalış.
• Recon kazandırır. Yahoo gibi bir ummanda recon yapmak elbette kolay değil. Odaklanma ve sabır gerektirdiği aşikar. Araştırmacı, günlük olarak Yahoo kaynaklarındaki hareketi Shodan.io'dan izlediğini belirtiyor. Her ne zaman bir subdomain keşfetse, onun altında olabilecek diğer subdomainleri de araştırdığını not ediyor.

Writeup'ın ayrıntılarına ulaşmak için lütfen tıklayınız.