Ilmu Hacking – Hackingology, Computer Security Blog [PDF]

Membuat file dengan SHA1 collision Ilmu Hacking Hackingology, Computer Security Blog

Sejumlah ilmuwan dengan didukung kekuatan komputasi Google berhasil melakukan serangan SHA1 collision terhadap dokumen PDF. Mereka menciptakan dua file PDF dengan nilai SHA1 hash yang identik walaupun isi filenya berbeda.

About Disclaimer

FB IlmuHacking.com

Categories Advisory

shattered-1.pdf dan shattered-2.pdf memiliki SHA1 yang sama

Basic Concept Cryptography Exploit How to Linux Malware Mobile Phone Security Programming Web Security

Comments Rizki Wicaksono on Memahami Cara Kerja Token Internet Banking anton on Memahami Cara Kerja Token Internet Banking jMozac on Membuat file dengan SHA1 collision dheAdhe on Kupas Tuntas SSH Tunneling Yose on MD5 itu Berbahaya, Titik! Alfagimin on Kupas Tuntas SSH Tunneling setuid0 on Belajar Membuat Shellcode (I): Local Exploit Shellcode

Lalu kenapa kalau ada 2 file SHA1-nya sama? Hash seperti MD5 atau SHA1 sering digunakan sebagai fingerprint untuk mengidentifikasi sebuah file. Mirip seperti sidik jari kita yang karena keunikannya bisa digunakan untuk mengidentifikasi seseorang dengan tepat. Bayangkan bila ada 2 orang yang sidik jarinya sama, tentu akan berbahaya dampaknya kalau sampai tertukar identitasnya. Masih banyak bahaya lain dari hash collision, silakan baca tulisan saya sebelumnya tentang bahaya memakai MD5. Salah satu bahaya dari collision untuk PDF adalah pemalsuan dokumen, dengan kata lain akan mudah memalsukan dokumen PDF walaupun sudah dilindungi dengan tandatangan digital. Dokumen penting seperti perjanjian bisnis, surat kontrak, akta jual beli, sangat rawan untuk dipalsukan. Bisakah collision SHA1 dilakukan untuk file selain PDF? Tentu bisa, dalam tulisan ini saya akan menunjukkan cara membuat SHA1 collision untuk file PHP dan HTML/Javascript. Mari kita mulai dengan memahami cara kerja SHA1. Cara kerja SHA1 SHA1 mengubah input data sepanjang berapapun, menjadi string singkat dan padat sebesar 20 bytes (40 byte dalam hexstring). Bagaimana caranya? Seperti kita makan, kalau makanannya sangat besar tentu sulit untuk menelan sekaligus semuanya, makanya biasanya kita memotong-motong makanan jadi potongan kecil-kecil yang cukup untuk masuk ke mulut. Begitu pula dengan SHA1, dia bekerja dengan memotong input dalam blok-blok berukuran 64 byte dan memprosesnya satu per satu dari blok pertama sampai blok terakhir.

Okki on Exploiting Weak Random Number Rana_sulistiana on Kupas Tuntas SSH Tunneling Kurnia Ramadhan Putra on Memahami Cara Kerja Token Internet Banking

contoh sha1 memproses 3 blok input

SHA1 menggunakan compression function, yang menerima 2 input yaitu 20 byte hash awal (input hash) dan 64 byte blok data untuk menghasilkan 20 byte hash keluaran (output hash). Karena fungsi ini menerima hash dan menghasilkan hash juga, maka hash keluaran dari fungsi ini bisa dipakai sebagai hash masukan untuk memanggil fungsi ini lagi untuk blok berikutnya. Khusus untuk blok pertama, karena tidak ada blok sebelumnya, maka perlu ada nilai hash awal (initial hash) yang sudah ditetapkan yaitu 0x67452301EFCDAB8998BADCFE10325476C3D2E1F0. Jadi semua SHA1 untuk input data apapun selalu berawal dari nilai hash yang sama, kemudian untuk setiap blok, hash awal ini berevolusi menjadi hash yang berbeda. Hash yang dikeluarkan dari blok terakhir menjadi nilai hash final dari keseluruhan input data. Analisa shattered-1.pdf dan shattered-2.pdf Mari kita bandingkan shattered-1.pdf dan shattered-2.pdf. Ternyata perbedaannya hanya dari offset 192 ke 320 (128 bytes), sedangkan di luar range tersebut isinya sama.

vimdiff shattered PDF

Karena SHA1 bekerja menggunakan block berukuran 64 byte, maka bisa kita lihat 2 file tersebut diawali dengan prefix yang sama sebesar 3 blok (common prefix), diikuti dengan 2 blok yang berbeda ( collision block), kemudian setelah itu diikuti dengan byte yang sama sampai akhir file.

shattered PDF structure

Kalau dilihat lebih detil lagi sebenarnya dalam collision block tidak semua byte berbeda, hanya 62 byte saja yang benar-benar berbeda. Perbedaan byte-byte pada posisi tertentu tersebut, terkait dengan format PDF dan sudah diatur sedemikian rupa sehingga bisa menghasilkan gambar yang berbeda ketika dilihat dengan PDF viewer.

byte differences

Dengan implementasi sha-1 yang dimodifikasi, kita bisa melihat intermediate hash yang dihasilkan setiap blok. Mari kita lihat hash yang dihasilkan oleh 5 blok pertama dari shattered-1.pdf dan shattered-2.pdf pada gambar di bawah ini.

intermediate hashes

Dari 5 blok pertama shattered-1 dan shattered-2, perbedaan hanya ada pada blok ke-4 dan blok ke-5, blok ke-1 hingga ke-3 sama persis (common prefix) sehingga bisa kita lihat 3 hash pertama yang dihasilkan juga sama. Hash yang dihasilkan dari 3 blok common prefix ini adalah 0x4ea9…bf45. Kita bisa melanjutkan rangkaian rantai compression function ini dengan blok ke-4 dan ke-5 (collision block).

first 3 hashes

Selanjutnya hash dari common prefix, 0x4ea9…bf45, akan menjadi input untuk memproses blok-4. Karena isi blok-4 berbeda, maka kedua file menghasilkan 2 hash yang berbeda. Menariknya perbedaan tersebut hanya 6 byte saja. Selanjutnya, 2 hash yang berbeda (keluaran dari blok-4) menjadi input untuk memproses blok-5. Ada yang ajaib disini, kedua file menghasilkan hash yang sama walaupun input hash dan isi blok ke-5 kedua file tersebut tidak sama. Perhatikan ilustrasi di bawah ini, perbedaan dimulai dari blok-4 namun blok-5 menyatukan perbedaan itu seolah tidak ada yang berbeda dari kedua file karena hash untuk 5 blok pertama keduanya sama, 1eac… 8ac5.

collision blocks

Membuat collision SHA1 untuk file PHP Mari kita mulai membuat 2 file PHP yang isinya berbeda dan melakukan hal yang berbeda (good.php dan evil.php), namun SHA1 dari kedua file tersebut sama. Bagaimana caranya? Apakah perlu super komputer? Tidak perlu, kita hanya perlu mengeksploitasi cara kerja SHA1 yang memproses hash blok demi blok. Ingat bahwa hash keluaran dari blok ke-5 kedua file tersebut sama. Karena output hash dari blok ke-5 akan menjadi input hash untuk memproses blok ke-6, maka bila isi blok ke-6 kedua file tersebut sama, maka bisa dipastikan hash keluaran blok ke-6 keduanya juga sama. Dengan kata lain, selama kedua file memiliki common suffix (isi yang sama untuk blok ke-6 dan seterusnya), maka hash akhir keduanya akan sama. Bila diketahui M1 dan M2 adalah dua blok yang berbeda, namun memenuhi SHA1(common prefix+M1) = SHA1(common prefix+M2)

maka menambahkan common suffix setelahnya akan membuat SHA1 keduanya tetap sama. SHA1(common prefix+M1+common suffix) = SHA1(common prefix+M2+common suffix)

Eksploitasi ini biasa disebut dengan hash length extension, yang ada pada fungsi hash yang menggunakan struktur Merkle-Damgard seperti MD5 dan SHA. Silakan baca tulisan saya sebelumnya tentang serangan ini hash length extension attack Common suffix, payload PHP Pada gambar di bawah ini, terlihat bahwa 320 byte (5 blok) pertama good.php berasal dari 5 blok pertama shattered-1, sedangkan 320 byte pertama evil.php berasal dari 5 blok pertama shattered-2. Selanjutnya diikuti dengan common suffix berupa payload php yang sama pada kedua file.

structure evil and good php

Walaupun code php pada payload sama, namun code tersebut harus melakukan hal yang jahat dalam evil.php dan tidak melakukan apa-apa pada good.php, bagaimanakah caranya? Tentu tidak bisa hanya sekedar melihat filename apakah evil/good, karena filename bisa diubah-ubah. Caranya adalah payload code tersebut perlu membaca 320 byte pertama dirinya sendiri, kemudian menentukan bila 320 byte tersebut berasal dari shattered-1, maka itu artinya good.php, sebaliknya bila berasal dari shattered-2, maka itu artinya evil.php.

shattered-2 unique string

Pada shattered-2 terdapat string “x0Z!Vd” yang tidak ada di shattered-1, sehingga string ini bisa dijadikan indikator untuk shattered-2. Bila ditemukan string “x0Z!Vd” dalam 320 byte pertama, maka itu artinya adalah evil.php karena 320 byte pertama dari evil.php berasal dari shattered-2. Kurang lebih payload code yang menjadi common suffix seperti di bawah ini. Berikut ini adalah contoh evil.php dan good.php dengan payload seperti contoh di atas. Dengan diff terlihat dua file tersebut sebenarnya berbeda, namun shasum menghasilkan SHA1 yang sama persis. $ diff -q good.php evil.php Files good.php and evil.php differ $ shasum good.php evil.php 9f98b1abdb660db00ce4b0d06576bca8988565e0 good.php 9f98b1abdb660db00ce4b0d06576bca8988565e0 evil.php Ini artinya kita sukses membuat SHA1 collision untuk file php. Namun bagaimana dengan eksekusinya? Apakah script php ini bisa dieksekusi?

evil.php execution

good.php execution

Kita telah berhasil mengeksekusi evil.php dan good.php, namun apa yang sebenarnya terjadi disini, kenapa ada karakter-karakter yang merupakan bagian dari header PDF terlihat di awal, sebelum kode payload dieksekusi? Mari kita lihat isi file good.php berikut ini.

good.php hexdump

Dari hexdump tersebut kita melihat bahwa 320 byte pertama file good.php berasal dari 320 byte pertama shattered-1.pdf, kemudian diikuti dengan kode php sebagai common suffix. PHP memiliki keistimewaan yang memungkinkan SHA1 collision ini bisa dilakukan. PHP interpreter hanya akan mengeksekusi kode php di antara tag “”. Dengan begini, maka header PDF di atas kode PHP tidak akan menjadi masalah, kode php dalam payload akan tetap bisa dieksekusi dengan sukses. Kita tidak bisa melakukan ini untuk python file misalkan, karena interpreter python akan komplain syntax error akibat adanya header PDF di awal file. Membuat collision SHA1 untuk file HTML Dengan cara yang sama kita juga bisa membuat SHA1 collision untuk jenis file html yang mengandung javascript di dalamnya. Kita bisa membuat evil.html dan good.html yang berbeda, namun memiliki SHA1 yang sama. Berikut ini adalah payload yang menjadi common suffix. Disini kita menggunakan javascript untuk mendeteksi apakah terdapat string “x0z!vd” yang menandakan ini adalah file evil.html yang berasal dari shattered2.pdf. Berikut ini adalah contoh good.html dan evil.html dengan nilai hash yang sama, namun isi filenya berbeda. 1 2 3 4 5

$ shasum good.html evil.html 4487d29d4ce7262c3cdb10edf4172ca7a3f2bf30 good.html 4487d29d4ce7262c3cdb10edf4172ca7a3f2bf30 evil.html $ diff -q good.html evil.html Files good.html and evil.html differ

Gambar di bawah ini menunjukkan tampilan di browser untuk good.html dan evil.html. Tidak seperti file PHP sebelumnya yang masih terlihat header PDF di awal, disini kita bisa dengan mudah “menyembunyikan” header PDF tersebut dengan menulis ulang document.body.innerHTML. Dengan cara yang sama sebenarnya kita juga bisa menyembunyikan header PDF untuk file php bila php script tersebut dijalankan di web server dan dibuka di browser, tapi karena dijalankan di console maka header tersebut tidak bisa disembunyikan.

evil.html and good.html

in Cryptography | 1,748 Words | 1 Comment

