Gündem
• 2008 Güvenlik Olayları Özeti
• Conficker virüsü
• Sahte SSL Sertifikaları
• DNS Önbellek Zehirlemesi
– Demo : İç DNS sunucu zehirleme + Java
update ile istemcilerin ele geçirilmesi
• Internet Explorer 7 XML açıklığı
– Demo : Kötü niyetli web sitesi ile istemcilerin
ele geçirilmesi

2008 güvenlik olayları özeti
• Web Tabanlı saldırılar
• Spam
• Politik çatışmaların sanal yansıması
– Gürcistan – Rusya
– Filistin – İsrail
– Tibet – Çin
• Tarayıcı açıklıkları
• Antivirüs firmalarına saldırılar
• Conficker virüsü
• Sahte SSL Sertifikaları
• DNS Önbellek Zehirlemesi
• Internet Explorer 7 (XML) açıklığı

Download:

9-2008_kritik_guvenlik-aciklari__

O Rafael Walrus fez um trabalho de documentação bem mais decente que o meu – eu fiz quase um sitrep rápido. Juro que vou editar depois melhor o post e repostar, com comentários meus. Segue o link do Walrus: http://stoa.usp.br/calsaverini/weblog/47528.html

O gosto amargo que o Walrus falou ficou bem amargo na minha boca. Quem já trabalho um pouco com segurança de redes sabe como é importante a integridade dos dados do usuário e o tempo de resposta à incidentes. O que aconteceu, pelo menos nas nossas descrições, foi um descalabro. E ou nos consideram completamente incapazes de entender sobre redes TCP/IP, e portanto fiquem quietinhos que a gente conserta nossos buracos sem vocês perceberem e danem-se se se fodem, ou tem algo que não estou conseguindo entender.

Mais tarde rola um repost.

O pessoal do CAIS respondeu hoje ao relatório do incidente de segurança, dizendo que o pessoal do Bradesco foi avisado. O site coreano também está inacessível agora. Não sei quem foi que fez o quê, mas pelo menos isso. E ainda não tenho confirmação de que o DNS do Virtua foi desligado ou consertado.

Alerta: Walrus acabou de achar um provável DNS Poisoning no DNS do Virtua 201.6.0.43. O post dele está em http://stoa.usp.br/walrus/weblog/47454.html.

Estou confirmando agora as informações usando o dig nesse DNS contra as informações do whois da RNP. Vou atualizar conforme mais informações forem chegando.

Atualmente este DNS está derrubado! – correção 22:31: ainda está de pé!!!

Edit 20:16: o DNS 201.6.0.43 está derrubado, e o outro DNS para SP, 201.6.0.113, está recusando acessos via dig.
Se você estiver no linux, teste os seus dns da seguinte forma:

dig @<nameserver> <site de banco>

assim: dig @189.7.80.15 www.bradesco.com.br

e vejam se a informação bate com a do whois brasileiro:

whois www.bradesco.com.br

Edit 20:22: esse erro continua sendo confirmado por Walrus a partir de um virtua de SP. Estamos montando os logs para enviar para a RNP
Edit 20:32: confirmado que o IP é sul-coreano, e o site é uma reprodução fiel do site do bradesco – Walrus está checando outros sites nesse DNS, eu estou tentando, mas aqui de SC está dando time out

Edit 21:40: Report de segurança foi enviado para a RNP, estou tentando entrar em contato com o SAC do Bradesco, e não tem ninguém!!!
Edit 21:44: Consegui entrar em contato com uma atendente do Bradesco. Ela anotou os dados que eu passei e disse que a equipe do internet banking funciona de segunda  a sábado (!!!). Pelo menos ela anotou, e disse que vai retornar com informações. Agora, passo de aguardo.

Edit 22:16: O Daniel sugeriu ligar para a Net. No telefone com eles agora.

Edit 22:21: O Rafael Walrus postou algo mais detalhado em http://stoa.usp.br/calsaverini/weblog/47461.html.Email para a Folha foi enviado.

Edit 22:27: a atendente da NET não consegue me transferir para alguém que saiba o que é um incidente de segurança!

Edit 22:33: A mulher do setor técnico da NET DESLIGOU na minha cara.

Edit 22:45: consegui falar com uma atendente da NET, e ela disse que este assunto está sendo verificado. Mas o Rafael ainda consegue fazer dig no DNS comprometido, e o ip errado continua lá.

Yeni hazirladigim bir egitim icin DNS Cache Poisoning acikligini test eden uygulamalari test ediyordum. Normalde dig ya da nslookup kullanarak aciklik testini gostermeye calisiyorum fakat her zaman bu ikilinin parametreleri hatirlanamiyor. Dolayisi ile bu isi web uzerinden yapan bir servis isimi oldukca kolaylastiracakti. Internette bu sekilde cesitli servisler var fakat ben IANA’ninkini tercih ettim.

