if99.net

IF99 ITB

Archive for April, 2013

Blockwise Chosen Boundary Attack – BEAST Attack

without comments

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).

Screen Shot 2013-04-19 at 12.43.42 AM

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.

Screen Shot 2013-03-10 at 6.54.29 PM

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.

Screen Shot 2013-04-20 at 12.07.53 PM

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.

Screen Shot 2013-04-20 at 1.20.15 PM

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 ?

Screen Shot 2013-04-20 at 2.25.16 PM

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”.

Screen Shot 2013-04-20 at 2.30.24 PM

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”’.

Screen Shot 2013-04-20 at 2.32.19 PM

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.

Screen Shot 2013-04-20 at 3.26.55 PM

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.

Screen Shot 2013-04-20 at 3.35.27 PM

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:

Screen Shot 2013-04-20 at 3.40.24 PM

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.

Screen Shot 2013-04-20 at 3.51.58 PM

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 di-XOR 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.

Screen Shot 2013-04-20 at 4.15.48 PM

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.

Screen Shot 2013-04-20 at 4.15.57 PM

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’.

Screen Shot 2013-04-20 at 4.16.04 PM

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 ?

Screen Shot 2013-04-20 at 5.29.22 PM

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:

Screen Shot 2013-04-20 at 5.37.59 PM

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.

Screen Shot 2013-04-20 at 5.45.51 PM

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.

Screen Shot 2013-04-20 at 6.23.31 PM

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.

Screen Shot 2013-04-20 at 6.28.12 PM

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 (0×00) 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.

Screen Shot 2013-04-20 at 6.31.13 PM

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.

Screen Shot 2013-04-20 at 6.32.15 PM

Ada situs yang membuat demo/simulasi BEAST attack dalam javascript, silakan kunjungi BEAST demo.

Written by Rizki Wicaksono

April 20th, 2013 at 6:47 pm

Posted in Cryptography

Kisruh UN 2013 Berawal dari Peraturan Itu Sendiri

without comments

Koran Kompas, 18 April 2013 halaman 12 memuat berita berjudul “Tipis, Lembar Jawaban UN Sulit Dipindai”.
LJUN Tipis 500

Pemeriksaan UN menggunakan scanner adalah pekerjaan rutin tahunan, lalu apa yang menyebabkan pemeriksaan tahun ini berbeda?

Setiap ruangan akan mendapatkan 21 jenis paket soal yang terdiri dari 20 jenis paket soal untuk peserta dan 1 jenis paket soal cadangan. Lembar Jawaban Ujian Nasional (LJUN) melekat pada naskah soal dan dapat dipotong, untuk memotong lembar jawaban dari lembar soal harus hati-hati agar tidak tersobek.

Setelah lembar jawaban dan soal dipisahkan, selanjutnya silahkan mengisi biodata. Biodata yang diisi harus sesuai dengan yang tertera pada kartu tanda peserta ujian, pada lembar soal juga tidak ada nomor paket, yang ada hanya barcode dan setiap soal itu kemungkinan tidak sama.

Sumber: http://sumsel.kemenag.go.id/index.php?a=berita&id=124069

Kesalahan fatal di sini adalah:

  1. LJUN disobek dari soal, sehingga LJUN menggunakan bahan kertas yang massa jenisnya sama dengan kertas soal, yaitu 70 gsm (baca: 70 gram per meter persegi). Hal ini tidak mengapa bila yang digunakan adalah scanner LJK DMR yang mampu mentolerir kertas tipis. Adapun bila menggunakan scanner OMR (sebagaimana pada UN SMA), umumnya digunakan kertas yang lebih tebal, 100gsm. Mengapa demikian? Scanner OMR tidak mentolerir masuknya kertas yang miring, apalagi ada bekas sobekan yang tidak lurus. Kertas 70gsm sangat letoy dan berpotensi miring saat masuk ke scanner. Oleh karenanya, LJK OMR harus kaku dan tebal. Dengan scanner OMR, bila kertas masuk miring atau ada error, scanning harus diulang. Akibatnya, scanner OMR yang katanya berkecepatan 5000 per jam, pada kenyataannya hanya 1000 sampai 2000 per jam. Ibarat angkutan kota yang top speed-nya 120 kpj, tapi di dalam kota hanya 20-40kpj karena sangat sering berhenti.
  2. Nomor paket pada LJUN tidak lagi tercetak (tak bisa dibaca mata manusia). Hal ini sangat berpotensi menimbulkan kesalahan skoring, karena bisa saja kesalahan terjadi saat pencetakan barcode maupun pembacaan barcode. Bukankah prosedur di swalayan, bila barcode tidak terbaca, petugas kasir harus melakukan entri kode secara manual dengan keyboard? Belum lagi dengan soal dan LJUN yang difotokopi. Pertama, scanner OMR tak mampu baca fotokopian, beda dengan scanner DMR. Walaupun jawabannya dipindahkan ke LJUN asli, bagaimana cara mendapatkan LJUN yang barcode kode soalnya persis sama dengan yang dikerjakan oleh siswa? Pakai mata tak bisa, barcode scanner pun tak tersedia di panitia, apalagi barcode printernya.
  3. Kerumitan pencetakan tidak dibarengi dengan ketersediaan waktu yang memadai. Setidaknya demikian kilah pengacara PT Ghalia, perusahaan percetakan yang membuat UN SMA di 11 propinsi tertunda. Apakah Anda mau membeli koran hari Senin di hari Kamis dengan harga yang sama? Apakah Anda mau melangsungkan resepsi pernikahan dahulu sebelum mencetak undangan resepsinya? Bila ternyata UN dilaksanakan di hari yang berbeda, mengapa harus mencetak soal lagi? Mengapa tidak menggunakan soal yang lama (sebagaimana buku tes psikologi yang digunakan berulang-ulang dan tipe soalnya beragam)? Penghematannya puluhan milyar rupiah lho, cukup mengeluarkan biaya ekspedisi, tak perlu biaya cetak.

Karena nila setitik, rusak susu sebelanga. Sedikit saja kesalahan panitia UN, membuat mereka dihujat publik habis-habisan. Kita doakan saja, mereka mampu fokus bekerja, tak ada siswa yang dirugikan, dan panitia UN Pusat mau belajar dari kesalahannya, tak mengulanginya lagi.

Pertanyaan berikutnya, bagaimana siswa dapat mengetahui bahwa dirinya tidak dirugikan? Bagaimana siswa dapat meyakini bahwa hasil pekerjaannya diperiksa dengan kunci kode paket soal yang sama dengan yang dikerjakannya? Bagaimana uji petik dan uji publik dapat dilakukan?

Arif Rahmat
Praktisi Pemeriksa Ujian dengan Scanner
Tim Peneliti DMR dari ITB
@arifdmr


Written by arifrahmat

April 18th, 2013 at 1:08 pm

Apa salahnya bersikap subyektif ?

without comments

 

Beberapa bulan terakhir, saya menjalankan 2 peran yang saling berlawanan yaitu sebagai dosen pembimbing dan sebagai seorang mahasiswa bimbingan. Setelah menjalani kedua peran tersebut secara bergantian, saya jadi memperoleh kesimpulan bahwa wajar saja ketika seorang pembimbing menjadi sangat subyektif terhadap mahasiswa-mahasiswa bimbingannya. Subyektif disini saya artikan sebagai perlakuan yang berbeda antara mahasiswa bimbingan yang satu dengan yang lainnya.

Seorang mahasiswa yang rajin datang, mencatat dengan baik masukan dan revisi dari pembimbing, memperbaiki proses pengerjaan sesuai arahan pembing, dan memiliki etika yang baik ketika berkomunikasi dengan pembimbing tentu punya daya tarik berbeda dibandingkan mahasiswa yang menunda-nunda bimbingan, tidak tanggap dengan arahan pembimbing, dan kurang beretika saat berkomunikasi dengan pembimbing. Saya sendiri sebagai pembimbing merasakan subyektifitas itu dan ini tak dapat dihindari.
Nah, apakah hal ini salah?
Tiap orang menuai apa yang telah ditanamnya. Akan tidak adil, menurut saya, jika saya memberikan perlakuan yang sama untuk mahasiswa bimbingan yang rajin & tidak rajin. Di saat mahasiswa A benar-benar mengerjakan revisi secara maksimal dan disertai tutur kata yang sopan ketika berdialog, sedangkan mahasiswa B yang sering tidak mencatat dengan rajin masukan dari pembimbing, tidak mau belajar serius sehingga tidak juga bisa mengerjakan revisi dari dosen, apalagi sopan santunnya kurang, mana mungkin saya memberi nilai yang sama.

Justru menurut saya, itu bukan lagi subyektifitas, malah sebuah bentuk obyektifitas karena memperlakukan orang lain sebagaimana dia bersikap. Subyektivitas yang salah adalah pilih kasih karena hubungan saudara semata atau karena pernah diberi hadiah oleh si mahasiswa misalnya. Saya justru menganggap inilah yang disebut adil, memberikan seseorang sesuai dengan haknya. Saya tetap memberikan hak kepada mahasiswa yang saya anggap kurang baik yaitu mendapatkan pendampingan selama pengerjaan tugas akhir. Saya tidak akan mengurangi nilainya karena malas belajar, tapi jujur saja, saya juga tidak akan memberikan nilai maksimal untuk mahasiswa yang seperti itu.
Jadi, jika saya seorang mahasiswa bimbingan, saya akan berusaha untuk mengambil hati pembimbing dengan cara memperhatikan dengn baik arahan & masukannya, menulis laporan serapi mungkin, serta berkomunikasi santun dengan dosen pembimbing. Pembimbing kan juga manusia, rasanya bersikap subyektif itu juga sebuah hal yang manusiawi.

 