Menghindari Deteksi Antivirus Anti Virus (AV) banyak diandalkan sebagai tools keamanan utama untuk mencegah virus (secara umum disebut malware). Banyak miskonsepsi dan mitos yang berkembang seputar AV ini. Salah satu miskonsepsi adalah merasa aman dengan adanya AV dan percaya 100% dengan AV, kalau AV bilang suatu file aman, maka kita akan percaya. Tapi tahukah anda bagaimana cara AV mendeteksi malware? Boleh kah kita percaya 100% dengan AV ? Mungkinkah ada malware yang tidak terdeteksi AV ? Dalam tulisan ini saya akan menjelaskan cara kerja AV dan dengan memahami cara kerjanya kita bisa meloloskan diri dari deteksi AV. Blacklist vs Whitelist Dalam computer science, secara teoretis, mendeteksi sebuah program malicious atau bukan dengan sempurna adalah pekerjaan yang mustahil dan problem ini sekelas dengan halting problem. Dengan kata lain, secara teoretis, tidak ada satu algoritma atau prosedur yang bisa membedakan dengan sempurna mana program yang malicious dan yang tidak. Ini adalah kabar buruk bagi kita semua pengguna komputer karena ternyata tidak mungkin ada AV yang bisa 100% melindungi kita dari malware. Namun di sisi lain, ini adalah kabar baik bagi pihak yang berniat jahat karena ini berarti terbuka lebar peluang untuk membuat malware yang tidak terdeteksi AV. Walaupun secara teoretis pendeteksi malware yang sempurna tidak mungkin dibuat, AV akan berusaha keras mencegah jangan sampai malware berhasil dieksekusi sambil tetap mengijinkan program yang baik untuk dieksekusi Bayangkan bila anda mengadakan acara hanya untuk orang baik saja. Bagaimana cara menyeleksi mana tamu yang baik dan tamu yang jahat ? Anda bisa menggunakan 2 pendekatan, whitelist atau blacklist. Whitelist. Pendekatan whitelist secara default akan menolak semua orang kecuali dia ada dalam daftar tamu (whitelist). Dalam pendekatan ini kita harus mempunyai daftar nama, ciri-ciri atau kriteria tamu yang baik. Blacklist. Pendekatan blacklist secara default akan menerima semua orang kecuali dia ada di dalam daftar terlarang (blacklist). Kebalikan dari whitelist, dalam pendekatan blacklist kita harus mempunyai daftar orang-orang yang dilarang masuk. Dari sudut pandang security tentu lebih aman menggunakan whitelist karena defaultnya adalah “deny all”, sedangkan blacklist defaultnya adalah “allow all”. Kapan kita memilih memakai whitelist/blacklist ? Salah satu kriterianya adalah berdasarkan jumlah/size dari whitelist/blacklist. Bila jumlah orang baik jauh lebih sedikit dari jumlah orang jahat, seperti dalam packet filtering firewall (deny all kecuali dari IP X.X.X.X) atau input validation (deny all kecuali inputnya hanya menggunakan digit 0-9), akan lebih aman dan sederhana menggunakan whitelist. Namun bila jumlah orang baik jauh lebih banyak dari orang jahat, kita akan menggunakan blacklist. Dalam hal ini AV dan IDS (intrusion detection system) menggunakan blacklist karena jumlah program normal/baik diasumsikan jauh lebih banyak dari program yang malicious. Dengan mengikuti pendekatan ini AV harus selalu mengupdate blacklistnya mengikuti perkembangan malware, setiap ada malware baru yang belum ada di blacklist harus ditambahkan ke dalam blacklist. Virus Signature Kita tahu AV menggunakan pendekatan blacklist, namun pertanyaannya apa yang disimpan dalam blacklistnya itu. AV menyimpan signature malware dalam blacklistnya. Signature adalah ciri atau pola unik yang bisa dijadikan penanda keberadaan malware. Signature ini bisa berupa string tertentu atau kumpulan instruksi yang diambil dari sample malware. Bila suatu file mengandung signature ini, maka AV akan mendeteksi file tersebut sebagai malware. Signature dalam file bisa dalam jumlah lebih dari satu dan berada di mana saja, bisa berada di awal file, di akhir atau di tengah.

Apakah ada file normal (bukan malware) yang “kebetulan” dalam filenya mengandung deretan byte yang sama dengan signature virus ? Itu mungkin saja terjadi dan hal itu disebut sebagai “false positive”. Hal sebaliknya, “false negative” juga mungkin terjadi bila signature/ciri khusus malware tersebut belum terdaftar dalam blacklist AV sehingga malware tersebut lolos dari deteksi AV. Dalam tulisan ini saya akan menunjukkan bagaimana meloloskan diri dari deteksi AV. Seperti apa bentuk signature dalam AV ? Berikut adalah salah satu contoh signature yang diambil dari signature ClamAV (dari /var/clamav/daily.cld):

Format detail untuk ClamAV bisa dibaca di sini. Sekarang mari kita ambil satu contoh signature paling atas: PUA.Win32.Packer.Expressor-29:1:*:e8530300008bf05656e8980300008bc8 Nama malware: PUA.Win32.Packer.Expressor-29 Jenis: 1 artinya Portable Executable, 32/64 Windows Offset: * artinya di posisi manapun dalam file Hex Signature: e8530300008bf05656e8980300008bc8 yang merupakan kumpulan instruksi assembly dalam hexa.

Jadi signature tersebut bisa dibaca sebagai: Bila dalam file windows executable (PE file) ditemukan deretan byte “E85303….8BC8” di posisi manapun maka file tersebut diyakini mengandung malware PUA.Win32.Packer.Expressor-29. Dengan kata lain, bila suatu file windows executable mengandung instruksi “CALL DWORD 0x358, MOV ESI, EAX” dan seterusnya sampai “MOV ECX,EAX” maka file tersebut diyakini mengandung malware Expressor-29. Static Analysis vs. Dynamic Analysis Secara umum analisis terhadap suatu file untuk menentukan malicious atau tidak bisa dibagi menjadi 2 cara: Static analysis. Dalam static analysis AV akan memeriksa isi file byte demi byte tanpa mengeksekusinya. AV akan membaca isi file dan mencari deretan byte yang cocok dengan salah satu signature dalam blacklist yang dimiliki AV. Bila di dalamnya terkandung signature, maka AV akan yakin bahwa file tersebut adalah malicious. Dynamic analysis. Dalam dynamic analysis AV akan mengeksekusi malware tersebut. Lho ? Kalau malware sudah berhasil dieksekusi berarti game over dong? Memang cara ini sangat beresiko oleh karena itu harus dilakukan dalam virtual machine/sandbox yang diawasi dengan ketat. Kelemahan dari static analysis adalah dia tidak mampu mendeteksi malware yang signaturenya belum terdaftar dalam blacklist. Kelemahan ini coba diatasi dengan dynamic analysis yang tidak hanya melihat signaturenya saja, namun juga mengeksekusi malware dalam sandbox dan melihat apakah program ini melakukan aktivitas yang tidak mungkin dilakukan oleh program baik-baik. Pendeteksian malware menggunakan dynamic analysis ini disebut juga teknik Heuristik. Jadi sebenarnya bisa dikatakan dynamic analysis juga menggunakan signature, namun tidak statik berupa deretan byte, signaturenya berbasis behavior/aktivitas. Bila aktivitasnya setelah dieksekusi dalam sandbox terlihat mencurigakan berdasarkan signature behavior tadi maka AV akan mendeteksi file tersebut sebagai malware. Metasploit Meterpreter vs. Antivirus Mari kita mulai membuat malware yang lolos dari deteksi AV. Dalam contoh ini saya akan menggunakan Metasploit meterpreter bind TCP sebagai malwarenya. Meterpreter dikategorikan sebagai malware oleh semua AV, namun dalam contoh ini saya akan gunakan AVG. Pertama kita akan membuat meterpreter.exe dengan msfpayload. Perhatikan saya tidak menggunakan msfencode untuk obfuscating/encoding, saya hanya menggunakan payload murni apa adanya.

Saya akan memastikan bahwa AVG saya adalah AVG dengan update terbaru (7 November 2013).

Agar tidak mengganggu, saya akan sementara mematikan resident shield. Nanti bila meterpreter yang lolos deteksi sudah selesai, saya akan menyalakan kembali untuk mengujinya.

Mendeteksi Posisi Signature Sebelumnya kita coba scan dulu file meterpreter.exe yang masih original. Hasilnya adalah meterpreter.exe kita terdeteksi sebagai Win32/Heur.

Tentu di dalam file ini mengandung signature sehingga terdeteksi sebagai malware. Pertanyaannya adalah pada posisi/offset berapakah signature tersebut ? Kita perlu tahu di mana posisi offset yang mengandung signature karena dengan mengetahui posisi signature dengan tepat, kita bisa mengubah isi filenya di posisi tersebut agar tidak lagi cocok dengan signature AV. Kita tidak tahu signature yang terdeteksi berada di posisi berapa antara 0 sampai 73802 (ukuran file meterpreter.exe). Bagaimana cara kita mencarinya ? Kita akan melakukan dengan memecah file meterpreter.exe menjadi beberapa file dengan ukuran kelipatan dari suatu blok. Maksudnya bagaimana? Sebagai contoh kita akan memotong meterpreter.exe dengan panjang blok 10.000 byte. Maka hasil split akan memecah menjadi 8 file: File pertama berukuran 10.000 byte File kedua berukuran 20.000 byte (file pertama + 10.000 byte) File ketiga berukuran 30.000 byte (file kedua + 10.000 byte) File keempat berukuran 40.000 byte (file ketiga + 10.000 byte) dan seterusnya. Saya membuat script python kecil untuk melakukan itu pydsplit.py yang sebenarnya adalah versi saya dari dsplit.exe. Pada gambar di bawah ini terlihat pydsplit.py memotong mulai dari offset 0 sepanjang kelipatan 10.000 byte. File yang terbentuk adalah meterpreter_10000.exe berukuran 10.000, file meterpreter_20000.exe berukuran 20000 yaitu file pertama ditambah satu blok 10000 lagi, dan seterusnya.

Sesudah dipotong menjadi 8 file, kita scan semuanya dengan AVG.

Berikut adalah hasil scan yang diexpor ke bentuk Excel. Terlihat bahwa semua file terdeteksi sebagai malware. Ingat bila file yang berukuran 10.000 byte terdeteksi malware, file-file lain yang lebih besar juga pasti akan terdeteksi malware karena file-file tersebut juga mengandung file yang berukuran lebih kecil . Oleh karena itu kita akan mulai mencari signature dari file yang paling kecil dulu.

Karena file meterpreter_10000 terdeteksi sebagai malware, maka hasil ini menunjukkan bahwa ada signature di offset 0 s/d 10.000. Perhatikan kita sudah mempersempit posisi signature dari tadinya signature ada di offset 0 – 73802, sekarang dipersempit menjadi rentang offset 0 – 10.000. Selanjutnya dengan cara yang sama kita akan melakukan split antara 0 s/d 10.000 dengan ukuran blok 1.000. Hasilnya adalah 10 file dengan ukuran 1000, 2000, 3000, 4000 s/d 10.000.

Selanjutnya kita scan juga dengan AVG untuk melihat mana di antara 10 file itu yang terdeteksi mengandung malware.

Berikut adalah hasil scan setelah diekspor ke Excel. Jangan kuatir dengan “Corrupted executable file” itu cara AVG untuk mengatakan file ini tidak mengandung malware dan namun dalam keadaan terpotong (tidak lengkap). Di antara 10 file hasil split ini ternyata file berukuran 7000 tidak terdeteksi malware, artinya pada posisi 0 – 7000 tidak mengandung signature. Namun file berukuran 8000 dan 9000 dikenali sebagai malware oleh AVG artinya dalam file ini mengandung signature. Karena kita tahu file berukuran 7000 tidak mengandung signature, tapi file berukuran 8000 mengandung signature, berarti ada sesuatu antara 70008000 yang menimbulkan kecurigaan AV. Sesuatu itu adalah signature, dari hasil ini kita yakin bahwa ada signature yang berada di offset 7000 s/d 8000.

Hasil scan ini bisa digambarkan seperti gambar di bawah ini (icon tengkorak melambangkan signature yang dicari).

Kini sudah semakin sempit rentang posisi signature, tapi masih belum cukup. Kita perlu split lagi kali ini antara 7000 – 8000 dengan ukuran blok 100 byte. Karena ukuran blok 100 byte, maka akan terbentuk file berukuran 7100, 7200, 7300, 7400 s/d 8000.

Kita juga scan file-file hasil split ini dengan AVG.

Hasil scan menunjukkan bahwa file berukuran 7400 ke atas dikenali sebagai malware sedangkan file berukuran 7300 ke bawah tidak. Ini artinya sampai dengan offset ke 7300 tidak mengandung signature. Karena file berukuran 7400 dikenali sebagai malware, maka signature bisa dipastikan berada di posisi rentang 7300 – 7400.

Hasil scan ini bisa digambarkan dalam ilustrasi berikut.

Sekarang rentang signature semakin kecil lagi, hanya 100 byte saja. Kita lanjutkan melakukan split antara offset 7300-7400 dengan ukuran blok 10 byte. Hasil split akan menciptakan file baru berukuran 7310, 7320, 7330, 7340 s/d 7400.