Verilen servisin ne kadar saglikli ciktilar urettigini test etmek isterken aklima acaba son acikliktan sonra hala dns sunucularinda gerekli onlemleri almamis birileri var mi diye merak ettim ve sonuc gercekten korkuttu. Aralarinda  devlet/özel üniversite Turkiye’nin en hassas kurumlari, telco sirketleri , medya sirketleri ve guvenlik uzerine is yapan sirketler ve bu konuda bilincli olacagini dusundugum arkadaslarin sistemleri olmak uzere 10-15 sisteme baktim .Cogu hala gerekli onlemi almamis gorunuyordu. Buradan benim cikardigim sonuc: guvenlik isini hakettigi kadar ciddiye almadigimizdir. Ne demis atalarimiz “bir musibet bin nasihatten evladir”. Henuz bizdeki hacker tayfasinin teknik kapasitesi web sayfalarini deface etmenin uzerine cikamadigi icin simdilik musibet konusunda rahatiz fakat ilerde bu bakis acisi degisecek ve web sayfalarindan istedigini elde edemeyeneler daha komplike saldiri yontemlerine basvuracak.

Aciklik ciktiktan sonra bunu duymamis olma ihtimalimiz yok ama nedense kendi sistemimize bir bakip bu zaafiyetten etkileniyor mu kontrol etmiyoruz -edenleri tenzih ederim-. Belki usengenclik belki “adam sendecilik” ne dersek diyelim  bir yerler eksiklik kaliyor hep…

Huzeyfe ONAL

Internet’in temel protokollerinden olan DNS üzerinde çok ciddi bir açık bulunmuştur.

Son günlerde görünürlüğü, etkisi ve alınan önlemleri açısından çokça tartışılan, Dan Kaminsky tarafından bulunan DNS protokol açığı, belli başlı ürünler için çözülmüş olmasına rağmen, açıklığı suistimal edebilecek saldırı araçlarının ortaya çıkması ve hala tüm ağ ve bilgisayar markaları tarafından çözümlerin sunulmamış olmasından dolayı, daha uzunca bir süre güvenlik açısından bir sorun olmaya devam edecek gibi görünmektedir.

DNS açıklığı bundan üç yıl önce Ian Green adlı bir SANS öğrencisi tarafından farkedilmiş olsa da, Dan Kaminsky’nin açığın pratik uygulamasını farkederek yamaların yayınlandığının açıklaması 9 Temmuz 2008 tarihine, US-CERT tarafında duyurulmasıysa 7 Temmuz 2008 tarihine denk gelmektedir. Bundan takriben bir ay öncesinden beri bilinmesine rağmen açıklık gizli tutulmuş, belli başlı üreticiler çözümlerini koordineli bir şekilde oluşturana kadar herhangi bir açıklama yapılmayarak, açıklığın genel olarak suistimali ihtimali azaltılmıştır.

Internete bağlı tüm DNS sunucularının www.bilgiguvenligi.gov.tr adresinde yayınlamış olduğumuz açıklık ve saldırıyı anlatan makaleyi inceleyerek gerekli önlemlerin alınması tavsiye edilmektedir.

Son günlerde görünürlüğü, etkisi ve alınan önlemleri açısından çokça tartışılan, Dan Kaminsky tarafından bulunan DNS protokol açığı, belli başlı ürünler için çözülmüş olmasına rağmen, açıklığı suistimal edebilecek saldırı araçlarının ortaya çıkması ve hala tüm ağ ve bilgisayar markaları tarafından çözümlerin sunulmamış olmasından dolayı, daha uzunca bir süre güvenlik açısından bir sorun olmaya devam edecek gibi görünmektedir.

DNS açıklığı bundan üç yıl önce Ian Green¹ adlı bir SANS öğrencisi tarafından farkedilmiş olsa da, Dan Kaminsky’nin açığın pratik uygulamasını farkederek yamaların yayınlandığının açıklaması 9 Temmuz 2008² tarihine, US-CERT tarafından duyurulmasıysa 7 Temmuz 2008³ tarihine denk gelmektedir. Bundan takriben bir ay öncesinden beri bilinmesine rağmen açıklık gizli tutulmuş, belli başlı üreticiler çözümlerini koordineli bir şekilde oluşturana kadar herhangi bir açıklama yapılmayarak, açıklığın genel olarak suistimali ihtimali azaltılmıştır. Bu açıklığın diğer açıklıklara kıyasla farklı yöntemler kullanarak çözülmesinin en büyük nedenlerinden biri de, Internet altyapısına arz ettiği tehlikedir: “Sıfırıncı gün saldırıları”nın hemen hemen tüm DNS sunucularını etkileyeceği düşünülürse, Internet altyapısında etkili olan başlıca markalar yamalarını üretmeden açıklığın açıklanması, ancak kötü niyetli bir hareket olabilirdi.

Bu yazıda, açıklığın niteliği ve olası tesiri hakkında bilgi verilecek, örnek bir saldırı gösterilecek ve alınabilecek önlemler belirtilecektir.

Açıklığın Doğası

DNS (Domain Name System) Internet’teki alan isimlerinin (www.tubitak.gov.tr gibi) IP adreslerine (192.140.80.201 gibi) ve IP adreslerinin alan isimlerine dönüştürülmesinden sorumludur. Bu göreviyle Internet’e bağlı herhangi bir sistemin normal çalışmasında kritik bir bileşendir. DNS protokolünün tanımı ve gerçeklenmesi RFC 1035′te⁴ tanımlanmıştır.

