Pendeteksian Celah Keamanan SSL/TLS Menggunakan Android

78  18 

Teks penuh

(1)

DAFTAR PUSTAKA

Akrout, R., Alata, E., Kaaniche, M. & Nicomette, V. 2014. An Automated Black Box Approach for Web Vulnerability Identification and Attack Scenario Generation.

Journal of the Brazilian Computer Society 2014, 20:4.

Sandulescu , Mihai .2014. Techniques for Finding Vulnerabilities in Web Applications . Journal of Mobile, Embedded and Distributed Systems Vol. VI, no.

1, 2014, 2067–4074.

Bau ,J., Elie , Gupta ,D. & Mitchell, J. 2010 . State of the Art: Automated Black-Box Web Application Vulnerability Testing. IEEE Symposium on security and

privacy, pp.332-345.

Gujrathi, S .2014. Heartbleed Bug: AnOpenSSL Heartbeat Vulnerability.

International Journal of Computer Science and Engineering Vol. 2(5), 2014, 2347-269.

CVE-2014-0160 .2014. The Heartbleed Bug, http://heartbleed.com/ (diakses 13 maret 2015).

Irianto, Nugraha .2011. Implementasi Google Hack For Penetration Testing Sebagai Addons Google Chrome .Skripsi. Universitas Pembangunan Nasional.

Zhang, V .2014. Heartbleed Bug—Mobile Apps are Affected Too,

http://blog.trendmicro .com/trendlabs-security-intelligence/heartbleed-bug-mobile-apps-are-affected-too/ (diakses 17 maret 2015).

Durumeric, Z et al .2014. Heartbleed Bug Health Report, https://zmap.io/heartbleed/ (diakses 13 maret 2015).

APJII .2015. Pengguna internet indonesia tahun 2014 sebanyak 88,1 juta (34,9%),

http://www.apjii.or.id/v2/read/content/info-terkini/301/pengguna-internet-indonesia-tahun-2014-sebanyak-88.html/ (diakses 1 april 2015).

US-CERT .2014. “Heartbleed” OpenSSL Vulnerability. https://www.us-cert.gov/sites/ default/files/publications/Heartbleed%20OpenSSL%20Vulnerability_0.pdf

(diakses 13 maret 2015).

Sarno, R. &Iffano, I. 2009.Keamanan Sistem Informasi. ITS press.

Netcraft .2014. Half a million widely trusted websites vulnerable to Heartbleed bug.

(2)

Herrmann, S.D. 2002. A Pratical Guide to Security Engineering And Information

Assurance. New York:Auerbach Publications.

Garfinkel, S. & Howard, S.E. 2001.Web Security & Commerce. United States:O'Reilly& Associates.

Chan, Y.B., Yoke,C.A., &Yousefi, D.2013.An Exploratory of Airline E-ticker

Purchasing Intenttion among Foreign Undergraduates in Malaysia. Journal of

Human and Social Science Research Vol. 1, No. 1 (2013), 51-61.

Stuttard, D., Pinto, M. 2011. The Web Application Hacker's Handbook: Finding And

Exploiting Security Flaws. 2 ndEdition. Canada: John Wiley & Sons, Inc.

Pressman, R.S. (2010), Software Engineering : a practitioner‟s approach, McGraw -Hill, New York, 68.

Wiesand S .2014. The Heartbleed Vulnerability in OpenSSL . Technical Seminar

Zeuthen

Hess R . 2014. NASA IV&V and the Heartbleed Vulnerability. NASA IV&V

International Workshop 2014

Suhina, V., Gros, S. &Kalafatic, Z. 2008.Detecting vulnerabilities in Web applications by clustering Web pages.31st International Convention MIPRO 2008, Vol. V: Digital Economy

McKinley, H.L. 2015. SSL and TLS: A Beginners Guide. SANS Institute

Digicert .2015. What Is SSL (Secure Sockets Layer) and What Are SSL Certificates?,

https://www.digicert.com/ssl.htm (diakses 13 maret 2015). detection-scripts (diakses 31 januari 2016)

OWASP .2014. OWASP Mobile Security Project .

(3)

Ableson, W.F., Sen, R., King, C., & Ortiz,C.E .Android in Action. 3 rdEdition. Shelter Island:New York

Westpoint .2014. Understanding the Heartbleed Proof of Concept .

(4)

BAB III

ANALISIS DAN PERANCANGAN SISTEM

3.1 Identifikasi Masalah

Keamanan informasi merupakan hal yang penting dalam era teknologi informasi yang berkembang semakin pesat saat ini. Perkembangan teknologi menjadikan informasi mudah diakses. Smartphone telah menjadi salah satu alat teknologi yang tidak bisa terlepas dari kehidupan manusia saat ini. Selain berfungsi untuk melakukan komunikasi dalam jarak jauh di berbagai belahan dunia, teknologi smartphone juga dapat menghubungkan dan mempererat sosial antar sesama manusia dalam berbagai ras, agama dan suku. Smartphone juga dapat menambah wawasan dan ilmu pengetahuan karena telah tersedia banyaknya informasi yang bisa didapat secara gratis. Pada teknologi smartphone kita dapat mengakses aplikasi berbasis web atau aplikasi berbasis mobile itu sendiri. Namun, masalah keamanan sering kali kurang diperhatikan baik itu oleh pemilik sistem (pengelola sistem) maupun pengguna sistem. Sehingga sering terjadi pencurian dan penyalahgunaan informasi untuk mencari keuntungan pribadi atau kelompok. Hal ini disebabkan kurangnya pengujian standar kelayakan penggunaan aplikasi web dan aplikasi mobile yang diakses melalui

smartphone.

(5)

sehingga server salah memvalidasi dan menanggapi request yang diterima dari klien dan serangan yang paling sering muncul pada perangkat mobile disebabkan adanya kelemahan disisi teknologi atau tools yang digunakan untuk dapat melakukan koneksi secara online. Resiko jika adanya celah keamanan yang ada pada aplikasi adalah terjadinya pencurian data maupun pembajakan informasi. Untuk itu diperlukan sistem yang dapat memverfikasi dan menemukan celah keamanan teknologi OpenSSL yang digunakan aplikasi web atau aplikasi mobile yang ada pada smartphone.

3.2 Analisis Sistem

Aplikasi untuk memverfikasi dan mendeteksi celah keamanan teknologi OpenSSL pada aplikasi web dan aplikasi mobile yang ada pada smartphone dengan menggunakan black-box testing merupakan suatu aplikasi yang memberikan hasil berupa ada tidaknya celah keamanan pada teknologi OpenSSL yang terdapat pada aplikasi web dan aplikasi mobile yang terinstall di smartphone maupun smartphone itu sendiri. Sistem menerima input berupa halaman URL dari sebuah website, kemudian akan diproses dengan black-box testing menggunakan serangkaian prosedur untuk memverifikasi dan mendeteksi celah keamanan pada aplikasi web. Sistem juga dapat pengecekkan versi OpenSSL yang digunakan aplikasi yang terinstal pada smartphone ataupun smartphone itu sendiri untuk mengetahui jenis celah keamanan yang rentan terhadapnya.

(6)

Sesuai Gambar 3.1 maka dapat dijelaskan sebagai berikut, dalam aplikasi ini ada 2 bagian kerja:

3.2.1 Scan Device

Pada saat melakukan pengecekkan terhadap device, maka akan dilakukan tahapan pengumpulan informasi (Information Gathering). Dimana informasi yang dikumpulkan akan digunakan untuk mengidentifikasi kelemahan. Dalam tahap ini, terjadi proses dimana aplikasi (scanner heartbleed) akan melakukan pengecekan versi OpenSSL dari library device smartphone (android). Aplikasi juga akan melakukan pengecekan terhadap versi google chrome dan mozilla firefox yang terinstall di

android. Kemudian akan dilanjutkan dengan pencarian versi OpenSSL aplikasi yang

terinstall di device smartphone, dengan cara menemukan data directory dari setiap aplikasi yang terinstall. Kemudian data directory tersebut digunakan untuk melihat isi dari library aplikasi yang terinstall. Jika library aplikasi terinstall ditemukan. Maka, akan dilakukan proses grep terhadap satu persatu library untuk mengetahui di library mana mengetahui apakah aplikasi memiliki OpenSSL dan versi OpenSSL yang digunakan aplikasi yang terinstall di smartphone (android). Setelah aplikasi menemukan versi OpenSSl android, versi browser dan aplikasi terinstall mana saja yang punya OpenSSL beserta versi OpenSSLnya. Maka akan dilakukan proses identifikasi untuk menentukan jenis kelemahan apa yang terkait OpenSSL yang rentan terhadap browser, aplikasi android maupun os android. Output berupa laporan mengenai versi browser, versi OpenSSL yang digunakan device (android) dan versi OpenSSL setiap aplikasi terinstall dan juga jenis celah keamanan yang rentan terhadapnya.

3.2.2 Scan URL

Pada bagian scan URL, ada 2 bagian kerja yaitu; scan heartbleed dan verify SSL. Input yang digunakan berupa alamat URL yang diberikan user dan juga dapat berupa URL yang diakses user dari Chrome (hanya untuk scan heartbleed). Alamat URL yang

di-input harus berupa alamat URL yang telah menggunakan layanan SSL/TLS.

(7)

1. Scan Heartbleed

a. Handshake

Setelah alamat URL didapatkan, maka akan dilakukan proses handshake,

