Minggu, 25 Maret 2012

INTERNET CONTROL MESSAGE PROTOCOL (ICMP)


INTERNET CONTROL MESSAGE PROTOCOL (ICMP)

Dalam suatu sistem connectionless setiap gateway akan melakukan pengiriman, perutean datagram yang dating tanpa adanya koordinasi dengan pengirim pertama. Tidak semua sistem berjalan dengan lancar. Kegagalan dapat saja terjadi. misalnya line komunikasi, prosesor atau dikarenakan mesin tujuan tidak sedang aktif, ttl dari counter habis, atau ketika terjadi kemacetan sehingga gateway tidak lagi bisa memproses paket yang datang. Dalam koneksi dengan internet pengirim tidak dapat memberitahukan & tidak tahu sebab kegagalan suatu koneksi. Untuk mengatasinya diperlukan suatu metode yang mengijinkan gateway melaporkan error atau menyediakan informasi mengenai kejadian yang tidak diinginkan sehingga dipakai mekanisme ICMP. Pesan ICMP merupakan bagian dari datagram IP. Tujuan akhir dari suatu pesan ICMP bukan merupakan program atau user melainkan software internet-nya. Ketika pesan ICMP hadir software ICMP akan menanganinya.
ICMP mengijinkan gateway untuk mengirim pesan error ke gateway lain atau host. ICMP menyediakan komunikasi antar software protocol Internet. Pada dasarnya terdapat dua macam pesan ICMP : ICMP Error Message & ICMP Query Message. ICMP error message digunakan pada saat terjadi kesalahan pada jaringan, sedangkan query message adalah jenis pesan yang dihasilkan oleh protokol ICMP jika pengirim paket menginginkan informasi tertentu yang berkaitan dengan kondisi jaringan.
:arrow:Error & Query Reporting
Secara teknis ICMP adalam mekanisme error reporting untuk gateway sehingga dapat memberitahu sumber mengenai kesalahan yang terjadi. Sedangkan untuk koreksinya diserahkan pada program aplikasi yang ada pada pengirim. Pesan ICMP ini selalu dikirimkan kepada gateway awal. Jika suatu datagram yang melewati beberapa gateway mengalami kegagalan & kesalahan tujuan di intermediategatewaynya maka tidak dapat dideteksi gateway mana yang gagal tersebut. Ada beberapa jenis pesan error diantaranya :
- destination unreachable
pesan ini dihasilkan oleh router jika pengiriman paket mengalami kegagalan akibat masalah putusnya jalur, baik fisik maupun lojik. Pesan ini dapat dibagi menjadi beberapa tipe:
o network unreachable
jika jaringan tujuan tidak dapat dihubungi
o host unreachable
jika host tujuan tidak bisa dihubungi
o protocol at destination is unreachable
jika di tujuan tidak tersedia protokol tersebut
o port is unreachable
jika tidak ada port yang dimaksud pada tujuan
o destination network is unknown
jika network tujuan tidak diketahui
o destination host is unknown
jika host tujuan tidak diketahui
- time exceeded
dikirimkan jika is field TTL dalam paket IP sudah habis masa aktifnya dan paket belum juga sampai ke tujuannya
- parameter problem
pesan ini dikirim jika terjadi kesalahan parameter pada header paket IP
- source quench
jika router atau tujuan mengalami kemacetan, sebagai respon terhadap pesan ini maka pihak penerima harus memperlambat pengiriman paket
- redirect
dikirimkan jika router merasa host mengirimkan paket IP melalui router yang salah.
Sedangkan untuk pesan query diantarannya adalah :
- Echo & Echo Reply
Bertujuan untuk memeriksa apakah sistem tujuan dalam keadaan aktif. Program ping merupakan program pengiriman paket ini. Responder harus mengembalikan data yang sama dengan data yang dikirimkan
- Timestamp & Timestamp Reply
menghasilkan informasi waktu yang diperlukan sistem tujuan untuk memproses suatu paket
- Address Mask
Untuk mengetahui berapa netmask yang harus digunakan oleh suatu host dalam suatu network.
:arrow:Pengiriman ICMP Message
ICMP memerlukan dua level enkapsulasi seperti pada gambar dibawah ini