Wassalaam,


Written by indahgita

April 18th, 2013 at 9:26 am

Posted in Bebas

Compression Side Channel Attack – CRIME Attack

without comments

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.

Written by Rizki Wicaksono

April 12th, 2013 at 8:37 pm

Posted in Cryptography

Seperti Inikah Sistem Pendidikan Kita?

without comments

Gambar kartun di bawah ini seakan menyindir sistem pendidikan di negara kita yang menganggap setiap anak didik dinilai dengan cara yang sama. Gambar kartun tersebut saya peroleh dari laman Facebook.

Our Education System

Hmmmm… padahal setiap anak didik itu unik, jadi sebenarnya tidaklah fair kalau kita memperlakukannya sama. Menilai anak didik dari satu jenis kecerdasan saja tidaklah adil. Kecerdasan itu banyak macamnya (multiple intelligence), ada kecerdasan matematik, kecerdasan bahasa, kecerdasan spasial, kecerdasan musik, dan lain-lain (lebih lengkap tentang multiple intelligence dapat dibaca di sini). Namun di dalam masyarakat kita, kecerdasan anak itu cenderung dinilai hanya dari kecerdasan matematik saja. Anak yang tidak pintar matematika dianggap anak yang bodoh, padahal mungkin saja kecerdasannya bukan pada sapek itu. Banyak orangtua yang memaksa anaknya ikut les matematika, les Kumon, dan lain-lain agar anaknya jago matematika, padahal minat dan bakat si anak boleh jadi ke arah yang lain.

Sistem pendidikan yang baik adalah yang menggali kecerdasannya setiap anak sesuai bakat atau telantanya. Sayangnya model pendidikan seperti ini belum mendapat perhatian yang serius dari Pemerintah. Mungkin banyak faktor penyebabnya (misalnya jumlah penduduk yang besar), tetapi mungkin juga karena masih ada paradigma bahwa semua pelajaran harus diberikan kepada semua anak, tidak peduli anak tersebut suka atau tidak, tidak peduli cocok dengan kebutuhannya atau tidak. Akhirnya, seperti gambar di atas, semua anak dilihat (baca: dinilai) dengan cara yang sama yang sebenarnya tidak fair. Tidak fair karena untuk kemampuan anak yang bermacam-macam dianggap adil dengan menilainya hanya dari satu aspek kecerdasan saja.


Written by rinaldimunir

April 9th, 2013 at 5:14 pm

Posted in Pendidikan

Pidato Wisudawan Terbaik, Memukau tetapi Sekaligus “Menakutkan”

without comments

Setiap acara wisuda di kampus ITB selalu ada pidato sambutan dari salah seorang wisudawan. Biasanya yang terpilih memberikan pidato sambutan adalah pribadi yang unik, tetapi tidak selalu yang mempunyai IPK terbaik. Sepanjang yang saya pernah ikuti, isi pidatonya kebanyakan tidak terlalu istimewa, paling-paling isinya kenangan memorabilia selama menimba ilmu di kampus ITB, kehidupan mahasiswa selama kuliah, pesan-pesan, dan ucapan terima kasih kepada dosen dan teman-teman civitas academica.

Namun, yang saya tulis dalam posting-an ini bukan pidato wisudawan ITB, tetapi wisudawan di Amerika. Beberapa hari yang lalu saya menerima kiriman surel dari teman di milis dosen yang isinya cuplikan pidato Erica Goldson pada acara wisuda di Coxsackie-Athens High School, New York, tahun 2010. Erica Goldson adalah wisudawan yang lulus dengan nilai terbaik pada tahun itu. Isi pidatonya sangat menarik dan menurut saya sangat memukau. Namun, setelah saya membacanya, ada rasa keprihatinan yang muncul (nanti saya jelaskan).Cuplikan pidato ini dikutip dari tulisan di blog berikut: http://pohonbodhi.blogspot.com/2010/09/you-are-either-with-me-or-against-me.html

“Saya lulus. Seharusnya saya menganggapnya sebagai sebuah pengalaman yang menyenangkan, terutama karena saya adalah lulusan terbaik di kelas saya. Namun, setelah direnungkan, saya tidak bisa mengatakan kalau saya memang lebih pintar dibandingkan dengan teman-teman saya. Yang bisa saya katakan adalah kalau saya memang adalah yang terbaik dalam melakukan apa yang diperintahkan kepada saya dan juga dalam hal mengikuti sistem yang ada.

Di sini saya berdiri, dan seharusnya bangga bahwa saya telah selesai mengikuti periode indoktrinasi ini. Saya akan pergi musim dingin ini dan menuju tahap berikut yang diharapkan kepada saya, setelah mendapatkan sebuah dokumen kertas yang mensertifikasikan bahwa saya telah sanggup bekerja.

Tetapi saya adalah seorang manusia, seorang pemikir, pencari pengalaman hidup – bukan pekerja. Pekerja adalah orang yang terjebak dalam pengulangan, seorang budak di dalam sistem yang mengurung dirinya. Sekarang, saya telah berhasil menunjukkan kalau saya adalah budak terpintar. Saya melakukan apa yang disuruh kepadaku secara ekstrim baik. Di saat orang lain duduk melamun di kelas dan kemudian menjadi seniman yang hebat, saya duduk di dalam kelas rajin membuat catatan dan menjadi pengikut ujian yang terhebat.

Saat anak-anak lain masuk ke kelas lupa mengerjakan PR mereka karena asyik membaca hobi-hobi mereka, saya sendiri tidak pernah lalai mengerjakan PR saya. Saat yang lain menciptakan musik dan lirik, saya justru mengambil ekstra SKS, walaupun saya tidak membutuhkan itu. Jadi, saya penasaran, apakah benar saya ingin menjadi lulusan terbaik? Tentu, saya pantas menerimanya, saya telah bekerja keras untuk mendapatkannya, tetapi apa yang akan saya terima nantinya? Saat saya meninggalkan institusi pendidikan, akankah saya menjadi sukses atau saya akan tersesat dalam kehidupan saya?

Saya tidak tahu apa yang saya inginkan dalam hidup ini. Saya tidak memiliki hobi, karena semua mata pelajaran hanyalah sebuah pekerjaan untuk belajar, dan saya lulus dengan nilai terbaik di setiap subjek hanya demi untuk lulus, bukan untuk belajar. Dan jujur saja, sekarang saya mulai ketakutan…….”

Hmmm… setelah membaca pidato wisudawan terbaik tadi, apa kesan anda? Menurut saya pidatonya adalah sebuah ungkapan yang jujur, tetapi menurut saya kejujuran yang “menakutkan”. Menakutkan karena selama sekolah dia hanya mengejar nilai tinggi, tetapi dia meninggalkan kesempatan untuk mengembangkan dirinya dalam bidang lain, seperti hobi, ketrampilan, soft skill, dan lain-lain. Akibatnya, setelah dia lulus dia merasa gamang, merasa takut terjun ke dunia nyata, yaitu masyarakat. Bahkan yang lebih mengenaskan lagi, dia sendiri tidak tahu apa yang dia inginkan di dalam hidup ini.

Saya sering menemukan mahasiswa yang hanya berkutat dengan urusan kuliah semata. Obsesinya adalah memperoleh nilai tinggi untuk semua mata kuliah. Dia tidak tertarik ikut kegiatan kemahasiswaan, baik di himpunan maupun di Unit Kegiatan Mahasiswa. Baginya hanya kuliah, kuliah, dan kuliah. Memang betul dia sangat rajin, selalu mengerjakan PR dan tugas dengan gemilang. Memang akhirnya IPK-nya tinggi, lulus cum-laude pula. Tidak ada yang salah dengan obsesinya mengejar nilai tinggi, sebab semua mahasiswa seharusnya seperti itu, yaitu mengejar nilai terbaik untuk setiap kuliah. Namun, untuk hidup di dunia nyata seorang mahasiswa tidak bisa hanya berbekal nilai kuliah, namun dia juga memerlukan ketrampilan hidup semacam soft skill yang hanya didapatkan dari pengembangan diri dalam bidang non-akademis.

Nah, kalau mahasiswa hanya berat dalam hard skill dan tidak membekali dirinya dengan ketrampilan hidup, bagaimana nanti dia siap menghadapi kehidupan dunia nyata yang memerlukan ketrampilan berkomunikasi, berdiplomasi, hubungan antar personal, dan lain-lain. Menurut saya, ini pulalah yang menjadi kelemahan alumni ITB yang disatu sisi sangat percaya diri dengan keahliannya, namun lemah dalam hubungan antar personal. Itulah makanya saya sering menyemangati dan menyuruh mahasiswa saya ikut kegiatan di Himpunan mahasiswa dan di Unit-Unit Kegiatan, agar mereka tidak menjadi orang yang kaku, namun menjadi orang yang menyenangkan dan disukai oleh lingkungan tempatnya bekerja dan bertempat tinggal. Orang yang terbaik belum tentu menjadi orang tersukses, sukses dalam hidup itu hal yang lain lagi.

Menurut saya, apa yang dirasakan wisudawan terbaik Amerika itu juga merupakan gambaran sistem pendidikan dasar di negara kita. Anak didik hanya ditargetkan mencapai nilai tinggi dalam pelajaran, karena itu sistem kejar nilai tinggi selalu ditekankan oleh guru-guru dan sekolah. Jangan heran lembaga Bimbel tumbuh subur karena murid dan orangtua membutuhkannya agar anak-anak mereka menjadi juara dan terbaik di sekolahnya. Belajar hanya untuk mengejar nilai semata, sementara kreativitas dan soft skill yang penting untuk bekal kehidupan terabaikan. Sistem pendidikan seperti ini membuat anak didik tumbuh menjadi anak “penurut” ketimbang anak kreatif.