handshake merupakan sebuah proses negosiasi otomatis yang secara dinamis

menentukan parameter dalam pembentukan kanal komunikasi antara dua entitas normal sebelum komunikasi melalui kanal dimulai.

b. Attack Scenario

Setelah di lakukan handshake hello, aplikasi akan mengirim script berupa paket malware Heartbleed ke alamat URL yang diberikan user.

c. Vulnerability identification

Server memberikan respon terhadap paket malware yang dikirim oleh aplikasi

pencegahan heartbleed bug tersebut. Respon yang diterima kemudian akan diidentifikasi, apakah alamat URL yang di scanning memiliki kelemahan terhadap heartbleed atau tidak.

2. Verify SSL

Setelah URL didapatkan maka akan dilakukan proses koneksi terhadap server untuk menjalani komunikasi antara klien dan server. Sistem akan mengambil informasi tentang SSL yang digunakan server dan akan dilakukan verifikasi kunci publik dan kunci private antara klien dan server, yang bertujuan untuk mengetahui apakah server menggunakan kunci self signed atau tidak. Verify SSL juga bertujuan untuk mengetahui jenis cipher yang didukung server

Aplikasi pencegahan SSL/TLS bug memberikan output berupa laporan kepada user apakah ada celah SSL/’TLS atau tidak. Dan aplikasi juga memberikan info tentang keamanan SSL yang digunakan server saat berkomunikasi dengan client.

Proses-proses pada sistem akan dijelaskan dengan menggunakan flowchart :

1) Handshake

(8)

Gambar 3.2 Proses Handshake URL Website

Untuk memperjelas tahapan Handshake pada Gambar 3.2 dijelaskan sebagai berikut : 1. Pengguna meng-input URL sebuah website.

2. Sistem akan mengirim hello dalam bentuk hex yang akan diubah nanti kedalam format byte sebelum dikirim ke server. Didalam hello hex sistem akan mendeklarasikan jenis content type header, versi TLS (Transport Layer

Security), panjang header, handshake types dan cipher suite. Hello dikirim

untuk mengetahui apakah server mempunyai SSL konten atau tidak.

3. Ketika server menanggapi hello yang dikirim sistem. Kemudian sistem akan membaca header yang dikirim server terhadap sistem. Pembacaan header bertujuan untuk mengetahui apakah server mempunyai ekstensi untuk mengadakan handshake dan apakah handshake hello yang dikirimkan sistem ditanggapi secara keseluruhan oleh server.

(9)

2) Proses Attack Scenario

Ketika handshake yang dilakukan telah selesai dan server telah menanggapi secara keseluruhan handshake hello dari klien, maka dilanjutkan proses pengirim paket

heartbleed dalam bentuk hex, yang nanti akan diubah lagi kedalam byte sebelum

dikirim ke server. di dalam paket heartbleed, dideklarasikan jenis content type, versi TLS (Transport Layer Security), panjang, handshake types dan payload length.

Proses penyerangan dimulai dengan cara mengelabui ekstensi heartbeat yang dimiliki server, sistem mengirim respon yang mempunyai panjang 3 byte namun meminta respon lebih dari tiga. Untuk mengetahui lebih jelasnya kita dapat lihat flowchart untuk mengetahui proses penyerangan secara umum pada gambar 3.3.

Gambar 3.3 Proses Penyerangan 3) Verifikasi layanan SSL

SSL digunakan pada server untuk menyediakan enkripsi data dalam komunikasi data. Verifikasi layanan SSL dibutuhkan untuk mengetahui kelemahan cipher yang disupport server (Signature Algorithm), validasi masa berlaku sertikat dan certificate

chain. Penentuan cipher ditentukan pada tahap awal koneksi SSL, server akan

(10)

dikirimkan server. Jenis cipher akan menentukan kekuatan enkripsi yang digunakan. Masa berlaku juga akan menentukan kekuatan sertifikat, ketika masa berlaku sertifikat kadaluarsa, maka akan memunculkan error dan layanan tidak aman. Certificate chain yang digunakan antara klien dan server, juga akan menentukan kekuatan dari keamanan SSL itu sendiri. Verifikasi subjectdn dan issuerdn diperlukan untuk mengetahui apakah sertifikat dijamin oleh CA (Certificate Authority) atau tidak. Self

signed certificate langsung ditandatangani pengguna tanpa bantuan CA (Certificate

Authority). Pada self signed certificate, dimungkin penyerang dapat mencuri private

key pengguna dan pengguna secara permanen kehilangan private key. Dengan

melakukan verifikasi layanan SSL, dapat diketahui seberapa terjamin layanan SSL yang tersedia. Untuk mengetahui lebih jelasnya kita dapat lihat flowchart untuk mengetahui proses verify SSL secara umum pada gambar 3.4.

Gambar 3.4 Proses Validasi SSL 4) Information Gathering

Pada saat melakukan scan device dan aplikasi, maka akan dilakukan tahapan pengumpulan informasi. Tahap pertama dalam pengumpulan informasi yaitu dengan mengecek versi OpenSSL pada library os android device yang terletak di

/system/lib/libssl.so. Sistem melakukan perintah command prompt untuk melakukan

(11)

dengan menggunakan perintah command prompt, selanjutnya data directory akan digunakan untuk mengetahui apakah aplikasi memiliki library atau tidak. Jika aplikasi terinstall memiliki library, maka akan dilakukan perintah command prompt untuk melakukan pengecekkan OpenSSL pada tiap-tiap library yang dimiliki aplikasi terinstall. Untuk mengetahui lebih jelasnya kita dapat lihat flowchart untuk mengetahui proses Information gathering secara umum pada gambar 3.5.

Gambar 3.5 Proses Pengumpulan Informasi

5) Proses Vulnerability Identification a. Scan URL

(12)

Gambar 3.6 Proses identifikasi kelemahan b. Scan device

(13)

Gambar 3.7 Proses Identifikasi Kelemahan device

3.3 Proses Menguji Celah Kelemahan Aplikasi Web dan Aplikasi Mobile

3.3.1 Proses menguji serangan Heartbleed

(14)

Gambar 3.8 Proses testing Heartbleed

Proses dari diagram alur pada gambar 3.8 dapat diperjelas sebagai berikut : 1. Pengguna memberikan input berupa URL, seperti :

http://www.example.com/

2. Setelah URL diinput, maka akan dilakukan proses koneksi dengan menggunakan socket programming untuk memastikan bahwa klien dan server sudah terhubung. 3. Setelah klien dan server terhubung, maka akan dilanjutkan dengan proses

(15)

"16030200dc010000d8" mendefinisikan tentang versi protokol URL dan panjang protokol. Jika server tidak mendukung TLSv1.1 maka sebagian koneksi akan terputus (Drop) ini terjadi pada server yang hanya mendukung TLSv1.0 atau TLSv1.2. menurut analisa pada januari 20144 SSL/TLS, dari 1.000.000 situs terbaik. hanya 0,163% situs mendukung TLSv1.0, 0,0011% mendukung TLSv1.2 dan bug didalam OpenSSL, 2,6332% dari situs tersebut didukung TLSv1.0 dan TLSv1.2 tapi tidak TLSv1.1. Secara keseluruhan, 2.8% dari 1.000.000 situs terbaik (28.000) berpotensi rentan terhadap Heartbleed.

16 Handshake protocol types 03 02 versi TLS (1.1)

00 dc Panjang dari protokol (4)

Bagian berikutnya menjelaskan tipe dari pesan handshake, panjang dan versi TLS klien

(16)

dan selanjutnya mendefinisikan tentang 01 Length of compression methods

00 Compression method NULL (ie no compression) 00 49 Length of TLS extensions

00 0b 00 04

03 00 01 02 Eliptic curve point formats extension 00 0a 00 34 00 32 00 0e 00 0d 00 19 00 0f 00 01 01 Heartbeat extension

4. Kemudian sistem akan membaca header hasil response hello yang dikirim olehh

server dan apabila type header server = 22 dan payload =0x0e, berarti server

sudah menanggapi secara keseluruhan request dari klien.

5. Apabila server sudah menanggapi secara keseluruhan isi dari pesan dari klien, maka sistem akan kembali mengirim pesan paket heartbleed yang juga dalam bentuk hex.

180302000301ffff

Bagian pertama dari isi paket heartbleed adalah menjelaskan tentang tipe protokol dan versi protokol

(17)

00 03 Length 01 Heartbeat request

ffff Payload length (16384 bytes)

6. Sistem kemudian akan membaca hasil response yang dikirim server ke pengguna. Apabila tipe dari header server seperti berikut :

type = 24 dan payload > 3 maka dipastikan server vulnerable terhadap heartbleed, kemudian sistem akan menampilkan isi memori server.

type= 24 namun payload tidak lebih besar 3, maka dapat dikatakan server rentan, karena server menanggapi heartbeat dari pengguna

type = 21 atau type = 0, server error atau server good.

3.3.2 Proses memverifikasi teknologi SSL server

SSL (Secure Sockets Layer) sebuah teknologi yang digunakan server untuk melakukan enkripsi komunikasi antara klien dan server. SSL/TLS menggunakan algoritma kriptografi, tanda tangan digital dan sertifikasi. Teknologi yang digunakan pada SSL/TLS bertujuan untuk penyandian informasi yang disebut dengan enkripsi. Hasil enkripsi kemudian akan dibubuhkan tanda tangan digital untuk menjamin data yang dikirimkan adalah data sebenarnya dan sertifikasi untuk mengontentifikasi