Setiap pesan ICMP merupakan bagian dari datagram IP yang juga merupakan bagain dari suatu frame data. Datagram yang membawa pesan ICMP mendapat perlakuan yang sama
dengan datagram lain dalam hal reliability & priority-nya. Pengecualian prioritas didapat untuk menghindari masalah : mendapat pesan error mengenai pesan error. Prioritas tersebut menentukan bahwa pesan tidak dibangkitkan untuk error yang disebabkan oleh datagram yang membawa pesan error.
:arrow:Format Pesan ICMP
Format diawali dengan 3 field :
8 bit     : field TYPE yang mengidentfikasikan pesan
8 bit     : field CODE yang menyediakan informasi lebih jauh tentang tipe pesan
16 bit   : field CHECKSUM untuk pengecekkan pesan ICMP
ICMP yang berisi pesan error terdiri dari header dan 64 bit pertamanya berisi penyebab error yang terjadi. Type field yang ada :

Beberapa waktu yang lalu saya menemukan sebuah website dengan vulnerability SQL injection. Sengaja nama website tersebut tidak saya publikasikan, karena artikel ini bukan tentang SQL injection melainkan bagaimana memecahkan enkripsi.
Berbeda dengan website lainnya, website tersebut menyimpan password dalam tabel user tidak dalam bentuk one-way hash (contohnya MD5 atau SHA1), melainkan dalam bentuk ter-enkripsi. Enkripsi yang dipakai juga unik karena tidak memakai algoritma enkripsi yang sudah dikenal luas.
Dalam kasus tersebut saya ingin melakukan privilege-escalation dari user dengan hak akses biasa menjadi user dengan hak akses penuh. Sebagai user biasa saya bisa melakukan SQLinjection untuk membaca username dan password dari tabel user. Dengan teknik tersebut saya mendapatkan encrypted password dari seorang user yang memiliki hak admin. Namun saya tidak bisa memakai password itu untuk menjadi admin sebelum saya mengerti pesan tersembunyi dalam chiphertext tersebut.
Analisa Ciphertext
Saya mencoba menggali informasi lebih dalam lagi tentang enkripsi unik di website tersebut. Saya mulai mengumpulkan banyak ciphertext dari user-user lainnya. Berikut beberapa ciphertext yang saya kumpulkan:
  • 804881451156416021528145
  • 9436353935332546555225378546953924846491
  • 11763273927622732276427712808233523172328227
Ada beberapa poin penting yang saya dapatkan dari pengumpulan ciphertext tersebut:
  • Panjang ciphertext bervariasi
Panjang ciphertext yang bervariasi membuat saya yakin bahwa itu bukan fungsi hash, karena ciri khas fungsi hash adalah panjang hash yang selalu tetap. Panjang ciphertext yang bervariasi kemungkinan besar tergantung dari panjang atau pendeknya password user tersebut. Nanti saya akan coba konfirmasi hipotesa ini dengan mengubah password user biasa yang saya pakai.
  • Ciphertext hanya terdiri dari angka
Ciphertext yang semua berupa angka membuat saya curiga bahwa ini adalah kode, semacam kode ASCII namun sudah dikalkulasi dengan formula matematis tertentu.
Chosen-Plaintext Attack
Chosen-Plaintext attack adalah salah satu cara “code breaking” (cryptanalysis) dengan cara membandingkan dan menganalisa contoh plaintext dan ciphertextnya. Dalam chosen plaintext attack, code breaker memiliki kebebasan untuk menentukan plaintext yang diiginkannya.
Untuk mendapatkan contoh plaintext dan ciphertextnya, saya melakukan langkah berikut ini setelah login sebagai seorang user biasa:
  1. Ubah Password
  2. Lihat ciphertext dari tabel user dengan SQLinjection