DNS kullanılmaya başladığından beri sistemlerde en sık bulunan “önbellek zehirlenmesi”, bu yazının konusu olan DNS açıklığının da saldırdığı zayıflıktır. Önbellek zehirlenmesi, bir DNS sunucusuna yetkisiz bir kaynaktan veri yüklenmesine verilen genel isimdir. Hatalı yazılımla, yapılandırma hatalarıyla ya da DNS protokolünün açıklarıyla başarıyla iletilen özgün olmayan veri, sistem performansını artırmak için saldırılan sunucunun önbelleğine gelir ve böylece önbellek “zehirlenmiş” olur. Alan adının sunucusunun IP adresinin ya da alan adının NS kaydının yönlendirilmesine dayanan değişik yöntemlerle zehirlenme mümkündür. Bir üçüncü yöntem de, gerçek alan adı sunucusu yanıt vermeden, kötü niyetli sunucunun araya girerek yanıt vermesine dayananan, man-in-the-middle (araya girmek) türünden bir saldırıyla DNS sunucusunun önbelleğinin zehirlenmesidir. Bu tür saldırılar, sorgu yapıldığında asıl yanıt vermesi beklenen DNS sunucusundan önce saldırganın yanıt vermesi esasına dayanır.

Bir DNS mesajı, header (başlık), question(soru), answer(yanıt), authority(yetki), additional(ekler) olmak üzere beş bölümden oluşur. Bunlardan konuyla ilgili olan “header” bölümünün ilk 16 biti ID olarak isimlendirilmiş bir “nonce”⁵ olarak tanımlıdır ve sorguyu düzenleyen program tarafından doldurulan bir alandır. Bu alan, sorguya verilen yanıta da birebir kopyalanır ve böylece soru-yanıt eşleştirmesi sağlanabilir. Araya girilerek yapılan önbellek zehirlenmesi saldırıları, bu sayının tahmin edilmesine dayanır.

Önce Ian Green’in farkettiği ve Dan Kaminsky’nin farkındalığı artırarak uygulama seviyesinde çözümleri koordine ettiği açıklık, kullandığı yöntemler ve zafiyetler açısından yeni olmamasına rağmen, olası nonce’ların azlığı, sorguların kaynak kapılarının rastgele seçilmemesi ya da yetersiz rastgelelikte seçilmesi gibi durumların bir arada araştırılması sonucunda, etkili bir yöntem bulunduğunun görülmesinden sonra açıklık olarak belirlenmiştir.

Aşağıda gösterilen örnek bir saldırı sonrasında saldırılan DNS sunucusu sorgulara hatalı yanıtlar verebilir ve kullanıcıları istedikleri sunucular yerine saldırganın istediği sunuculara aktarabilir. Bunun sonucunda web trafiği, e-posta iletileri ve diğer önemli ağ üzerinden iletilen veriler saldırganın kontrolündeki sistemlere yönlendirilebilir.