server. Untuk menguji kelemahan teknologi SSL/TLS yang digunakan server

berdasarkan jenis algoritma yang digunakan dan jenis tanda tangan yang digunakan. Adapun untuk lebih jelasnya tahapan proses dalam menguji aplikasi web lemah dalam teknologi SSL/TLS dipresentasikan pada gambar 3.9.

(18)

3.3.3 Proses mengecek kelemahan terkait OpenSSL pada os android device dan

aplikasi mobile

OpenSSL pada android ataupun aplikasi yang terinstall didalamnya, digunakan untuk memastikan pengguna terhubung dengan server dan menjamin keamanan komunikasi informasi antara pengguna dan server. Untuk menguji apakah android dan aplikasi rentan terhadap serangan beberapa jenis kelemahan terkait OpenSSL atau tidak berdasarkan dengan mengetahui versi OpenSSL yang digunakan android dan tiap aplikasi yang terinstall pada android. Adapun representasi proses menguji serangan OpenSSL terhadap android dan aplikasi adalah;

(19)

Proses dari diagram dapat diperjelas sebagai berikut :

1. Ketika pengguna memilih untuk scan device, maka dilakukan pengumpulan informasi (Information gathering). Sistem akan mengecek versi OpenSSL yang terdapat pada library android yang terletak di /system/lib/. Akan dilakukan perintah egrep (Shell Command) untuk mengecek versi OpenSSL android dari library

/system/lib/libssl.so.

2. Sistem kemudian akan mengecek data directory semua aplikasi yang terinstall di android, misalnya data directory aplikasi bbm : data/data/com.bbm/.

3. Kemudian data directory aplikasi akan digunakan untuk mengecek apakah aplikasi yang terinstall tersebut mempunyai library atau tidak. Letak dari library aplikasi ada di data/data/com.bbb/lib/.

4. Jika aplikasi mempunyai library, maka sistem akan melakukan perintah egrep untuk mengecek versi OpenSSL yang digunakan aplikasi. Sistem akan mengecekkan pada setiap library yang dimiliki aplikasi.

5. Berdasarkan versi OpenSSL yang digunakan os android dan aplikasi terinstall. Sistem akan mengindetifikasi kelemahan apa yang rentan terhadap versi OpenSSL yang dimiliki os android dan tiap-tiap aplikasi yang terinstall pada os tersebut. 6. Sistem akan menampilkan jenis-jenis kelemahan terkait OpenSSL dan apakah os

android dan aplikasi rentan terhadap kelemahan tersebut. 3.4 Perancangan Sistem

Pada tahap perancangan sistem akan dilakukan perencanaan dari bagaimana suatu aplikasi website dan aplikasi mobile dapat diketahui memiliki celah kelemahan keamanan terkait OpenSSL. Dalam tahap ini juga dijelaskan bagaimana analisis kebutuhan seperti analisis pengguna, beberapa diagram yang dapat menjelaskan sistem seperti diagram aktivitas, use case, data flow diagram dan juga perancangan antarmuka sistem yang akan dibangun.

3.4.1 Fungsi utama

(20)

website dan melakukan pendeteksian celah keamanan OpenSSL di android dan

aplikasi terinstall yang ada didalamnya.

3.4.2 Batasan -batasan

Adapun batasan- batasan sistem yang akan dibangun adalah :

1. Perancangan aplikasi pendeteksi celah keamanan OpenSSL pada aplikasi

website dan aplikasi mobile akan dibangun menggunakan bahasa pemograman

Java.

2. Target website yang akan discan adalah aplikasi website yang mempunyai keamanan SSL/TLS.

3. Untuk dapat menjalankan scan device, android harus dalam keadaan rooted

device dan sudah terinstall unix command.

3.4.3 Data yang digunakan

Data yang digunakan dalam penelitian ini adalah data yang bersifat real time.Jadi pengguna dapat langsung meng-input URL aplikasi web yang akan di-scan celah keamanan sebuah aplikasi web dan melakukan scan device secara realtime.

3.4.4 Analisis pengguna

Analisis Pengguna merupakan mengidentifikasi para pengguna yang dapat melakukan interaksi dengan sistem. Dalam penelitian ini, pengguna yang dapat berinteraksi dengan sistem tidak perlu adanya proses registrasi. Pengguna hanya sebagai pengguna yang akan melakukan pendeteksian celah keamanan pada aplikasi web dan aplikasi

mobile .

3.5 Perancangan User Interface

(21)

3.5.1 Rancangan halaman utama

Pada halaman utama aplikasi merupakan halaman akan muncul pertama kali saat pengguna menggunakan aplikasi, terdapat menu-menu untuk berpindah ke halaman lainnya, dua buah button untuk memilih dan menguji celah keamanan pada aplikasi

website (URL) dan aplikasi mobile. Tampilan rancangan halaman utama dapat dilihat

seperti pada gambar 3.11.

Gambar 3.11 Rancangan Halaman Utama

Pada gambar terdapat 4 komponen, yaitu nama aplikasi yang menjelaskan aplikasi ini, scan url dan scan device merupakan pilihan untuk mencari kelemahan aplikasi web, device dan aplikasi mobile dan pada informasi aplikasi menjelaskan kegunaan aplikasi.

3.5.2 Rancangan halaman Scan Url

Pada halaman scan url akan diisi komponen untuk input url oleh pengguna, sebuah

textview untuk menampilkan hasil scan, button scan untuk memproses input yang

(22)

Rancangan halaman scan url pada gambar 3.12. Memiliki delapan komponen pada antarmuka. Yaitu sebagai berikut:

1. Nama aplikasi, menjelaskan aplikasi

2. Edittext menggambarkan area input Url yang akan digunakan pengguna.

3. Textview menggambarkan hasil saat melakukan proses.

4. Listview menggambarkan history url dari google chrome

5. Tombol scan url berfungsi untuk menjalankan proses pencarian celah keamanan pad aplikasi web.

6. Tombol get url berfungsi untuk mengambil history url dari google chrome. 7. Tombol ssl info berfungsi untuk melakukan verifikasi ssl dan key certificate. 8. Tombol reset berfungsi untuk menghapus isi dari textview ataupun listview 9. Informasi aplikasi untuk tambahan.

Gambar 3.12 Rancangan Halaman Scan URL

3.5.3 Rancangan halaman Scan Device dan Application

(23)

ada image view, textview untuk menampilkan icon dari sebuah aplikasi, versi openssl aplikasi dan jenis 3 kelemahan terkait OpenSSL yang diidentifikasi

Rancangan halaman scan device and appliacation pada gambar 3.13, terdiri dari 11 komponen pada antarmuka. Yaitu sebagai berikut :

1. Nama aplikasi menjelaskan aplikasi

2. Textview VersiOpenssl yang berisi versi openssl android, jenis kelemahan

android dan kerentanan browser terhadap logjam. 3. Textview data yang berisi nama aplikasi.

4. ImageView image1 yang berisi gambar (icon) aplikasi.

5. Textview openssl menggambarkan versi OpenSSL aplikasi.

6. Textview jamlog menggambarkan aplikasi rentan terhadap logjam atau tidak.

7. Textview cve2015 menggambarkan aplikasi rentan terhadap cve 2015 atau

tidak.

8. Textview bleed menggambarkan aplikasi rentan terhadap heartbleed atau tidak.

9. LinearLayout holdlayout berisikan textview data dan image1

10.LinearLayout holdlayout1 berisikan textview openssl, jamlog, cve2015 dan

bleed.

11.View l1 berisikan holdlayout dan holdlayout1

(24)

3.5.2 Rancangan halaman tutorial aplikasi

Pada halaman tutorial akan diisi mengenai tata cara penggunaan aplikasi ini. Rancangan tampilan halaman tutorial dapat dilihat pada Gambar 3.14.

Gambar 3.14 Rancangan Halaman Tutorial

(25)

BAB 4

IMPLEMENTASI DAN PENGUJIAN SISTEM

4.1 Implementasi Sistem

Tahap implementasi merupakan tahap kelanjutan dari kegiatan perancangan sistem. Wujud dari hasil implementasi ini nantinya adalah sebuah sistem yang siap untuk diuji dan digunakan.

4.1.1 Spesifikasi perangkat keras dan perangkat lunak yang digunakan

Spesifikasi perangkat keras (hardware) dan perangkat lunak yang digunakan untuk membangun sistem ini adalah sebagai berikut :

1. Prosesor Intel®CoreTM i3 CPU M370 2.40GHz. 2. Kapasitas hardisk 320 GB.

3. Memori RAM yang digunakan 3.00 GB.

4. Sistem operasi yang digunakan adalah Microsoft Windows 7 Ultimate. 5. Java 1.7.0_51

6. IDE Eclipse + ADT v22.3.0-887826.

(26)

4.1.2 Implementasi Black-Box testing

Setelah dilakukan perancangan sistem, maka data yang di-input oleh pengguna akan diproses dengan Black-Box testing. Implementasi dari pendeteksi kelemahan SSL pada aplikasi web dan aplikasi android dapat dilihat pada gambar 4.1 implementasi perancangan antarmuka pengguna.

Implementasi perancangan antarmuka yang telah dilakukan sebelumnya pada bab 3 adalah sebagai berikut :

1. Halaman Utama