Pertama saya ubah password menjadi ‘d’, kemudian saya lihat ciphertext untuk plaintext ‘d’. Saya ulangi langkah itu dengan contoh plaintext yang lain berkali-kali.
Apa saja plaintext yang saya pilih? Berikut chosen-plaintext dan ciphertextnya yang saya pilih:
Plaintext
Ciphertext
d
92254325
dd
831214121412
ddd
6180128012807280
dddd
15013601660186017601
abcd1234
433034273428242944308379538023819382
Perhatikan bahwa panjang ciphertext tergantung dari panjang plaintext.  Plaintext sepanjang 1 karakter, ciphertext panjangnya 8 digit. Setiap penambahan satu karakter plaintext, ciphertext bertambah 4 digit.
Saya sengaja memilih plaintext berurutan (d,dd,ddd,dddd) untuk melihat apa ada pola yang muncul. Perhatikan pada plaintext “dd”, ciphertextnya adalah 831214121412, terlihat pola berulang pada angka 412 sebanyak 2x. Dalam ciphertext ini saya menyimpulkan bahwa 412 adalah kode untuk karakter ‘d’.
Untuk plaintext “ddd”, ciphertextnya adalah 6180128012807280, terlihat pola berulang pada angka 280 sebanyak 3 kali. Dalam ciphertext ini saya menyimpulkan bahwa 280 adalah kode untuk karakter ‘d’.
Begitu juga pada plaintext “dddd”, ciphertextnya adalah 15013601660186017601, dengan pola berulang pada angka 601 sebanyak 4 kali. Dalam ciphertext ini, saya menyimpulkan bahwa 601 adalah kode untuk karakter ‘d’.
Ingat bahwa untuk setiap penambahan satu karakter plaintext membuat ciphertext bertambah 4 digit. Ternyata 4 digit tersebut adalah satu digit apapun diikuti dengan 3 digit kode karakter. Chosen plaintext dalam contoh sebelumnya saya pecah-pecah menjadi kelompok 4 digit dipisahkan dengan karakter ‘#’ dan dari 4 digit tersebut saya pecah dua menjadi 1 digit dan 3 digit dengan karakter ‘-’.
Plaintext
Ciphertext
Kode
d
9-225#4-325
325 = ‘d’
dd
8-312#1-412#1-412
412 = ‘d’
ddd
6-180#1-280#1-280#7-280
280 = ‘d’
dddd
1-501#3-601#6-601#8-601#7-601
601 = ‘d’
Oke sampai disini saya sudah mendapatkan titik terang. Saya sudah mengetahui komposisi dan posisi tiap karakter pada plaintext ketika dipetakan pada ciphertext. Tapi masih ada yang belum jelas, dalam contoh tersebut kode untuk krakter ‘d’ ternyata berbeda-beda, pada contoh pertama kodenya adalah 325, pada contoh lain kode untuk ‘d’ adalah 412, 280 dan 601.
Kini saya harus mengetahui bagaimana hubungan antara kode yang berurutan, untuk itu saya memilih plaintext “abcd1234″ dengan ciphertext 433034273428242944308379538023819382. Mari kita pecah ciphertext tersebut menjadi kelompok 4 digit seperti tabel di atas.
4-330#3-427#3-428#2-429#4-430#8-379#5-380#2-381#9-382
Dari pengelompokan tersebut kita bisa simpulkan bahwa:
427 = ‘a’, 428 = ‘b’, 429 = ‘c’, 430 = ‘d’, 379 = ’1′, 380 = ’2′, 381=’3′, 382=’4′
Perhatikan bahwa kode-kode tersebut sengaja saya pilih berurut ‘a’->’b'->’c'->’d’ dan ternyata ciphertextnya pun ikut berurut 427->428->429->430. Begitu juga untuk ’1′->’2′->’3′->’4′, ciphertextnya juga berurut 379->380->381->382. Saya mencurigai bahwa enkripsi ini memakai kode ASCII karena memang kode ASCII untuk ‘abcd’ dan ’1234′ berurutan.Kode ASCII untuk  ‘a’=97, ‘b’=98,’c'=99,’d'=100,’1′=49,’2′=50,’3′=51,’4′=52.
Terlihat ada jarak yang cukup jauh antara kode ASCII dan kode pada ciphertext. Contohnya ‘a’ dengan ASCII 97, dalam ciphertext dikodekan dengan 427, selisihnya 427-97 adalah 330. Begitu juga dengan ’1′ dengan ASCII 49, dalam ciphertext dikodekan menjadi 379, dengan selisih 379-49 adalah 330. Ternyata kalau dilihat semua kode pada ciphertext juga berjarak 330 dengan kode ASCII. Pertanyaannya, darimana angka 330 ini muncul?
Mari kita lihat sekali lagi ciphertext dari ‘abcd1234′ (setelah dikelompokkan 4 digit):
4-330#3-427#3-428#2-429#4-430#8-379#5-380#2-381#9-382
Adakah angka 330 dalam ciphertext tersebut? Aha, ternyata ada! Ingat bahwa plaintext satu karakter, ciphertextnya adalah 8 digit, padahal tiap karakter dikodekan dalam 4 digit, jadi ada kelebihan 4 digit. Ternyata pada kelompok 4 digit pertama mengandung offset dengan kode ASCII, yaitu pada digit ke-2 hingga ke-4.
Jadi sekarang misteri enkripsi ini terpecahkan. Mari kita coba dekrip contoh ciphertext yang saya kumpulkan di awal:
  • 804881451156416021528145