Baiklah, pada bagian akhir tulisan ini saya kutipkan teks asli (dalam Bahasa Inggris) Erica Goldson di atas agar kita memahami pidato lengkapnya. Teks asli pidatonya dapat ditemukan di dalam laman web ini: Valedictorian Speaks Out Against Schooling in Graduation Speech .

Valedictorian Speaks Out Against Schooling in Graduation Speech

by Erica Goldson

Here I stand

There is a story of a young, but earnest Zen student who approached his teacher, and asked the Master, “If I work very hard and diligently, how long will it take for me to find Zen? The Master thought about this, then replied, “Ten years.” The student then said, “But what if I work very, very hard and really apply myself to learn fast – How long then?” Replied the Master, “Well, twenty years.” “But, if I really, really work at it, how long then?” asked the student. “Thirty years,” replied the Master. “But, I do not understand,” said the disappointed student. “At each time that I say I will work harder, you say it will take me longer. Why do you say that?” Replied the Master, “When you have one eye on the goal, you only have one eye on the path.”

This is the dilemma I’ve faced within the American education system. We are so focused on a goal, whether it be passing a test, or graduating as first in the class. However, in this way, we do not really learn. We do whatever it takes to achieve our original objective.

Some of you may be thinking, “Well, if you pass a test, or become valedictorian, didn’t you learn something? Well, yes, you learned something, but not all that you could have. Perhaps, you only learned how to memorize names, places, and dates to later on forget in order to clear your mind for the next test. School is not all that it can be. Right now, it is a place for most people to determine that their goal is to get out as soon as possible.

I am now accomplishing that goal. I am graduating. I should look at this as a positive experience, especially being at the top of my class. However, in retrospect, I cannot say that I am any more intelligent than my peers. I can attest that I am only the best at doing what I am told and working the system. Yet, here I stand, and I am supposed to be proud that I have completed this period of indoctrination. I will leave in the fall to go on to the next phase expected of me, in order to receive a paper document that certifies that I am capable of work. But I contend that I am a human being, a thinker, an adventurer – not a worker. A worker is someone who is trapped within repetition – a slave of the system set up before him. But now, I have successfully shown that I was the best slave. I did what I was told to the extreme. While others sat in class and doodled to later become great artists, I sat in class to take notes and become a great test-taker. While others would come to class without their homework done because they were reading about an interest of theirs, I never missed an assignment. While others were creating music and writing lyrics, I decided to do extra credit, even though I never needed it. So, I wonder, why did I even want this position? Sure, I earned it, but what will come of it? When I leave educational institutionalism, will I be successful or forever lost? I have no clue about what I want to do with my life; I have no interests because I saw every subject of study as work, and I excelled at every subject just for the purpose of excelling, not learning. And quite frankly, now I’m scared.

John Taylor Gatto, a retired school teacher and activist critical of compulsory schooling, asserts, “We could encourage the best qualities of youthfulness – curiosity, adventure, resilience, the capacity for surprising insight simply by being more flexible about time, texts, and tests, by introducing kids into truly competent adults, and by giving each student what autonomy he or she needs in order to take a risk every now and then. But we don’t do that.” Between these cinderblock walls, we are all expected to be the same. We are trained to ace every standardized test, and those who deviate and see light through a different lens are worthless to the scheme of public education, and therefore viewed with contempt.

H. L. Mencken wrote in The American Mercury for April 1924 that the aim of public education is not “to fill the young of the species with knowledge and awaken their intelligence. … Nothing could be further from the truth. The aim … is simply to reduce as many individuals as possible to the same safe level, to breed and train a standardized citizenry, to put down dissent and originality. That is its aim in the United States.”

To illustrate this idea, doesn’t it perturb you to learn about the idea of “critical thinking?” Is there really such a thing as “uncritically thinking?” To think is to process information in order to form an opinion. But if we are not critical when processing this information, are we really thinking? Or are we mindlessly accepting other opinions as truth?

This was happening to me, and if it wasn’t for the rare occurrence of an avant-garde tenth grade English teacher, Donna Bryan, who allowed me to open my mind and ask questions before accepting textbook doctrine, I would have been doomed. I am now enlightened, but my mind still feels disabled. I must retrain myself and constantly remember how insane this ostensibly sane place really is.

And now here I am in a world guided by fear, a world suppressing the uniqueness that lies inside each of us, a world where we can either acquiesce to the inhuman nonsense of corporatism and materialism or insist on change. We are not enlivened by an educational system that clandestinely sets us up for jobs that could be automated, for work that need not be done, for enslavement without fervency for meaningful achievement. We have no choices in life when money is our motivational force. Our motivational force ought to be passion, but this is lost from the moment we step into a system that trains us, rather than inspires us.

We are more than robotic bookshelves, conditioned to blurt out facts we were taught in school. We are all very special, every human on this planet is so special, so aren’t we all deserving of something better, of using our minds for innovation, rather than memorization, for creativity, rather than futile activity, for rumination rather than stagnation? We are not here to get a degree, to then get a job, so we can consume industry-approved placation after placation. There is more, and more still.

The saddest part is that the majority of students don’t have the opportunity to reflect as I did. The majority of students are put through the same brainwashing techniques in order to create a complacent labor force working in the interests of large corporations and secretive government, and worst of all, they are completely unaware of it. I will never be able to turn back these 18 years. I can’t run away to another country with an education system meant to enlighten rather than condition. This part of my life is over, and I want to make sure that no other child will have his or her potential suppressed by powers meant to exploit and control. We are human beings. We are thinkers, dreamers, explorers, artists, writers, engineers. We are anything we want to be – but only if we have an educational system that supports us rather than holds us down. A tree can grow, but only if its roots are given a healthy foundation.

For those of you out there that must continue to sit in desks and yield to the authoritarian ideologies of instructors, do not be disheartened. You still have the opportunity to stand up, ask questions, be critical, and create your own perspective. Demand a setting that will provide you with intellectual capabilities that allow you to expand your mind instead of directing it. Demand that you be interested in class. Demand that the excuse, “You have to learn this for the test” is not good enough for you. Education is an excellent tool, if used properly, but focus more on learning rather than getting good grades.

For those of you that work within the system that I am condemning, I do not mean to insult; I intend to motivate. You have the power to change the incompetencies of this system. I know that you did not become a teacher or administrator to see your students bored. You cannot accept the authority of the governing bodies that tell you what to teach, how to teach it, and that you will be punished if you do not comply. Our potential is at stake.

For those of you that are now leaving this establishment, I say, do not forget what went on in these classrooms. Do not abandon those that come after you. We are the new future and we are not going to let tradition stand. We will break down the walls of corruption to let a garden of knowledge grow throughout America. Once educated properly, we will have the power to do anything, and best of all, we will only use that power for good, for we will be cultivated and wise. We will not accept anything at face value. We will ask questions, and we will demand truth.

So, here I stand. I am not standing here as valedictorian by myself. I was molded by my environment, by all of my peers who are sitting here watching me. I couldn’t have accomplished this without all of you. It was all of you who truly made me the person I am today. It was all of you who were my competition, yet my backbone. In that way, we are all valedictorians.

I am now supposed to say farewell to this institution, those who maintain it, and those who stand with me and behind me, but I hope this farewell is more of a “see you later” when we are all working together to rear a pedagogic movement. But first, let’s go get those pieces of paper that tell us that we’re smart enough to do so!

~~~~~~~~~~

Pidato Erica tersebut juga dimuat di blog America dan mendapat tanggapan luas oleh publik di sana. Silakan baca di sini: http://americaviaerica.blogspot.com/2010/07/coxsackie-athens-valedictorian-speech.html

Kalau ingin melihat video pidato Erica di Youtube, klik ini:

atau masuk pada pranala berikut: http://www.youtube.com/watch?v=9M4tdMsg3ts&feature=player_embedded#!


Written by rinaldimunir

April 7th, 2013 at 11:13 pm

Posted in Pendidikan

XML Encryption Attack

without comments

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.

Screen Shot 2013-04-07 at 7.52.19 PM

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.

Screen Shot 2013-04-07 at 7.52.33 PM

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

Screen Shot 2013-04-07 at 7.52.51 PM

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.

Screen Shot 2013-04-07 at 7.53.18 PM

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.

Screen Shot 2013-04-07 at 6.49.03 PM

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.

Screen Shot 2013-04-07 at 7.09.01 PM