Kullanılan DNS sunucusunun açıklığının bulunup bulunmadığı Dan Kaminsky’nin sayfasından (http://www.doxpara.com/) kontrol edilebilir.

Örnek Bir Saldırı

1. Saldırı öncesi keşif :

(1) 192.168.1.26 IP adresli saldırgan hedef DNS sunucu üzerinden www.ntvmsnbc.com sayfasını sorgular.

(2) DNS sunucu , www.ntvmsnbc.com alan adı kendi üzerinde olmadığı için ntvmsnbc.com alan adından sorumlu olan ns1.ntvmsnbc.com sunucusundan alan adını sorgular.

(3) ns1.ntvmsnbc.com sunucusu, www.ntvmsnbc.com alan adı için geçerli olan 88.255.82.100 IP adresini yanıt olarak hedef DNS sunucusuna döndürür.

(4) DNS sunucusu da saldırgana www.ntvmsnbc.com alan adının IP adresi olan 88.255.82.100 adresini döndürür. Burada dikkat edilmesi gereken hedef DNS sunucusunun saldırgan ile haberleşirken istek ve cevaplarda aynı kaynak portu (6134) kullanması ve tahmin edilebilir TXID (0×6749) değerini kullanmasıdır. Hedef DNS sunucusundan gelen cevabın geçerli olması için istekte bulunurken kullanılan TXID değerinin cevap kısmında da aynen dönmesi gerekmektedir.

Yapılan sorgulamanın dig çıktısı aşağıdadır  :

Bu şekilde DNS sunucuda açık olduğu tespit edildikten sonra asıl saldırıya geçiyoruz.

2. Saldırı

Saldırı 3 adımda gerçekleştirilecektir.

2.1 Birinci aşamada saldırgan hedef DNS sunucuya ntvmsnbc.com alan adına ait bir çok alt alan ismi (abc1.ntvmsnbc.com , abc2.ntvmsnbc.com ….. xyz9832.ntvmsnbc.com ) için DNS sorgusu göndermektedir. Burada amaç hedef sunucunun ntvmsnbc.com alan adı için yetkişi sunucuya birçok sorguda bulunmasını sağlamaktır.

2.2 İkinci aşamada hedef DNS sunucu tüm alt alan isimleri için ns1.ntvmsnbc.com sunucusuna istekte bulunmaktadır. Ns1.ntvmsnbc.com sunucusu da tüm alanlar için geri cevaplarda bulunmaktadır. Fakat aynı zamanda saldırgan da hedef DNS sunucuya sanki ns1.ntvmsnbc.com sunucusundan geliyormuş gibi cevaplar göndermektedir. Bu cevaplarda www.ntvmsnbc.com alan adı için IP adresini kendisi göstermektedir ve her seferinde TXID alanını arttırarak tahmin etmeye çalışmaktadır.

Nihayet abc4.ntvmsnbc.com alan adı için saldırganın gönderdiği cevap paketlerinde TXID alanı tahmin edilmekte ve hedef DNS sunucu bu cevabın gerçek ns1.ntvmsnbc.com sunucusundan geldiğini Kabul etmektedir. Bu sayede saldırgan hedef DNS sunucusunun belleğini zehirlemiş oluyor.

2.3 Üçüncü adımda kurban zehirlenen DNS sunucuna www.ntvmsnbc.com adresini sorgulamaktadır (1) . DNS sunucu da önbelleğinde www.ntvmsnbc.com adresine ait kayıt olduğu için gerçek ns1.ntvmsnbc.com sunucusuna sormadan zehirlenmiş önbelleğindeki 192.168.1.26 adresini cevap olarak vermektedir (2) . Bu durumdan habersiz kurban gerçek www.ntvmsnbc.com sayfası yerine saldırganın oluşturduğu tuzak sayfayı ziyaret etmektedir. (3)

Saldırı yapıldıktan sonraki dig çıktısı aşağıdadır.

Tedbirler

Sistemlerin Yamanması

Sistemlerde recursive(özyinelemeli) DNS sunucularının hepsinin yamanması gerekmektedir. http://www.bilgiguvenligi.gov.tr/index.php?option=com_content&task=view&id=277&Itemid=16 adresindeki TR-CERT ve http://www.kb.cert.org/vuls/id/800113 adresindeki US-CERT uyarısında etkilenen sistemler, yamaların mevcut olup olmadığı ve nasıl edinileceği üzerine bilgi bulunmaktadır. Başta ADSL modem, access point cihazları gibi gömülü sistemlerde güncellemenin donanımca mümkün olmaması ya da güncelleme imkanının bulunmaması ve bazı markaların henüz sorunun çözümünde adım atmamasından dolayı, yamanın mümkün olmadığı durumlarda, aşağıda belirtilen önlemlerin uygulanabilirliği gözden geçirilmelidir.

Erişimin Engellenmesi

Yamaların uygulanamadığı durumlarda, sunuculara özyinelemeli sorgu yapacak sistemler sınırlandırılarak saldırı kaynakları azaltılabilir. Fakat bu türden bir önlemden sonra bile sorgulamaya izni olan sistemlere erişimi olan saldırganlar açıklığı kullanarak önbellek zehirlemesi saldırısı yapabilirler.

Trafiğin Filtrelenmesi

Saldırının gerçekleşmesi için IP spoofing (aldatma) tekniği kullanılması gerektiğinden, sahte IP adreslerinin filtrelenmesi gerekmektedir. Filtrelemenin ayrıntıları için önerilebilecek RFC belgeleri aşağıdadır:

1. http://tools.ietf.org/html/rfc2827 – RFC2827
2. http://tools.ietf.org/html/rfc3704 – RFC3704
3. http://tools.ietf.org/html/rfc3013 – RFC3013

Yerel DNS Önbelleği Kullanılması

Erişimin ve trafiğin engellenmesi gibi önlemlerle birlikte, hem istemci hem de sunucu tarafında yerel önbellekler kullanılarak, Internet üzerindeki açıklığı olan sunuculara yapılan saldırılardan yerel ağdaki kullanıcıların en az düzeyde etkilenmesi sağlanmalıdır.

Özyinelemenin Kapatılması

Güvenilmeyen sistemlerden gelen, özyineleme gerektiren sorgular engellenmelidir.

NAT/PAT Uygulanması

Port Address Translation (Kapı adresi tercümesi) uygulayan cihazlar genellikle bağlantı durumunu izleyebilmek için kaynak kapı adreslerini değiştirirler. NAT/PAT uygulamasında kullanılan bazı gömülü cihazlar, saldırıya karşı önerilen kaynak kapısının rastgeleliğinin uygulama tarafında artırılmasıyla kazanılan korumayı, kapı adreslerini yeniden ve daha etkisiz bir şekilde değiştirerek azaltabilir. Bu yüzden ağ üzerindeki NAT/PAT uygulamaları gözden geçirilmelidir.

Buna rağmen, uygun bir NAT uygulaması, rastgele kapı atanmasını sağlayabilir ve yamanmamış DNS sunucuları için de bir çözüm oluşturabilir. Iptables kullanarak önerilen bir çözüm http://cipherdyne.org/blog/2008/07/mitigating-dns-cache-poisoning-attacks-with-iptables.html adresinde bulunabilir. OpendBSD PF kullanılarak önerilen bir çözüm de http://blog.spoofed.org/2008/07/mitigating-dns-cache-poisoning-with-pf.html adresinde bulunabilir.

DNS trafiğinin başka bir sunucuya yönlendirilmesi

DNS açıklık bulunan sunucular yamanamıyorsa tüm sorguları yamaları uygulanmış ve açıklıkları kapatılmış başka bir sunucuya yönlendirilmesi sağlanabilir. Yaygın kullanılan Microsoft DNS ve BIND sunucuları için bu işlemin nasıl yapılacağı aşağıdaki adreslerden bakılabilir :

http://www.isc.org/index.pl?/sw/bind/docs/forwarding.php

http://technet2.microsoft.com/windowsserver/en/library/ee992253-235e-4fd4-b4da-7e57e70ad3821033.mspx?mfr=true

DNSSEC kullanımı

DNS tarafından sunulan bilgilerin güvenli hale getirilmesi için, DNS verisinin kaynağını doğrulayan, ve veri bütünlüğünü sağlayan genişletmeler içeren DNSSEC, bu ve benzeri saldırılara karşı en etkili çözüm olarak görülmekle birlikte, henüz bir standart olarak yaygınlaşmamıştır. Buna rağmen, DNSSEC kullanan iki ağ arasında güvenli veri paylaşımının ve olası saldırıların önüne geçilmesi mümkündür. DNSSEC uzantıları hakkında daha geniş bilgiye http://www.dnssec.net/ adresinden ulaşılabilir.

Sonuç

Internetin sağlıklı çalışması için kritik protokollerden olan DNS in uygulanmasında çok ciddi bir açıklık bulunmuştur. Bu açıklık sayesinde recursive(özyinelemeli) özelliği bulunan DNS sunucular önbellek zehirlenmesi saldırısına maruz kalabilmektedir. Bu açıklığı kullanan araçların da ortaya çıkması ile durum daha da ciddi bir hal almıştır. Başarılı bir saldırı sonrasında bu DNS sunucuları kullanan kurbanlar istekte bulundukları sayfalar yerine saldırganların belirlemiş olduğu sayfalara yönlendirilebilmektedirler. Açıklık kapatılması için yaygın yazılım üreticileri tarafından çıkartılan yamaların uygulanması tavsiye edilmektedir. Yamalar uygulanamiyorsa veya yama mevcut değilse bu sunuculara erişimin kısıtlanması , yerel (internetten doğrudan ulaşılamayan ) DNS önbelleğinin kullanılması , DNS sunucuları önüne saldırıyı kesebilecek Linux Iptables veya OpenBSD PF yerleştirilmesi veya tüm trafiğin yamanmış, açıklığı olmayan bir sunucuya yönlendirilmesi tavsiye edilmektedir.

A variant of the DNSChanger worm is reported to use DNS poisoning to infect new machines on a network, according to a well explained article from the The Register[1]. The attack used is quite interesting, but far from being new mind you.

The first strains of the DNSChanger worm infected Windows and Mac machines. It modified and would modify the internal settings of the OS by changing the Primary and Secondary DNS address property in the “Internet Protocol” settings of the network card. It also used to change the HOSTS file to map specific domains to malicious IP address[2].This time, the variants try to bypass the DNS addresses used by ADSL modems used by home networks. Here are the mechanics of the attack:

First, one needs to set up a fake website by ripping a legitimate one and doing a mirror copy of it. Legitimate sites usually copied are banks, MMORPGs, online retailers or social network websites. Multiple tools are available on the net to download entire websites page to page. Once an attacker has a copy of the website, it needs to upload it to an illegimate web server. It can either be use a free one offered by various providers or by criminal hosting companies. It can also easily set up one using open source software such as Apache.

Up to this point, the attacker has a web server hosting a copy of a legitimate website, but it has two major flaws. If someone was to navigate to this website, it would see that:

1)      The address bar would show either some IP address or a fake name server. For example, by clicking a link to go on the Royal Bank of Canada, the address bar of the browser could display something like: http://68.16.48.145 or http://rbcbank.dyndns.org instead of http://www.rbc.com.