Pertama kita kelompokkan menjadi kelompok 4 digit: 8-048#8-145#1-156#4-160#2-152#8-145. Kelompok 4 digit pertama 8048 menunjukkan offset yaitu 048. Kelompok 4 digit kedua, 8145 menunjukkan kode karakter pertama adalah 145, dikonversi ke kode ASCII menjadi 145-048=97. ASCII 97 ini adalah ‘a’. Jadi kita temukan karakter pertama ‘a’. Berikutnya, 156-48=108, yaitu kode untuk ‘l’. Berikutnya, 160-48=112, yaitu kode untuk ‘p’. Berikutnya 152-48=104, yaitu kode untuk ‘h’. Berikutnya 145, sama dengan karakter pertama, ‘a’. Jadi hasil dekripsinya adalah ‘alpha’.
  • 9436353935332546555225378546953924846491
Kita kelompokkan menjadi kelompok 4 digit: 9-436#3-539#3-533#2-546#5-552#2-537#8-546#9-539#2-484#6-491. Karakter pertama: 539-436=103=’g’. Karakter ke-2: 533-436=97=’a’. Karakter ke-3: 546-436=110=’n’. Karakter ke-4: 552-436=116=’t’. Karakter ke-5: 537-436=110=’e’. Karakter ke-6 sama dengan ke-3, ‘n’. Karakter ke-7 sama dengan karakter ke-1, ‘g’. Karakter ke-8: 484-436=48=’0′. Karakter ke-9: 491-436=55=’7′. Jadi hasil dekripsinya adalah ‘ganteng07′.
Pada akhirnya dengan mengetahui teknik enkripsi yang dipakai, saya berhasil mendapatkan password seseorang dengan hak administrator. Tidak lama kemudian GAME OVER, webshell uploaded :)
Kesimpulan
Pelajaran yang bisa diambil dari kasus tersebut adalah bahwa membuat algoritma kriptografi yang kuat tidaklah mudah, jangan pernah memakai enkripsi buatan sendiri, walaupun algoritmanya anda rahasiakan. Selalu gunakan algoritma enkripsi terbuka yang sudah teruji oleh para ahli.
Sedangkan untuk password, sebaiknya jangan gunakan enkripsi, tapi gunakan one-way hash function yang kuat seperti SHA1. Enkripsi tidak cocok dipakai untuk menyimpan password karena ketika terjadi compromised, maka semua password yang ada di tabel akan bisa diambil attacker dengan cara menjalankan rutin dekripsi yang pasti tersedia di salah satu file script seperti PHP pada web tersebut.
Walaupun algoritma dekripsinya anda rahasiakan, suatu saat ketika terjadi compromised, seorang attacker akan bisa melakukan dekripsi dengan membaca source code php untuk men-dekrip password. Biasanya rutin dekripsinya tidak jauh dari file php yang terkait dengan halaman login



File Dari http://blog.math.uny.ac.id

Tidak ada komentar:

Posting Komentar

masukkan komentar anda disini