Halaman utama adalah halaman yang akan muncul pertama kali di saat aplikasi dijalankan. Pada halaman utama terdapat 2 menu yaitu scan url , dan scan device and application. Pengguna dapat memilih apakah akan melakukan pengujian terhadap url atau terhadap device dan juga aplikasi dalam device dengan mengklik salah satu dari menu yang ada.

(27)

2. Halaman Scan URL

Halaman scan URL merupakan halaman dimana black-box testing

diimplementasikan untuk melakukan pendeteksian celah keamanan terhadap aplikasi website dan melakukan validasi terhadap layanan SSL yang dimiliki aplikasi website. Pada halaman ini pengguna melakukan pendeteksian dan validasi pada aplikasi web sesuai dengan URL website yang di-input. Setelah pengguna meng-input alamat URL sebuah website dan memilih untuk melakukan scanning, maka sistem akan mendeteksi apakah aplikasi website tersebut memiliki celah keamanan terhadap serangan heartbleed atau tidak memiliki celah keamanan. Dan apabila pengguna memilih untuk melakukan untuk validasi layanan SSL, maka sistem akan mengecek seberapa terjamin layanan SSL yang dimiliki aplikasi website. Sistem melakukan scanning dan validasi dengan menggunakan black-box

testing.

(28)

3. Halaman scan device dan aplikasi

Halaman scan device dan aplikasi merupakan halaman dimana blackbox testing juga akan dimanfaatkan untuk mengetahui celah keamanan terkait OpenSSL yang dimiliki os android device dan aplikasi yang terinstall didalamnya. Pada halaman ini pengguna akan ditampilkan versi OpenSSL os android dan aplikasi terinstall yang memiliki OpenSSL. Sistem akan melakukan pendeteksian 3 celah keamanan terkait OpenSSL berdasarkan versi OpenSSL yang dimiliki os android dan aplikasi yang ada didalamnya dengan menggunakan blackbox testing.

Gambar 4.3 Halaman Scan Device 4.2 Pengujian Sistem

(29)

4.3 Pengujian Sistem Secara Menyeluruh dan Hasil Blackbox testing

Data yang digunakan sistem untuk pengujian adalah data yang bersifat real time. Untuk mengetahui keberhasilan aplikasi peneliti memilih alamat website dan aplikasi android untuk uji coba black-box testing. Data tersebut berupa alamat website yang telah dipastikan memiliki celah keamanan SSL dan juga berupa alamat website yang sering dikunjungi yang mempunyai layanan SSL. Data yang digunakan juga dapat berupa os android dan beberapa jenis aplikasi android yang menggunakan OpenSSL.

Data tersebut kemudian akan dilakukan pengujian untuk mengetahui apakah aplikasi website atau aplikasi android tersebut memiliki celah keamanan atau tidak dengan black-box testing.

Contoh alamat situs website dan aplikasi android yang digunakan untuk diuji coba dengan black-box testing dapat dilihat pada tabel 4.1 dan 4.2.

(30)

Tabel 4.2 sampel aplikasi android

Pengujian dilakukan dengan meng-input alamat website atau dengan mengecek aplikasi yang terinstall pada android yang telah peniliti pilih sebelumnya. Untuk memperjelas pengimplementasian black-box testing yang digunakan aplikasi contohnya kita pilih satu sampel untuk scan url dan beberapa sampel untuk scan device sesuai dengan aplikasi yang terinstall di android yang punya OpenSSL.

4.3.1 Hasil Black-box Testing

(31)

Tabel 4.3 hasil pengujian terhadap aplikasi Website

Tabel 4.4 hasil pengujian terhadap aplikasi browser

Browser Versi Logjam

Google Chrome 1-43 

44-48 -

Mozilla Firefox 1.0-38 

38.5-44 -

(32)
(33)

Services 4.4-5.0 1.0.1g - -

6.1-6.5 1.0.1h - - -

6.7-7.0 1.0.1j - - -

7.3-7.5 1.0.1l - - -

4.3.2 Hasil pengujian aplikasi web terhadap Heartbleed dan Validasi SSL

Proses pengujian diawali dengan meng-input salah satu URL dari situs yang ada pada tabel sampel 4.1, dari situs itu akan dilakukan proses koneksi dengan URL. Setelah dipastikan klien dan server terhubung, kemudian masuk ke tahap handshake dengan mengirim pesan hello dalam format hex, setelah tahap handshake selesai, maka dilakukan pengiriman paket heartbleed. Hasil proses penyerangan ini diperoleh celah keamanan dapat dilihat di tabel 4.3 yang rentan diserang Heartbleed.

Berdasarkan proses pengujian serangan Heartbleed, disimpulkan sebuah website vulnerable atau memiliki celah keamanan heartbleed, karena kesalahan penanganan request yang dilakukan ekstensi heartbeat OpenSSL. Ekstensi heartbeat yang berfungsi untuk menjaga hubungan antara klien dan server, memiliki kelemahan dalam menanggapi respon yang dikirim klien ke server. Server tidak melakukan pengecekan terhadap pesan dan panjang pesan yang di request oleh klien. Sehingga klien bebas mengakses memori server. Dengan kelemahan yang dimiliki server, pengguna dapat meminta isi memori server yang bersifat rahasia sampai 64.000 karakter. Pada saat pengguna menginginkan untuk melakukan validasi SSL, maka

input berupa URL yang telah diberikan, akan dilakukan pengecekan jenis cipher yang

(34)

Gambar 4.4 hasil testing heartbleed

Gambar diatas salah satu contoh aplikasi website (www.voobys.com) yang rentan terhadap heartbleed. Dimana payload sebanyak 16384 bytes yang diminta klien diberikan server secara keseluruhan. Berbeda dengan aplikasi website yang tetap mengijinkan handshake namun tidak rentan terhadap heartbleed. Server hanya akan memberikan respon tidak lebih dari panjang request yang dikirim klien, seperti gambar 4.5

(35)

Gambar 4.6 proses verifikasi SSL/TLS server

4.3.3 Hasil pengujian aplikasi Mobile terhadap Kelemahan OpenSSl

Setelah dilakukan scan otomatis oleh aplikasi dari sampel aplikasi mobile yang diuji, dapat dilihat beberapa versi aplikasi dan versi OpenSSL yang dimiliki aplikasi serta jenis kelemahan versi OpenSSL yang dimiliki aplikasi yang diidentifikasi. Untuk menjelaskan proses pengujian diambil beberapa sampel pada tabel 4.7, dilakukan pengujian untuk mendeteksi jenis kelemahan OpenSSL terhadap versi OpenSSL aplikasi atau tidak.

Proses pengujian dilakukan dengan pengecekan versi OpenSSL android, dilanjutkan dengan proses pengecekan versi browser dan kemudian dilakukan pengecekkan versi OpenSSL aplikasi. Untuk hasilnya dapat dilihat pada tabel 4.9 dan 4.10.

(36)
(37)

BAB 5

KESIMPULAN DAN SARAN

5.1 Kesimpulan

Berdasarkan analisis sistem dan pengujian sistem pencegahan eksploitasi SSL/TLS bug pada android dengan menggunakan Black-box Testing dapat diambil kesimpulan pada penelitian ini antara lain:

1. Celah keamanan SSL/TLS telah mempengaruhi banyak organisasi atau pihak. Pengaruh bencana bug dapat dikurangi atau dihindari dengan cara melakukan pendeteksian sedini mungkin. Sistem yang dibangun bukan hanya dengan menguji payload yang didapatkan dari server. Namun, dapat memberikan pengetahuan terhadap pengguna atau klien terhadap teknologi SSL/TLS yang digunakan server untuk menjamin layanan komunikasi. Sistem juga akan memberikan info tentang celah keamanan terkait OpenSSL yang ada pada androidnya dan aplikasi yang terinstall didalamnya. Sehingga dengan dilakukan pendeteksi baik pada sisi klien dan server. diharapkan dapat menghindari dari kehilangan data-data atau informasi yang berada didalamnya.

(38)

3. Penerapan black-box testing dalam sistem memberikan solusi untuk mencegah dari ancaman yang terjadi dari pihak-pihak yang tidak diinginkan.

4. Metode yang diimplementasikan untuk mendeteksi keamanan aplikasi android dan device hanya dengan melakukan pengecekkan terhadap version OpenSSL yang dimiliki.

5. Metode yang diajukan mampu mengeksploitasi heartbleed bug, mengetahui kelemahan teknologi SSL/TLS server, kelemahan OpenSSL pada device android (seperti : aplikasi didalamnya dan OS) dan kelemahan browser.

5.2 Saran

Pada penelitian selanjutnya, untuk mengembangkan aplikasi pencegahan eksploitasi SSL/TLS bug dapat dikemukakan saran-saran.

1. Sistem selanjutanya dapat dilakukan penambahan teknik untuk dapat memberikan penilaian terhadap teknologi layanan SSL/TLS yang dimiliki server.

(39)

BAB II

LANDASAN TEORI

Landasan teori ini akan digunakan sebagai landasan pengerjaan aplikasi mendeteksi celah keamanan SSL pada aplikasi website dan mobile di android. Pembahasan bertujuan untuk mengurai teori tentang keamanan informasi, keamanan web dan aplikasi android, celah keamanan web dan celah keamanan aplikasi android, dan teori penunjang yang berhubungan untuk pencegahan heartbleed bug dan kelemahan SSL pada android.

2.1 Keamanan Informasi