2)      The communications would be unencrypted (the address bar would still be white, while it should be yellow)

An attacker won’t encrypt the communications, since the main goal is to steal the username and password. If it’s encrypted, it’s going to take a lot more time and effort and might never be able to guess the credentials. However, it might solve the first problem mentioned by “poisoning” a DNS server. Usually, DNS servers contain tables that link domain names to IP addresses. For example:

An attacker can set up a DNS server, or hack into one by exploiting some vulnerability and change those tables so that a name can link to another IP address, most of the time, to the fake website created by the attacker:

With this type of attack, the victim doesn’t have to click on a fake link or be persuade to type a fake address, it just have to type the legitimate domain and the malicious site will be returned. Here is a schema of the usual way to surf on the net:

Standard IP address request to the sain DNS server

Poisoned DNS server delivers the attacker's server IP address

As you may have guess, this is a typical phishing attack. This is basically how the DNSChanger worm works.

Once it gets install on a machine, the worm will install NDISProt, a driver for reading and sending raw Ethernet frames. It will do so by create the legitimate %System%\drivers\ndisprot.sys file and the following Registry entries[3]:

• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\Root\LEGACY_NDISPROT\”NextInstance” = “1″
• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\Root\LEGACY_NDISPROT000\”Service” = “Ndisprot”
• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\Root\LEGACY_NDISPROT000\”Legacy” = “1″
• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\Root\LEGACY_NDISPROT000\”ConfigFlags” = “0″
• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\Root\LEGACY_NDISPROT000\”Class” = “LegacyDriver”
• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\Root\LEGACY_NDISPROT000\”ClassGUID” = “{8ECC055D-047F-11D1-A537-0000F8753ED1}”
• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\Root\LEGACY_NDISPROT000\”DeviceDesc” = “ArcNet NDIS Protocol Driver”
• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\Root\LEGACY_NDISPROT000\Control\”*NewlyCreated*” = “0″
• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\Root\LEGACY_NDISPROT000\Control\”ActiveService” = “Ndisprot”
• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Ndisprot\Enum\”Count” = “1″
• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Ndisprot\Enum\”NextInstance” = “1″
• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Ndisprot\TimestampMode” = “0″
• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Ndisprot\”Type” = “1″
• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Ndisprot\”Start” = “3″
• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Ndisprot\”ErrorControl” = “1″