Berikut adalah hasil scan file hasil split tersebut. AVG mendeteksi malware pada file berukuran 7370 ke atas. Karena file berukuran 7360 tidak mengandung signature, ini artinya signature berada pada posisi 7360 s/d 7370.

Hasil scan ini bisa diilustrasikan seperti gambar di bawah ini.

Sampai disini kita tahu signature berada di posisi 7360 – 7370. Namun kita perlu satu kali lagi melakukan split dengan ukuran blok 1 byte saja sehingga tercipta file berukuran 7361. 7362, 7363 s/d 7370.

Hasil Scan file menunjukkan file berukuran 7361 s/d 7369 tidak terdeteksi sebagai malware. Hal ini meyakinkan kita bahwa signature berada di offset 7370 karena file berukuran 7370 terdeteksi sebagai malware sedangkan 7369 tidak.

Modifikasi File Meterpreter Setelah kita tahu pasti offset signature yang memicu AV mendeteksi malware pada posisi 7370, sekarang kita akan melihat dengan hex editor byte pada posisi tersebut. Pada posisi tersebut 7370 terdapat 0x75.

Kalau byte pada offset 7370 (0x75) dan satu atau beberapa byte sebelumnya kita “rusak” atau ganti dengan byte lain, maka seharusnya AV akan gagal mendeteksi malware karena signature yang tadinya ada disana kini sudah tidak ada lagi. Namun sebelum kita menimpa byte signature tadi dengan byte lain untuk mengelabui AV. Pertanyaannya apakah pengubahan ini membuat meterpreter.exe menjadi corrupt/rusak ? Mari kita coba lihat dengan ollydbg. Kita pasang jebakan breakpoint di 2 byte terakhir, EO 75 dan mulai menjalankan meterpreter. Ternyata setelah dieksekusi, meterpreter.exe bisa berjalan normal dan membuka session meterpreter dengan sempurna tanpa satu kali pun menginjak jebakan breakpoint kita.

Gambar berikut ini adalah eksploitasi meterpreter bind TCP. Eksploitasi ini dilakukan dalam keadaan meterpreter.exe dipasangi jebakan breakpoint. Eksploitasi berjalan sukses tanpa terhenti di breakpoint sama sekali.

Karena semua fungsi meterpreter jalan normal, tanpa sekalipun menginjak breakpoint, ini artinya instruksi pada posisi 7370 ini tidak berpengaruh pada jalannya program (menjadi semacam code cave / unreachable code). Hasil ini meyakinkan kita untuk mengubah 2 byte terakhir 7369 dan 7370 menjadi byte 00 (null byte) tanpa perlu takut mengganggu/merusak program.

Setelah 2 byte pada posisi 7369 dan 7370 (E0-75) diubah menjadi 00-00, kita coba scan ulang meterpreter.exe. Hasil scan ulang menunjukkan kini AVG tidak lagi mendeteksi meterpreter.exe sebagai malware. Game Over, You Win!

Dengan hasil ini berarti kita telah berhasil menghindari deteksi AVG hanya dengan mengubah 2 byte menjadi null. Sekarang kita aktifkan lagi resident shield di AVG karena disitu ada fitur “Use Heuristics”. Setelah itu kita coba double-click meterpreter.exe untuk mengeksekusinya, apakah bisa berjalan dengan sempurna tanpa hambatan dari AV ?

Setelah di double-click, ternyata eksekusi tetap berhasil walaupun opsi “Use heuristics” dan “Enable Resident Shield” diaktifkan, ini artinya AVG gagal total mendeteksi meterpreter kita. File meterpreter.exe yang sudah kita modifikasi 2 byte pada posisi 7369-7370 sekarang bisa dieksekusi secara lancar tanpa diblok oleh AV.

Terus terang saya agak kecewa juga melihat AVG begitu mudahnya ditipu hanya dengan mengubah 2 byte saja. Bahkan fitur Heuristic analisisnya pun tak berdaya dengan “obfuscation” sesederhana ini. Bagaimana dengan AV lain ? Saya harap lebih baik dari ini, mungkin di lain kesempatan saya akan bahas in Malware | 2,107 Words | Comment

Menghindari Deteksi Antivirus Anti Virus (AV) banyak diandalkan sebagai tools keamanan utama untuk mencegah virus (secara umum disebut malware). Banyak miskonsepsi dan mitos yang berkembang seputar AV ini. Salah satu miskonsepsi adalah merasa aman dengan adanya AV dan percaya 100% dengan AV, kalau AV bilang suatu file aman, maka kita akan percaya. Tapi tahukah anda bagaimana cara AV mendeteksi malware? Boleh kah kita percaya 100% dengan AV ? Mungkinkah ada malware yang tidak terdeteksi AV ? Dalam tulisan ini saya akan menjelaskan cara kerja AV dan dengan memahami cara kerjanya kita bisa meloloskan diri dari deteksi AV. Blacklist vs Whitelist Dalam computer science, secara teoretis, mendeteksi sebuah program malicious atau bukan dengan sempurna adalah pekerjaan yang mustahil dan problem ini sekelas dengan halting problem. Dengan kata lain, secara teoretis, tidak ada satu algoritma atau prosedur yang bisa membedakan dengan sempurna mana program yang malicious dan yang tidak. Ini adalah kabar buruk bagi kita semua pengguna komputer karena ternyata tidak mungkin ada AV yang bisa 100% melindungi kita dari malware. Namun di sisi lain, ini adalah kabar baik bagi pihak yang berniat jahat karena ini berarti terbuka lebar peluang untuk membuat malware yang tidak terdeteksi AV. Walaupun secara teoretis pendeteksi malware yang sempurna tidak mungkin dibuat, AV akan berusaha keras mencegah jangan sampai malware berhasil dieksekusi sambil tetap mengijinkan program yang baik untuk dieksekusi Bayangkan bila anda mengadakan acara hanya untuk orang baik saja. Bagaimana cara menyeleksi mana tamu yang baik dan tamu yang jahat ? Anda bisa menggunakan 2 pendekatan, whitelist atau blacklist. Whitelist. Pendekatan whitelist secara default akan menolak semua orang kecuali dia ada dalam daftar tamu (whitelist). Dalam pendekatan ini kita harus mempunyai daftar nama, ciri-ciri atau kriteria tamu yang baik. Blacklist. Pendekatan blacklist secara default akan menerima semua orang kecuali dia ada di dalam daftar terlarang (blacklist). Kebalikan dari whitelist, dalam pendekatan blacklist kita harus mempunyai daftar orang-orang yang dilarang masuk. Dari sudut pandang security tentu lebih aman menggunakan whitelist karena defaultnya adalah “deny all”, sedangkan blacklist defaultnya adalah “allow all”. Kapan kita memilih memakai whitelist/blacklist ? Salah satu kriterianya adalah berdasarkan jumlah/size dari whitelist/blacklist. Bila jumlah orang baik jauh lebih sedikit dari jumlah orang jahat, seperti dalam packet filtering firewall (deny all kecuali dari IP X.X.X.X) atau input validation (deny all kecuali inputnya hanya menggunakan digit 0-9), akan lebih aman dan sederhana menggunakan whitelist. Namun bila jumlah orang baik jauh lebih banyak dari orang jahat, kita akan menggunakan blacklist. Dalam hal ini AV dan IDS (intrusion detection system) menggunakan blacklist karena jumlah program normal/baik diasumsikan jauh lebih banyak dari program yang malicious. Dengan mengikuti pendekatan ini AV harus selalu mengupdate blacklistnya mengikuti perkembangan malware, setiap ada malware baru yang belum ada di blacklist harus ditambahkan ke dalam blacklist. Virus Signature Kita tahu AV menggunakan pendekatan blacklist, namun pertanyaannya apa yang disimpan dalam blacklistnya itu. AV menyimpan signature malware dalam blacklistnya. Signature adalah ciri atau pola unik yang bisa dijadikan penanda keberadaan malware. Signature ini bisa berupa string tertentu atau kumpulan instruksi yang diambil dari sample malware. Bila suatu file mengandung signature ini, maka AV akan mendeteksi file tersebut sebagai malware. Signature dalam file bisa dalam jumlah lebih dari satu dan berada di mana saja, bisa berada di awal file, di akhir atau di tengah.

Apakah ada file normal (bukan malware) yang “kebetulan” dalam filenya mengandung deretan byte yang sama dengan signature virus ? Itu mungkin saja terjadi dan hal itu disebut sebagai “false positive”. Hal sebaliknya, “false negative” juga mungkin terjadi bila signature/ciri khusus malware tersebut belum terdaftar dalam blacklist AV sehingga malware tersebut lolos dari deteksi AV. Dalam tulisan ini saya akan menunjukkan bagaimana meloloskan diri dari deteksi AV. Seperti apa bentuk signature dalam AV ? Berikut adalah salah satu contoh signature yang diambil dari signature ClamAV (dari /var/clamav/daily.cld):

Format detail untuk ClamAV bisa dibaca di sini. Sekarang mari kita ambil satu contoh signature paling atas: PUA.Win32.Packer.Expressor-29:1:*:e8530300008bf05656e8980300008bc8 Nama malware: PUA.Win32.Packer.Expressor-29 Jenis: 1 artinya Portable Executable, 32/64 Windows Offset: * artinya di posisi manapun dalam file Hex Signature: e8530300008bf05656e8980300008bc8 yang merupakan kumpulan instruksi assembly dalam hexa.

Jadi signature tersebut bisa dibaca sebagai: Bila dalam file windows executable (PE file) ditemukan deretan byte “E85303….8BC8” di posisi manapun maka file tersebut diyakini mengandung malware PUA.Win32.Packer.Expressor-29. Dengan kata lain, bila suatu file windows executable mengandung instruksi “CALL DWORD 0x358, MOV ESI, EAX” dan seterusnya sampai “MOV ECX,EAX” maka file tersebut diyakini mengandung malware Expressor-29. Static Analysis vs. Dynamic Analysis Secara umum analisis terhadap suatu file untuk menentukan malicious atau tidak bisa dibagi menjadi 2 cara: Static analysis. Dalam static analysis AV akan memeriksa isi file byte demi byte tanpa mengeksekusinya. AV akan membaca isi file dan mencari deretan byte yang cocok dengan salah satu signature dalam blacklist yang dimiliki AV. Bila di dalamnya terkandung signature, maka AV akan yakin bahwa file tersebut adalah malicious. Dynamic analysis. Dalam dynamic analysis AV akan mengeksekusi malware tersebut. Lho ? Kalau malware sudah berhasil dieksekusi berarti game over dong? Memang cara ini sangat beresiko oleh karena itu harus dilakukan dalam virtual machine/sandbox yang diawasi dengan ketat. Kelemahan dari static analysis adalah dia tidak mampu mendeteksi malware yang signaturenya belum terdaftar dalam blacklist. Kelemahan ini coba diatasi dengan dynamic analysis yang tidak hanya melihat signaturenya saja, namun juga mengeksekusi malware dalam sandbox dan melihat apakah program ini melakukan aktivitas yang tidak mungkin dilakukan oleh program baik-baik. Pendeteksian malware menggunakan dynamic analysis ini disebut juga teknik Heuristik. Jadi sebenarnya bisa dikatakan dynamic analysis juga menggunakan signature, namun tidak statik berupa deretan byte, signaturenya berbasis behavior/aktivitas. Bila aktivitasnya setelah dieksekusi dalam sandbox terlihat mencurigakan berdasarkan signature behavior tadi maka AV akan mendeteksi file tersebut sebagai malware. Metasploit Meterpreter vs. Antivirus Mari kita mulai membuat malware yang lolos dari deteksi AV. Dalam contoh ini saya akan menggunakan Metasploit meterpreter bind TCP sebagai malwarenya. Meterpreter dikategorikan sebagai malware oleh semua AV, namun dalam contoh ini saya akan gunakan AVG. Pertama kita akan membuat meterpreter.exe dengan msfpayload. Perhatikan saya tidak menggunakan msfencode untuk obfuscating/encoding, saya hanya menggunakan payload murni apa adanya.

Saya akan memastikan bahwa AVG saya adalah AVG dengan update terbaru (7 November 2013).

Agar tidak mengganggu, saya akan sementara mematikan resident shield. Nanti bila meterpreter yang lolos deteksi sudah selesai, saya akan menyalakan kembali untuk mengujinya.

Mendeteksi Posisi Signature Sebelumnya kita coba scan dulu file meterpreter.exe yang masih original. Hasilnya adalah meterpreter.exe kita terdeteksi sebagai Win32/Heur.

