Compression Side Channel Attack – CRIME Attack

chmood
Β  Β  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”
Screen Shot 2013-04-11 at 11.27.28 PM
Screen Shot 2013-04-12 at 6.50.39 AM
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.
Screen Shot 2013-04-12 at 7.45.07 AM
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.
Screen Shot 2013-04-18 at 3.20.45 PM
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.
Screen Shot 2013-04-18 at 3.21.48 PM
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.
Screen Shot 2013-04-18 at 3.22.33 PM
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 look-ahead 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.
Screen Shot 2013-04-18 at 3.09.47 PM
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 β€˜_’.
Screen Shot 2013-04-18 at 9.42.43 PM
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).
Screen Shot 2013-04-09 at 9.49.10 PM
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.
Screen Shot 2013-04-09 at 9.59.16 PM
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).
Screen Shot 2013-04-11 at 9.28.55 AM
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 sama-sama satu blok.
Gambar di bawah ini menunjukkan bagaimana data β€œwdatabase mysql” disimpan dalam blok (kotak berwarna merah adalah padding).
Screen Shot 2013-04-09 at 6.45.39 PM
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 block-cipher 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.
Screen Shot 2013-04-09 at 6.54.29 PM
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.
Screen Shot 2013-04-09 at 7.02.06 PM
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”).
Screen Shot 2013-04-09 at 8.12.52 PM
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.
Screen Shot 2013-04-09 at 9.04.09 PM
Β 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.
Screen Shot 2013-04-09 at 7.19.03 AM
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 (cookie-bearing) 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
Screen Shot 2013-04-09 at 11.39.22 PM
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 <IMG>. 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.
Screen Shot 2013-04-08 at 11.34.02 PM
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’.
Screen Shot 2013-04-12 at 8.29.32 PM
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.
Screen Shot 2013-04-09 at 5.45.36 AM
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.
Screen Shot 2013-04-12 at 4.48.55 PM
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”.
Screen Shot 2013-04-12 at 8.27.03 PM
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”.
Screen Shot 2013-04-12 at 8.22.48 PM
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”.
Screen Shot 2013-04-12 at 8.15.13 PM
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”.
Screen Shot 2013-04-12 at 6.38.24 PM

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.

Β  Β  Β  Β  Β  Β  Β  Β  Β  Β  Β  Β  Β  Β  Β  Β  Β  Β 


If you enjoyed this article, please consider sharing it!
Category
Komentar