Security fault bisa terjadi karena dua hal:

  • Incorrect Padding
  • Error ini terjadi bila byte terakhir bukan berada pada rentang 0×01-0×10 (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 (“<") yang dianggap sebagai pembuka tag XML namun tidak diikuti dengan penutup tag yang benar, atau hasil dekripsinya mengandung karakter 26 ("&") sebagai pengawal entity tanpa diikuti dengan entity reference yang valid.

Kita tidak bisa membedakan apakah error security fault disebabkan karena incorrect padding atau invalid XML karena respons yang diterima sama. Jadi bila kita menerima security fault artinya ada kesalahan padding atau invalid XML.

Jenis respons berikutnya adalah application-specific error. Cirinya adalah ketika kita menerima respons seperti di bawah ini.

Screen Shot 2013-04-07 at 7.09.45 PM

Jenis error ini terjadi setelah kita lolos dari jeratan security fault, artinya kita lolos dari kesalahan padding dan hasil dekripsinya pun tidak mengandung kesalahan XML. Namun karena kita tidak mengirimkan perintah web service yang benar, maka request kita dianggap salah.

Dari dua jenis respons ini kita bisa menyusun sebuah Oracle yang menjawab dengan jawaban boolean, yes/no. Bila kita mendapat respons security fault bisa kita anggap sebagai false, bila bukan security fault bisa dianggap sebagai true, atau sebaliknya.

Tergantung dari bagaimana kita menyusun pertanyaan dengan tepat, jawaban true/false dari “the oracle” bisa kita jadikan petunjuk untuk menebak-nebak plaintext hasil dekripsi ciphertext.

Byte Masking dalam CBC

Sedikit review mengenai mode CBC (cipher block chaining). Karena Pn = Cn-1 XOR Dec(Cn), maka bisa dikatakan isi Pn ditentukan oleh ciphertext blok sebelumnya.

Perhatikan contoh pada gambar di bawah ini, P1 adalah IV XOR Dec(C1). Apa yang terjadi bila byte pertama IV kita XOR dengan A ? Bila byte pertama IV diXOR dengan A, yang terjadi adalah byte pertama P1 juga akan terXOR dengan A.

Screen Shot 2013-04-07 at 8.21.38 PM

Jadi bila kita ingin mengubah P1, kita bisa lakukan dengan cara melakukan “masking”, yaitu mengXOR IV dengan byte masking tertentu, sehingga nilai P1 juga akan terXOR dengan byte yang sama. Prinsip ini sangat penting karena kita akan sering memainkan IV dengan cara meng-XOR IV pada posisi byte tertentu dengan suatu byte masking untuk membuat nilai P1 pada posisi tersebut terXOR juga.

Remote Execution Web Service

Saya akan menjelaskan proses dekripsi ciphertext XML dengan contoh. Saya sudah menyiapkan web service yang melayani remote command execution di server Apache AXIS2. Web service ini menerima argument berupa command shell seperti ls, cat, uname dari client, kemudian mengirimkan hasil eksekusinya kepada client sebagai respons.

Berikut adalah hasil sniffing wireshark, contoh request dan respons, ketika client menginvoke service tersebut untuk mengeksekusi perintah “uname -v”.

Screen Shot 2013-04-07 at 7.40.01 PM

Karena service remote command execution ini adalah service yang sangat sensitif, tentu saja harus dilindungi dari resiko berikut:

  • Seorang peretas bisa mencuri dengar komunikasi antara client dan server

Screen Shot 2013-04-06 at 10.23.49 AM

  • Seorang peretas bisa mengirimkan command yang berbahaya seperti “rm -rf /” atau “shutdown -h now”

Screen Shot 2013-04-06 at 10.25.11 AM

Secured Web Service

Sebagai jawaban dari ancaman resiko tersebut, web service tersebut akan dilindungi dengan xml encryption sehingga semua request dan response dari server dienkrip dengan symmetric encryption (dalam contoh ini digunakan AES-128 dalam mode CBC). Karena digunakan symmetric encryption, sebelumnya client dan server sudah sepakat dengan kunci rahasia yang akan digunakan untuk mengenkrip dan mendekrip request dan response.

Screen Shot 2013-04-06 at 10.31.00 AM

Dengan xml encryption walaupun si peretas tetap bisa menyadap komunikasi client dan server namun kini dia tidak bisa lagi mengerti apa isi komunikasinya.

Si peretas juga tidak bisa mengirimkan malicious command lagi karena dia harus mengirimkan command tersebut dalam bentuk encrypted sedangkan dia tidak tahu kunci untuk mengenkripnya. Tanpa kunci yang benar, command yang dia kirim ke server ketika didekrip di server akan menjadi “garbage text” yang jelas akan ditolak server.

Berikut adalah source code web service yang sudah diamankan dengan xml encryption. Saya mengambil dan memodifikasi sedikit dari sample #09 yang dibawa oleh rampart 1.5. Pada intinya source code tersebut menerima input String cmd kemudian memanggil Runtime.exec() untuk mengeksekusi command shell.

Screen Shot 2013-04-07 at 4.37.12 PM

Web service tersebut saya compile dan deploy dalam Apache Tomcat 5.5.36 + Axis2 1.5.3 + Rampart 1.5. Versi Axis2 dan rampart sengaja saya pilih versi yang masih vulnerable terhadap serangan ini.

Screen Shot 2013-04-07 at 4.47.52 PM

Gambar berikut memperlihatkan contoh ketika seorang client menginvoke web service ‘commandExecute’ dengan input parameter “ls -l”.

Screen Shot 2013-04-07 at 4.53.01 PM

Dengan melakukan sniffing peretas memang masih bisa mendapatkan komunikasi web service antara client dan server. Namun karena web service ini sudah diamankan dengan xml encryption, maka dia hanya mendapatkan request dan respons dalam bentuk ciphertext saja.

Gambar di bawah ini request POST dari client ke server yang didapatkan dari hasil sniffing dengan wireshark.

Screen Shot 2013-04-06 at 9.46.52 AM

Dari request POST tersebut SOAP message yang dikirim client terlihat pada gambar di bawah ini. SOAP message ini meng-invoke service “commandExecute” dengan input berupa command shell. Namun berbeda dengan hasil sniffing pada web service yang tidak diamankan dengan xml encryption, kali ini command shell yang dieksekusi tidak terlihat karena sudah dalam bentuk terenkripsi.

Pada tag EncryptionMethod atribut algorithm menunjukkan bahwa enkripsi yang dipakai adalah AES dengan panjang blok 128 bit dan dalam mode CBC (cipher block chaining). Kalau peretas ingin mengetahui command shell apa yang dikirim ke server dia harus mendekrip ciphertext yang tersimpan pada tag CipherValue dalam bentuk base64 encoded.

Screen Shot 2013-04-06 at 11.53.32 AM

Sedangkan gambar di bawah ini adalah response dari server ke client yang didapatkan dari hasil sniffing dengan wireshark.

Screen Shot 2013-04-06 at 9.51.21 AM

Dari hasil sniffing tersebut SOAP message response dari server terlihat pada gambar di bawah ini. Hasil eksekusi command juga tidak bisa dilihat karena sudah terenkrip. Kalau peretas ingin mengetahui hasil eksekusi command dari client, dia harus mendekrip ciphertext yang ada pada tag CipherValue dalam bentuk base64 encoded.

Screen Shot 2013-04-06 at 12.01.40 PM

Hollywoord Style Decryption

Apakah benar dengan menggunakan XML Encryption masalah akan selesai? Peretas tidak bisa membaca komunikasi antara client dan server dan tidak bisa juga mengirimkan malicious command?

Ternyata si peretas masih bisa mendekrip komunikasi terenkrip antara client dan server walaupun tidak mengetahui kuncinya, dia juga bisa mengirimkan malicious command ke server sekali lagi tanpa mengetahui kuncinya.

Mirip dengan padding oracle attack, kita akan memanfaatkan AXIS2 server sebagai “the oracle” untuk membantu kita mendekrip ciphertext (dan juga mengenkrip ciphertext) byte per byte. Cara dekripsi ciphertext byte per byte ini sering terlihat di film-film hollywood.

Saya telah membuat tools untuk melakukan dekripsi ciphertext baik dari sisi client (request) maupun dari sisi server (response). Berikut adalah rekaman screen recording ketika tools tersebut dijalankan.


Source code dari tools di atas: source code.

Bagaimana cara kerja tools di atas? Bagaimana kita bisa memanfaatkan AXIS2 server sebagai “the oracle” untuk mendekrip ciphertext? Silakan ikuti penjelasannya di bawah ini.

Decrypting Request 

Kita bisa mendekrip ciphertext request dari client maupun ciphertext response dari server. Mari kita mulai dengan mendekrip ciphertext request dari client. Berikut adalah ciphertext yang harus didekrip oleh si peretas.

Screen Shot 2013-04-06 at 12.11.49 PM

Ciphertext di atas adalah dalam bentuk base64 encoded yang terbagi menjadi blok-blok seukuran 16 byte (128 bit). Blok ciphertext pertama (16 byte pertama) adalah initialization vector (IV). Ciphertext tersebut di atas terdiri dari satu blok IV dan 15 blok ciphertext seperti pada gambar di bawah ini.

Screen Shot 2013-04-06 at 12.26.46 PM

Kita akan mendekrip satu blok per satu blok dimulai dari blok ciphertext pertama (C1).

Find IV Procedure

Karena kita akan mendekrip C1, maka kita akan menggunakan dua blok, C0 sebagai IV dan C1 sebagai blok ciphertext target yang akan didekrip. Begitu juga nanti bila kita akan mendekrip blok C2, maka blok yang digunakan adalah C1 sebagai IV dan C2 sebagai blok target.

Ketika mendekrip selalu digunakan sepasang blok, blok pertama sebagai IV dan blok kedua sebagai ciphertext target yang akan didekrip. Blok kedua selalu tetap, sedangkan blok pertama (IV) adalah blok yang berubah-ubah, dimanipulasi untuk mengorek informasi dari “The Oracle”

Kalau kita potong ciphertextnya hanya dua blok awal saja kemudian kita kirimkan ke AXIS2 server, maka kita akan mendapat response error invalid padding karena byte terakhir dari blok pertama kini dianggap byte yang menunjukkan panjang padding (panjang padding yang valid antara 1-16 byte).  Jadi bila hasil dekrip byte terakhir blok pertama tersebut nilainya bukan antara 0×01 – 0×10 maka akan menghasilkan error, invalid padding.

Pada gambar di bawah ini terlihat bahwa di server byte terakhir hasil dekripnya IV+C1 (P1) adalah 0×63 sehingga jelas bukan padding yang valid. Server AXIS2 akan memberikan response “invalid padding OR invalid XML” dalam bentuk error “security fault” (karena error messagenya sama, kita tidak bisa membedakan apakah security fault disebabkan karena invalid padding atau invalid XML).

Dalam hal ini seperti tulisan sebelumnya tentang padding oracle, server AXIS2 bertindak sebagai ‘the oracle’ yang bisa kita interogasi untuk mendekrip ciphertext.

Screen Shot 2013-04-06 at 1.36.11 PM

Agar kita mendapatkan hasil dekrip dengan padding byte yang valid (antara 0×01-0×10), kita harus mencari byte terakhir IV yang membuat byte terakhir P1 valid. Gambar di bawah ini menunjukkan ketika byte terakhir IV bernilai 0×02, maka byte terakhir P1 bernilai 06 yang berarti valid padding.

Screen Shot 2013-04-06 at 1.39.01 PM

Walaupun kita sudah temukan IV yang membuat P1 valid padding, namun kita tetap mendapatkan error “invalid padding OR invalid XML” kenapa begitu ? Mari kita lihat isi dari P1 pada gambar di bawah ini. Setelah 6 byte terakhir dibuang, hasil akhirnya adalah teks: “<nsl:comma” yang jelas bukan XML yang valid karena ada karakter pembuka tag 3C (“<”) yang tidak ditutup.

Screen Shot 2013-04-06 at 1.41.07 PM

Karena ada karater pembuka tag “<” di awal blok maka satu-satunya yang bisa membuat P1 tidak mendapatkan error “invalid padding dan invalid XML” adalah ketika byte terakhir P1 bernilai 10 hexa (16 byte). Dengan byte terakhir bernilai 10 hexa (16 byte), artinya semua isi P1 akan dibuang karena dianggap byte padding, dengan kata lain P1 akan menjadi empty string. Karena P1 adalah empty string, maka lolos dari jeratan error “invalid padding” dan “invalid XML”.

Screen Shot 2013-04-06 at 1.54.59 PM

Bila dalam blok tersebut tidak ada karakter 3C (“<”), maka kita akan mendapatkan 16 IV yang menghasilkan valid padding dan valid XML. Bila jumlah IV yang membuat valid padding dan valid XML tidak mencapai 16, artinya dalam plaintextnya mengandung karakter “<” di posisi “jumlah IV”:

  • Bila jumlah IV yang valid hanya satu, artinya di byte ke-1 ada karakter “<” dan byte padding yang valid adalah 10 hexa.
  • Bila jumlah IV yang valid ada 2, artinya di byte ke-2 ada karakter “<” dan byte padding yang valid adalah 0F dan 10 hexa.
  • Bila jumlah IV yang valid ada 3, artinya di byte ke-3 ada karakter “<” dan byte padding yang valid adalah 0E, 0F dan 10.
  • Bila jumlah IV yang valid ada 4, artinya di byte ke-4 ada karakter “<” dan byte padding yang valid adalah 0D, 0E, 0F dan 10.
  • Bila jumlah IV yang valid ada 5, artinya di byte ke-5 ada karakter “<” dan byte padding yang valid adalah 0C, 0D, 0E, 0F dan 10
  • dan seterusnya

Contoh dalam gambar di bawah ini menunjukkan bahwa dari 16 byte padding yang valid, hanya ada 5 yang menghasilkan P1 yang valid. Sisanya 11 byte padding dari 01-0B masih menyisakan karakter “<” sehingga hasil akhirnya menjadi invalid XML. Begitu si peretas mendeteksi ada 5 IV yang valid, maka bisa diketahui bahwa di karakter ke-5 mengandung karakter “<”.

Screen Shot 2013-04-06 at 3.24.24 PM

Jumlah IV yang valid menunjukkan posisi karakter “<”

Kembali lagi ke contoh kita. Setelah kita mencoba semua kemungkinan byte terakhir IV dari 0-255, kita hanya mendapatkan satu IV yang tidak menghasilkan respons invalid padding dan invalid XML. Dari hasil ini kita meyakini bahwa karakter pertama P1 adalah “<” (0x3C).

Mengubah “<” menjadi “=”

Oke, kini kita sudah berhasil mendapatkan satu byte pertama, yaitu karakter “<”. Lalu apa lagi ? Sebenarnya yang ingin kita dapatkan di tahap “Find IV” ini adalah mendapatkan 16 IV yang tidak menghasilkan respons invalid padding dan invalid XML. Tapi karena ada karakter “<” di byte pertama, kita hanya mendapatkan 1 saja.

Agar kita bisa mendapatkan 16 IV yang valid, kita harus menghilangkan karakter “<” dengan mengubahnya menjadi karakter “=”. Bagaimana caranya? Itu mudah, kita sudah tahu posisi karakter “<” di byte ke berapa, selanjutnya kita hanya perlu menyesuaikan IV di byte tersebut agar P1 di posisi tersebut berubah dari “<” menjadi “=”.

Bagi yang sudah membaca padding oracle di tulisan saya sebelumnya tentu mengerti caranya, yaitu dengan operasi XOR karena dalam mode CBC, P1 adalah hasil XOR antara IV dan hasil dekrip C1, dengan memainkan IV kita bisa menentukan P1 mau dibuat menjadi apa. Karena 3C (“<”) XOR 3D (“=”) adalah 01, maka IV di posisi yang mengandung karakter 3C harus kita XOR-kan 01 agar hasil akhirnya nanti byte pertama P1 berubah menjadi “=”.

Kita tadi menggunakan IV dengan byte pertama 1A, setelah kita XOR dengan 01, maka kini byte pertama IV kita menjadi 1B. Dengan byte pertama IV 1B, maka byte pertama P1 dijamin bernilai “=” bukan lagi “<”.

Setelah kita mem-fix-kan byte pertama P1 menjadi “=”, kita harus mengulangi lagi prosedur find IV sampai kita mendapatkan 16 IV yang valid. Gambar di bawah ini menunjukkan 3 IV yang menghasilkan valid P1 setelah byte pertama P1 dikunci menjadi “=”. Perhatikan bahwa byte pertama IV sudah kita tetapkan 1B sehingga byte pertama P1 selalu bernilai 3D (“=”).

Screen Shot 2013-04-06 at 4.17.36 PM

Bila proses ini diteruskan, kita akan menemukan 16 IV yang membuat P1 menjadi valid. Gambar berikut adalah daftar 16 IV yang menghasilkan P1 yang valid. Perhatikan bahwa hanya byte terakhir saja yang berbeda dan byte pertama selalu 1B.

Screen Shot 2013-04-07 at 8.09.43 PM

Sampai sini kita hanya mengumpulkan 16 IV yang menghasilkan byte terakhir P1 yang valid antara 01-10 hexa. Kita tidak tahu IV mana yang menghasilkan byte terakhir 01. Kita hanya menginterogasi AXIS2 sebagai “the oracle” dan the oracle hanya menjawab valid atau tidak valid, dia tidak pernah memberitahukan isi P1.

Namun ada sedikit petunjuk yang bisa kita pakai, dari ke-16 byte terakhir IV tersebut, hanya ada satu yang bit ke-4nya berbeda dari yang lain. IV yang berbeda sendiri itu adalah IV yang membuat P1 berakhiran 10 hexa. Hanya itu petunjuk yang kita tahu. Kita hanya bisa mencari IV mana yang membuat P1 menjadi berakhiran dengan byte 10 hexa.

Secara sepintas sebenarnya sudah bisa dilihat, 15 IV yang lain depannya adalah 0, sedangkan hanya dia sendiri yang depannya adalah 1, jadi bisa disimpulkan bahwa IV dengan byte terakhir 14 hexa adalah IV yang membuat byte terakhir P1 menjadi 10 hexa.

Membuat Single Byte Padding

Sebenarnya tujuan akhir pada fase “find IV” ini adalah kita mencari IV yang membuat P1 menjadi berakhiran dengan byte 01 (single byte padding). Kita telah mengetahui bahwa byte terakhir IV 14 menghasilkan byte terakhir P1 10. Berapakah byte terakhir IV yang membuat byte terakhir P1 menjadi 01 ?

Dengan operasi matematika sederhana bisa kita hitung, 10 XOR 01 = 11, sehingga 14 XOR 11 = 05. Jadi sekarang kita sudah mendapatkan informasi bahwa byte terakhir IV 05 menghasilkan byte terakhir P1 01. Kok bisa begitu? Tentu saja bisa, just simple math :) Bila anda masih bingung, silakan baca lagi tulisan saya tentang “Padding Oracle Attack” yang menjelaskan tentang operasi XOR pada block cipher mode CBC.

Jadi prosedur Find IV ini diakhiri dengan didapatkannya IV berikut ini:

Screen Shot 2013-04-06 at 5.09.07 PM

Dengan IV tersebut, dijamin P1 akan berakhiran dengan 01 (single byte padding).

Mencari byte terakhir

Hal paling mudah yang bisa kita lakukan di tahap ini adalah mencari byte terakhir hasil dekrip C1. Sebelumnya kita sudah tahu bahwa dengan IV yang berakhiran 05, maka byte terakhir P1 adalah 01. Dari sini bisa kita ketahui bahwa byte terakhir hasil dekrip C1 adalah 05 XOR 01 = 04.

Screen Shot 2013-04-06 at 5.53.39 PM

Masih ada 15 byte lain hasil dekrip C1 yang belum diketahui. Mari kita lanjutkan prosesnya untuk mencari byte ke-1 sampai byte ke-15.

Mencari Byte ke-1

Kita mulai dari mencari byte pertama dulu baru kemudian mencari byte berikutnya sampai byte ke-15.

Strategi mencari byte ke-X adalah dengan menggunakan IV yang sudah kita temukan dalam prosedur “Find IV” sebagai IV dasar. IV tersebut akan kita ubah pada posisi byte ke-X kemudian mengamati respons dari “the oracle” AXIS2 Server, apakah perubahan IV pada byte ke-X tersebut mentrigger error ?

Bila ternyata setelah IV diubah di posisi byte ke-X terjadi error, maka bisa dipastikan error tersebut karena adanya “illegal character” di posisi byte ke-X (tidak mungkin karena invalid padding karena IV tersebut sudah kita kunci agar paddingnya selalu 01). Response dari “the oracle” tersebut bisa kita gunakan untuk menebak hasil dekripsi C1.

Jadi pertama yang akan kita lakukan adalah mencari byte pertama IV yang membuat “the oracle” memberikan response error invalid XML. Kita akan mencari byte pertama IV tersebut dengan melakukan XOR antara byte pertama IV dasar kita dengan byte 0×00, 0×10, 0×20, 0×30, 0×40, 0×50, 0×60 dan 0×70 dan mencatat IV mana saja yang menghasilkan error “invalid XML”.

Kita akan menginterogasi “the oracle” untuk menjawab pertanyaan-pertanyaan:

  • Apakah dengan byte pertama IV 1B XOR 00 = 1B, menghasilkan error invalid XML ?
  • Apakah dengan byte pertama IV 1B XOR 10 = 0B, menghasilkan error invalid XML ?
  • Apakah dengan byte pertama IV 1B XOR 20 = 3B, menghasilkan error invalid XML ?
  • Apakah dengan byte pertama IV 1B XOR 30 = 2B, menghasilkan error invalid XML ?
  • Apakah dengan byte pertama IV 1B XOR 40 = 5B, menghasilkan error invalid XML ?
  • Apakah dengan byte pertama IV 1B XOR 50 = 4B, menghasilkan error invalid XML ?
  • Apakah dengan byte pertama IV 1B XOR 60 = 7B, menghasilkan error invalid XML ?
  • Apakah dengan byte pertama IV 1B XOR 70 = 6B, menghasilkan error invalid XML ?

Ternyata setelah dicoba, didapatkan hasil bahwa hanya ada satu IV yang membuat error invalid XML, yaitu bila byte pertama IV bernilai 3B (=1B XOR 20).

Screen Shot 2013-04-07 at 2.01.25 PM

Bila hanya ada satu IV yang membuat jadi invalid XML, maka kemungkinan byte pertama P1 adalah 19, 1A atau 1D. Kita belum tahu yang mana, yang jelas di antara tiga itu. Kita perlu menginterogasi “the oracle” lebih lanjut untuk mendapatkan konfirmasi lanjutan apakah 19, 1A atau 1D.

Screen Shot 2013-04-06 at 6.59.49 PM

Sebagai cara untuk konfirmasi, kita akan membuat tiga kandidat P1 (19 / 1A / 1D) menjadi byte 3C “<” sehingga men-trigger error invalid XML. Kita akan malakukan byte masking sekali lagi dengan byte 25, 26, 21 karena 19 XOR 25 = 3C, 1A XOR 26 = 3C dan 1D XOR 21 = 3C.

Ingat bila IV di XOR dengan A, maka P1 juga akan berubah menjadi P1 XOR A.

Screen Shot 2013-04-07 at 8.57.59 AM

Byte pertama IV (3B) akan kita XOR dengan 25, 26 dan 21 kemudian kita interogasi “the oracle” untuk mengetahui jawaban pertanyaan berikut:

  • Apakah dengan byte pertama IV 3B XOR 25 = 1E, menghasilkan error invalid XML ?
  • Apakah dengan byte pertama IV 3B XOR 26 = 1D, menghasilkan error invalid XML ?
  • Apakah dengan byte pertama IV 3B XOR 21 = 1A, menghasilkan error invalid XML ?

Setelah dicoba, hanya 1A (=3B XOR 21)  yang menghasilkan error invalid XML. Perhatikan bahwa ketika byte pertama IV di-XOR dengan 21, maka byte pertama P1 juga akan ter-XOR dengan 21. Karena byte pertama P1 diXOR 21 mentrigger error invalid XML, maka diyakini bahwa byte pertama P1 XOR 21 = 3C sehingga kita dapat konfirmasi kepastian bahwa byte pertama P1 adalah 1D.

Screen Shot 2013-04-07 at 9.05.05 AM

Dengan mengetahui byte pertama IV dan byte pertama P1, kita bisa menghitung byte pertama hasil dekrip C1 adalah 3B XOR 1D = 26 atau bisa juga menggunakan 1A XOR 3C = 26.

Screen Shot 2013-04-06 at 7.07.35 PM

Mencari Byte ke-2

Mari kita lanjutkan untuk mencari byte ke-2, masih dengan menggunakan IV dasar hasil prosedur “Find IV” yang membuat single byte padding. Dengan prosedur yang sama kita harus mengubah byte ke-2 IV tersebut sehingga mentrigger error invalid XML.

Sama seperti cara mencari byte pertama, kali ini byte ke-2 IV akan kita XOR-kan dengan byte 00,10,20,30,40,50,60,70 sehingga byte ke-2 P1 juga akan ter-XOR dengan byte-byte tersebut. Dari ketujuh byte mask 00 – 70 tersebut akan ada satu atau lebih yang membuat P1 berubah menjadi karakter illegal sehingga mentrigger error invalid XML.

Sekali lagi kita akan menginterogasi “the oracle” untuk menjawab pertanyaan-pertanyaan:

  • Apakah dengan byte ke-2 IV 8A (=8A XOR 00), menghasilkan error invalid XML ?
  • Apakah dengan byte ke-2 IV 9A (=8A XOR 10), menghasilkan error invalid XML ?
  • Apakah dengan byte ke-2 IV AA (=8A XOR 20), menghasilkan error invalid XML ?
  • Apakah dengan byte ke-2 IV BA (=8A XOR 30), menghasilkan error invalid XML ?
  • Apakah dengan byte ke-2 IV CA (=8A XOR 40), menghasilkan error invalid XML ?
  • Apakah dengan byte ke-2 IV DA (=8A XOR 50), menghasilkan error invalid XML ?
  • Apakah dengan byte ke-2 IV EA (=8A XOR 60), menghasilkan error invalid XML ?
  • Apakah dengan byte ke-2 IV FA (=8A XOR 70), menghasilkan error invalid XML ?

Setelah dicoba kali ini sedikit berbeda, ada lebih dari satu IV yang mentrigger error invalid XML, yaitu EA dan FA. Pasangan IV tersebut tersebut membuat P1 menjadi pasangan “illegal XML character” berikut:

  • 0×00 dan 0×10
  • 0×01 dan 0×11
  • 0×02 dan 0×12
  • 0×03 dan 0×13
  • 0×04 dan 0×14
  • 0×05 dan 0×15
  • 0×07 dan 0×17
  • 0×08 dan 0×18
  • 0x0B dan 0x1B
  • 0x0E dan 0x1E
  • 0x0F dan 0x1F

Kita tidak tahu, EA dan FA membuat P1 menjadi pasangan yang mana? Oleh karena itu kita butuh konfirmasi lebih lanjut dari “the oracle” untuk memastikan. Sebenarnya kita tidak perlu menguji kedua IV tersebut karena yang manapun yang kita pilih hasilnya akan sama, jadi kita pilih salah satu saja yang pertama, EA.

Screen Shot 2013-04-06 at 8.36.52 PM

Sampai disini kita tidak tahu, byte ke-2 IV EA membuat byte ke-2 P1 menjadi bernilai berapa? Kita hanya tahu byte ke-2 P1 adalah salah satu dari 22 kandidat: 00, 10, 01, 11, 02, 12, 03, 13, … ,0E, 1E, 0F, 1F.

Lagi-lagi kita gunakan byte mask untuk menguji kandidat. Karena kita ingin membuat byte ke-2 P1 bernilai 3C, maka semua 22 kemungkinan P1 tersebut kita XOR dengan 3C untuk membuat 22 byte mask. Jadi byte mask yang akan kita pakai untuk menguji adalah:

  • 0x3C (=00 XOR 3C)
  • 0x2C (=10 XOR 3C)
  • 0x3D (=01 XOR 3C)
  • 0x2D (=11 XOR 3C)
  • 0x3E (=02 XOR 3C)
  • 0x2E (=12 XOR 3C)
  • 0x3F (=03 XOR 3C)
  • 0x2F (=13 XOR 3C)
  • dan seterusnya.. 0×38, 0×28, 0×39, 0×29, 0x3B, 0x2B, 0×34, 0×24, 0×37, 0×27, 0×32…
  • 0×22 (=1E XOR 3C)
  • 0×33 (=0F XOR 3C)
  • 0×23 (=1F XOR 3C)

Gambar berikut menunjukkan alur logika bagaimana dengan jawaban valid/invalid XML dari “the oracle” kita bisa menebak dengan tepat isi byte ke-2 P1.

Screen Shot 2013-04-07 at 11.22.01 AM

Setelah IV 0xEA di XOR dengan 22 byte mask di atas ditemukan dua di antaranya yang mentrigger error invalid XML, yaitu C2 (=EA XOR 28) dan D8 (=EA XOR 32).

Screen Shot 2013-04-07 at 2.32.46 PM

Karena kandidatnya tinggal dua kemungkinan, 26 atau 3C dan diketahui bahwa 26 XOR 2F = 09 (karakter legal, tidak mentrigger error invalid XML) sedangkan 3C XOR 2F = 13 (karakter ilegal, mentrigger invalid XML), maka kita akan gunakan byte mask 0x2F sebagai pembeda di antara keduanya.

Sekali lagi kita tidak perlu memakai kedua IV tersebut, cukup gunakan salah satu saja, C2 atau D8, yang manapun yang dipilih hasilnya sama saja. Dalam contoh ini kita pilih saja C2 sebagai byte ke-2 IV.

Ingat, bila IV diXOR dengan 2F, maka P1 nilainya juga akan berubah menjadi P1 XOR 2F

Kita akan menginterogasi “the oracle” untuk mengetahui jawaban dari pertanyaan:

  • Apakah dengan mengubah byte ke-2 IV menjadi ED (=C2 XOR 2F), akan mentrigger error invalid XML ?

Bila jawaban dari AXIS “the oracle” adalah no (tidak mentrigger error invalid XML), maka bisa dipastikan bahwa byte ke-2 P1 adalah 09. Sebaliknya bila jawaban “the oracle” adalah yes, maka bisa dipastikan bahwa byte ke-2 P1 adalah 13.

Screen Shot 2013-04-07 at 11.39.08 AM

Setelah dicoba dengan megubah byte ke-2 IV menjadi ED ternyata tidak mentrigger error invalid XML, sehingga kita yakin bahwa byte ke-2 P1 adalah 09. Dengan mengetahui byte ke-2 IV dan byte ke-2 P1, maka kita bisa menghitung byte ke-2 hasil dekrip C1 adalah ED XOR 09 = E4.Screen Shot 2013-04-06 at 9.04.48 PM

Mencari Byte ke-3

Sejauh ini kita sudah mendapatkan 3 byte, yaitu byte ke-1, ke-2 dan byte terakhir. Kini kita lanjutkan pencarian kita untuk mencari byte ke-3.

Karena yang dicari adalah byte ke-3, maka kita akan mengXORkan byte ke-3 IV 80 dengan byte mask 00, 10, 20 – 70 kemudian mencatat byte mask mana yang mentrigger error invalid XML. Gambar di bawah ini memperlihatkan proses mencari byte ke-3 IV yang mentrigger error invalid XML.

Screen Shot 2013-04-07 at 6.33.18 AM

Setelah dicoba diketahui bila byte ke-3 IV bernilai E0 (=80 XOR 60) atau F0 (=80 XOR 70) mentrigger error invalid XML. Dalam contoh ini kita ambil salah satu saja, yaitu E0.

Selanjutnya byte ke-3 IV, E0 akan diubah dengan meng-XOR-kan dengan 22 byte mask (yang sudah dijelaskan sebelumnya ketika mencari byte ke-2) untuk mencari mencari lagi mana di antara 22 byte ke-3 IV tersebut yang mentrigger error invalid XML.

Gambar di bawah ini menunjukkan proses interogasi “the oracle” untuk byte ke-3 IV yang berbeda-beda (XOR dengan 22 byte masking). Ternyata baru pada percobaan ke-8, sudah ditemukan byte ke-3 IV yang mentrigger error invalid XML, yaitu CF (=E0 XOR 2F).

Screen Shot 2013-04-07 at 6.36.47 AM

Seperti yang sudah dijelaskan sebelumnya, byte ke-3 IV CF ini membuat byte ke-3 P1 menjadi dua kemungkinan, 3C atau 26. Untuk memastikan byte ke-3 P1 adalah 3C atau 26 kita harus menginterogasi “the oracle” lagi. Byte ke-3 IV, CF kita XOR dengan 2F (akibatnya byte ke-3 P1 juga akan ter-XOR dengan 2F) kemudian kita lihat respons dari “the oracle”, apakah mentrigger error invalid XML lagi atau tidak. Bila the oracle merespons dengan error invalid XML, artinya byte ke-3 P1 adalah 13, bila the oracle tidak merespons dengan “invalid xml”, maka byte ke-3 P1 adalah 09.

Screen Shot 2013-04-07 at 6.49.11 AM

Ternyata setelah byte ke-3 IV (CF) di-XOR dengan 2F menjadi E0, mentrigger error invalid XML, sehingga kita yakin bahwa byte ke-3 IV tersebut (E0) membuat byte ke-3 P1 menjadi 13. Dengan mengetahui byte ke-3 IV E0 dan byte ke-3 P1 13, kita bisa menghitung byte ke-3 hasil dekrip C1 yaitu E0 XOR 13 = F3.

Screen Shot 2013-04-06 at 10.13.09 PM

Mencari byte ke-4

Mari kita lanjutkan untuk mencari byte ke-4. Karena yang dicari adalah byte ke-4, maka byte ke-4 IV (D0) di XOR dengan 7 byte masking (00-10-20-30…-70) untuk mencari byte ke-4 IV yang mentrigger error invalid XML. Berikut adalah proses mencari byte ke-4 IV yang menghasilkan error invalid xml.

Screen Shot 2013-04-06 at 10.49.47 PM

Dari gambar di atas terlihat bahwa byte ke-4 IV F0 dan E0 mentrigger error invalid XML. Karena ada dua IV kita pilih saja yang pertama, yaitu F0. Selanjutnya prosesnya sama, kita mengXORkan F0 dengan 22 byte masking untuk mencari byte masking yang mentrigger error invalid XML.

Screen Shot 2013-04-06 at 10.53.26 PM

Gambar di atas menunjukkan bahwa ketika byte ke-4 IV bernilai DD (=F0 XOR 2D) membuat “the oracle” merespons dengan error invalid XML. Selanjutnya diperlukan konfirmasi sekali lagi dari the oracle untuk menentukan nilai byte ke-4 P1.

Byte ke-4 IV DD diXORkan dengan 2F menjadi F2 kemudian kita amati respons dari “the oracle”. Ternyata respons dari “the oracle” adalah invalid XML, artinya kita yakin bahwa byte ke-4 IV F2 membuat byte ke-4 P1 menjadi 13.

Dengan mengetahui byte ke-4 IV dan byte ke-4 P1, kita bisa menghitung byte ke-4 hasil dekrip C1 adalah F2 XOR 13 = E1.

Screen Shot 2013-04-06 at 10.44.10 PM

Mencari Byte ke-5

Mencari byte ke-5 prosedurnya tetap sama. Kita selalu mulai lagi dengan IV hasil prosedur “Find IV” di awal, yaitu IV yang membuat byte terakhir menjadi 01. Kemudian dari IV tersebut byte-5nya kita masking dengan 7 byte (00, 10, 20 – 70) untuk mencari byte ke-5 IV yang mentrigger error invalid XML.

Gambar di bawah ini adalah proses mencari byte ke-5 IV yang mentrigger error invalid XML. Ternyata hanya ada satu IV yang mentrigger error invalid XML, yaitu bila byte ke-5 bernilai 35.

Screen Shot 2013-04-07 at 6.52.27 AM

Byte ke-5 IV, 35 ini membuat P1 menjadi salah satu dari 3 kandidat: 19, 1A atau 1D. Kita butuhkan “the oracle” untuk menentukan satu dari 3 kemungkinan kandidat itu. Caranya adalah kita meng-XOR-kan byte ke-5 IV (35) dengan 25, 26 dan 21 (untuk membuat byte ke-5 P1 menjadi 3C) kemudian melihat mana yang mentrigger error invalid XML.

Screen Shot 2013-04-07 at 6.59.38 AMPerhatikan gambar di atas, ketika byte ke-5 IV menjadi 10 (=35 XOR 25) tidak mentrigger error invalid XML, namun ketika byte ke-5 IV menjadi 13 (=35 XOR 26) mentrigger error invalid XML. Dari 2 percobaan ini kita yakin bahwa byte ke-5 IV 13 membuat byte ke-5 P1 menjadi 3C.

Dengan mengetahui byte ke-5 IV 13 membuat byte ke-5 P1 menjadi 3C, maka kita bisa menghitung byte ke-5 hasil dekrip C1 adalah 13 XOR 3C = 2F.

Screen Shot 2013-04-07 at 7.33.32 AM

Mencari byte ke-6 s/d 15

Karena caranya sama, byte ke-6 sampai byte ke-15 saya tuliskan di bawah ini.

Spoiler Inside: Proses mecari byte ke-6 s/d byte ke-15 SelectShow

Setelah semua byte berhasil didekrip, kini hasil Dekrip blok C1 sudah lengkap. Bila kita kembalikan IV yang asli (bukan IV hasil prosedur “find IV”), kemudian kita XOR-kan antara hasil Dekrip C1 dan IV tersebut kita akan dapatkan plaintext yang benar.

Screen Shot 2013-04-07 at 1.43.07 PM

Screen Shot 2013-04-07 at 1.43.51 PM

Decrypting C2

Mendekrip C2 caranya sama dengan mendekrip C1, bedanya adalah kalau dulu kita pakai C0 dan C1 untuk mendekrip C1, kini kita pakai C1 dan C2 untuk mendekrip C2. Jadi prosedurnya tetap sama:

  1. “Find IV” untuk mencari IV yang membuat single byte padding
  2. Cari byte ke-X

Find IV Blok C2

Kita mulai prosedur pertama mencari IV yang membuat single byte padding. Input dari prosedur ini adalah dua blok, yaitu C1 (sebagai IV) dan C2 (sebagai blok yang akan didekrip).

Screen Shot 2013-04-07 at 2.45.03 PM

Dengan cara yang sama seperti C1, kita akan mendapatkan 16 IV yang membuat P1 menjadi valid (valid padding dan valid XML).

Screen Shot 2013-04-07 at 2.55.38 PM

Kita hanya tahu 16 IV tersebut menghasilkan byte terakhir P1 antara 01 – 10, tapi kita tidak tahu pasti yang mana. Namun kita punya petunjuk bahwa ada satu IV yang bit ke-4nya berbeda sendiri dari 15 IV lainnya, dan IV yang berbeda sendiri itu adalah IV yang menghasilkan padding 10.

Kalau kita perhatikan ada 15 IV yang diawali dengan A, dan hanya ada satu IV yang diawali dengan B, yaitu B8. Dari situ kita bisa simpulkan bahwa byte terakhir IV B8 akan membuat byte terakhir P1 bernilai 10.

Karena tujuan kita adalah mencari IV yang membuat single byte padding, maka byte terakhir IV harus kita buat menjadi B8 XOR 11 = A9. Sekarang kita sudah dapatkan IV yang akan menjadi masukan bagi prosedur untuk mendekrip byte-byte dalam blok C2.

Screen Shot 2013-04-07 at 3.05.31 PM

Mencari byte ke-16

Setelah mendapatkan IV yang membuat single byte padding, kita bisa dengan mudah menghitung byte ke-16 dari hasil Decrypt(c2) yaitu byte terakhir IV (A9) XOR 01 = A8.

Screen Shot 2013-04-07 at 3.15.20 PM

Mencari byte ke-1 s/d ke-6

Dengan cara yang sama kita bisa mendekrip byte-byte mulai dari byte ke-1 sampai ke-15. Berikut ini adalah proses bagaimana mendekrip byte ke-1 s/d byte ke-6.

Spoiler Inside: Proses mencari byte ke-1 s/d byte ke-6 SelectShow

Mencari byte ke-7

Proses pencarian byte ke-7 akan saya bahas karena ternyata hasilnya agak sedikit berbeda dari contoh sebelumnya. Kali ini kita mendapatkan 3 IV yang mentrigger error invalid XML (contoh sebelumnya hanya 1 atau 2 IV), yaitu C9, F9, E9.

Screen Shot 2013-04-07 at 3.25.08 PM

Seperti biasa kita tidak perlu memakai semua IV tersebut, kita pilih saja salah satu yaitu C9. Bila ditemukan 3 IV seperti ini maka ada 6 kemungkinan P1 di byte ke-7 yaitu: 0×06, 0×16, 0×26, 0x0C, 0x1C, 0x3C.

Screen Shot 2013-04-07 at 3.35.44 PM

Bagaimana cara kita menentukan byte P1 yang mana dari 6 kandidat tersebut? Kita akan gunakan byte masking 3A, 2A, 1A, 30, 20 dan 00 untuk membantu menebak byte P1 yang benar.

Gambar di bawah ini adalah alur logika bagaimana menggunakan jawaban “the oracle” (valid/invalid XML) bisa membawa kita menuju byte P1 yang benar. Byte ke-7 IV (C9) akan kita XOR dengan byte masking tersebut kemudian melihat reaksi dari “the oracle”, apakah valid atau invalid XML. Bila ternyata invalid XML, kita XOR lagi dengan 2F sebagai ujian terakhir, bila reaksi “the oracle” adalah invalid XML, maka kita sudah berhasil menebak P1 dengan benar.

Screen Shot 2013-04-07 at 3.51.50 PM

Setelah mengikuti alur logika di atas, diketahui bahwa invalid XML terjadi 2 kali di cabang 00 (ketika di XOR dengan 00). Dari hasil ini kita bisa menebak bahwa byte ke-7 P1 adalah 3C.

Screen Shot 2013-04-07 at 4.14.14 PM

Dengan mengetahui bahwa byte ke-7 P1 adalah 3C dan byte ke-7 IV adalah C9, kita bisa menghitung byte ke-7 Decrypt(c2) adalah C9 XOR 3C = F5.

Screen Shot 2013-04-07 at 4.17.32 PM

Mendekrip byte ke-8 s/d ke-15

Perlu diketahui bahwa hanya ada 3 kemungkinan ketika kita mencari IV yang membuat jadi invalid XML, yaitu 1 IV, 2 IV atau 3 IV. Pada byte ke-7 di atas kita mendapati bahwa terdapat 3 IV yang mentrigger error invalid XML, sedangkan pada contoh-contoh lain sebelumnya kita sudah menemukan contoh kasus 1 IV dan 2 IV.

Dengan cara yang sama, berikut adalah proses dekripsi byte ke-8 sampai byte ke-15.

Spoiler Inside: Proses mencari byte ke-8 s/d byte ke-15 SelectShow

Kini kita sudah berhasil mendekrip c2 dari byte ke-1 sampai byte ke-16.

Screen Shot 2013-04-07 at 4.27.45 PM

Screen Shot 2013-04-07 at 4.28.20 PM

Gambar berikut adalah hasil dekripsi gabungan C1 dan C2

Screen Shot 2013-04-07 at 5.03.41 PM

Selanjutnya dengan cara yang sama kita bisa melanjutkan untuk mendekrip C3, C4, C5 dan seterusnya.

Written by Rizki Wicaksono

April 7th, 2013 at 8:56 pm

Posted in Cryptography

Bubur Ayam Cianjur

without comments

Ini masih cerita soal makanan. Bubur ayam adalah sarapan pagi orang Bandung dan orang Sunda umumnya. Bubur yang hangat dengan tambahan daging ayam suwir, telor rebus, kacang kedele, bawang goreng, sambal dan kerupuk, hmmmm… sungguh nikmat. Kalau mau sedikit “mewah” bsia ditambah ati ampela.

Makan bubur ayam Bandung itu biasa, tapi kalau bubur ayam Cianjur sudah pernah coba? Dulu saa pikir bubur ayam itu di mana-mana sama saja, tetapi bubur ayam Cianjur sedikit beda dengan bubur ayam Bandung. Di kawasan Antapani Bandung, tepatnya di jalan Terusan Jakarta (arah ke Arcamanik) ada warung bubur ayam Cianjur di pinggir jalan.

030420133159

Karena sering melewati jalan itu maka saya penasaran untuk berhenti, saya ingin mencoba bubur ayam Cianjur yang khas itu. Saya hentikan motor saya dan masuk ke dalam warung. Saya pesan satu mangkok bubur ayam.

030420133156

Hmmm… ternyata perbedaan bubur ayam Cianjur dengan bubur ayam lainnya terletak pada dua hal: bawang daun tumis dan kerupuk warna warni. Bawang daun ditumis dengan kaldu ayam dan bumbu-bumbu. Satu sendok bawang daun tumis tadi disiram ke atas bubur ayam, lalu ditambah dengan kerupuk aneka warna yang telah dihancurkan, plus emping.

030420133157

Setelah bubur saya aduk-aduk rata, inilah hasilnya, bubur warna-warni:

030420133158

Rasanya? Mantap! Bawang daun tumis kaldu tadi menambah rasa khas pada bubur. Mau?


Written by rinaldimunir

April 5th, 2013 at 9:37 am

Posted in Uncategorized

Menangisi Nasib Saudaraku di Seberang Benua

without comments

Apa perasaan dan reaksimu setelah melihat foto-foto pada situs web berikut?

http://banoosh.com/2013/03/28/photos-of-killed-muslims-with-armed-terrorist-buddhists-in-meiktila-myanmar/

Saya hanya bisa menangis!
Di manakah ajaran cinta damai itu?


Written by rinaldimunir

April 4th, 2013 at 10:02 am

Posted in Dunia oh Dunia

Kerak Telor Betawi van Bandung

without comments

Hampir semua orang tahu kerak telor adalah makanan khas orang Betawi (Jakarta). Namun sekarang ini tidak perlu jauh-jauh ke Jakarta untuk menikmati kerak telor, sebab kerak telor sudah melakukan ekspansi ke luar Jakarta. Di kota Bandung cukup banyak ditemukan pedagang kerak telor betawi. Mereka umumnya berjualan di dekat Lapangan Gasibu atau di depan Gedung Sate. Para pedagang kerak telor itu berjualan dari sore hingga malam hari. Lapangan Gasibu dan depan Gedung Sate selalu ramai pada sore dan malam hari, apalagi pada akhir pekan. Keramaian orang di Lapangan Gasibu dan di depan Gedung Sate adalah lahan rezeki bagi pedagang kerak telor.

030420133160

Pedagang kerak telor di lapangan Gasibu itu bukan orang Betawi, tetapi orang Sunda asli. Melihat kemiripan bentuk pikulan antara pedagang yang satu dengan yang lain, saya menduga juragan mereka sama. Mereka hanya berperan memasak dan menjajakan kerak telor saja, tetapi bahan-bahan dan pikulan disediakan oleh juragan.

Sore tadi, sepulang dari kampus saya melewati Lapangan Gasibu. Banyak orang sedang berolahraga di sana, selain itu beberapa turis lokal berfoto ria dengan latar belakang Gedung Sate. Seorang pedagang kerak telor terlihat sedang menunggu pembeli.

030420133162

Saya memesan kerak telor untuk dibawa pulang. Pedagang itu mulai menyiapkan wajannya. Diambilnya satu sendok besar beras ketan yang sudah direndam dengan air, lalu dimasukkan ke dalam wajan (katel) yang dipanaskan di atas bara api. Wajan itu kemudian ditutupnya dan ketan di dalamnya dibiarkan sampai matang hingga membentuk kerak.

030420133161

Setelah beberapa menit, tutup wajan dibuka, lalu satu butir telur dan satu sendok serundeng kelapa dituangkan ke atas kerak tadi. Tidak lupa dimasukkan garam, merica, dan bumbu penyedap.

030420133163

Semua bahan diaduk rata sembari wajan tetap berada di atas bara api:

030420133164

lalu wajan dibalikkan sehingga api memanggang kerak tadi:

030420133165

dan kerak telor pun akhirnya matang:

030420133166

Sebagai finishing, di atas kerak tadi ditaburkan kembali serundeng dan bawang goreng:

030420133167

Kerak telor siap dibungkus dan dibawa pulang. Harga kerak telor dengan satu butir telur ayam itu Rp12.000, jika pakai telur bebek harganya Rp14.000.


Written by rinaldimunir

April 3rd, 2013 at 11:22 pm

Posted in Makanan enak