Blogs
Penjelasan isu google.com.my DNS hijacking.
Salam,
Baru saja habis mengajar "DNSSEC Training" yang dianjurkan oleh syarikat saya Localhost S/B. DNSSEC adalah teknologi untuk memastikan keselamatan DNS secara menyeluruh, ia mampu menahan serangan dari "Cache poisoning", "DNS MITM dan lain-lain.
Pagi ini 11-10-2013 kita digemparkan dengan domain google.com.my telah di hijack dan ini menarik perhatian saya untuk membuat sedikit analysis. Jika anda membuka laman web google.com.my pada masa kejadian ia akan memberi content yang salah seperti contoh di bawah:
![]() Di sini ada 2 kemungkinan:
1. Data DNS telah ditukar kepada rekod lain (A, NS atau CNAME) atau
2. Server google.com.my telah diceroboh
Langkah seterusnya memeriksa data pada DNS dengan menggunakan tool DNS. Dalam langkah ini saya menggunakan dig command.
![]() Daripada data di atas kita dapat melihat cache server 8.8.8.8 (google DNS) telah memberi jawapan yang mana google.com.my telah dipetakan kepada 142.4.211.228. Kemudian kita periksa data untuk NS rekod:
![]() Ini amat mengejutkan kerana jawapan dari 8.8.8.8 (google DNS) telah memberi maklumat nameserver google.com.my seperti berikut:
sdns1.ovh.ca
ks4003824.ip-142-4-211.net
Sepatutnya google.com.my menggunakan nameserver mereka sendiri. (nameserver adalah server yang digunakan untuk menghost data DNS). Pemeriksaan diteruskan dengan menggunakan cache server lain (cth: OpenDNS - 208.67.222.222 ) dan ia memberi jawapan yang sama.
Saya beruntung kerana mempunyai akses kepada database DNS seluruh dunia. Untuk mengesahkan apa yang berlaku, saya telah menggunakan akses saya ini. Sistem ini menunjukkan perubahan setiap data pada DNS secara global (keseluruhan data DNS di dalam root(.) tree):
![]() Daripada informasi di atas, kita dapati google.com.my telah dipetakan kepada IP penggodam pada 2013-10-10 13:44:57 (UTC) dan telah dibuang dari rekod DNS pada 2013-10-10 21:51:02 (UTC). Peringatan walaupun telah dibuang, data akan berada di dalam cache DNS mengikut TTL.
![]() Seterusnya untuk data NS (name server). Data mula dilihat pada 2013-10-10 13:44:57 (UTC) dan telah dilihat kali terakhir pada 2013-10-10 21:49:37 (UTC). Data ini boleh di analysis secara detail lagi, tapi untuk penulisan ini ia sudah cukup untuk memberi hint kepada kita apakah yang telah berlaku. Di bawah adalah domain-domain yang telah dipetakan kepada IP penggodam 142.4.211.228. Di sini telah mengukuhkan lagi bahawa IP tersebut bukan kepunyaan GOOGLE.
![]() Persoalan kenapa bukan google.com? tetapi google.com.my :) dan bukan .com.my, net.my, .my, org.my? Jadi entry point boleh berlaku pada: 1. Reseller domain yang menjaga google.com.my yang menghantar data kemaskini (unauthorize update dari attacker) atau 2. Registry (kebarangkalian adalah rendah) Oleh demikian masih awal untuk membuat andaian. Jawapan punca bagaimana kejadian ini berlaku perlu dibincangkan secara berhemah, saya yakin tahap sistem keselamatan MYNIC (.my) adalah dalam keadaan baik. Sebagai rumusan, pengodam telah menukar data DNS (mungkin melalui aplikasi reseller dan kemudian dikemaskini pada MYNIC melalui EPP) kepada data yang salah (tiada server Google yang terlibat). Setiap data DNS akan disimpan di dalam DNS cache server, ini akan memberi impact kepada pengguna internet lain, kerana data salah yang disimpan di dalam cache DNS akan berada disitu untuk seketika (bergantung kepada TTL). Oleh demikian pengguna akan dipetakan kepada server penggodam dengan menggunakan data yang salah ini. Dari pemerhatian di atas ini bukan DNS cache poisoning tapi data modification di bahagian atas dan menyebabkan data yang diterima oleh cache server adalah data yang salah. Lantaran itu DNS hijacking ini mungkin melibatkan DNS cache server utama dan impactnya adalah amat besar (kerana semua pengguna akan terkesan). DNSSEC adalah salah satu cara untuk menahan data dari dilencongkan ke server penyerang (dengan syarat). TTL - Time to live (masa yang digunakan oleh cache server untuk menyimpan data DNS. Jika TTL adalah 1 hari , maka data itu akan disimpan selama satu hari) EPP - Extensible Provisioning Protocol (ialah protocol yang digunakan di antara registrar/reseller dengan registry (MYNIC) untuk berkomunikasi antara satu sama lain dalam urusan mentadbir pendaftaran/perubahan pada maklumat domain). Kemaskini: Punca perkara ini berlaku adalah dari account reseller yang telah digodam. Dari akaun reseller data telah diubah dan kemudian dikemaskini ke dalam sistem registry. Kenyataan MYNIC telah diceroboh adalah TIDAK BENAR dan kenyataan DNS cache poisoning juga agak tidak tepat. Method serangan adalah NS delegation modification in reseller apps (unauthorize modification + social engineering). Sekian, Terima Kasih. Disclaimer: This information is for educational purpose only.
Amir Haris Ahmad
Certified DNS/BIND Associates (DNS/CA), GSEC, GCIH.
|
Creating Linux Debian bootable USB
# apt-get install mtools # apt-get install syslinux # apt-get install dosfstools # modprobe usb-storage # fdisk -l /dev/sda # mkdosfs -I /dev/sda # syslinux /dev/sda # wget http://http.us.debian.org/debian/dists/stable/main/installer-i386/current/images/hd-media/boot.img.gz # zcat boot.img.gz > /dev/sda # mount /dev/sda /tmp 1. Download the netinst (Net Install) ISO image of size 150-180MB from here. # cp <image.iso> /mnt # umount /mnt Regards Amir Haris Ahmad amir@localhost.my |
Encrypting Sensitive Data With Ruby
In Encrypting Sensitive Data with Perl I wrote about how to use public key encryption to automatically and securely encrypt information with Perl. This allows you encryption things like credit card numbers, bank routing information, or that winning PowerBall number in a unattended fashion. Typically, you would use this in a situation where a user needs to enter sensitive information into a form which need to be stored in a secure manner. We can do this with Ruby (on Rails) as well, and it’s even easier. First we need to generate a key pair. This creates two keys, a public key which will only be used to encrypt data, and a private key, which will only be used to decrypt data. The private key is protected by a password know only to us. When it comes to choosing strong passwords, I suggest using Diceware. 2048 is the key size in bits. Bigger is better, but also slower; 2048 is considered a good trade off between speed and encryption strength. We are also limited by this to encrypting as most 2048 bits, more on this below.
Then we extract the public key:
Once we have the keys, we can encrypt data using the following: #!/usr/bin/env ruby require 'openssl' require 'base64' public_key_file = 'public.pem'; string = 'Hello World!'; public_key = OpenSSL::PKey::RSA.new(File.read(public_key_file)) encrypted_string = Base64.encode64(public_key.public_encrypt(string)) print encrypted_string, "\n" Simply, public_key_file is path to the file containing the public key, and string is the string to encrypt. We open the public key and then use public_encrypt to encrypt it. Because the encrypted string is binary I have converted to text using Base64. If your are storing the encrypted string in a database that can hold binary data, you could change:
to:
Now that we have encrypted data, we’ll want to be able to get it back. #!/usr/bin/env ruby require 'openssl' require 'base64' private_key_file = 'private.pem'; password = 'boost facile' encrypted_string = %Q{ qBF3gjF8iKhDh+g+TOvAzBkJA/1d2lD8RUyz2Ol+s1OpLB5aA3RA7EHm0KGL XaP3upvJ7I5rN1yO9Qat9kyRQu9OMqAUmFvwUaiW/1NPjxnpmcFn9mhkttP9 qfO6iIfyxErUqKIxHYqavyPmivre9eEcXiBdtIK6NJJKG3WmSfIFgpZ6eBWI wxlZg+x0fI4L2JsODMGx5Khn7CUt0bTkH6HMHwxEG24NbsmrqtC2zn8Hm/87 UyN5ZCDyJ/mtIHAjzPry6vbVPTF0QCR4lZ7uSt/W7JZ0tNgX7eQQwoPCgbqU /uwRCwww/c407jw7YEE5Lgpx20/jyLXJwvZHxNEcxA== } private_key = OpenSSL::PKey::RSA.new(File.read(private_key_file),password) string = private_key.private_decrypt(Base64.decode64(encrypted_string)) print string, "\n" Here private_key_file is path to the file containing the private key, password andencrypted_string is the string to decrypt. In a real application you would not want to hard-code the password, rather you should prompt for it in some way. Again we are using Base64 to make the encrypted string human readable. If this is not necessary, change:
to:
As noted above, you can not use this method to encrypt anything larger than the key size minus 11 bytes of overhead (padding). In this case we have a 2048 bit key which gives 256 – 11 = 245 bytes. The temptation is to increase the key size to accommodate more data, but this quickly become to slow to be useful. The correct way to accomplish this is to use public key encryption to encrypt random password, which, in turn is used to encrypt the data using symmetric-key encryption. I’ll cover this next time. |
[DNSSEC] The simplest way to integrate the Alea I with dnssec-keygen
The simplest way to integrate the Alea I with dnssec-keygen is to use the "randomfile" program which is provided as C source on the Alea I driver CD, and pipe its output into the standard input of the dnssec-keygen program. For example, this command will generate a 2048-bit RSA zone key for the "my" TLD: sudo randomfile -b | dnssec-keygen -r /dev/fd/0 -a RSASHA1 -b 2048 my. Here, the "-b" causes the randomfile program to output the randomness in binary form (which is what dnssec-keygen expects), and the "-r /dev/fd/0" causes dnssec-keygen to read randomness from standard input instead of /dev/random. Note that the randomfile program needs to be run as root unless you set up specific udev rules to give non-root users permission to access the Alea I USB device. amir@localhost.my |