Tentu di dalam file ini mengandung signature sehingga terdeteksi sebagai malware. Pertanyaannya adalah pada posisi/offset berapakah signature tersebut ? Kita perlu tahu di mana posisi offset yang mengandung signature karena dengan mengetahui posisi signature dengan tepat, kita bisa mengubah isi filenya di posisi tersebut agar tidak lagi cocok dengan signature AV. Kita tidak tahu signature yang terdeteksi berada di posisi berapa antara 0 sampai 73802 (ukuran file meterpreter.exe). Bagaimana cara kita mencarinya ? Kita akan melakukan dengan memecah file meterpreter.exe menjadi beberapa file dengan ukuran kelipatan dari suatu blok. Maksudnya bagaimana? Sebagai contoh kita akan memotong meterpreter.exe dengan panjang blok 10.000 byte. Maka hasil split akan memecah menjadi 8 file: File pertama berukuran 10.000 byte File kedua berukuran 20.000 byte (file pertama + 10.000 byte) File ketiga berukuran 30.000 byte (file kedua + 10.000 byte) File keempat berukuran 40.000 byte (file ketiga + 10.000 byte) dan seterusnya. Saya membuat script python kecil untuk melakukan itu pydsplit.py yang sebenarnya adalah versi saya dari dsplit.exe. Pada gambar di bawah ini terlihat pydsplit.py memotong mulai dari offset 0 sepanjang kelipatan 10.000 byte. File yang terbentuk adalah meterpreter_10000.exe berukuran 10.000, file meterpreter_20000.exe berukuran 20000 yaitu file pertama ditambah satu blok 10000 lagi, dan seterusnya.

Sesudah dipotong menjadi 8 file, kita scan semuanya dengan AVG.

Berikut adalah hasil scan yang diexpor ke bentuk Excel. Terlihat bahwa semua file terdeteksi sebagai malware. Ingat bila file yang berukuran 10.000 byte terdeteksi malware, file-file lain yang lebih besar juga pasti akan terdeteksi malware karena file-file tersebut juga mengandung file yang berukuran lebih kecil . Oleh karena itu kita akan mulai mencari signature dari file yang paling kecil dulu.

Karena file meterpreter_10000 terdeteksi sebagai malware, maka hasil ini menunjukkan bahwa ada signature di offset 0 s/d 10.000. Perhatikan kita sudah mempersempit posisi signature dari tadinya signature ada di offset 0 – 73802, sekarang dipersempit menjadi rentang offset 0 – 10.000. Selanjutnya dengan cara yang sama kita akan melakukan split antara 0 s/d 10.000 dengan ukuran blok 1.000. Hasilnya adalah 10 file dengan ukuran 1000, 2000, 3000, 4000 s/d 10.000.

Selanjutnya kita scan juga dengan AVG untuk melihat mana di antara 10 file itu yang terdeteksi mengandung malware.

Berikut adalah hasil scan setelah diekspor ke Excel. Jangan kuatir dengan “Corrupted executable file” itu cara AVG untuk mengatakan file ini tidak mengandung malware dan namun dalam keadaan terpotong (tidak lengkap). Di antara 10 file hasil split ini ternyata file berukuran 7000 tidak terdeteksi malware, artinya pada posisi 0 – 7000 tidak mengandung signature. Namun file berukuran 8000 dan 9000 dikenali sebagai malware oleh AVG artinya dalam file ini mengandung signature. Karena kita tahu file berukuran 7000 tidak mengandung signature, tapi file berukuran 8000 mengandung signature, berarti ada sesuatu antara 70008000 yang menimbulkan kecurigaan AV. Sesuatu itu adalah signature, dari hasil ini kita yakin bahwa ada signature yang berada di offset 7000 s/d 8000.

Hasil scan ini bisa digambarkan seperti gambar di bawah ini (icon tengkorak melambangkan signature yang dicari).

Kini sudah semakin sempit rentang posisi signature, tapi masih belum cukup. Kita perlu split lagi kali ini antara 7000 – 8000 dengan ukuran blok 100 byte. Karena ukuran blok 100 byte, maka akan terbentuk file berukuran 7100, 7200, 7300, 7400 s/d 8000.

Kita juga scan file-file hasil split ini dengan AVG.

Hasil scan menunjukkan bahwa file berukuran 7400 ke atas dikenali sebagai malware sedangkan file berukuran 7300 ke bawah tidak. Ini artinya sampai dengan offset ke 7300 tidak mengandung signature. Karena file berukuran 7400 dikenali sebagai malware, maka signature bisa dipastikan berada di posisi rentang 7300 – 7400.

Hasil scan ini bisa digambarkan dalam ilustrasi berikut.

Sekarang rentang signature semakin kecil lagi, hanya 100 byte saja. Kita lanjutkan melakukan split antara offset 7300-7400 dengan ukuran blok 10 byte. Hasil split akan menciptakan file baru berukuran 7310, 7320, 7330, 7340 s/d 7400.

Berikut adalah hasil scan file hasil split tersebut. AVG mendeteksi malware pada file berukuran 7370 ke atas. Karena file berukuran 7360 tidak mengandung signature, ini artinya signature berada pada posisi 7360 s/d 7370.

Hasil scan ini bisa diilustrasikan seperti gambar di bawah ini.

Sampai disini kita tahu signature berada di posisi 7360 – 7370. Namun kita perlu satu kali lagi melakukan split dengan ukuran blok 1 byte saja sehingga tercipta file berukuran 7361. 7362, 7363 s/d 7370.

Hasil Scan file menunjukkan file berukuran 7361 s/d 7369 tidak terdeteksi sebagai malware. Hal ini meyakinkan kita bahwa signature berada di offset 7370 karena file berukuran 7370 terdeteksi sebagai malware sedangkan 7369 tidak.

Modifikasi File Meterpreter Setelah kita tahu pasti offset signature yang memicu AV mendeteksi malware pada posisi 7370, sekarang kita akan melihat dengan hex editor byte pada posisi tersebut. Pada posisi tersebut 7370 terdapat 0x75.

Kalau byte pada offset 7370 (0x75) dan satu atau beberapa byte sebelumnya kita “rusak” atau ganti dengan byte lain, maka seharusnya AV akan gagal mendeteksi malware karena signature yang tadinya ada disana kini sudah tidak ada lagi. Namun sebelum kita menimpa byte signature tadi dengan byte lain untuk mengelabui AV. Pertanyaannya apakah pengubahan ini membuat meterpreter.exe menjadi corrupt/rusak ? Mari kita coba lihat dengan ollydbg. Kita pasang jebakan breakpoint di 2 byte terakhir, EO 75 dan mulai menjalankan meterpreter. Ternyata setelah dieksekusi, meterpreter.exe bisa berjalan normal dan membuka session meterpreter dengan sempurna tanpa satu kali pun menginjak jebakan breakpoint kita.

Gambar berikut ini adalah eksploitasi meterpreter bind TCP. Eksploitasi ini dilakukan dalam keadaan meterpreter.exe dipasangi jebakan breakpoint. Eksploitasi berjalan sukses tanpa terhenti di breakpoint sama sekali.

Karena semua fungsi meterpreter jalan normal, tanpa sekalipun menginjak breakpoint, ini artinya instruksi pada posisi 7370 ini tidak berpengaruh pada jalannya program (menjadi semacam code cave / unreachable code). Hasil ini meyakinkan kita untuk mengubah 2 byte terakhir 7369 dan 7370 menjadi byte 00 (null byte) tanpa perlu takut mengganggu/merusak program.

Setelah 2 byte pada posisi 7369 dan 7370 (E0-75) diubah menjadi 00-00, kita coba scan ulang meterpreter.exe. Hasil scan ulang menunjukkan kini AVG tidak lagi mendeteksi meterpreter.exe sebagai malware. Game Over, You Win!

Dengan hasil ini berarti kita telah berhasil menghindari deteksi AVG hanya dengan mengubah 2 byte menjadi null. Sekarang kita aktifkan lagi resident shield di AVG karena disitu ada fitur “Use Heuristics”. Setelah itu kita coba double-click meterpreter.exe untuk mengeksekusinya, apakah bisa berjalan dengan sempurna tanpa hambatan dari AV ?

Setelah di double-click, ternyata eksekusi tetap berhasil walaupun opsi “Use heuristics” dan “Enable Resident Shield” diaktifkan, ini artinya AVG gagal total mendeteksi meterpreter kita. File meterpreter.exe yang sudah kita modifikasi 2 byte pada posisi 7369-7370 sekarang bisa dieksekusi secara lancar tanpa diblok oleh AV.

Terus terang saya agak kecewa juga melihat AVG begitu mudahnya ditipu hanya dengan mengubah 2 byte saja. Bahkan fitur Heuristic analisisnya pun tak berdaya dengan “obfuscation” sesederhana ini. Bagaimana dengan AV lain ? Saya harap lebih baik dari ini, mungkin di lain kesempatan saya akan bahas in Malware | 2,108 Words | 15 Comments

Blockwise Chosen Boundary Attack – BEAST Attack Pada September 2011 lalu dunia sempat dikejutkan dengan BEAST (Browser Exploit Against SSL/TLS) attack yang menyerang SSL/TLS oleh Thai Duong dan Juliano Rizzo. Serangan tersebut didemokan dalam Ekoparty 2011 dan dijelaskan dalam paper berjudul Here Comes the XOR Ninjas. Serangan ini practical dan terbukti efektif mencuri session ID yang disimpan dalam cookie website yang dilindungi dengan SSL/TLS (selanjutnya saya hanya menyebut SSL untuk SSL/TLS). Dalam tulisan ini saya akan membahas apa itu BEAST attack dan bagaimana cara kerjanya. BEAST Attack Bagi yang belum pernah mendengar BEAST attack silakan melihat dulu youtube, BEAST vs HTTPS yang mendemokan bagaimana BEAST attack bisa digunakan membajak akun Paypal korban. Dalam video tersebut terlihat bagaimana BEAST berhasil mendekrip paket SSL satu byte per satu byte sampai akhirnya seluruh cookie korban berhasil dicuri. Menakutkan bukan? Gara-gara BEAST attack ini rame-rame situs pengguna SSL mengubah algoritma enkripsinya dari block cipher menjadi stream cipher (RC4). Lho kenapa kok sampai harus mengganti dari block cipher menjadi stream cipher ? Rupanya BEAST attack ini hanya menyerang SSL yang menggunakan algoritma block cipher (e.g AES/DES/3DES) dalam mode CBC (cipher block chaining). Dengan beralih ke stream cipher maka situs tersebut menjadi kebal dari serangan BEAST. Mari kita bahas ada apa dengan SSL block cipher dan mode CBC sehingga bisa dieksploitasi sampai sedemikian fatalnya. Block-Cipher dan SSL Record Sebelumnya sebagai background saya akan menjelaskan sedikit mengenai enkripsi dengan block-cipher dalam SSL. SSL pada dasarnya mirip dengan protokol pada transport layer seperti TCP yang memberikan layanan connection oriented communication dan menjamin reliability untuk layer di atasnya, hanya bedanya adalah data yang lewat SSL dalam bentuk terenkripsi. Kalau dalam TCP ada yang namanya 3-way handshake untuk membentuk koneksi, dalam SSL ada negotiation. Dalam proses negosiasi akan disepakati algoritma (e.g encryption, key exchange,MAC) apa yang dipakai dan juga disepakati kunci simetris yang dipakai untuk mengenkripsi data. Perlu diketahui SSL menggunakan algoritma simetris (e.g RC4, AES, DES) untuk mengenkripsi data karena lebih murah komputasinya dibanding algoritma asimetris (e.g RSA). Algoritma asimetris hanya dipakai selama proses negosiasi saja untuk mengamankan proses pertukaran kunci simetris, setelah session/channel/connection SSL terbentuk, algoritma asimetris tidak dipakai lagi, semua komunikasi dalam channel SSL menggunakan algoritma enkripsi simetris baik block-cipher maupun stream-cipher. Dalam channel SSL data dikirim dalam bentuk record SSL yang berukuran maksimal 16 kB. Data yang dikirim adalah data yang ada pada layer di atasnya seperti request/response HTTP dalam HTTPS (HTTP over SSL).

Data yang dikirim melalui channel SSL akan dipecah menjadi satu atau lebih SSL record sebelum dikirimkan ke tujuan dan semua record dienkrip dengan kunci simetris yang sama (satu kunci untuk client ke server, dan satu kunci untuk server ke client). Sebagai pengingat saja, dalam block cipher dalam mode opeasi CBC, setiap blok plaintext di-XOR dengan blok ciphertext sebelumnya untuk menghasilkan blok ciphertext. Khusus untuk blok pertama, blok plaintext di-XOR dengan IV.

Chained IV Bagaimanakah cara mengenkripsi SSL record ? Data plaintext yang akan dienkrip dalam SSL record tentu terdiri dari satu atau lebih blok plaintext, P1, P2, P3,…, Pn yang akan dienkrip menjadi ciphertext C1, C2, C3,… ,Cn. Ingat dalam CBC mode, dibutuhkan IV untuk menghasilkan C1, nah yang menjadi pertanyaan adalah dari manakah IV atau C0 ini berasal ? Dalam RFC 2246 tentang TLS 1.0 dijelaskan begini: With block ciphers in CBC mode (Cipher Block Chaining) the initialization vector (IV) for the first record is generated with the other keys and secrets when the security parameters are set. The IV for subsequent records is the last ciphertext block from the previous record. Ternyata IV untuk SSL record pertama ditentukan pada saat handshaking (negosiasi), sedangkan IV untuk record selanjutnya adalah block ciphertext terakhir dari record SSL sebelumnya. Menggunakan block ciphertext terakhir sebagai IV untuk record berikutnya disebut dengan chained IV.