Menurut (ISO/IEC 17799:2005) keamanan informasi adalah upaya perlindungan dari berbagai macam ancaman untuk memastikan keberlanjutan bisnis, meminimalisir resiko bisnis, dan meningkatkan investasi dan peluang bisnis.

Sehingga keamanan informasi secara tidak langsung dapat menjamin keutuhan informasi, kontinuitas bisnis, mengurangi resiko-resiko yang terjadi. Karena semakin banyak informasi perusahaan yang disimpan, dikelola dan di-sharing-kan maka semakin besar pula resiko terjadi kerusakan, kehilangan atau tereksposnya data ke pihak eksternal yang tidak diinginkan (Sarno, 2009). Apapun bentuk informasi yang disampaikan harus selalu dilindungi (ISO/IEC 17799, 2005).

Keamanan Informasi memiliki empat aspek (ISO/IEC 17799, 2005) yaitu sebagai berikut :

1. Confidentiality

(40)

merupakan tindakan pencegahan dari orang atau pihak yang tidak berhak untuk mengakses informasi.

2. Integrity

Keamanan informasi menjamin kelengkapan informasi dan menjaga dari kerusakan atau ancaman lain yang mengakibatkan berubah informasi dari aslinya. Pengertian lain dari integrity adalah memastikan bahwa informasi tersebutmasih utuh, akurat, dan belum dimodifikasi oleh pihak yang tidak berhak.

3. Availability

Keamanan informasi menjamin pengguna dapat mengakses informasi kapanpun tanpa adanya gangguan dan tidak dalam format yang tidak bisa digunakan. Pengguna dalam hal ini bisa jadi manusia, atau komputer yang tentunya dalam hal ini memiliki otorisasi untuk mengakses informasi. Availability meyakinkan bahwa pengguna mempunyai kesempatan dan akses pada suatu informasi.

4. Non-repudiation

Kemanan informasi menjaga agar seseorang tidak dapat menyangkal telah melakukan sebuah transaksi. Sebagai contoh, seseorang yang mengirimkan email untuk memesan barang tidak dapat menyangkal bahwa dia telah mengirimkan email tersebut.

2.2 Celah Keamanan / Vulnerability

Vulnerability adalah kelemahan dalam sistem yang dapat dimanfaatkan untuk

melanggar perilaku sistem yang relatif terhadap keselamatan, keamananan, keandalan, ketersediaan, integritas, dan sebagainya. Dapat didefinisikan perilaku dari sistem tersebut adalah sebagai berikut:

1. Keselamatan

Keselamatan adalah melakukan atau mengontrol fungsi yang diaktifkanuntuk mencegah atau meminimalkan efek dari kegagalan sistem keamanan.

2. Keamanan

(41)

3. Keandalan

Keandalan adalah kondisi, acara, proses, kontrol, kerja, atau toleransi penting yang dapat diandalkan sistem.

4. Ketersediaan

Ketersediaan adalah aspek yang menjamin dimana sistem, data dan sumber daya operasional dapat diakses bila diperlukan.

5. Integritas

Integritas adalah aspek yang menjamin bahwa sistem tidak boleh berubah tanpa ijin pihak yang berwenang.

Vulnerability yang melekat dalam desain, operasi, atau lingkungan operasional

dari sistem tersebut berkembang sebagai hasil dari kesalahan, dari kelalaian, kesalahan komisi, dan kesalahan operasional yang terjadi selama kehidupan dari suatu sistem (Herrmann, 2002).

2.2.1 Celah Keamanan Aplikasi Web

Celah keamanan pada aplikasi web adalah suatu celah yang menjadi jalan penyerang untuk menyebabkan kerusakan pada aplikasi web. Jenis celah keamanan web yang umumnya dijumpai adalah sebagai berikut (Stuttard, 2011) :

1. Input Validation Vulnerability

Kelemahahan yang paling umum dari aplikasi web adalah kegagalan untuk memvalidasi input yang berasal dari pengguna. Kelemahan ini menyebabkan adanya serangan-serangan terhadap aplikasi web seperti SQL Injection, Cross Scripting (XSS), buffer overflow.

2. Broken Authentication

Dalam keamanan komputer autentikasi adalah proses untuk memverifikasi indentitas digital dari pengirim dalam berkomunikasi. Kelemahan dalam kategori ini adalah berbagai cacat aplikasi dalam mekanisme login, seorang penyerang dapat dengan mudahnya untuk menebak password yang lemah, melancarkan serangan brute force, dan melewati login.

3. Broken Access control / Authority Vulnerability

(42)

ini terjadi karena kegagalan aplikasi untuk melindungi akses ke data, sehingga memungkinkan penyerang untuk melihat data sensitif pengguna lain yang dimiliki server atau melakukan tindakan istimewa.

4. Information leakage / Error Handling Vulnerability

Aspek penting dari pengembangan aplikasi yang aman adalah mencegah kebocoran informasi. Dalam kategori kelemahan ini, aplikasi membocorkan informasi sensitif yang berguna untuk penyerang dalam mengembangkan serangan selanjutnya terhadap aplikasi melalui pesan kesalahan. Aplikasi gagal karena menyajikan informasi penting ketika terjadi error.

5. Session Management Vulnerability

Salah satu inti dari aplikasi web adalah mekanisme untuk mengontrol dan memanajemen status / keadaan pengguna ketika berinteraksi dengan aplikasi. Misalnya saat login bagaimana otentifikasi pengguna dilakukan dan bagaimana yang terjadi terhadap pengguna ketika mereka log out. Kelemahan dalam kategori ini berarti kegagalan aplikasi sehingga dapat digunakan pengguna dalam konteks tingkatan pengguna dan hak istimewa.

2.2.2 Celah Keamanan Pada Aplikasi Mobile

Celah keamanan pada aplikasi mobile adalah suatu celah yang terdapat pada teknologi yang ada disisi teknologi yang digunakan klien ataupun server pendukung, yang bisa menjadi jalan penyerang untuk mengetahui informasi tentang pengguna. Ada beberapa resiko pada aplikasi mobile yang menjadi sebuah celah keamanan (www.owasp.org) :

1. Weak Server Side Controls

(43)

2.3 Aplikasi dan Keamanan Aplikasi

Aplikasi berasal dari kata application yang bermakna penerapan, lamaran dan penggunaan. Secara garis besar, aplikasi adalah program yang siap digunakan untuk menjalankan suatu fungsi tertentu untuk pengguna.

Aplikasi dapat digolongkan menjadi beberapa kelas, antara lain:

1. Enterprise

Digunakan untuk organisasi (perusahaan) yang cukup besar dengan maksud menghubungkan aliran data dan kebutuhan informasi antar bagian

2. Enterprise – SupPort

Sebagai aplikasi pendukung dari Enterprise.

3. Individual Worker

Sebagai aplikasi yang biasa digunakan untuk mengolah/edit data oleh tiap individu.

4. Aplikasi Akses Konten

Adalah aplikasi yang digunakan oleh individu (hanya) untuk mengakses konten tanpa kemampuan untuk mengolah atau mengedit datanya melainkan hanya melakukan kustomisasi terbatas.

5. Aplikasi Pendidikan

Biasanya berbentuk simulasi dan mengandung konten yang spesifik untuk pembelajaran.

6. Aplikasi Simulasi

Biasa digunakan untuk melakukan simulasi penelitian, pengembangan dan lain-lain.

7. Aplikasi Pengembangan Media

Berfungsi untuk mengolah/mengembangkan media biasanya untuk kepentingan komersial, hiburan dan pendidikan.

8. Aplikasi Mekanika dan Produk

(44)

2.3.1 Aplikasi Web

Aplikasi web adalah suatu aplikasi berbasis web yang diakses menggunakan penjelajah web (browser) melalui suatu jaringan seperti internet atau intranet. Pada dasarnya aplikasi web adalah sebuah repositori informasi yang berisi dokumen statis. Aplikasi web dapat dibagi menjadi dua jenis yaitu aplikasi web statis dan dinamis. Web statis dibentuk dengan menggunakan HTML. Kekurangan web statis terletak pada pemelihara program secara terus-menerus. Dimana saat informasi di update, maka program pun perlu diubah. Web dinamis adalah pengembangan dari web statis, dimana saat dilakukan perubahan informasi, tidak perlu merubah program tetapi melalui perubahan data.

Arsitektur aplikasi web meliputi klien, web server, middleware dan basis data. Saat klien berinteraksi melalui penjelajah web (browser) dengan web server. Secara internal, web server berkomunikasi dengan middleware dan middleware yang berkomunikasi dengan basis data. Pada web dinamis terjadi tambahan proses pembentukan halaman yaitu terjadinya pemrosesan di server untuk menerjemahkan kode PHP menjadi kode HTML, kemudian kode HTML yang telah diterjemahkan oleh mesin PHP lah yang akan diterima oleh pemakai (Abdul Kadir, 2009).

2.3.2 Aplikasi mobile

Aplikasi mobile adalah sebuah aplikasi yang memungkinkan untuk melakukan mobilitas dengan menggunakan perlengkapan seperti PDA (Personal Digital

Assistant), telepon seluler atau Handphone. Dengan menggunakan aplikasi mobile,

(45)

2.3.3 Keamanan Aplikasi

Menurut (Garfinkel, 2001), keamanan aplikasi adalah serangkaian prosedur, praktek, dan teknologi untuk melindungi web server, pengguna web, dan organisasi sekitarnya. Keamanan melindungi terhadap perilaku tak terduga.