With this, the worm will fake a DHCP server on ports 67 and 68[4] and listen for DHCP DISCOVERY request send by a computer that needs an IP address in order to connect to the network. Once it catches one, it will reply with a fake DHCP OFFER, containing the poisoned DNS servers’ addresses.

Fake DCHP OFFER Packet sent by DNSChanger

This is a tricky part for the worm, because it has to reply quicker to the request than the real DHCP server. Otherwise, the victim will receive the legitimate addresses and the worm will have to wait for the IP address lease to expire before the client asks for another request. So I guess it would be intelligent for the worm to set a very long lease period so that the client won’t make too many requests…

If the client receives the crafted DHCP OFFER, then all the DNS requests will be sent through the poisoned DNS servers. In the example above, those servers are 85.255.112.36 and 85.255.112.41 [5]. Those will then intercept request to banks and other sites the authors of DNSChanger set in these DNS servers and return the fake site, where passwords entered by the victim will be stolen.

[2] “DNSChanger Trojans v4.0″, Craig Schmugar, McAfee Avert Labs Blog, December 4, 2008, http://www.avertlabs.com/research/blog/index.php/2008/12/04/dnschanger-trojans-v40/ (accessed on December 8, 2008)

[3] “Trojan.Flush.M”, Raimondo Chiodi, Elia Florio, Symantec, December 4, 2008, http://www.symantec.com/security_response/writeup.jsp?docid=2008-120318-5914-99&tabid=2 (accessed on December 8, 2008)

[4] Ibid.

[5] “Rogue DHCP servers”, Bojan Zdrnja , SANS Internet Storm Center, December 4, 2008, http://isc.sans.org/diary.html?storyid=5434 (accessed on December 8, 2008)

DNS Refers to Domain Name Systems or Domain name Service, which basically resolves domain name into its equivalent IP address.
When ever you type a valid URL in the browser, it will first look for primary DNS which is in the same box, if it fail then it will try to communicate with the seconaday DNS servers on the internet, once it finds the right match then it resolves the human readable Domain name or FQDM ( Fully Qualified Domain Name ) into its equivalent IP adress that can be easily understood by machines and also updates the same in the primary DNS so that the next time, there is no need to contact the secondary DNS.

Here is a trick that you can use for DNS Poisoning in Widnows Boxes.

just move on the following location

C:\WINDOWS\system32\drivers\etc\hosts

a dialog box prompts to choose open with, select notepad and open it up, then it will display a window like below….

On the last line you can see something like

127.0.0.1       localhost

Here 127.0.0.1 is the loopback dotted deciaml IP address, and localhost is its equivalent human readable domain name. So what happens once you type \\localhost in the URL box of the internet explorer or any browser? It will contact the DNS which is actually the host file, then it will open up the locahost window, instead you can type \\127.0.0.1 in the URL box, which does the same opertaion.

Here comes the trick where you can use this to poison DNS and redirect the victims to some other website. So, lemme make it clear that if a user types www.google.com in the browser, then they will be redirected to www.yahoo.com

Once you opened up the hosts file, just obtain the IP address of the yahoo just by pinging or nslookup, then copy and paste the IP address of www.google.com in the hosts file that you recently have opened with a notepad, make sure that you are pasting it in a new line, then leave a space (CRLF – Carriage Return Line Feed) and type www.yahoo.com, then close the hosts file, it will prompt you to save the changes, you have to save it. Now restart your browser and type www.yahoo.com in the URL, now you will be re-directed to www.google.com and you are done now!

By using DNS poisoning, anyone can launch a phishing attack, and re-direct to any malicious websites to create havoc.

// This is Meant for Educational Means alone. technocrawl and its members are not responsible for what ever you do using this.

The latest issue of the free digital security publication is out and includes some thought provoking articles:

• Browser security: bolt it on, then build it in by Jeremiah Grossman
• Windows driver vulnerabilities: the METHOD_NEITHER odyssey by Anibal Sacco
• Insecurities in privacy protection software by Shrikant Raman
• Compliance does not equal security but it’s a good start by Jack Danahy

This issue also includes my column which talks about why the latest happenings in the security industry should shake us to our senses. The idea is that we need to realize that some of the Internet technologies that we rely on have fundamental flaws.

Here’s a download link.