Pada gambar di atas terlihat bahwa blok ciphertext terakhir dari record pertama (c4) menjadi C0 atau IV untuk record kedua. Begitu juga block ciphertext terakhir dari record kedua akan menjadi IV untuk record ketiga. Nanti bila ada record ke-4, block ciphertext terakhir dari record ke-3 akan berperan sebagai IV untuk record SSL ke-4. Pada gambar di atas c0 digambarkan sebagai kotak bergaris putus-putus karena memang C0/IV bukan bagian dari record SSL. Dalam record SSL, block pertama ciphertext adalah C1 bukan C0 atau IV dengan kata lain pendekatan yang dipakai adalah implicit IV. Pendekatan chained IV ini memandang semua blok ciphertext dari semua record SSL seolah-olah sebagai aliran blok ciphertext yang berurutan, C1, C2, C3….Cn. Pada gambar di atas terlihat record pertama adalah c1 || c2 || c3 || c4, dan 4 blok ciphertext pada record ke-2 bisa dianggap kelanjutan dari record sebelumnya, c5 || c6 || c7 || c8. Tiga blok ciphertext pada record ke-3 juga bisa dianggap sebagai kelanjutan dari blok ciphertext sebelumnya, c9 || c10 || c11.

Chained IV terbukti menjadi masalah keamanan serius karena seorang penyerang sudah tahu duluan IV untuk mengenkrip data berikutnya. Nanti akan saya jelaskan bagaimana chained IV ini bisa dieksploitasi. Sebagai catatan: Kelemahan chained IV ini diperbaiki di TLS 1.1 dengan menggunakan explicit IV, setiap record menyertakan IV untuk record tersebut (IV menjadi bagian dari record sebagai c0). Eksploitasi Chained IV Sekarang akan saya bahas bagiamana chained IV bisa dieksploitasi. Kita akan asumsikan seorang penyerang sedang sniffing jaringan dan mendapatkan (encrypted) ssl record berisi ciphertext Ca = C1 || C2 || C3 || C4 || C5. Dalam BEAST attack ini penyerang memiliki privilege chosen plaintext, artinya dia bisa menentukan plaintext apa yang akan dienkrip dan mendapatkan hasil enkripsinya (ciphertext). Penyerang tersebut ingin mengetahui apakah plaintext dari suatu blok ciphertext, misalkan C2 adalah G(uess). Bagaimana caranya? Penyerang akan membuat plaintext P6 = C1 XOR C5 XOR G kemudian meminta sistem mengenkrip plaintext tersebut. Mari kita lihat bagaimana P6 dienkripsi menjadi C6. Ingat melakukan XOR dengan nilai yang sama dua kali akan meniadakan efeknya, karena ada XOR C5 dua kali, maka dua XOR C5 tersebut bisa dihapus. C6 = E(P6 XOR C5) = E(C1 XOR C5 XOR G XOR C5) = E(C1 XOR G) Apa artinya dari persamaan C6 = E(C1 XOR G) di atas? Perhatikan bahwa bila G = P2 (plaintext dari C2) maka yang terjadi adalah C6 = E(C1 XOR P2) = C2. Okey, jadi jika G = P2, maka C6 = C2, lalu so what? apa istimewanya? Bagi yang belum menyadari potensi bahayanya, perhatikan bahwa hanya dengan melihat apakah C6 = C2, si penyerang bisa memastikan apakah G = P2. Bila si penyerang melihat bahwa C6 = C2 artinya bisa dipastikan bahwa G = P2, atau tebakannya benar. Kini si penyerang memiliki cara untuk memastikan apakah tebakannya benar atau salah Sudah mulai terbayang bukan cara mendekrip C2 ? Pertama penyerang akan memilih tebakan G’ dan meminta P6 = C1 XOR C5 XOR G’ untuk dienkrip (chosen plaintext). Kemudian penyerang akan melihat apakah hasil enkripsi P6, C6 = C2 atau tidak ?

Bila dilihat C6 tidak sama dengan C2, maka penyerang akan memilih tebakan baru G”. Ingat karena adanya chained IV, maka C6 tersebut menjadi IV untuk mengenkripsi P7 sehingga pada tebakan kedua, si penyerang memilih P7 = C1 XOR C6 XOR G”.

Penyerang juga akan melihat apakah C7 = C2 ? Bila masih salah, penyerang akan memilih tebakan baru, G”’. Sekali lagi karena adanya chined IV, C7 tersebut menjadi IV untu mengenkripsi P8 sehingga pada tebakan ke-3 si penyerang memilih P8 = C1 XOR C7 XOR G”’.

Bila kali ini penyerang melihat bahwa C8 = C2, maka penyerang yakin bahwa G”’ adalah P2 (plaintext dari C2). Namun bila masih salah, penyerang akan terus membuat tebakan baru sampai didapatkan hasil yang positif. Dalam contoh di atas, plainteks yang dipilih selalu melibatkan C1 karena kita ingin mendekrip C2 (mencari P2). Secara umum bila yang ingin didekrip adalah Cn (mencari Pn), maka plainteks yang dipilih harus memakai Cn-1. Chosen Boundary Bagi yang jeli tentu akan melihat masih ada yang kurang dari cara ini. Ingat bahwa G adalah tebakan dari penyerang yang berukuran satu blok (AES berukuran 16 byte). Bagaimana cara menentukan G ? Mengingat G berukuran satu blok 16 byte sehingga kemungkinan G sangat banyak, tentu tidak mungkin kita memilih G sembarangan. Lalu, bagaimana cara kita membuat “educated guess” atau “smart guess” untuk memilih G yang paling berpotensi benar ? Memilih G yang tepat untuk menebak P2 sangat susah bila yang tidak diketahui adalah semuanya (16 byte). Tapi kalau kita yakin bahwa 15 byte pertama P2 adalah huruf ‘x’ sedangkan satu byte terakhir P2 tidak diketahui isinya, maka hanya ada 256 kemungkinan tebakan yang harus dicoba. Salah satu diantara 256 tebakan di bawah ini pasti ada yang benar kalau hanya 1 karakter terakhir yang tidak diketahui isinya. Ga = xxxxxxxxxxxxxxxa Gb = xxxxxxxxxxxxxxxb Gc = xxxxxxxxxxxxxxxc Gd = xxxxxxxxxxxxxxxd Ge = xxxxxxxxxxxxxxxe … dan seterusnya Bagaimana kalau plaintextnya adalah teks “topsecret” dan penyerang tidak mengetahui satu byte pun isinya? Dalam BEAST attack, selain privilege chosen plaintext, si penyerang punya satu privilege lagi, yaitu menyisipkan teks (prepend) di awal atau di tengah teks lain sebelum teks tersebut dienkripsi. Jadi bila si penyerang mengirimkan teks “abcd”, maka sistem akan mengenkripsi gabungan “abcd” dan “topsecret”. Privilege penyisipan teks ini sangat penting dalam kesuksesan BEAST attack karena dengan menyisipkan teks artinya sama saja kita bisa menggeser batas blok plaintext. Bagaimana maksudnya ? Ingat bahwa agar kita bisa menebak satu blok dengan mudah, kita harus membuat 15 byte pertama blok tersebut menjadi sesuatu yang kita ketahui, kemudian hanya menyisakan satu byte saja yang tidak diketahui. Apa yang terjadi bila teks “topsecret” disisipkan teks “xxxxxxxxxxxxxxx” di awalnya? Setelah digabung teks gabungannya menjadi “xxxxxxxxxxxxxxxtopsecret”. Lalu so what? Apa gunanya menambahkan teks di awal? Memang sepintas tidak terlihat bedanya, baru akan terlihat gunanya ketika kita melihat teks gabungan tersebut dalam bentuk blok-blok plainteks.

Sudah terlihat bedanya bukan? Setelah ditambahkan 15 huruf ‘x’ di awal, sekarang jumlah blok plainteks menjadi 2 (P1 dan P2), dan blok plainteks pertama adalah ‘xxxxxxxxxxxxxxxt’. Aha! Sekarang kita bisa menebak P1 dengan mudah karena kita yakin bahwa 15 karakter pertama P1 berisi ‘x’ karena kita sendiri yang menambahkan huruf ‘x’ tersebut. Teknik menyisipkan teks ini bertujuan untuk menggeser batas blok (chosen boundary) sehingga hanya menyisakan satu karakter saja yang tidak diketahui. Setelah penyerang menebak 256 kali, dijamin dia akan mengetahui bahwa huruf pertama adalah ‘t’. Selanjutnya bagaimana cara menebak karakter ke-2 ? Menebak karakter ke-2 dilakukan dengan mengulang langkah awal tadi, yaitu menggeser batas dengan menyisipkan teks di awal. Kali ini yang disisipkan adalah 14 huruf ‘x’, bukan lagi 15 huruf ‘x’. Mari kita lihat blok plainteksnya.

Karena karakter yang disisipkan (prepend) hanya 14, maka dalam P1 menyisakan ‘to’. Kita sudah tahu 14 huruf pertama adalah ‘x’ dan huruf pertama adalah ‘t’, jadi dari P1 hanya karakter terakhir yang tidak diketahui isinya. Sekali lagi, kita berada dalam posisi yang kita inginkan, kita hanya perlu menebak 256 kali tebakan untuk mendapatkan huruf ke-2 : Ga = xxxxxxxxxxxxxxta Gb = xxxxxxxxxxxxxxtb Gc = xxxxxxxxxxxxxxtc … Go = xxxxxxxxxxxxxxto Menebak karakter ke-3 juga dilakukan dengan cara yang sama. Kita menggeser boundary dengan menyisipkan 13 karakter ‘x’ di awal sehingga blok plainteks yang terbentuk adalah:

Kali ini P1 adalah 13 huruf ‘x’, diikuti dengan 2 karakter yang sudah diketahui ‘to’ dan satu karakter lagi yang belum diketahui. Karena hanya karakter terakhir yang tidak diketahui, maka hanya diperlukan paling banyak 256 kali tebakan untuk mengetahui isi karakter ke-3: Ga = xxxxxxxxxxxxxtoa Gb = xxxxxxxxxxxxxtob Gc = xxxxxxxxxxxxxtoc … Gp = xxxxxxxxxxxxxtop Dua Fase Serangan Tadi sudah kita bahas bagaimana cara mendekrip satu blok cipherteks. Secara umum tahapannya bisa dibagi menjadi 2 fase: 1. Fase menggeser batas 2. Fase melakukan 256 tebakan Fase pertama si penyerang memanfaatkan privilege chosen boundarynya untuk menggeser batas. Penyerang akan menyisipkan suatu teks untuk menggeser batas blok plainteks sedemikian hingga hanya menyisakan satu karakter yang tidak diketahui. Gambar di bawah ini menunjukkan proses serangan pada fase pertama. Penyerang mengirimkan 15 karakter ‘x’ kemudian menerima hasil enkripsi 15 karakter ‘x’ dan ‘topsecret’ dalam bentuk C0||C1||C2.

Fase kedua adalah fase untuk menebak karakter terakhir, pada fase ini penyerang memanfaatkan privilege chosen plaintextnya (lempar plaintext, terima ciphertext). Dari fase pertama penyerang sudah mengetahui: Ciphertext C = C0||C1||C2 P1 = xxxxxxxxxxxxxxx? Penyerang harus menebak karakter terakhir P1 yang belum diketahui isinya. Langkah pertama penyerang memilih tebakan Ga = ‘xxxxxxxxxxxxxxxa’ kemudian menentukan plaintext P3 = C0 XOR C2 XOR Ga. Hanya pengingat saja. Karena adanya chained IV, kita tahu bahwa plaintext yang kita pilih ini akan dienkrip dengan menggunakan C2 sebagai IV. Nanti plaintext tersebut akan diXOR lagi dengan IV (C2) sebelum dienkrip sehingga menyisakan C0 XOR Ga saja yang akan dienkrip. C3 = E(P3 XOR C2) = E(Co XOR C2 XOR Ga XOR C2) = E(Co XOR Ga) Karena P3 sudah kita XOR duluan dengan C2, nanti akan menyisakan C3 = Encrypt(C0 XOR Ga). Dalam P3 juga kita gunakan C0 karena kita akan membandingkan dengan C3 dengan C1 dan C1 = Encrypt(C0 XOR P1). Plaintext P3 ini adalah plaintext yang dipilih penyerang (chosen plaintext) untuk dienkrip menjadi C3. Kemudian penyerang akan melihat apakah C3 = C1 ? Bila tidak sama, maka penyerang akan melanjutkan dengan tebakan lain.