Keamanan aplikasi telah sering dianggap oleh praktisi sebagai kunci kerberhasilan atau kegagalan vendor yang terkait dengannya. Sering developer kesulitan untuk menerapkan kebijakan mengenai keamanan di dalam aplikasi yang mereka bangun. Di samping karena banyaknya faktor keamanan yang harus diterapkan dengan baik dan benar untuk mencegah orang yang tidak berhak mengakses sebuah aplikasi, juga karena kurangnya pengetahuan mengenai fitur keamanan apa saja yang harus diterapkan di seluruh bagian dari aplikasi tersebut. Apalagi jika harus menerapkannya secara komprehensif (tidak boleh sebagian saja). Keamanan aplikasi melindungi pengguna dari resiko penipuan, hacking dan phising, sehingga meningkatkan kepercayaan konsumen (Chan et all, 2013). Dalam pengamanannya, ada beberapa hal yang dilakukan sebagai access control terhadap web ataupun mobile, seperti : melakukan pembatasan akses terhadap web sehingga hanya alamat ip yang terdapat yang dapat mengaksesnya, melakukan pembatasan terhadap user (user yang terdapat dalam sebuah file dengan password yang dimiliki dapat mengakses) dan yang paling umum digunakan oleh perusahaan-perusahaan besar seperti perbankan, korporasi dan lainnya yaitu SSL (Secure Sockets Layer).

2.4 SSL/TLS dan OpenSSL

2.4.1 SSL/TLS

SSL (Secure Sockets Layer) adalah standar keamanan yang melakukan proses enkripsi antara server dan client. Atau mail server dan mail client. TLS (Transport Secure

Layer) adalah lanjutan dari SSL. SSL/TLS memungkinkan berisi informasi sensitif

seperti nomor kartu kredit, nomor jaminan sosial, dan login untuk ditransmisikan dengan aman. Biasanya, data yang dikirim antara browser dan server dalam bentuk

plain-text (teks biasa) sehingga rentan terhadap penyadapan. Jika seorang dapat

(46)

adalah sebuah protokol keamanan. Protokol menggambarkan bagaimana seharusnya sebuah algoritma digunakan dan dalam hal ini protokol menentukan variabel enkripsi yang akan digunakan (digicert.com). Enkripsi yang digunakan di SSL/TLS menggunakan enkripsi asimetris, suatu enkripsi yang menggunakan private key dan public key.

Perbedaan antara SSL dan TLS sangatlah halus dan sangat teknis, tapi sistem TLS ini lebih baru dan lebih halus. Keamanan versi SSL 3.0, sebanding dengan TLS 1.0, tapi TLS 1.1 dan 1.2 mampu memberikan keamanan yang sangat tajam. Meski begitu, dua metode ini sangat mirip. Pengguna dapat mengakses situs web yang dijamin dengan SSL dan TLS melalui sistem yang disebut Hypertext Transfer Protocol Secure (HTTPS).

SSL dan TLS sama-sama bertujuan untuk menjamin kerahasiaan, kesatuan dan keaslian informasi yang terkait. Untuk menjaga informasi, SSL dan TLS menggunakan kriptografi. Sedangkan untuk menjaga kesatuan informasi dimungkinkan dengan menggunakan digital signature (tanda tangan digital). Keaslian informasi dijamin dengan adanya sebuah sertifikat.

1. Algoritma Kriptografi

Kriptografi adalah ilmu pengetahuan seni untuk menjaga pesan atau informasi agar tetap aman dari pihak-pihak yang tidak dikehendaki. Untuk menjaga keamanan data, kriptografi melakukan proses penyandian informasi yang disebut dengan enkripsi. Dimana proses enkripsi bertujuan untuk menyandikan informasi berupa plainteks kedalam bentuk chiperteks. Proses pengambilan informasi dalam bentuk cipherteks ke dalam plaintext disebut dengan proses deskripsi. Proses enkripsi dan deskripsi menggunakan algoritma (cipher) dan sebuah kunci. Semakin baik algoritma yang digunakan, maka semakin sulit bagi orang yang tidak mengetahui kunci rahasia untuk dalam memperoleh dan mengetahui informasi yang disandikan.

Berdasarkan jenis kunci yang digunakan, algoritma kriptografi ada 2 jenis : 1. Kriptografi simetris

(47)

2. Kriptografi Asimetris

Kriptografi asimetris menggunakan kunci yang berbeda saat proses enkripsi dan deskripsi. Sehingga, asimetris lebih aman untuk digunakan. Karena, pihak-pihak lain harus mengetahui 2 kunci yang digunakan.

2. Digital Signature (Tanda Tangan Digital)

Dalam memastikan kesatuan informasi yang dikirimkan dalam setiap pertukaran informasi dalam SSL dilengkapi dengan adanya sebuah digital signature. Digital signature memiliki fungsi sebagai penanda pada data yang memastikan bhwa data tersebut adalah data yang sebenarnya. Digital signature berupa informasi yang melalui proses enkripsi dengan kunci umum menggunakan fungsi hash. Hash berfungsi mengubah masukan menjadi sebuah untaian karakter yang panjangnya tetap dan tertentu. Keluaran dari fungsi hash disebut nilai hash. Contohnya belanja online, informasi yang hendak akan dikirim oleh seorang pembeli diubah dengan fungsi hash sehingga menjadi untaian karakter yang disebut dengan message digest. Message digest kemudian akan dienkripsi oleh kunci publik menjadi digital

signature. Untuk dapat membuka digital signature dibutuhkan kunci privat.

Bila data telah diubah maka digital signature juga telah berubah sehingga kunci privat yang ada tidak akan bisa membukanya. Sehingga, keaslian data dapat terjamin dari perubahan-perubahan yang dilakukan pihak luar.

3. Sertifikasi

(48)

SSL bekerja melalui empat layer protocol (Record Layer, ChangeChiperSpec

protokol, Alert Protokol, dan Handshake Protokol) berfungsi mengenkapsulasi semua

komunikasi antara komputer client dengan server sehingga bisa terjalin koneksi yang aman (McKinley, 2015).

1. Record Layer

Record layer berupa layer yang melakukan format terhadap layer lainnya yaitu

ChangeChiperSpec Protocol, Alert Protocol, Handshake Protocol dan

application protokol messages. Format tersebut membentuk sebuah header

untuk tiap pesan dan hash yang dikirim. Header mempunyai nilai 5 byte, yang berisi protocol definition (1 byte), protocol Version (2 bytes), dan Length (2

bytes).

2. ChangeChiperSpec Protocol

Layer ChangeCipherSpec adalah suatu pesan yang memberi sinyal untuk

memulai komunikasi yang aman antara client dan server. Meskipun protokol ini menggunakan format record layer, layer ini sebenarnya hanya sebesar 1 byte.

3. Alert Protocol

Protokol ini mengirimkan error, masalah, ataupun warning mengenai koneksi antara klien dan server. Layer ini terbentuk dari dua field yaitu severity level dan alert description. Severity Level mengirim pesan dengan nilai “1” atau “2”, tergantung pada level concern-nya. Pesan dengan nilai “1” berarti sebuah peringatan agar klien dan server memutus session yang telah mereka lakukan dan reconnect lagi menggunakan handshake baru. Sedangkan nilai “2” berarti sebuah fatal alert message dan mengharuskan kedua belah pihak untuk mengakhiri session mereka. Kemudian field alert description yang bertugas mendeskripsikan secara spesifik error yang menyebabkan alert message tersebut keluar.

4. Handshake Protocol

Handshake protocol adalah proses pengiriman pesan secara bolak-balik dan

terus-menerus antara klien dan server untuk memulai sebuah komunikasi yang aman. Terdapat beberapa tahap dalam proses handshake ini yaitu: ClientHello,

(49)

TLS merupakan penerus dari SSL. Namun pada pengembangannya, TLS menerapkan dua level protokol pada kinerja untuk lebih meningkatkan keamanan (McKinley, 2015) :

1. TLS Record Protocol

TLS record protocol berfungsi untuk melakukan koneksi dan negoisasi yang

privat dan handal antara klien dan server. Meski record protocol bisa digunakan tanpa enkripsi, namun protokol ini tetap menggunakan kunci kriptografi simetris (symmetric cryptography Keys) untuk memastikan privasi keamanan koneksi. Koneksi ini diamankan melalui pemakaian fungsi hash yang dihasilkan oleh Message Authentication Code.

2. TLS Handshake Protokol

TLS Handshake protocol memberikan izin untuk mengautentikasi sebuah

komunikasi untuk memulai koneksi antara klien dan server. Protokol ini mengijinkan klien dan server untuk saling berkomunikasi dengan bahasa yang sama dan mengijinkan kedua belah pihak untuk menyetujui sebuah algoritma

enkripsi dan kunci enkripsi terlebih dahulu sebelum protokol aplikasi memulai

pengiriman data. Jalanya proses handshake pada TLS ini sama dengan proses yang terjadi pada SSL. TLS menyediakan autentikasi ke server dan juga secara opsional ke klien. Meskipun begitu, ada beberapa perubahan yang terjadi pada proses handshake tersebut.

2.4.2 OpenSSL

(50)

2.5 Socket