I’m continually seeing scare stories–from around the world, for that matter, as far as those translated to English–about various traps being used.  There’s the DNS flaw (it’s been around for a long time, with evidently no known way to actually fix it) and a new kind of visual file that isn’t static (from what I gather); it’s a movie.  I would expect that latter especially to especially be at the porn sites right now; sorry, guys.  I’m assuming there won’t be too much protest about sexually-based assumptions.  Oddly enough, I should add don’t click on any links unless you’re absolutely sure.  (Good luck.)

Moving to Linux isn’t a solution in any way, and I won’t even ever migrate wholly to it.  I might go into why it’s not anything approaching a solution at some other time…

–Glenn

Surprisingly enough, PC World has come up with a solution to DNS poisoning:  USE OPEN DNS.  Heck, I even said so; there was even a post where I intimated the relative intelligence, unfortunately, of not using Open DNS.  If you use a router (my older Belkin, with three computers, two different operating systems–two out-of-the-box and one made-to-spec locally (a mistake)–etc. wasn’t going to accept it without a whole system tweak), try to set up your router with it, although it isn’t all-important.  The more randomization of your address and path you use, the better.  I’ve even gone back to an actual hidden mode, which I haven’t done since the first days of the public internet.  If you have essential information, back it up offline.  Briefly what I mean by that is one of two things, with the latter possibly the more reasonable; either write it on a disk (CD/DVD) or else write it to something like a USB hard drive and only use said external drive for backups.

And there is absolutely no certain cure except hard copy or ROM discs.  That is the “white line” mechanism that I’ve discussed, and actually doesn’t apply to any kind of electromagnetic reading except to something like Notepad ++ where it’s a character-only transition, with no exec’s (*.exe files) able to cross the line.  The discussion of solutions is becoming very high level.  The military solution in the 70s in a barely similar situation was to use a mutual one-time code at both ends, essentially a “book code”.  The problem here is, someone else may have the dam’ book.  Okay.  I couldn’t find it on two pages of Google.  I have a book, you do–seems like this may have been touched on in Da Vinci Code.  I reference page, line, and word (by whatever system; remember you can also count characters); you take my references (ideally alphanumeric, with obscuring characters, designed to obfuscate the nature of the code) to an identical copy of the book it is…and reconstruct what I’m saying.  I’m nearly certain EAP (no, my friends of online shorthand, I won’t decode that) referenced it in a cryptographic study in one of his shorts (quoth the raven).

A one-time is a shared book used to encode/decode one message and then destroyed, and is close to fool-proof depending on distribution of the book and the method.  What I mean is that your data can be read and decrypted in real time almost without doubt.  Bear in mind that a book code must use words not letters, although phonetic transliteration might barely be possible.  True randomization is not possible with state of the art, although I believe the model could be constructed on primes; I am not going that way.  I’m 55 in a couple of months, and I don’t have time to study that too.

Hopefully I’ve scared and confused the stubborn ones.  The easiest solution (not foolproof, but it takes you from bright orange to camouflage) is Open DNS.  It’s easy to use for one IP address (you don’t have to use it on your home router).  It will help protect you from phishing–going to your bank, for instance, and entering in information…only it wasn’t actually your bank.

–Glenn

P.S.  I deployed Open DNS a couple of years ago, as I recall…