Karena C3 tidak sama dengan C1 artinya tebakan Ga salah. Penyerang membuat tebakan baru Gb = ‘xxxxxxxxxxxxxxxb’ kemudian menentukan P4 = C0 XOR C3 XOR Gb. Plainteks pilihan penyerang ini akan dienkrip menjadi C4. Penyerang akan melihat apakah C4 = C1 ? Bila tidak sama, penyerang akan melanjutkan dengan tebakan lain.

Penyerang akan terus mencoba sampai pada tebakan ke-20 (dalam contoh kasus ini), penyerang membuat tebakan Gt = ‘xxxxxxxxxxxxxxxt’ dan menentukan P22 = C0 XOR C21 XOR Gt. Setelah P22 dienkrip menjadi C22, penyerang melihat bahwa ternyata C22 = C1, yang artinya penyerang yakin bahwa P1 adalah ‘xxxxxxxxxxxxxxxt’.

Setelah penyerang mengetahui karakter pertama adalah ‘t’ selanjutnya penyerang akan mengulangi lagi dari fase pertama untuk menggeser batas dan fase kedua untuk menebak karakter terakhir sebanyak maksimal 256 kali tebakan. Chosen Boundary dalam HTTPS Selama ini yang sudah kita bahas masih dalam tataran model atau teoretis saja. Sebenarnya apakah model tersebut ada di dunia nyata ? Jawabnya ada, BEAST attack adalah serangan yang mengeksploitasi chained IV menggunakan teknik pergeseran batas blok (chosen boundary) untuk mendekrip SSL record. Berikut adalah contoh cookie-bearing request yang dikirim oleh browser dan sudah dipotong-potong menjadi blok-blok plainteks, P1 || P2 || P3 || P4. Dengan sniffing penyerang berhasil mendapatkan ciphertext C = C1 || C2 || C3 || C4 dan ingin mencuri cookie PHPSESSID korban. Bagaimanakah caranya ?

Penyerang bisa mencuri cookie PHPSESSID dengan cara yang sama dengan yang sudah kita bahas tadi. Fase pertama kita harus menggeser batas bloknya sehingga hanya byte terakhir saja yang tidak diketahui isinya. Dalam request HTTP di atas sebagian besar isi teks sudah diketahui, “POST”, “HTTP/1.1” dan “Cookie” adalah teks yang umum ada pada request HTTP, bukan hal yang rahasia. Satu-satunya yang rahasia pada request di atas hanyalah isi dari PHPSESSID “af25c…”, bahkan panjang dari isi PHPSESSID bukan sesuatu yang rahasia. Penyerang bisa menyisipkan teks tambahan dalam URI path untuk menggeser batas. Dalam contoh request di atas kita ingin menggeser “af25c…” sebanyak 12 karakter ke kanan. Penyerang akan mengirimkan cookie-bearing request dengan URI PATH /xxxxxxxxxxxx sehingga blok plainteks dari request yang terbentuk adalah:

Perhatikan pada request yang telah digeser ini, P3 adalah “kie: PHPSESSID=a”. Dari P3 tersebut hanya karakter terakhir saja yang tidak diketahui, “Cookie” dan “PHPSESSID” adalah teks yang umum pada request HTTP. Sudah terbayang kan caranya? Setelah kita menggeser agar P3 menjadi seperti itu, selanjutnya kita masuk ke fase dua, yaitu menebak karakter terakhir sebanyak maksimal 256 kali. Dengan mengulangi fase pertama dan fase kedua untuk semua karakter pada cookie, pada akhirnya penyerang akan bisa mencuri cookie. Inilah yang sebenarnya terjadi dalam serangan BEAST attack. Skenario Serangan Bagaimana sebenarnya serangan BEAST itu dilakukan untuk mencuri cookie PHPSESSID seperti contoh request di atas? Gambar di bawah menunjukkan skenario serangan BEAST bagaimana seorang penyerang mencuri cookie PHPSESSID bank.com.

Serangan BEAST ini mensyaratkan penyerang berada dalam posisi yang memungkinkan untuk melakukan sniffing (e.g. satu jaringan LAN, berada di proxy/router). Syarat kedua adalah penyerang berhasil menjalankan script di browser yang sama (di tab berbeda) dengan yang dipakai korban untuk membuka bank.com. Script tersebut berfungsi sebagai agent yang mampu mengirimkan cookie-bearing request dan mengirimkan data (over SSL) ke situs bank.com. Ada banyak cara penyerang bisa mengeksekusi script di browser korban, antara lain dengan merayu korban mengklik situs evil.com yang berisi script agent. Berikut adalah cara yang dilakukan penyerang untuk mencuri PHPSESSID: 1. Pada fase pertama script yang jalan di browser korban memaksa browser korban mengirimkan cookie-bearing request ke bank.com dengan URI path mengandung ‘xxxxxxxxxxxxxxxx’ untuk menggeser isi PHPSESSID sebanyak 12 karakter. 2. Sniffer yang dipasang si penyerang mencatat request POST tersebut dalam bentuk SSL record yang berisi C=C1||C2||C3||C4 3. Karena karakter pertama PHPSESSID berada pada byte terakhir P3, maka selanjutnya penyerang masuk ke fase dua untuk menebak karakter terakhir P3 4. Script agent akan memaksa browser mengirimkan data ke situs target sebagai lanjutan dari request POST pada fase pertama (sebagai bagian dari POST body) 5. Penyerang akan meminta browser mengenkripsi P5 = C2 XOR C4 XOR Ga dan mengirimkannya (over SSL) ke situs target 6. Sniffer penyerang akan melihat C5 yang lewat di jaringan dan memeriksa apakah C5 = C3 ? Bila sama, maka tebakan penyerang benar 7. Bila tebakan penyerang salah maka penyerang akan membuat tebakan baru dan kembali ke langkah 5. 8. Paling banyak dalam 256 kali tebakan si penyerang akan berhasil mendapatkan karakter pertama isi PHPSESSID. 9. Selanjutnya penyerang kembali ke fase pertama di langkah 1 sampai semua karakter PHPSESSID berhasil dicuri. Simulasi Serangan Saya membuat script python kecil untuk mensimulasikan bagaimana proses dekripsi dalam BEAST attack ini terjadi. Berikut ini adalah screen recording ketika script demo simulasi BEAST attack tersebut dijalankan. Source code dari script di bawah ini bisa didownload di sini: beast2.py

Saya akan jelaskan sedikit cara kerja script tersebut. Cipher yang dipakai adalah AES dengan panjang blok 16 byte, kunci dan isi teks rahasia disimpan dalam variabel key dan secret. Fungsi challengePhase1(text) ini digunakan untuk mensimulasikan serangan pada fase pertama. Teks yang dikirim ke fungsi akan ditambahkan di awal teks rahasia, “plaintext = text + secret”. Selanjutnya plainteks gabungan ini dienkrip dengan AES mode CBC dan fungsi ini mengembalikan IV+ciphertextnya. Perhatikan bahwa initialization vector pada variabel iv selalu berubah menjadi blok ciphertext terakhir. Hanya IV pertama yang digenerate secara random.

Fungsi challengePhase2(text) mensimulasikan serangan pada fase kedua (fase tebakan). Teks yang dikirim ke fungsi adalah plainteks yang dipilih (chosen plaintext) untuk dienkrip. Fungsi mengembalikan ciphertext hasil enkripsinya. Pada fungsi ini IV juga selalu diubah menjadi blok ciphertext terakhir.

Setelah kita siapkan dua fungsi untuk fase pertama dan fase kedua, sekarang kita lihat bagaimana penyerang melakukan serangannya (tentu dalam simulasi). Pertama penyerang akan membuat r yang berisi banyak karakter NULL (0x00) sebagai teks yang akan disisipkan untuk menggeser blok plainteks. Pada awalnya r akan berisi 15 karakter NULL untuk menebak karakter pertama secret. Berikutnya r berisi 14 karakter NULL untuk menebak karakter kedua secret dan seterusnya.

Blok loop di bawah ini adalah blok yang melakukan tebakan mulai dari karakter ASCII 32 sampai karakter ASCII 127 (karena kita tahu plainteks adalah printable ASCII). Guess block G adalah r + satu karakter ASCII antara 32-127 dan chosen plainteks (challengeblock) yang akan dienkrip adalah Ci XOR IV XOR G. Keluaran dari challengePhase2 akan dibandingkan dengan cipherteks yang dicari, bila sama, maka karakter yang dicari berhasil ditemukan.

Ada situs yang membuat demo/simulasi BEAST attack dalam javascript, silakan kunjungi BEAST demo. in Cryptography | 3,093 Words | 15 Comments

Compression Side Channel Attack – CRIME Attack Kompresi selain berguna untuk menghemat ruang dan waktu, namun ternyata ada sisi lain dari kompresi yang bisa membahayakan. Kompresi bisa disalahgunakan untuk mencuri data yang telah dilindungi dengan enkripsi. Kebocoran informasi dari kompresi ini dieksploitasi oleh Juliano Rizzo and Thai Duong dalam CRIME attack (Compression Ratio Info-leak Made Easy) untuk mencuri cookie dari web yang dilindungi SSL. Bagi yang belum pernah mendengar CRIME attack, silakan lihat dulu youtube CRIME vs startups yang mendemokan bagaimana CRIME attack mampu dengan cepat membajak account Dropbox, Github dan Stripe yang menggunakan HTTPS. CRIME attack mampu mencuri data yang telah dienkrip dalam paket SSL satu byte demi satu byte sampai akhirnya semua cookie berhasil dicuri. Gara-gara CRIME attack ini fitur kompresi SSL dalam Google Chrome dimatikan, sehingga praktis kini tidak ada lagi browser yang mendukung kompresi SSL. Dalam tulisan ini saya akan membahas mengenai bagaimana memanfaatkan kebocoran informasi dari ukuran paket data yang terkompres untuk mendekrip paket SSL seperti yang digunakan dalam CRIME attack. Algoritma Kompresi Algoritma kompresi dalam memampatkan data ada dua pendekatan, ada yang menghilangkan sebagian datanya, ada yang menjaga datanya tetap untuh 100%. Lossless compression Lossless compression adalah jenis kompresi yang memampatkan data dalam suatu cara tertentu sedemikian hingga bisa dikembalikan ke bentuk semula lagi tanpa ada data yang hilang. Contoh algoritma kompresi lossless adalah deflate, run-length encoding. Dalam tulisan ini kita menggunakan deflate (dan turunannya zip, gzip) karena deflate adalah algoritma kompresi yang dipakai untuk memampatkan halaman web. Lossy compression Lossy compression adalah jenis kompresi yang memampatkan data dengan cara menghilangkan sebagian data sehingga data hasil kompresi tidak bisa dimekarkan kembali ke bentuk semula 100%. Contoh lossy compression adalah format video, musik dan gambar. Dengan menggunakan lossy compression pasti akan terjadi penurunan kualitas gambar, video atau musik karena ada data yang dihilangkan. Lossy compression hanya boleh dipakai untuk data-data yang memang boleh dikurangi sebagian datanya dengan menurunkan kualitasnya seperti gambar, video dan musik. Lossy compression tidak boleh dipakai untuk data-data yang harus utuh 100% seperti data transaksi, data financial dan lain-lain. Algoritma Kompresi Kita sebenarnya sudah sering menggunakan kompresi dalam percakapan sehari-hari tanpa kita sadari seperti contoh-contoh berikut: PPPK (4 byte) biasa disingkat menjadi P3K (3 byte) karena kita lebih mudah menyebut kotak P3K daripada kotak PPPK PPPP (4 byte) biasa disingkat menjadi P4 (2 byte) karena kita lebih mudah menyebut penataran P4 daripada penataran PPPP Contoh kompresi yang dilakukan di atas adalah algoritma RLE (run length encoding), yang intinya mengganti suatu karakter [X] yang berulang n kali dengan n[X]. Contoh lain kompresi yang dipakai sehari-hari adalah bahasa alay contohnya: “demi apa” (8 byte) menjadi “miapah” (6 byte) “terimakasih” (11 byte) menjadi “maacih” (6 byte) “sama-sama” (9 byte) menjadi “macama” (6 byte) “sama siapa” (10 byte) menjadi “macapa” (6 byte) Kompresi yang dipakai di dunia komputer secara prinsip juga mirip dengan yang kita pakai sehari-hari. Algoritma kompresi yang dipakai dalam dunia web adalah deflate (beserta turunannya, zip/gzip). Deflate sendiri sebenarnya menggunakan algoritma kompresi LZ77 (Lempel-Ziv 1977) dan huffman coding. LZ77 bekerja dengan cara mengurangi redundancy dengan mengganti teks yang redundan dengan perintah untuk menyalin teks yang sama dari tempat lain di belakangnya (sebelumnya). Perintah untuk menyalin teks adalah dalam bentuk triplet: Jarak atau offset ke belakang, yaitu berapa karakter jarak ke belakang dari posisi sekarang Panjang karakter yang disalin, yaitu berapa banyak karakter yang akan disalin Karakter sesudahnya, yaitu karakter sesudah proses salin dilakukan Perhatikan contoh teks “bad mood install moodle”, teks “mood” dalam “moodle” redundan dengan teks “mood” 13 karakter di belakangnya sehingga kita tidak perlu lagi menulis lengkap “moodle”, kita cukup mengatakan [13,4,’l’] yang artinya mundur 13 karakter ke belakang dan salin 4 karakter, kemudian tambahkan huruf ‘l’. Jadi bentuk kompresi “bad mood install moodle” bisa disingkat menjadi “bad mood install [13,4,l]e”