Socket adalah titik komunikasi dari lalu lintas komunikasi antar proses di dalam sebuah jaringan komputer. Hampir semua komunikasi antar komputer sekarang berdasarkan protokol internet, oleh karena itu hampir semua socket di jaringan komputer adalah Socket Internet. Adapun tujuan utama dari sebuah socket adalah untuk dapat menjembatani komunikasi yang terjadi antara dua buah program yang dijalankan pada mesin yang sama ataupun berbeda.

Hampir semua sistem operasi menyediakan application programming

interface (API) yang memungkinkan sebuah aplikasi komputer mengkontrol dan

menggunakan socket jaringan komputer. API socket internet biasanya berdasarkan pada standar berkeley sockets.

Sebuah alamat socket terdiri atas kombinasi sebuah alamat ip dan sebuah nomor port, mirip seperti sebuah koneksi telpon yang memiliki nomer telpon dan nomor ekstensinya. Berdasarkan alamat ini, socket internet mengirim paket data yang masuk ke sebuah proses atau thread aplikasi tujuan. Socket mampu menangani banyak klien sekaligus (multiple clients).

Ada 4 jenis socket yang sering digunakan user (Tutorials point,2015) .

1. Stream Socket

Stream Socket digunakan untuk komunikasi 2 arah dan menggunakan

protokol TCP (Transmission Control Protocol). Jika salah satu mengirim 3 item melalui stream socket “A,B,C” dan sebaliknya penerima juga akan mengirimkan data yang sama “A,B,C”. Namun, jika data itu bersifat tidak mungkin, maka pengirim akan menerima error.

2. Datagram Sockets

Datagram Socket dalam melakukan proses interaksi antara client-server

(51)

3. Raw Sockets

Raw Socket digunakan untuk melakukan pengiriman pesan ICMP (internet

control message protocol) pada layar internet/ip.

4. Sequenced Packet Sockets

Sequenced packet sockets disediakan hanya untuk bagian dari Network

Systems (NS) dan juga digunakan untuk aplikasi NS. Sequenced packet

sockets mengizinkan pengguna untuk memanipulasi Sequence Packet

Protocol (SPP) atau Internet Datagram Protocol (IDP).

2.6 Android

Menurut Safaat Nazruddin (2011) Android adalah sistem operasi untuk perangkat

mobile berbasis Linux. Android menyediakan platform yang bersifat open source bagi

para pengembang untuk menciptakan sebuah aplikasi. Awalnya, Google Inc mengakuisi Android Inc. Yang mengembangkan software untuk ponsel yang berada di Palo Alto, California Amerika Serikat. Untuk pengembangannya, dibentuklah Open Handset Alliance, yaitu konsorsium dari 34 perusahaan hardware, software, dan telekomunikasi, termasuk Google, HTC, Intel, Motorola, Qualcomm, T-Mobile, dan Nvidia. Telepon pertama yang memakai sistem operasi Android adalah HTC Dream, yang dirilis pada 22 Oktober 2008. Pada penghujung tahun 2009 diperkirakan di dunia ini paling sedikit terdapat 18 jenis. Dari segi arsitektur sistem, Android merupakan sekumpulan framework dan virtual machine yang berjalan di atas kernel linux. Virtual machine Android bernama Dalvik Virtual Machine (DVM), engine ini berfungsi untuk menginterpretasikan dan menghubungkan seluruh kode mesin yang digunakan oleh setiap aplikasi dengan kernel linux. Sementara untuk framework aplikasi sebagian besar dikembangkan oleh google dan sebagian yang lain dikembangkan oleh pihak ketiga (developer).

Menurut King C, Ableson (2011) Android memiliki empat komponen : a. Activity

(52)

class yang memperluas dasar kelas activity. Class akan menampilkan user

interface yang terdiri dari views dan merespon kejadian. Kebanyakan aplikasi terdiri dari beberapa layar. Sebagai contoh, sebuah aplikasi panggilan telepon mungkin memiliki satu layar yang menunjukkan daftar kontak untuk memanggil, layar kedua untuk menyimpan nomor telepon dan layar lain untuk memeriksa pesan masuk atau keluar. Masing-masing layar akan diimplementasikan sebagai suatu activity. Berpindah ke layar lain berarti memulai aktivity baru.

b. Broadcast Receiver

Broadcast receiver adalah komponen yang merespon terhadap siaran (broadcast) yang dikeluarkan oleh sistem. Seperti, broadcast memberitahukan bahwa layar akan mati, baterai lemah, pesan masuk. Meskipun broadcast receiver tidak menampilkan user interface, broadcast receiver bisa membuat notifikasi di status bar untuk memberitahukan user sedang terjadi broadcast. Secara umum, broadcast receiver hanyalah sebuah "gerbang" kepada komponen lain dan ditujukan untuk melakukan pekerjaan yang sangat minimal.

c. Service

Jika sebuah aplikasi memiliki sebuah siklus yang panjang, maka hal terbaik adalah meletakkannya dalam sebuah layanan. Service melakukan sinkronisasi data dibalik layar. Contohnya: saat sebuah service mendownload dari internet tanpa menganggu interaksi user dengan aktivitas yang lain.

d. Content provider

Jika sebuah aplikasi mengelola data dan butuh untuk mengekspos data ke aplikasi lain yang ada dalam lingkungan android, anda harus mempertimbangkan penyedia konten (content provider). Sebuah content

provider mengatur sekumpulan data aplikasi yang terbagi (shared). Kita

(53)

2.7 Kelemahan Pada SSL/TLS

2.7.1 Heartbleed Bug (Heartbleed Vulnerability )

Heartbleed Vulnerability adalah sebuah celah keamanan paling fatal, yang secara

resmi diidentifikasi oleh CVE-2014-0160. Kelemahan ini memungkinkan seseorang untuk mencuri informasi yang dilindungi dengan enkripsi SSL/ TLS. SSL/TSL yaitu sebuah aplikasi untuk mengamankan dan mengenkripsi teks (seperti username dan password) yang dikirim melalui browser. SSL/TLS menyediakan keamanan komunikasi dan privasi melalui internet untuk aplikasi seperti web, email, instant

messaging (IM) dan beberapa jaringan pribadi virtual (VPN).

Heartbeat adalah salah satu fitur OpenSSL yang diperkenalkan tahun 2012. Tujuan heartbeat adalah mengecek apakah komputer client masih terhubung ke sebuah server.

Gambar 2.1

Pada gambar 2.1 menunjukkan bagaimana seharusnya client dan server terhubung dan bagaimana server seharusnya menanggapi request dari klien. Namun, fasilitas heartbeat ini memiliki kelemahan karena server terlalu percaya dengan komputer pengirim (client). Seperti gambar di bawah, komputer hacker cuma mengirimkan

payload = test namun meminta respon sebanyak 30 karakter.

Gambar 2.2

(54)

memenuhi permintaan 30 karakter. 30 karakter hanyalah ilustrasi, sang hacker bisa meminta sampai 64.000 karakter.

Kelemahan yang terdapat pada aplikasi heartbeat inilah yang disebut dengan

Heartbleed bug, dimana dengan adanya celah ini, memungkinkan setiap orang di

internet untuk membaca memori dari sistem yang dilindungi OpenSSL dan membuat penyerang dapat mengamati komunikasi, mencuri data langsung dari layanan dan pengguna dan juga menyamar sebagai layanan dan pengguna.

2.7.2 Logjam

Logjam adalah sebuah jenis celah keamanan yang memungkinkan seseorang dapat menyusup kedalam enkripsi sebagai pihak ketiga, dalam proses interaksi secara virtual dengan tujuan menyadap ataupun melihat dari pesan yang disampaikan pengirim ke penerima. Celah keamanan ini mengancam keamanan privasi data pengguna. Hacker dapat melakukan serangan dengan menginjeksikan diri ke komunikasi antara klien dan server MITM (Man-In-The-Middle). Serangan logjam mempengaruhi setiap server yang mendukung DHE_EXPORT cipher, dan mempengaruhi semua web browser yang sudah modern. 8,4% dari Top 1 Juta domain awalnya rentan.

2.7.3 CVE 2015-1793

Selama verifikasi sertifikat berlangsung, OpenSSL (mulai dari versi 1.0.1n dan 1.0.2b) akan mencoba untuk menemukan alternative certificate chain jika upaya pertama untuk membangun hubungan sertifikat gagal. Kesalahan dalam pegimplementasian logika, membuat seorang penyerang dapat menyebabkan pemeriksaan tertentu pada sertifikat yang tidak dipercaya untuk dilewatkan, seperti yang dilakukan CA (Certificate Authority), kelemahan ini memungkinkan penyerang untuk melewati sertifikat terpercaya seperti CA dan dalam masalah ini yang masuk adalah sertifikat tidak terpercaya.

(55)

2.8 Pengujian Aplikasi

2.8.1 White-Box Testing

White-Box testing adalah cara pengujian yang berfokus pada pengecekan terhadap detail perancangan dengan melihat ke dalam modul untuk meneliti kode-kode program yang ada, dan menganalisis apakah ada kesalahan atau tidak. Jika ada modul yang menghasilkan output yang tidak sesuai dengan proses bisnis yang dilakukan, maka baris-baris program, variabel, dan parameter yang terlibat pada unit tersebut akan dicek satu persatu dan diperbaiki, kemudian di-compile ulang. White-box testing bertujuan untuk mendapatkan program yang benar secara keseluruhan. White-box

testing, perangkat dapat melakukan :

