Cloudflare, müşterilerine alan adı (DNS) hizmetleri, Dağıtılmış Hizmet Reddi (DDoS) koruması ve içerik dağıtım ağı (CDN) sağlayan bir şirkettir. Bu hizmetler, web sitelerinin kullanıcılara tutarlı, hızlı ve yüksek düzeyde kullanılabilir içerik sunmasını destekler. Hem ücretsiz hem de ücretli hizmet katmanlarına sahip Cloudflare, son on yılda büyük bir pazar payı elde etti – genel CDN alanının yaklaşık %20’si ve Alexa Top One Million web sitelerinin %40’ından fazlası.
Bu nedenle araştırmacılar, bir web varlığı ile bir hedefi araştırırken sıklıkla Cloudflare tarafından korunan web sitelerine rastlayacaklardır. “Korunan” kelimesini belirli bir nedenden dolayı kullanıyorum. Cloudflare DNS, ücretsiz teklifinin bir parçası olarak, arka uç web sitesi adına trafiği “proxy” etme seçeneğini sunar. Bu, Cloudflare’in web sitesi içeriğini dünya çapında çoğaltmasına olanak tanır ve genellikle şirketin dünya çapındaki ölçeğinden yararlanarak gelişmiş bir web sitesi yükleme hızı sunar. Bu aynı zamanda web sitesinin IP adresi gibi web sitesinin bazı tanımlayıcı özelliklerinin Cloudflare dışındaki herkesten gizlenmesine de neden olur.
Bir IP adresiyle, aynı web yöneticisine ait diğer web sitelerini tanımlamak ve hatta kullanıcının kendisini (uygun izin belgesiyle) tanımlamak da dahil olmak üzere birçok şey yapabilirsiniz; dolayısıyla bu veri parçası, birçok OSINT araştırması için çok önemlidir. Kötü oyuncular da bunu biliyor ve Cloudflare’in koruyucu özelliklerinden sonuna kadar yararlanıyorlar. Bu, Cloudflare’in nispeten “müdahalesiz” yaklaşımıyla birleştiğinde, şirketin çocuk istismarı görüntülerinin veya beyaz milliyetçi içeriğin ağlarında yayılmasını durdurmak için yeterince çaba gösterip göstermediği konusunda birkaç sıyrıkla karşılaştığı anlamına geliyor. Cloudflare’in destek ekibinin fazla yardımı olmadan, araştırmacılar genellikle Cloudflare’in IP korumasını aşmanın yollarını bulmak zorunda kalıyor.
Francesco Poldi’ninki de dahil olmak üzere pek çok harika araç var. favoriCloudflare korumalı bir alanın arkasındaki gerçek IP adresini belirlemek için , Crimeflare ve bu SecJuice gönderisinde paylaşılan teknikler, ancak bugün Cloudflare’in arkasına gizlenmiş bir WordPress web sitesinin IP adresini tanımlamaya yönelik bir teknikten bahsedeceğim.
WordPress çok popüler bir web sitesi İçerik Yönetim Sistemidir (CMS) ve web yöneticilerinin genellikle en son yamaları ve güncellemeleri uygulamaması nedeniyle saldırılara karşı savunmasız olmasıyla ün kazanmıştır. Ancak bunun için saldırılara güvenmemize gerek yok. IP adresini, varsayılan ayarlarla ve birkaç web aracıyla basit bir WordPress kurulumundan başka bir şey kullanmadan bulabiliriz.
Bu web araçları, çoğu WordPress örneğinde varsayılan olarak etkin olan “Geri Pingler” adı verilen bir özellikten yararlanacaktır. Geri bildirimler, bir blogdaki bir yazı başka bir bloga bağlandığında farklı WordPress web sitelerinin birbirleri arasında bağlantı kurmasına olanak tanır. Geri ping, yeni yayınladığınız blog sayfanıza bağladığınız sayfadan geri bir “ters bağlantı” oluşturur; bu, blogların arkadaşlarına trafik oluşturmak için ilgili bloglara bağlantı verdiği 1990’lardaki “blog halkalarını” biraz anımsatır. toplum.
Bunun çalışma şekli, bir geri ping isteğinin kullanıcıları ikna etmesidir. WordPress sunucusunu hedefle
Bir geri ping üzerinde anlaşmak için kullanıcı tarafından kontrol edilen bir sunucuya ulaşmak. Hedef, geri pingleri devre dışı bırakmadığı veya IP kaynağını gizlemek için WordPress kurulumunu manuel olarak düzenlemediği sürece, WordPress sunucusunun kendisi ping geri sunucunuzla iletişim kuracak ve bu onların IP adresini size gösterecektir.
Cloudflare ve WordPress sitesi ile normal iletişimi gösteren aşağıdaki şemayı alın. Cloudflare, arka uçla iletişim kurmak için kullandığı IP adresini açıklamayacak, bu da bizi başka bir yol bulmaya zorluyor.
Bir pingback’in WordPress sunucusunu, bulduğu IP adresini bize ileten “bal küpü” pingback sunucumuza ulaşmaya nasıl ikna edeceğini gösteren bir sonraki diyagramla karşılaştırın.
Mevcut bir sitenin “istismarını” önlemek için, geçici olarak* bir DigitalOcean sunucusunda IP adresi sızıntısını göstermek için kullanacağım bir WordPress örneğini başlattım. Sunucuyu kurduktan sonra yaptığım ilk şey sitem ile alan adı arasında Cloudflare proxy’sini etkinleştirmek oldu, böylece kaynak IP normal kanallardan sızdırılamazdı.
* Bu siteyi kısa bir süreliğine açık bırakacağım, mevcut olduğu sürece tekniği test etmekten çekinmeyin 🙂
Bunu test etmek için test ana bilgisayar adıma ping attım:
Bu, aşağıdaki IP adresini döndürür:
Bu IP adresini myip.ms gibi herhangi bir IP arama sitesine taktığınızda, IP adresi sahibinin beklendiği gibi “Cloudflare, Inc” olduğunu göreceksiniz. Alan adını doğrudan aradığınızda da aynı durum geçerlidir.
Sunucumun arkasındaki özel IP adresini keşfetmek için uygulayabileceğiniz iki yaklaşım vardır. Biri, WordPress sitesini araştırmak ve veri toplamak için iki web aracına güveniyor, diğeri ise aynı verileri toplamak için yaygın olarak bulunan Linux komut satırı uygulamalarını kullanıyor. Şahsen ben web araçlarını kullanmayı tercih ediyorum tüm durumlar Korunan web sitelerinin arkasındaki IP adresinin maskesini tek bir basit nedenden dolayı kaldırmak için: web araçları IP adresinizi gizler. sahip olmak Hedef web sayfasını kontrol eden (potansiyel olarak suçlu) hedeflerin IP adresi. Her iki durumda da, bu “pasif” bir keşif olmayacaktır – sondanızın hedefin erişim kayıtlarında görünme olasılığı yüksektir (eğer hedef onları izliyorsa), dolayısıyla sizinle onlar arasında ne kadar çok katman tutarsanız o kadar iyi olur . Yine de hem web araçlarını hem de Linux araçlarını göstereceğim çünkü OSINT uygulayıcılarının kendi araçlarını oluşturmaya açık olmaları gerekir. Bu web araçları herhangi bir zamanda internetten kaybolabilir ve en azından alternatif web araçlarını değerlendirirken veya kendiniz bir tane oluştururken geriye dönüp bakabileceğiniz bir referans sağlamak istiyorum.
Başlamak için sunucuda geri pinglerin etkinleştirildiğini doğrulamamız gerekiyor. Hedef WordPress sitenizi tarayıcınıza yükleyin ve herhangi bir blog yazısını açın. URL’yi değiştirin ve ekleyin view-source: sayfanın kaynak kodunu görüntülemek için başlangıca gidin ve Enter tuşuna basın. Basmak Ctrl+F ve kelimeyi arayın pingback. Geri pingler etkinse, “href” özelliğinin içinde pingback öğesine bağlı bir URL olacaktır (ör. )
Her iki geri ping URL’sine de dikkat edin Ve Daha sonra kullanmak üzere blog gönderisinin tam URL’si.
Geri ping URL’si
https://wordpress.nem.ec/xmlrpc.php
Blog Gönderisi URL’si
https://wordpress.nem.ec/2020/01/22/hello-world/
Şimdi tarayıcınıza aşağıdaki web sitesini yükleyin: https://webhook.site/
Siteyi ilk kez yüklüyorsanız, yepyeni bir benzersiz URL’ye yönlendirileceksiniz (ör. https://webhook.site/#!/e1f36ec8-850a-4cc3-b3dc-c3d19448a6b2) ve web sitesi “İlk istek bekleniyor…” başlayacaktır. Web sitesini daha önce kullandıysanız kenar çubuğunda bazı eski isteklerin listelendiğini görebilirsiniz. Sorun değil, onları görmezden gelebilirsin. Bu sekmeyi daha sonraya kadar açık bırakın.
Yeni bir sekmede tarayıcınızda https://reqbin.com/ URL’sini ziyaret edin. üzerine tıklayın Content
sekmesine tıklayın ve seçin XML (application/xml) varsayılan yerine içerik türünüz olarak:
Şimdi değiştir GET açılır menü POST ve daha önce kaydettiğiniz Pingback URL’sini açılır menünün yanındaki URL kutusuna yapıştırın:
Bundan sonra aşağıdaki şablonu kopyalayıp XML içeriği metin alanına yapıştırın:
pingback.ping
https://webhook.site/e1f36ec8-850a-4cc3-b3dc-c3d19448a6b2
https://wordpress.nem.ec/2020/01/22/hello-world/
Şablondaki her iki URL’yi de kendi URL’lerinizle değiştirmelisiniz. İlki senin sahip olmak Bu bölümün başında bulduğunuz benzersiz webhook.site URL’si. İkincisi, daha önce kaydettiğiniz blog yazısı URL’sinin tamamıdır.
“Gönder”e tıklayın ve sunucudan yanıt bekleyin. Sunucu sizi ana sayfaya yönlendirmeye çalışırsa, bu muhtemelen sunucunun geri pingleri engelleyecek bir yazılım yüklediği anlamına gelir. Kendi kurulumumda bu sinir bozucu sorunla karşılaştım (her ne kadar bu yazıyı yazabilmek için onları yeniden etkinleştirmiş olsam da!) ve bu, ilk isteğinizi gönderene kadar test edebileceğiniz bir şey değil. Böyle bir durumda web sitesi kendisini geri pinglere karşı korumuştur ve bu teknikle IP adreslerini ortaya çıkaramazsınız.
Ayrıca bu yöntem biraz kör bir işlemdir. Kontrolünüz başarılı olsa da olmasa da, isteğinizin ardından sunucudan 0 değerinde bir “faultCode” almayı beklemelisiniz. XML şöyle görünür:
Bu nedenle başarılı olduğunuzu anlamanın tek yolu https://webhook.site sekmenizdeki istek günlüğünü kontrol etmektir. Önceki isteğimi gönderdikten sonra şunu görüyorum:
Başarı! Bir istek bulundu ve daha önce görmediğimiz yeni bir IP adresi görüntüleniyor. IP’nin yanındaki küçük “whois” bağlantısını tıklarsanız tam olarak aradığımız şeyi görüntüler:
DigitalOcean, LLC DO-13 (NET-64-225-0-0-1) 64.225.0.0 - 64.225.127.255
Daha fazla onay olarak IP adresi 64.225.37.249 aslında bu DigitalOcean sunucusunu kaydettikten sonra bana atanan IP adresiyle eşleşiyor. Tebrikler, Cloudflare perdesinin arkasına göz attınız ve sunucu IP’mi açığa çıkardınız!
IP adreslerini proxy olarak kullandıklarından şüpheleniyorsanız, araştırdığınız herhangi bir WordPress sitesine aynı taktiği uygulayın.
Önceki bölümdeki yetenekli web araçlarına alternatif olarak, aynı görevi gerçekleştirmek için bazı standart Linux komut satırı uygulamalarını kullanabiliriz. Biz şunu istiyoruz: netcat Ve curl uygulamaların yanı sıra yönlendiricinizde/güvenlik duvarınızda bir bağlantı noktası açma erişimi.
Pingback URL’nizi ve Blog Yazısı URL’nizi kaydetmek için önceki bölümün ilk paragrafını izleyin
Geri ping URL’si
https://wordpress.nem.ec/xmlrpc.php
Blog Gönderisi URL’si
https://wordpress.nem.ec/2020/01/22/hello-world/
Şimdi yönlendiricinize gidin ve TCP bağlantı noktası 80’i bilgisayarınıza iletin. Deneyimlerime göre, WordPress 80 veya 443 (https) dışındaki bağlantı noktalarına geri ping göndermeyi reddedecektir, bu nedenle bağlantı noktasının 80 olması gerekir. Yönlendiriciniz izin veriyorsa, yönlendirici bağlantı noktasını kendi bilgisayarınızdaki başka bir aralığa yönlendirebilirsiniz. Bunu yapmanın yöntemi her yönlendirici için farklı olacaktır. Gerekirse kılavuzunuza bakın. Bunu test etmek için bir VPS (Sanal Özel Sunucu) kiralamaya karar verirseniz, port 80’iniz muhtemelen zaten internete açık olacaktır ve bu adımı atlayabilirsiniz.
Ardından, halk IP adresi. 192.168.* veya 10.0.* ile başlayan bir IP’niz varsa, muhtemelen özel IP adresi ve çalışmayacak. Ek olarak, bazı İSS’ler, yerleşim planında web sitelerini kendi kendine barındırmanızı önlemek için 80 numaralı bağlantı noktasından veri almayı engeller ve bilgisayarınız bir VPN arkasındaysa, hedef sunucudan da ping geri alamazsınız. Bu durumda, hedef WordPress sunucusunun iletişim kurması için bir “bal küpü” sağlamak amacıyla VPN’nizi devre dışı bırakın veya kısa süreliğine bir VPS kiralayın.
Gerekirse genel IP’nizi aşağıdaki komutla bulabilirsiniz:
Boş bir terminal penceresinde aşağıdaki komutu çalıştırın. Hedef WordPress sunucusundan yeni bir bağlantı bekleyecektir. sudo gereklidir çünkü yalnızca root/admin erişimi için ayrılmış <= 1024 numaralı bağlantı noktasını dinliyoruz.
adında yeni bir dosya oluşturun pingback.xml aşağıdaki içeriklerle. İlk URL’yi değiştirin (10.0.0.1) seninle sahip olmak genel IP adresi ve bağlantı noktası. Sahte “yolu” yalnız bırakın çünkü bazı WordPress kurulumları, kötüye kullanımı ve spam’i azaltmak için düz bir alana ping atmayı reddedecektir. İkinci URL’yi hedef sunucudaki bir blog gönderisinin URL’si ile değiştirin.
pingback.ping
http://10.0.0.1/hello/world
https://wordpress.nem.ec/2020/01/22/hello-world/
Şimdi aşağıdaki komutu çalıştırın. pingback.xml az önce oluşturduğunuz dosyanın göreceli yoludur ve https://wordpress.nem.ec/xmlrpc.php bu bölümün başından itibaren geri ping URL’si ile değiştirilmelidir.
curl -X POST -d @pingback.xml https://wordpress.nem.ec/xmlrpc.php
Komutu yürüttükten sonra, verilerin netcat oturumunuzda görünmesi için bir süre bekleyin. Aşağıdakine benzer bir şeye benzeyecektir:
listening on [any] 80 ...
64.225.37.249: inverse host lookup failed: Unknown host
connect to [10.0.0.2] from (UNKNOWN) [64.225.37.249] 47647
GET /some/site HTTP/1.1
Host: 10.0.0.1
User-Agent: WordPress/5.3.2; https://wordpress.nem.ec; verifying pingback from 10.0.0.1
Accept: */*
Accept-Encoding: deflate, gzip
Referer: http://10.0.0.1/hello/world
X-Pingback-Forwarded-For: 10.0.0.1
Connection: close
netcat komutundan herhangi bir çıktı alamıyorsanız, bunun birçok nedeni olabilir ve ne yazık ki hedef WordPress sunucusu size tam olarak neden başarısız olduğunu söylemeyecektir. Genel IP’nizdeki netcat oturumunuza bağlanabildiğinizi kontrol edin (örn. curl http://my.public.ip) ve erişimi engelleyen herhangi bir işletim sistemi güvenlik duvarınızın bulunmadığını.
WordPress sunucusunun IP adresini almak için netcat çıkışının ikinci satırını kontrol edin. Daha önce olduğu gibi, gizli değer 64.225.37.249.
Artık bir IP adresiniz olduğuna göre, bunun gerçekten hedefinize ait olup olmadığını nasıl kontrol edebilirsiniz? Basit bir yol, bir cURL isteği yapmak ve Sunucu başlığını, sunucunun ana bilgisayar adından geliyormuş gibi davranacak şekilde taklit etmektir.
Örnek:
curl -k -H 'wordpress.nem.ec' https://64.225.37.249
Hedef web siteniz, tek bir IP adresinde birden fazla HTTPS web sitesini çalıştırmak için Sunucu Adı Belirtimi (SNI) adı verilen bir teknik kullanan, paylaşılan bir IP ile paylaşılan barındırmada çalışıyorsa bu işe yaramayabilir. Bunu düzeltmek için cURL bir teklif sunar: --resolve
geleneksel DNS aramasını kullanmak yerine bir etki alanı adını ve bağlantı noktasını bir IP adresine açıkça eşleme argümanı. BT mutlak bağlantı noktasını ve tam alan adını ekleyin.
curl -k --resolve wordpress.nem.ec:443:64.225.37.249 https://wordpress.nem.ec
İşte bu kadar. Mutlu avlar!