Pada LZ77 ada batasan sejauh mana dia boleh melihat ke belakang dan ke depan untuk mencari kecocokan/redundansi, jarak pandang ini disebut lebar jendela karena dalam prosesnya digunakan jendela geser (sliding window). Seandainya lebar jendelanya adalah 10, walaupun teks “mood” redundan, tapi karena jaraknya (13) di luar batas jendela, maka tidak akan diganti. Jadi lebar jendela ini mirip dengan jarak pandang, kalau jarak pandangnya hanya 10, dia tidak akan melihat bahwa ada teks “mood” juga 13 karakter di belakangnya karena maksimum hanya bisa melihat 10 karakter ke belakang. Contoh yang sedikit berbeda untuk teks “Blah blah blah blah!” bisa dikompresi menjadi “Blah b[5,13,!]”. Kali ini agak sedikit aneh karena kita mundur 5 langkah tapi yang dicopy adalah 13 karakter, hal ini terjadi karena LZ77 mencari “longest match”. Gambar di bawah ini adalah proses dekompresi dari “Blah b[5,13,’!’]” menjadi “Blah blah blah blah!”, perhatikan bahwa proses copy-paste dilakukan bertahap, 5 byte, 5 byte dan 3 byte.

Algoritma kompresi LZ77 menggunakan 2 sliding window (jendela geser), search buffer dan look-ahead buffer. Sliding window selalu bergeser ke kanan setiap memproses satu karakter. Search buffer adalah buffer history, karakter yang sudah dilalui sedangkan look ahead buffer adalah karakter yang akan diproses. LZ77 akan mencari apakah ada teks dalam search buffer yang sama dengan teks dalam look ahead buffer. Jadi lebar sliding window menentukan sejauh mana dia melihat ke belakang dan sejauh mana dia melihat ke depan. Mari kita lihat lebih langkah per langkah bagaimana LZ77 memampatkan teks “ratatatat a rat at a rat” berikut ini. Pada mulanya search buffer masih kosong dan look-ahead buffer dimulai dari karakter pertama ‘r’. Pada posisi ini akan dicari apakah ada teks dalam search yang cocok dengan look-ahead buffer ? Karena tidak ada yang cocok, maka karakter pertama ‘r’ masuk ke search buffer dan look-ahead buffer bergeser ke kanan satu karakter.

Pada langkah ke-2, look-ahead buffer dimulai dari karakter ke-2 ‘a’ dan search buffer hanya berisi satu karakter. Pada langkah kedua ini juga tidak ditemukan kecocokan sehingga karakter kedua ‘a’ masuk ke search buffer dan look-ahead buffer bergeser ke kanan.

Pada langkah ke-3, look-ahead buffer dimulai dari karakter ke-3 ‘t’ dan search buffer berisi ‘ra’. Pada langkah ke-3 ini juga tidak ditemukan kecocokan sehingga karakter ke-3 ‘t’ masuk ke search buffer dan look-ahead buffer bergeser ke kanan.

Pada langkah ke-4, look ahead buffer dimulai dari karakter ke-4 ‘a’ dan search buffer berisi ‘rat’. Perhatikan bahwa kali ini kita mendapatkan kecocokan pada teks ‘atatat’ di lookahead buffer dengan teks ‘at’ pada search buffer. Teks ‘atatat’ pada look-ahead bisa diganti dengan [2,6,’_’] yang artinya mundur 2 langkah, copy dan paste sebanyak 6 karakter kemudian tambahkan karakter underscore.

Setelah menemukan kecocokan, 6 karakter dan satu karakter ‘_’ di look-ahead buffer masuk ke dalam search buffer, dan look-ahead buffer bergeser ke posisi sesudah karakter ‘_’.

Selanjutnya prosesnya bisa dilanjutkan sampai semua karakter selesai diproses. Kurang lebih seperti itulah cara LZ77 melakukan kompresi. Compression Information Leakage Sebelumnya sudah kita bahas cara kerja lossless compression adalah dengan menyingkat data yang bisa disingkat (data yang berulang, redundan atau duplikat). Cara kerja kompresi yang seperti ini bisa membocorkan informasi dan dijadikan petunjuk untuk mengambil informasi rahasia yang sudah dilindungi enkripsi. Bagaimana caranya ? Ingat dalam algoritma losssless compression, data yang redundan atau duplikat akan dihilangkan atau disingkat. Namun tidak semua data bisa dimampatkan, bila tidak ada redundancy atau duplikat sama sekali, maka kompresi tidak membuat panjangnya menjadi lebih kecil. Gambar di bawah ini adalah dua himpunan data A dan B yang sama sekali berbeda, tidak ada sedikitpun kesamaan antara keduanya. Dalam kasus ini, panjang union A dan B adalah panjang A + panjang B atau dalam notasi matematika, n(A È B) = n(A) + n(B).

Algoritma kompresi lossless tidak bisa memampatkan data yang seperti ini. Panjang hasil kompresi dari A+B adalah panjang A+B bahkan mungkin malah lebih besar karena adanya overhead tambahan seperti header file. Bila kita memampatkan data A dan B, kemudian melihat panjangnya ternyata lebih besar atau sama dengan panjang A+B, maka tanpa melihat isi A dan B kita yakin bahwa tidak ada data yang beririsan, kita yakin bahwa A dan B benar-benar berbeda, sekali lagi, tanpa melihat isi A dan B. Kasusnya berbeda bila ada sebagian dari B yang ada di A atau semua isi B sudah ada di A seperti gambar di bawah ini. Irisan antara A dan B adalah data yang redundan atau duplikat. Dalam kasus ini berlaku, n(A È B) = n(A) + n(B) – n(A Ç B) atau panjang A + panjang B – panjang data yang redundan sehingga panjang kompresi A+B akan lebih kecil dari panjang A + panjang B.

Lalu dimana letak kebocoran informasinya? Kebocoran informasinya adalah pada panjang data hasil kompresi. Bila hasil kompresi A dan B lebih kecil dari panjang A dan panjang B, tanpa melihat isi A dan B, kita tahu bahwa ada irisan antara A dan B. Bayangkan bila A adalah data rahasia yang tidak kita ketahui isinya. Kita bisa menebak isi A dengan menambahkan B sebagai tebakan isi A, kemudian melihat apakah panjang kompresi A+B lebih kecil atau tidak. Bila panjang hasil kompresinya lebih kecil artinya tebakan kita benar, ada sebagian dari guess yang ada di A. Gambar di bawah memperlihatkan bila tebakan kita salah, maka tidak ada irisannya, bila tebakan kita benar maka akan ada irisannya. Semakin banyak irisan antara guess dan data rahasia yang dicari, rasio kompresinya akan semakin tinggi (semakin kecil panjang hasil kompresi secret+guess).

Jadi kita bisa mengetahui jawaban dari “apakah dalam A mengandung ‘ab’ ?” dengan melihat hasil kompresi A + “ab”, bila hasilnya lebih kecil artinya jawaban atau tebakan kita benar. Bila tebakan kita salah kita bisa coba lagi dengan “apakah dalam A mengandung ‘ac’ ?” dan seterusnya. Bermain di Perbatasan Dalam block cipher encryption, data dan padding byte disusun dalam blok-blok berukuran sama, contohnya dalam AES-128 data disusun dalam blok berukuran 16 byte. Karena data disusun dalam blok maka record SSL akan berukuran kelipatan “block size”, bukan lagi berukuran sejumlah total size data dalam byte. Sebagai contoh, data yang berisi string “database mysql” yang berukuran panjang 14 byte, dalam block cipher akan diperlakukan sebagai data yang berukuran 16 byte atau satu blok dengan menambahkan padding. Jadi walaupun datanya berukuran 14, kita akan melihat encrypted packet yang berukuran 16 atau 1 blok. Bila string “database mysql” kita tambahkan dengan huruf ‘w’ di awal menjadi string “wdatabase mysql”, dari sudut pandang SSL, data tersebut berukuran sama dengan string sebelumnya, yaitu masih 16 byte. Dari sudut pandang string string yang baru ukurannya lebih panjang satu byte, tapi dari sudut pandang block-cipher ukurannya sama, yaitu samasama satu blok. Gambar di bawah ini menunjukkan bagaimana data “wdatabase mysql” disimpan dalam blok (kotak berwarna merah adalah padding).

Apa yang terjadi bila string “wdatabase mysql” ditambahkan huruf ‘w’ lagi di awal ? Ternyata string tersebut tepat berukuran 16 byte. Bila datanya sudah berukuran sama dengan ukuran blok, maka harus ditambahkan satu blok kosong yang berfungsi sebagai padding. String “wwdatabase mysql” yang berukuran 16 byte dari sudut pandang blockcipher berukuran 32 byte. Jadi walaupun kita hanya menambahkan satu byte saja, ternyata ukuran encrypted packet bukan bertambah 1 tapi malah bertambah 16 byte. Dalam situasi ini berarti string “wdatabase mysql” adalah string yang sudah berada di pinggir batas wilayah, tinggal satu langkah lagi untuk keluar dari batas blok.

Bila kita tambahkan lima huruf ‘w’ lagi di awal tidak akan merubah ukuran encrypted packet, ukurannya masih 32 byte. Ukuran encrypted packet tidak berubah karena datanya masih muat dalam 2 blok.

Ukuran encrypted packet hanya akan bertambah bila kita menambahkan data di “perbatasan” blok. Tadi kita sudah lihat bagaimana menambahkan satu huruf saja membuat blok bertambah, hal tersebut terjadi karena data yang ditambahkan sudah berukuran satu byte kurang dari kelipatan 16 (di perbatasan blok). Penting untuk diperhatikan bahwa karena kita tidak mungkin melihat isi data dari paket SSL, kita hanya bisa melihat panjang datanya, dan panjang data tersebut dalam kelipatan panjang blok bukan jumlah total byte datanya. Mencari Perbatasan Tadi kita sudah bahas bagaimana panjang encrypted paket bisa mengembang data ditambahkan sedemikian hingga melewati batas blok. Lalu dimana sebenarnya batas itu? Menentukan batas tidak sulit, hanya diperlukan beberapa percobaan saja. Sebagai contoh kasus saya sudah menyiapkan sebuah website yang dilindungi dengan SSL: https://localhost:8443/kripto/kompres.php?search=text URL tersebut menerima input parameter GET kemudian mengirimkan kembali (echoing) isi parameter ‘search’ tersebut dalam response. Ada banyak web yang meng-echo-kan kembali input dari user, contoh paling sering adalah pada fitur pencarian (contoh: “Your search query is bla bla bla”).

Jadi masukan user dalam parameter ‘search’ akan menjadi bagian dari response dari server. Semakin besar data yang dikirimkan user, panjang response dari server juga semakin besar. Gambar ini menunjukkan script findboundary.sh yang melakukan request ke kompres.php dengan parameter search (“qo4vxmG….+RAHASIA:”) yang panjangnya bertambah terus. Dalam 10 request pertama, panjang paket data SSL adalah tetap 454 tidak bertambah panjang walaupun dalam setiap request parameter search selalu bertambah satu karakter. Pada request ke-11 (parameter search sudah ditambahkan 11 karakter), baru terlihat ada perubahan panjang paket SSL. Pada request tersebut ternyata panjang paket SSL menjadi 470, atau bertambah 16 byte atau bertambah 1 blok. Disini kita berarti berada pada situasi dimana data sudah di perbatasan, melangkah satu langkah lagi kita sudah berada di luar blok. Bila data sudah berada pada batas blok, menambah satu karakter lagi akan membuat panjang data bertambah satu blok.

Gambar di bawah ini adalah script yang sama namun dilihat dengan tcpdump. Pada request ke-11 panjang paket bertambah 16 byte (1 blok) dari 378 ke 394. TCP dump menampilkan panjang paket 378-394 adalah panjang dari layer TCP ke atas, sedangkan wireshark menunjukkan 454-470 adalah panjang frame dari layer IP sampai atas.