1. Memberikan jaminan bahwa semua jalur independen pada suatu modul telah digunakan paling tidak satu kali.

2. Menggunakan semua keputusan logis pada sisi true and false

3. Mengeksekusi semua loop pada batasan mereka dan pada batas operasional mereka.

4. Menggunakan struktur data internal untuk menjamin validitasnya. Proses Pengujian White-Box testing :

1. Untuk mengetahui cara kerja suatu perangkat lunak secara internal.

2. Untuk menjamin operasi-operasi internal sesuai dengan spesifikasi yang telah ditetapkan dengan menggunakan struktur dari prosedur yang dirancang.

2.8.2 Black-Box Testing

Black-Box testing berfokus pada persyaratan fungsional perangkat lunak yang memungkinkan engineers untuk memperoleh set kondisi input yang sepenuhnya akan melaksanakan persyaratan fungsional untuk sebuah program (Pressman, 2010). Black

Box Testing bukan merupakan alternatif dari pengujian White Box Testing.

Sebaliknya, Black Box Testing adalah pendekatan komplementer yang mungkin untuk mengungkap kelas yang berbeda dari kesalahan daripada metode White Box Testing.

Black-Box testing berusaha untuk menemukan kesalahan dalam kategori berikut:

1. Fungsi yang tidak benar atau fungsi yang hilang 2. Kesalahan antarmuka

(56)

4. Kesalahan perilaku (behavior) atau kesalahan kinerja 5. Inisialisasi dan pemutusan kesalahan

Tes ini dirancang untuk menjawab beberapa pertanyaan-pertanyaan berikut ini: 1. Bagaimana validitas fungsional diuji?

2. Bagaimana perilaku dan kinerja sistem diuji? 3. Apa kelas input akan membuat kasus uji yang baik? 4. Apakah sistem sensitive terhadap nilai input tertentu? 5. Bagaimana batas-batas kelas data yang terisolasi?

6. Kecepatan dan volume data seperti apa yang dapat ditolerir sistem?

7. Efek apakah yang akan menspesifikasikan kombinasi data dalam sistem operasi?

2.8.3 Gray-Box testing

Gray-Box testing Adalah metode yang merupakan kombinasi dari Black-box testing

dan White-box testing. Dalam pengujian Gray-box testing, struktur internal sebagian dikenal. Ini melibatkan akses ke internal struktur data dan algoritma untuk tujuan merancang uji kasus, tetapi pengujian pada pengguna atau tingkat Black box adalah tidak. Grey-box, berusaha menggabungkan kedua metode diatas, mengambil kelebihan keduanya, dan mengetahui kekurangan keduanya. Teknik verifikasi modern menerapkan kombinasi kedua metode untuk pengujian aplikasi.

2.9 Penelitian Terdahulu

Penulis memaparkan beberapa metode yang telah digunakan pada penilitian sebelumnya untuk menguji keamanan aplikasi web dan aplikasi mobile. Seperti yang tercantum pada tabel 2.1, metode black-box digunakan untuk mengurangi kesalahan dalam mengeksploitasi celah keamanan dan juga untuk lebih meningkatkan kinerja aplikasi untuk menemukan halaman yang nanti digunakan untuk mendeteksi celah keamanan. Namun, peneliti menggunakan metode black-box testing untuk memastikan kinerja dan kekuatan dari sebuah teknologi yang digunakan untuk mengetahui kelemahan yang dapat ditimbulkan dari teknologi tersebut.

(57)

of false positives dengan memberikan query dengan tujuan agar eksploitasi tentang

celah keamanan berhasil. Dengan menggunakan metode black box, memungkinkan aplikasi untuk menemukan halaman baru pada web, yang mungkin berisi poin injeksi dan halaman yang rentan.

Pada tahun 2014 Gujrathi, memberikan penjelasan secara rinci kerja dari Heartbleed bug dan bagaimana bug ini dapat mempengaruhi privasi dan integritas data. Jurnal ini menjelaskan bagaimana seharusnya heartbleed bekerja, dan bagaimana seorang hacker dapat memberikan sebuah script yang dapat mencuri data yang tersimpan dalam memori server. Gujrathi menjelaskan bagaimana seharusnya user memproteksi diri dari heartbleed bug.

Pada tahun 2008 Suhina et al, mengusulkan sebuah pendekatan untuk menemukan celah keamanan pada aplikasi web dengan clustering halaman web. Metode yang digunakan bukan seperti teknik pencari kelemahan aplikasi web yang menganalis isi halaman web tetapi dengan menganalis struktur dari halaman web. Kinerja metode yang diusulkan yaitu menganalisis respon dari struktur halaman, dikelompokkan ke beberapa kategori berdasarkan strukturnya dan menemukan penyimpangan dari struktur standar halaman.

J Bau et al. (2010), State of the Art: Automated Black-Box Web Application

Vulnerability Testing, metode black box bertujuan untuk mendeteksi kelemahan dan

menguji efektivitas sistem dalam mendeteksi celah kelemahan seperti Cross-Site Scripting, SQL Injection, dan bentuk lain dari Cross-Channel Scripting. J Bau et al menyatakan bahwa script atau kode injeksi berhasil disimpan, yang dikemudian akan di deteksi lagi.

Pada tahun 2014 Stephan, menjelaskan bahwa heartbleed bug adalah kelemahan yang terletak pada teknologi heartbeat yang terdapat pada OpenSSL, dimana terjadi sebuah kesalahan dari server dalam menangani request dari client. Dijelaskan juga bagaimana seharusnya server dan user menangani bug heartbleed.

Figur

Gambar 3.1  Arsitektur Umum Aplikasi
Gambar 3 1 Arsitektur Umum Aplikasi . View in document p.5
Gambar 3.2 Proses Handshake URL Website
Gambar 3 2 Proses Handshake URL Website . View in document p.8
Gambar 3.3 Proses Penyerangan
Gambar 3 3 Proses Penyerangan . View in document p.9
Gambar 3.4 Proses Validasi SSL
Gambar 3 4 Proses Validasi SSL . View in document p.10
Gambar 3.5 Proses Pengumpulan Informasi
Gambar 3 5 Proses Pengumpulan Informasi . View in document p.11
Gambar 3.6 Proses identifikasi kelemahan
Gambar 3 6 Proses identifikasi kelemahan . View in document p.12
Gambar 3.7 Proses Identifikasi Kelemahan device
Gambar 3 7 Proses Identifikasi Kelemahan device . View in document p.13
Gambar 3.8 Proses testing Heartbleed
Gambar 3 8 Proses testing Heartbleed . View in document p.14
Gambar 3.9 flowchart validasi SSL
Gambar 3 9 flowchart validasi SSL . View in document p.17
Gambar 3.10 Proses Scan device
Gambar 3 10 Proses Scan device . View in document p.18
Gambar 3.11 Rancangan Halaman Utama
Gambar 3 11 Rancangan Halaman Utama . View in document p.21
Gambar 3.12 Rancangan Halaman Scan URL
Gambar 3 12 Rancangan Halaman Scan URL . View in document p.22
Gambar 3.13 Rancangan Halaman Scan device
Gambar 3 13 Rancangan Halaman Scan device . View in document p.23
Gambar 3.14 Rancangan Halaman Tutorial
Gambar 3 14 Rancangan Halaman Tutorial . View in document p.24
Gambar 4.1 Halaman Utama
Gambar 4 1 Halaman Utama . View in document p.26
Gambar 4.2 Halaman Scan URL
Gambar 4 2 Halaman Scan URL . View in document p.27
Gambar 4.3 Halaman Scan Device
Gambar 4 3 Halaman Scan Device. View in document p.28
Tabel 4.2 sampel aplikasi android
Tabel 4 2 sampel aplikasi android . View in document p.30
Tabel 4.4 hasil pengujian terhadap aplikasi browser
Tabel 4 4 hasil pengujian terhadap aplikasi browser . View in document p.31
Tabel 4.5 sampel hasil pengujian terhadap aplikasi android
Tabel 4 5 sampel hasil pengujian terhadap aplikasi android . View in document p.31
Tabel 4.3 hasil pengujian terhadap aplikasi Website
Tabel 4 3 hasil pengujian terhadap aplikasi Website . View in document p.31
tabel sampel 4.1, dari situs itu akan dilakukan proses koneksi dengan URL. Setelah
URL Setelah . View in document p.33
Gambar 4.4 hasil testing heartbleed
Gambar 4 4 hasil testing heartbleed . View in document p.34
gambar 4.5
gambar 4.5 . View in document p.34
Gambar 4.6 proses verifikasi SSL/TLS server
Gambar 4 6 proses verifikasi SSL TLS server . View in document p.35
Gambar 4.6 hasil testing device
Gambar 4 6 hasil testing device. View in document p.36
Gambar 2.1 Pada gambar 2.1 menunjukkan bagaimana seharusnya client dan server terhubung dan
Gambar 2 1 Pada gambar 2 1 menunjukkan bagaimana seharusnya client dan server terhubung dan . View in document p.53
Gambar 2.2 Pada gambar 2.2, server ternyata tidak mengecek kalau test hanya memiliki 4 karakter
Gambar 2 2 Pada gambar 2 2 server ternyata tidak mengecek kalau test hanya memiliki 4 karakter. View in document p.53
Tabel 2.1 Penelitian Terdahulu
Tabel 2 1 Penelitian Terdahulu . View in document p.58

Referensi

Memperbarui...