I’m going to go into the DNS thing in a bit more detail later, probably.  DNS is a Domain Name Server.  As I recall–being senile, I’m probably wrong [I'm not] you had to type in the whole thing, http[s]:/ etc. and at least sometimes actual IPs.  If you go to Open DNS you’ll see an example.  You don’t have to set up your router, if you have one.  The internet actually “sees” your router as one IP address.  This is an added layer of (trusted) protection named at the Black Hat Conference.  That’s not fedoras, it’s hackers.  So I hear, never having known how to program.  Here’s one of Erik Larkin’s comments on lines of protection: “5. Your fix-it options: Apply the patch for your particular DNS server.  Or switch to a protected service like Open DNS where you use their servers.”  [If you don’t use a router, then your Internet Service Provider is the source of your servers…which pretty much means you actually just use their servers.  Nor have any of the providers been particularly speedy or adept at applying any fixes.  That may–not that I sympathize in the least–have been because the management felt overwhelmed and unable to dedicate enough tech support time.  If I were daring, I’d say it was actually mainly because they didn’t give a damn, but I believe in, well, everything.  It’s why I’m so cheerful.  Note that I linked to Erik’s article twice, because it’s nearly a must-read for anyone who uses the internet, especially for businesses.  It’s serious, and it’s a simple fix.

–Glenn

====================================================================
title: MITM vs Cryptography Protocol ??
post author: kernellicious
date posted: August, 04th 2008
posted in: News
====================================================================

Menurut aye, isu MITM adalah termasuk yang sukar ditangani (hehehheh… ngemeng doang neh).

Ngelandjutin dari postingan aye yang sebelumnya, aye jadi ngebahasa lagi isu ini.

Oke guys, ada beberapa faktor penting (yang aye tau) untuk secure connection:
1. algoritma engkripsi asimetris
2. algoritma enkripsi simetris
3. algoritma ttd digital
4. name server

okeh, untuk algoritma asimetris, kita bisa bilang ini sangat bisa diandalkan kalo doi pake RSA 1024bit atau lebih. Atau mungkin pake ECC (Elliptic Curve Cryptography). Atau algoritma asimetris lainnya.

untuk algoritma enkripsi simetris, kita bisa percaya pada AES (Rijndael atau bahkan Twofish), untuk saat ini. Dan bukan tidak mungkin para Guru kriptografi ini merancang suatu backdoor matematis pada algoritma AES mereka.

untuk faktor algoritma tanda tangan digital, ada yang pake hash atau DSA (Digital Signature Algorithm).
Lebih baik kesampingkan MD2, MD5 (yang jelas2 dah bisa direverse), SHA1, SHA3, dan hanya gunakan algoritma MAC atau algoritma one-way-hash lain yang lebih baik. IDEA??? hmmmm…. I really got to learn more..!!

dan bila ketiga faktor awal tersebut telah dapat sangat diandalkan, maka yang harus diperhatikan adalah keamanan dari sisi DNS Cache. Seperti yang diberitakan di situs KKI (Komunitas Keamanan Informasi), DNS cache poisoning vulnerability masih banyak yang punya.

hufffhh & waw!!!

security is a never ending process.
i lovin it!!

=======================================================================

./lovetoshares

Today, a customer emails us asking if he should be worried about a recent Critical Internet Flaw

He is worried that it is some kind of virus or worm that might be already in his laptop. I assure him that it is not a common exploit and that we, as end-users, should not be the most worried. It is in fact the ISPs and hosting services provider that should be on the lookout and patch up their servers against attacks. What the flaw is capable of doing is it is able, in layman terms, to fool the computer to redirect you to a another website or page even though the url on your address bar is correct.

This is worrying if you do a lot of banking through internet and could open up your bank accounts and passwords to the wrong hands. However, banking accounts that require secondary logins like e.g. mobile phone sms or token IDs should be safe as these illegitimate sites are not capable of generating IDs.

If you are worried about such attacks, there is a possible short term fix for this but only works if the ISPs are not already being attacked in the first place. You can go to “Start->Run” and type “ipconfig /flushdns” without the quotes. This command will clear out any dns entries(entries use to identify websites) including any poisoned entries from your computer DNS cache store. After that make sure you delete your caches and cookies from your web browsers and you should be good to go.

For the techies out there, you can get more details and updates from this site DoxPara

[QUESTION:]

Ngga berapa lama, saat kernee sedang mendevelop (dengan susah payah ngoprek logaritma diskrit, karena kernee bukan seorang jenius) suatu sistem cryptography yang disebut Hybrid Cryptosystem. Kernee menyadari bahwa adanya kelemahan pada protokol autentikasi yang dipakai (apa hybrid cryptosystem pake otentikasi?? hheehehhehehhh.. lupa lagi!!).

Sistem yang kernee develop dalam rupa software ini masih sangat rawan terhadap serangan MITM (Man In The Middle). Kenapa??

Karena saat A ingin bertukar kunci dengan B, maka mereka haruslah saling mengotentikasi satu sama lain. Tetapi bisa saja terdapat oknum C yang telah menyadap komunikasi mereka dari awal, lalu saat mereka akan mulai otentikasi, maka C akan mengaku sebagai A terhadap B. Dan C juga akan mengaku sebagai B terhadap A. Lalu, C terus menerus menjadi seorang penyamar ulung di tengah-tengah mereka.

Nah, pertanyaan kernie bukanlah tentang kekuatan algoritma enkripsi simetri ataupun asimetri, dan bukan pula terhadap keintegritasan Hash yang dimiliki oleh server (walaupun sekarang telah ada cara untuk me-reverse hash MD5 menjadi plainteks semula).

[Terlepas dari pembahasan tentang software yang kernie develop]

Pertanyaan kernee lebih kepada yang terjadi pada protokol SSL, sesaat sebelum autentikasi tersebut dimulai.

1. Bagaimana cara server ‘yakin’ bahwa client adalah client yang asli, sedangkan semua data yang dikirim client adalah berupa plainteks (tak teramankan) dan melalui jaringan publik, yang intinya semua orang masih bisa menyadap, melihat dan memodifikasi data dari client.

2. (Yang ini adalah versi ekstrimnya) Dan bagaimana cara client ‘yakin’ bahwa server adalah server yang asli, dan bukan ’server’ palsu?? Sedangkan para penyadap dapat melakukan berbagai hal agar tanda tangan digital yang penyadap keluarkan adalah tanda tangan digital yang sama persis dengan yang dimiliki oleh server yang asli.

Inilah yang bikin kernee penasaran (tanpa punya cukup niat & usaha untuk mencari jawabannya).

Dan pada saat kernie membaca-baca di wikipedia, kernie nemu bahwa untuk meng-counter serangan ini adalah dengan cara membandingkan data DNS (yang biasanya terdapat di dalam sertifikat A.K.A tandatangan dgital) dengan hasil dari DNS resolve. Hal ini dapat dikatakan aman jika public key tidak dapat di-sub-versi dan DNS doi tidak sedang diracuni.

Tapi, jika pada sesaat sebelumnya sudah dilakukan DNS poisoning dan CA (Certificate Authority) telah di-sub-versi dengan sukses..??

Bagaimana solusinya??

*still searching for an answer(s)..*

——————————————-

(^-Q) #4

kernellicious.