Jadi kini kita sudah mengetahui panjang data dimana bila ditambahkan satu byte lagi, jumlah blok akan bertambah satu. Simulasi Attack Sekarang kita mulai mendemokan serangan ini dengan contoh file kompres.php yang sudah dijelaskan di atas. Dalam page tersebut ada kode rahasia “RAHASIA:topsecret2013” dan input dari client dituliskan di sebelahnya jadi input dari user juga menjadi bagian dari respons. Bila user mengirimkan input berisi “test” maka panjang respons dari server akan bertambah 4 (kita kesampingkan dulu adanya blok). Namun bila user mengirimkan input berisi “RAHASIA:” atau “RAHASIA:t” atau “RAHASIA:to” maka panjang respons dari server bukan bertambah tapi tetap atau berkurang ada string yang sama muncul dua kali (redundan). Ini penting untuk diingat karena yang akan kita jadikan indikator apakah tebakan kita benar atau salah adalah panjang respons. Sebelumnya kita sudah mendeteksi boundary atau batas blok dengan input parameter search adalah “qo4vxmGlcKzYpUKk9CmQwZ8uEq+RAHASIA:”. Bila kita tambahkan satu karakter lagi pada parameter search ini, maka panjang respons data akan bertambah satu blok, kecuali bila data tambahan tersebut beririsan atau redundan dengan data yang sudah ada sehingga kita bisa membedakan apakah tebakan kita benar atau salah dengan melihat apakah panjang paket SSL bertambah satu blok atau tidak. Skenario Attack Serangan ini sebenarnya dilakukan dalam situasi dimana seorang peretas ingin mencuri data rahasia milik korban di situs yang dilindungi SSL. Dalam skenario ini si peretas hanya bisa membuat korban mengirim request berisi parameter search yang sudah dirancang khusus namun tidak bisa membaca responsnya karena dilindungi oleh SSL. Walaupun tidak bisa membaca isi paket SSLnya, si peretas bisa membaca panjang paket SSL tersebut. Berikut adalah salah satu skenario yang memungkinkan dalam attack ini. 1. Seorang peretas berada dalam posisi MITM (man in the middle) bisa secara aktif memanipulasi http respons dan bisa menyisipkan javascript ke browser korban khusus untuk situs NON-SSL (situs dengan SSL tidak bisa dimanipulasi). Dia juga bisa secara passif melakukan sniffing traffic yang lewat antara korban dan situs bank, namun untuk situs yang dilindungi SSL, dia tidak bisa membaca isinya. 2. Korban membuka situs NON-SSL, berita.com. Diam-diam si peretas mencegat dan mengubah response HTTP dari server berita.com untuk menyisipkan malicious html yang akan dieksekusi di browser korban. 3. Malicious html membuka halaman evil.com dalam hidden iframe sehingga javascript dari evil.com diload di browser korban tanpa disadari korban 4. Javascript di browser korban memaksa browser untuk mengirimkan (cookiebearing) request ke situs HTTPS://bank.com dengan parameter search yang sudah dirancang khusus dengan karakter tebakan 5. Si peretas mengamati panjang encrypted packet yang lewat baik request dari korban maupun response dari server bank.com. Dengan melihat panjang paketnya saja dia bisa mengetahui apakah tebakannya benar atau salah

Apa itu cookie bearing request? Cookie bearing request itu sebenarnya request HTTP biasa, GET atau POST, hanya saja karena dilakukan dalam browser yang sama (walaupun dalam tab yang berbeda), maka setiap request akan otomatis membawa cookie untuk situs tersebut ( ini sudah behaviour bawaan semua browser ). Ada banyak cara untuk memaksa browser mengirim request ke situs tertentu. Cara paling mudah dengan menaruh URL yang akan direquest (sembarang URL boleh, tidak harus URL gambar) pada atribut SRC dari tag . Suatu halaman web memang boleh merequest dan memuat gambar dari situs-situs lain. Jadi pada intinya dalam serangan ini peretas memaksa browser korban mengirim request dengan parameter khusus ke situs target kemudian mengamati panjang paket SSL yang lewat Dalam tulisan ini saya hanya melakukan simulasi saja, saya tidak menggunakan javascript untuk membuat cookie-bearing request. Saya hanya mensimulasikan dengan curl kemudian mengamati paket yang lewat dengan tcpdump/wireshark. Mencari Karakter Pertama Kita sudah menemukan bahwa menambahkan satu karakter sesudah parameter “qo4vxmGlcKzYpUKk9CmQwZ8uEq+RAHASIA:” akan membuat panjang paket SSL naik dari 378 menjadi 394. Namun tidak semua huruf akan mebuat paket SSL menjadi 394, akan ada satu huruf yang panjang paketnya adalah 378. Berikut adalah source code script untuk melakukan brute force dari a-z.

Sebelum script tersebut dijalankan kita harus menjalankan tcpdump atau sniffer dulu karena kita akan menangkap paket SSL dan mengamati panjang paketnya. Gambar berikut ini adalah eksekusi script brute-atoz.sh dan hasil tcpdump ketika 26 request di atas dijalankan. Terlihat bahwa dari 26 huruf, hanya ada satu huruf yang panjang paket SSLnya adalah 378. Dari hasil ini kita yakin bahwa karakter pertama adalah huruf ‘t’.

Kalau kita lihat dengan wireshark hasilnya juga sama, tepat ketika kita mencoba guess “RAHASIA:t” panjang paket SSL berbeda sendiri, tidak bertambah 16 byte seperti yang lainnya.

Kenapa bisa begitu, apa yang sebenarnya terjadi? Mari kita lihat apa yang terjadi di sisi server. Tadi kita sudah lihat bahwa dalam response HTTP terdapat teks “RAHASIA:topsecret2013”. Kalau kita kirim parameter search “RAHASIA:x” maka teks input dari user dan teks dari server yang redundan hanya sampai “RAHASIA:”, sedangkan sisanya huruf ‘x’ tidak redundan yang menyebabkan huruf ‘x’ tersebut menambah panjang respons sebesar satu byte. Ingat karena kita bermain di perbatasan, penambahan satu panjang data satu huruf akan menambah satu blok. Sedangkan bila kita mengirim request “RAHASIA:t” maka parameter tersebut redundan semua sehingga setelah dikompresi tidak menambah panjang data. Perhatikan bahwa walaupun sebenarnya data ditambah satu huruf ‘t’ tapi penambahan huruf tersebut tidak membuat panjang data bertambah satu huruf karena algoritma kompresi bekerja. Itulah yang terjadi mengapa “RAHASIA:t” berbeda sendiri dengan “RAHASIA:a”, “RAHASIA:b” dan yang lainnya.

Mencari karakter ke-2 Setelah kita mengetahui karakter pertama adalah ‘t’, maka kita akan mencari karakter ke-2 dengan mengirimkan request “RAHASIA:ta” sampai “RAHASIA:tz”. Hasil sniffing di bawah ini menunjukkan bahwa ketika kita mengirim request “RAHASIA:to” panjang paket menjadi 378, artinya “RAHASIA:to” beririsan dengan teks yang kita cari sehingga kita yakin bahwa dua karakter pertama adalah “to”.

Mencari karakter ke-3 Kita lanjutkan prosesnya untuk mencari karakter ke-3. Kali ini kita mengirimkan request “RAHASIA:toa” sampai dengan “RAHASIA:toz”. Hasil sniffing menunjukkan bahwa request “RAHASIA:top” beririsan dengan teks yang kita cari sehingga kita yakin bahwa karakter ke-3 adalah “p”.

Mencari karakter ke-4 Sekarang kita lanjutkan prosesnya untuk mencari karakter ke-4. Kali ini kita mengirim request dengan parameter “RAHASIA:topa” sampai dengan “RAHASIA:topz”. Hasil sniffing menunjukkan bahwa karakter ke-4 adalah huruf ‘s’ sehingga kita sudah menemukan 4 karakter pertama yaitu “tops”.

Mencari karakter ke-5 Kita akan mengirim request “RAHASIA:topsa” sampai dengan “RAHASIA:topsz” untuk mencari karakter ke-5. Hasil sniffing menunjukkan bahwa karakter ke-5 adalah huruf ‘e’ sehingga kita sudah menemukan 5 karakter pertama yaitu “topse”.

Proses pencarian 5 karakter pertama ini saya pikir sudah cukup sebagai proof-of-concept, bila kita teruskan proses ini kita akan mendapatkan semua karakter dari teks rahasia yang ingin dicari. in Cryptography | 3,225 Words

XML Encryption Attack XML Encryption adalah bagian dari standar xml security yang dibuat oleh W3C. XML encryption mendefinisikan standar bagaimana mengenkrip dokumen XML dengan granularitas tinggi, mulai dari mengenkrip seluruh dokumen XML atau hanya salah satu elemen saja dalam XML. Dalam tulisan ini saya akan membahas paper dari ilmuwan Jerman tahun 2011 berjudul “How to break XML encryption” yang memaparkan bagaimana memecahkan enkripsi XML encryption. Teknik dekripsi XML encryption ini juga menggunakan “oracle” walaupun sedikit berbeda tetapi sangat disarankan untuk membaca dulu tulisan saya sebelumnya tentang padding oracle attack agar lebih mudah membaca tulisan ini karena beberapa konsep yang sudah dibahas disana tidak saya ulangi lagi disini. XML Encryption Cara untuk mengirimkan data yang terstruktur dari satu tempat ke tempat lain ada banyak cara, antara lain dengan JSON, YAML dan yang paling populer adalah XML. XML dipakai di banyak aplikasi, termasuk dalam aplikasi e-commerce dan web service sehingga kebutuhan untuk menjaga kerahasiaan data dalam XML sangat tinggi. Bayangkan bila XML dipakai untuk mengirimkan purchase order seperti dibawah ini. Tentu sangat riskan bila data rahasia seperti kratu kredit dikirimkan apa adanya tanpa dilindungi kerahasiaannya dengan enkripsi.

Standar XML Encryption memiliki granularitas tinggi dalam hal data apa yang akan dienkripsi dalam XML. Kita bisa mengenkrip seluruh dokumen XML tersebut seperti dibawah ini.

Kita juga bisa hanya mengenkrip tag Payment dan semua sub-tagnya saja, sedangkan tag Order tidak dienkrip.

Bahkan bila data yang perlu dirahasiakan hanya data dalam tag CardId saja, sedangkan CardName, ValidDate tidak perlu dirahasiakan, itu juga bisa dilakukan dengan XML encryption.

Skema Padding XML Encryption Soal padding sudah saya bahas panjang lebar di tulisan saya tentang padding oracle attack, dalam tulisan tersebut padding yang dipakai adalah standar PKCS#5 dan PKCS#7. XML encryption juga menggunakan padding untuk menggenapi plaintext menjadi berukuran tertentu sesuai dengan algoritma enkripsi yang dipakai seperti AES dengan blok berukuran 16 byte. Padding pada standar XML Encryption berbeda dengan padding menurut aturan PKCS#5/#7. Byte terakhir menjadi petunjuk panjang padding byte, dalam hal ini masih sama dengan PKCS#5/#7. Namun bedanya dengan PKCS#5/#7, byte-byte yang menjadi padding pada standar XML encryption, boleh bernilai apapun, tidak harus bernilai sama dengan byte terakhir. Sebagai contoh, bila byte terakhir bernilai 03, sesuai standar PKCS, 3 byte terakhir juga harus bernilai 03-03-03, sementara dalam standar XML encryption, 2 byte sebelum byte terakhir boleh bernilai apapun, tidak harus sama dengan byte terakhir. Jadi padding XML encryption dikatakan valid bila byte terakhirnya bernilai antara 01-10 (bila satu blok berukuran 16 byte), tanpa perlu lagi melihat byte-byte sebelumnya seperti pada standar PKCS. Berikut adalah contoh-contoh padding yang valid.

AXIS sebagai “The Oracle” Dalam tulisan ini kita menggunakan web service berbasis AXIS. Apache AXIS adalah salah satu implementasi dari protokol SOAP open source yang digunakan untuk web service. Strategi attack ini adalah dengan mengirimkan “specially crafted”, ciphertext yang sudah kita susun sedemikian rupa sehingga ketika dikirimkan ke AXIS, dia akan meresponse dengan jawaban yes/no, valid/invalid yang bisa kita pakai untuk menebak-nebak hasil dekripsi ciphertext kita. Sebelumnya kita harus mengenal dulu jenis respons yang diberikan oleh AXIS. Pertama adalah jenis error “security fault”, cirinya adalah jika kita menerima respons XML berikut ini.

Security fault bisa terjadi karena dua hal: Incorrect Padding Error ini terjadi bila byte terakhir bukan berada pada rentang 0x01-0x10 (1 byte s/d 16 byte). Illegal XML Character (XML parsing failed) Error ini terjadi bila blok berhasil didekrip (valid padding), namun plaintext hasil dekripsinya mengandung karakter yang tidak dibolehkan dalam XML atau mengandung kesalahan syntax XML. Karakter yang haram berada di XML adalah karakter dengan kode ASCII antara 00 – 1F kecuali karakter whitespace 09, 0A dan 0D. Kesalahan sintaks XML mungkin terjadi bila hasil dekripsinya mengandung karakter 3C (“