Pendeteksian Celah Keamanan SSL/TLS Menggunakan Android

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

http://news.netcraft.com/archives/2014/04/08/half-a-million-widely-trusted-websites-vulnerable-to-heartbleed-bug.html(Diakses 13 maret 2015)


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

Tutorials point .2015. What is a

Socket?,http://www.tutorialspoint.com/unix_sockets/what_is_socket.htm(diakses 16 januari 2016)

Netcraft .2014. April 2014 Web Server Survey,

http://news.netcraft.com/archives/2014/04/02/april-2014-web-server-survey.html

(diakses 16 januari 2016)

Raiyani, S., Shah, D., Shah, A. & Rustagi, R. 2015. A Survey Of Heartbleed Bug.

International Journal of Multidisciplinary Consortium Volume – 2 | Issue – 1 | March 2015.

Simpson ,S. & Hayter, A .2014. Bugs in heartbleed detection scripts.

http://www.hut3.net/blog/cns---networks/security/2014/04/14/bugs-in-heartbleed-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 .

http://www.westpoint.ltd.uk/blog/2014/04/14/understanding-the-heartbleed-proof-of-concept/ (diakses 3 juni 2015 )


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

Penyebab aplikasi sering diserang dikarenakan kesalahan dari pihak pemilik sistem dan pihak pengelola, yang seharusnya menguji dan mengawasi kinerja sistem dan teknologi yang digunakan secara rutin. Kemungkinan masih banyak celah keamanan yang melekat pada aplikasi web dan aplikasi mobile yang memerlukan proses autentifikasi untuk dapat mengaksesnya. Celah keamanan disisi aplikasi web salah satunya adalah kesalahan dari teknologi yang digunakan pada sisi server,


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

Kemudian input yang diberikan pengguna akan diproses sesuai dengan bagian kerja yang dipilih pengguna.


(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

Pada sistem yang akan dibangun, tahapan Handshake ditujukan untuk memastikan komunikasi telah terjalin antara server dan klien. Dalam tahhapan Handshake sistem akan mengirimkan pesan ke server dan memastikan kanal atau protokol yang akan digunakan antara klien dan server saat melakukan komunikasi.


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

4. Setelah melewati tahapan pembacaan header, dapat dipastikan bahwa komunikasi antara server dan klien sudah terjalin dan telah ada pertukaran


(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 grep OpenSSL. Pada tahap selanjutnya akan dilakukan pengecekkan aplikasi yang


(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

Saat melakukan scenario penyerangan pada satu URL, kemudian akan dilakukan pembacaan response yang dikirim server saat itu juga akan dilakukan vulnerable identification. Response dari web server berupa parameter-parameter header, yang didalam terdapat type, payload dan length. Pembacaan type dan panjang payload akan menentukan kelemahan server terhadap heartbleed. Setelah server dinyatakan lemah berdasarkan parameter yang didapatkan dari server, maka akan dilakukan pembacaan hex dump memory, untuk melihat isi memory server. untuk merepresentasikan proses vulnerable identification scan url dapat dilihat pada gambar 3.6.


(12)

Gambar 3.6 Proses identifikasi kelemahan b. Scan device

Setelah dilakukan pengumpulan informasi oleh sistem dan didapatkan hasil berupa versi OpenSSL yang digunakan Os android dan aplikasi terinstall didalamnya, maka akan ditentukan kelemahan os android dan aplikasi berdasarkan versi OpenSSL. Versi OpenSSL os android berbeda dengan OpenSSL aplikasi yang terinstall didalamnya. Kelemahan OpenSSL pada sisi pengguna dapat diketahui hanya dengan mengetahui versi OpenSSL yang digunakan karena server yang akan menyesuaikan SSL yang akan digunakan saat berkomunikasi sesuai dengan SSL yang bawaan os android atau aplikasi. Versi browser juga akan di cek untuk menentukan apakah browser vulnerable terhadap logjam atau tidak.


(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

Heartbleed terjadi karena adanya kesalahan dari server yang menggunakan teknologi OpenSSL untuk menanggapi panjang respon yang berbeda dari nilai payload yang dikirim client ke server. untuk menguji sebuah aplikasi apakah rentan terhadap serangan Heartbleed atau tidak, diuji berdasarkan panjang respon yang dikirimkan URL sebuah web. Adapun lebih jelasnya tahapan proses dalam menguji aplikasi web rentan atau tidak terhadap serangan Heartbleed dipresentasikan pada gambar 3.8.


(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

handshake untuk mengetahui apakah server yang diinput oleh pengguna mempunyai teknologi heartbeat yang berfungsi untuk mengecek komunikasi antara klien dan server terhubung. Proses handshake dilakukan dengan cara mengirim hello dalam format hex ke server. Isi pesan hello yang dikirim pengguna


(15)

"16030200dc010000d8" "030253435b909d9b720bbc0cbc2b92a84897cfbd" "3904cc160a8503909f770433d4de000066c014c0" "0ac022c0210039003800880087c00fc005003500" "84c012c008c01cc01b00160013c00dc003000ac0" "13c009c01fc01e00330032009a009900450044c0" "0ec004002f00960041c011c007c00cc002000500" "040015001200090014001100080006000300ff01" "000049000b000403000102000a00340032000e00" "0d0019000b000c00180009000a00160017000800" "0600070014001500040005001200130001000200" "03000f0010001100230000000f000101"

Bagian pertama dari isi pesan hello klien adalah pesan handshake SSL dan 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

01 Handshake types (Client Hello) 00 00 d8 panjang hello

03 02 versi TLS klien (1.1) Bagian selanjutnya adalah

53 43 5b 90 Timestamp

9d 9b 72 0b bc 0c bc 2b 92 a8 48 97 cf

bd 39 04 cc 16 0a 85 03 90 9f 77 04 33 d4 de Random bytes


(16)

dan selanjutnya mendefinisikan tentang 00  panjang session id

00 66 panjang cipher suite

c0 14 c0 0a c0 22 c0 21 00 39 00 38 00 88

00 87 c0 0f c0 05 00 35 00 84 c0 12 c0 08 c0 1c

c0 1b 00 16 00 13 c0 0d c0 03 00 0a c0 13 c0 09

c0 1f c0 1e 00 33 00 32 00 9a 00 99 00 45 00 44

c0 0e c0 04 00 2f 00 96 00 41 c0 11 c0 07 c0 0c

c0 02 00 05 00 04 00 15 00 12 00 09 00 14 00 11

00 08 00 06 00 03 00 ff Cipher suites 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 0b 00 0c 00 18 00 09 00 0a 00 16 00 17 00 08

00 06 00 07 00 14 00 15 00 04 00 05 00 12 00 13

00 01 00 02 00 03 00 0f 00 10 00 11

Elliptic curve

00 23 00 00  TLS session ticket 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

18  TLS record is a heartbeat 03 02 TLS version 1.1


(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

Fungsi utama sistem dibangun adalah sistem mampu untuk melakukan pendeteksian celah keamanan heartbleed pada aplikasi website, melakukan verifikasi SSL aplikasi


(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

User interface atau antar muka merupakan sebuah sarana yang menghubungkan manusia dengan sistema agar manusia dan sistem dapat saling berinteraksi. Perancangan user interface atau antarmuka pengguna memberikan gambaran umum mengenai perancangan setiap tampilan antarmuka pengguna pada aplikasi yang dibangun.


(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

dimasukkan pengguna, button ssl info untuk memverifikasi input yang dimasukkan pengguna, button get url untuk menampilkan history dari google chrome yang akan discannig dan button reset untuk menghapus tampilan di textview.


(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

Pada halaman scan device dan application akan diisi kompone textview untuk menampilkan info openssl android, textview untuk menampilkan identifikasi kelemahan aplikasi browser yang ada di android, dan ada viewgroup yang didalamnya


(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

Gambar 3.13 Rancangan Halaman Scan device Nama Aplikasi

Textview VersiOpenssl

View 1i

holdlayout

data image1

holdlayout1

openssl bleed logjam cve2015


(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

Pada Gambar terdapat 2 komponen pada interface, yaitu nama aplikasi yang menjelaskan aplikasi dan textview menampilkan tatacara penggunaan aplikasi.


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

7. Sistem operasi android versi 4.1.2 (jelly bean) 8. Memori RAM android yang digunakan 1.00 GB 9. Busybox


(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

Pengujian sistem merupakan hal yang penting untuk menemukan kesalahan atau kekurangan pada komponen sistem yang telah diimplementasi. Pengujian sistem memastikan apakah setiap komponen dalam sistem telah berfungsi sesuai yang diharapkan. Teknik black-box testing juga digunakan untuk menguji sistem, yaitu pengujian yang dilakukan pada interface sistem tanpa melihat coding. Pengujian bertujuan untuk mengetahui perangkat lunak yang dibuat sudah memenuhi kriteria yang sesuai dengan tujuan perangkat lunak.


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

Tabel 4.1 sampel alamat website

No Alamat Website

1 https://www.mail.usu.ac.id 2 https://www.olx.co.id 3 https://www.its.ac.id/

4 https://ww.worthytoshare.net/ 5 https://www.lazada.co.id/ 6 https://www.ugm.ac.id / 7 https://www.ui.ac.id/

8 https://www.koreabridge.net/ 9 https://www.kaskus.co.id/ 10 https://www.voobys.com/ 11 https://www.uns.ac.id/ 12 https://www.bukalapak.com/ 13 https://www.news.detik.com/


(30)

Tabel 4.2 sampel aplikasi android

No Aplikasi android

1 BBM 2 Facebook

3 Facebook messenger 4 Candy crush

5 Netflix 6 Instagram

7 Google play services 8 Getrich

9 Kakaotalk 10 Google Chrome 11 Mozilla Firefox

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

Metode pada penelitian ini juga diuji dengan data alamat website yang benar-benar memiliki celah keamanan maupun tidak seperti sampel data alamat website, browser dan aplikasi android pada tabel 4.3 sampai 4.5. Hal ini dilakukan untuk menunjukkan kemampuan aplikasi yang mengimplemenatasikan metode black-box testing untuk mendeteksi celah keamanan pada aplikasi website ataupun aplikasi android yang rentan terhadap kelemahan terkait OpenSSL. Sampel data alamat website ataupun aplikasi android tersebut telah peneliti uji dengan black-box testing untuk mengetahuo ada tidaknya celah keamanan. Hasil pengujian ini disajikan pada tabel. Sehingga dapat disimpulkan metode yang diajukan mampu untuk mendeteksi celah keamanan pad aplikasi web ataupun aplikasi android.


(31)

Tabel 4.3 hasil pengujian terhadap aplikasi Website

No. Website Heartbleed

Validasi SSL

SHA1 Self Signed DHE Support

1 https://www.mail.usu.ac.id/ -  - 

2 https://www.olx.co.id/ - - - 

3 https://www.its.ac.id/ - - - 

4 https://worthytoshare.net/    

5 https://www.lazada.co.id/ - - - 

6 https://www.ugm.ac.id/ -  - 

7 https://www.ui.ac.id/ -  - 

8 https://www.koreabridge.net/    

9 https://www.kaskus.co.id/ - - - 

10 https://www.voobys.com/    

11 https://www.uns.ac.id/ -   

12 https://www.bukalapak.com/ - - - -

13 https://www.news.detik.com/ -  - 

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 -

Tabel 4.5 sampel hasil pengujian terhadap aplikasi android Nama

aplikasi Versi

Versi

OpenSL Heaarbleed Logjam

Cve 2015-1793

BBM 2.1 1.0.1e  - -


(32)

2.3 1.0.1h - - -

2.4-2.6 1.0.1i - - -

2.7 1.0.1l - - -

2.8 1.0.1m - - -

2.9 1.0.1o - - 

2.10-2.11 1.0.1p - - -

Facebook Messenger

1.0-2.5 - - - -

2.7-3.2 1.0.1c  - -

3.3-9 1.0.1e  - -

10-25 1.01h - - -

Facebook

1.8-3.5 - - - -

3.7-4.0 1.0.1c  - -

6-10.0 1.0.1e  - -

11.0-28.0 1.0.1h - - -

29.0-30.0 1.0.2 -  -

31.0 1.0.2a - - -

Instagram

3.4-6.2 - - - -

6.3.1 1.0.1e  - -

6.4-6.18 1.0.1h - - -

Candy crush Saga

1.0-1.15 1.0.0a - - -

1.16-1.31 1.0.1e  - -

1.32-1.33 1.0.1g - - -

1.34-1.66 1.0.1h - - -

Kakaotalk

2.5 - - - -

4.0-4.4 1.0.1e  - -

4.5-5.3 1.0.1h - - -

Netflix

3.2 1.0.0j - - -

3.7.2-3.8.1 1.0.1g - - -

3.8.2-3.12 1.0.1i - - -

3.13-3.16 1.0.1m - - -


(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

digunakan, jenis verifikasi kunci dan cipher suite yang digunakan aplikasi. Kemungkinan resiko yang disebabkan ketika aplikasi web diserang karena kelemahan di teknologi SSl adalah pembajakan data-data penting dengan mempengaruhi layanan SSL untuk menampilkan data-data sensitif yang terdapat dalam aplikasi web seperti username, password, alamat, data-data keuangan, dan data pribadi lainnya. Untuk hasil testing nya dapat dilihat pada gambar 4.6.


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

Berdasarkan proses menguji kelemahan OpenSSL, disimpulkan rentannya OpenSSL yang dimiliki android dan aplikasi terinstall didalamnya dengan melakukan pengecekkan terhadap versi OpenSSL yang dimiliki.


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

2. Penerapan black-box testing dalam sistem mampu mendeteksi celah keamanan pada aplikasi web dan aplikasi android pada android yang umumnya disebabkan oleh kesalahan pengimplementasian dan kelemahan teknologi didalam layanan SSL/TLS.


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

2. Sistem selanjutnya diharapkan bukan hanya mampu mengeksploitasi heartbleed bug, tapi dapat mengeksploitasi kelemahan terkait OpenSSL (seperti : logjam, CVE 2015, dll).


(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

Keamanan informasi menjamin bahwa hanya mereka yang memiliki hak yang boleh mengakses informasi tertentu. Pengertian lain dari 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

Keamanan adalah perlindungan sumber daya dari kerusakan dan perlindungan data terhadap penyingkapan dari orang yang tidak sah atau modifikasi yang tidak sah.


(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

Dalam keamanan komputer, otorisasi adalah proses setelah autentikasi, untuk memverifikasi hak akses pengguna terhadap data. Dalam kategori kelemahan


(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 2. Insecure Data Storage

3. Insufficient Transport Layer Protection 4. Unintended Data Leakage

5. Poor Authorization and Authentication 6. Broken Cryptography

7. Client Side Injection

8. Security Decisions Via Untrusted Inputs 9. Improper Session Handling


(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

Dibuat sebagai pelaksana/pengolah data yang spesifik untuk kebutuhan tertentu.


(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,

Anda dapat dengan mudah melakukan berbagai macam aktifitas mulai dari hiburan, berjualan, belajar, mengerjakan pekerjaan kantor, browsing dan lain sebagainya. Pemanfaatan aplikasi mobile untuk hiburan paling banyak digemari oleh hampir 70% pengguna telepon seluler, karena dengan memanfaatkan adanya fitur game, music player, sampai video player membuat kita menjadi semakin mudah menikmati hiburan kapan saja dan dimanapun


(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

mencegat semua data yang dikirimkan browser ke webserver, maka mereka dapat melihatnya dan menggunakan informasi tersebut. Lebih spesifik lagi, SSL dan TLS


(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

Kriptografi simetris menggunakan kunci yang sama saat proses enkripsi dan deskripsi. Sehingga, dinamakan dengan single-key


(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

Dalam hal memastikan siapa saja yang terlibat dalam pertukaran informasi lewat internet, SSL menggunakan sertifikat digital untuk mengotentikasi (memastikan indentitas) server. Otentifikasi pengunjung situs tidak harus dilakukan (optional). Sehingga dengan sertifikat ini maka dapat terhindar dari pihak yang mengaku sebagai server dengan kunci yang salah. SSL menggunakan sertifikat X.509 untuk menvalidasi identitas. Sertifikat mengandung informasi dari pihak yang terkait, termasuk kunci publik dan nama.


(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

Menurut www.openssl.org, OpenSSL adalah proyek open source yang menyediakan layanan yang kuat, commercial-grade, dan toolkit dengan fitur lengkap untuk Transport Layer Security (TLS) dan Secure Socket Layer (SSL) protokol. OpenSSL juga merupakan sebuah library kriptografi untuk tujuan yang sama. OpenSSL toolkit ini di bawah lisensi Apache, yang pada dasarnya berarti bahwa anda bebas untuk mendapatkan dan menggunakannya untuk tujuan komersial dan non-komersial dan harus tunduk pada beberapa kondisi lisensi sederhana. OpenSSL memberikan layanan untuk menjaga keamanan komunikasi dari pihak yang tidak diinginkan.


(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

tidak harus selalu terhubung terus-menerus (connectionless). Klien Dapat mengirimkan data ke server, namun data tersebut ada kemungkinan sampai ke server atau tidak. Untuk itu client menunggu sinyal „error free‟ dari server. Jika client tidak menerima sinyal „error free‟ dalam suatu kurun waktu, maka client akan mengirimkan lagi data tersebut. Datagram Socket menggunakan UDP (User Datagram Protocol).


(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

Setiap aplikasi mungkin mempunyai user interface (UI), namun tidak harus memiliki satu UI. Jika sebuah aplikasi memiliki UI, setidaknya memiliki satu Activity. Setiap activity diimplementasikan sebagai satu


(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

bisa menyimpan data di filesystem, sebuah database SQLite, di web, atau di metode penyimpanan data lainnya yang bisa diakses oleh aplikasi 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

Pada gambar 2.2, server ternyata tidak mengecek kalau test hanya memiliki 4 karakter. Server langsung mengirimkan semua karakter yang tersimpan di memorinya untuk


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

Jenis kelemahan ini termasuk MITM attack dan dapat menyebabkan aplikasi menerima SSL certificate yang tidak valid dan terpercaya seolah SSL certificate yang valid.


(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


(1)

vi

SSL/TLS VULNERABILITY DETECTOR USING ANDROID

ABSTRACT

Increasing of crime cause smartphone technology which not only used for communication. Web application and android application is often attacked for obtain confidental information such as account bank number, personal photos, or sensitive data such as SMS (Short Message service) and contact number. This risk occur cause there are errors from the technology which are used by web application or mobile application to provide security data communication service. One type of vulnerability which exploited by cracker is heartbleed. To assist user for find out security service and vulnerability of SSL/TLS using application of security detection. The Blackbox testing method is used in this application for detection of security vulnerable in web application and android application. This Application detect SSL/TLS vulnerability which is open source such as heartbleed, logjam and CVE 2015-1793 and this application also can verify SSL provider which is used by web application


(2)

vii

DAFTAR ISI

PERSETUJUAN ii

PERNYATAAN iii

UCAPAN TERIMA KASIH iv

ABSTRAK v

ABSTRACT vi

DAFTAR ISI vii

DAFTAR TABEL x

DAFTAR GAMBAR xi

BAB IPENDAHULUAN 1

1.1 Latar Belakang 1

1.2 Rumusan Masalah 4

1.3 Batasan Masalah 4

1.4 Tujuan Penelitian 4

1.5 Manfaat Penelitian 5

1.6 Metodologi Penelitian 5

1.7 Sistematika Penulisan 5

BAB II LANDASAN TEORI 7

2.1 Keamanan Informasi 7

2.2 Celah Keamanan / Vulnerability 8

2.2.1 Celah Keamanan Aplikasi Web 9

2.2.2 Celah Keamanan Pada Aplikasi Mobile 10

2.3 Aplikasi dan Keamanan Aplikasi 11

2.3.1 Aplikasi Web 12


(3)

viii

2.3.3 Keamanan Aplikasi 13

2.4 SSL/TLS dan OpenSSL 13

2.4.1 SSL/TLS 13

2.4.2 OpenSSL 17

2.5 Socket 18

2.6 Android 19

2.7 Kelemahan Pada SSL/TLS 21

2.7.1 Heartbleed Bug (Heartbleed Vulnerability ) 21

2.7.2 Logjam 22

2.7.3 CVE 2015-1793 22

2.8 Pengujian Aplikasi 23

2.8.1 White-Box Testing 23

2.8.2 Black-Box Testing 23

2.8.3 Gray-Box testing 24

2.9 Penelitian Terdahulu 24

BAB IIIANALISIS DAN PERANCANGAN SISTEM 27

3.1 Identifikasi Masalah 27

3.2 Analisis Sistem 28

3.2.1 Scan Device 29

3.2.2 Scan URL 29

3.3 Proses Menguji Celah Kelemahan Aplikasi Web dan Aplikasi Mobile 36

3.3.1 Proses menguji serangan Heartbleed 36

3.3.2 Proses memverifikasi teknologi SSL server 40

3.3.3 Proses mengecek kelemahan terkait OpenSSL pada os android device dan

aplikasi mobile 41

3.4 Perancangan Sistem 42


(4)

ix

3.4.2 Batasan -batasan 43

3.4.3 Data yang digunakan 43

3.4.4 Analisis pengguna 43

3.5 Perancangan User Interface 43

3.5.1 Rancangan halaman utama 44

3.5.2 Rancangan halaman Scan Url 44

3.5.3 Rancangan halaman Scan Device dan Application 45

3.5.2 Rancangan halaman tutorial aplikasi 47

BAB 4IMPLEMENTASI DAN PENGUJIAN SISTEM 48

4.1 Implementasi Sistem 48

4.1.1 Spesifikasi perangkat keras dan perangkat lunak yang digunakan 48

4.1.2 Implementasi Black-Box testing 49

4.2 Pengujian Sistem 51

4.3 Pengujian Sistem Secara Menyeluruh dan Hasil Blackbox testing 52

4.3.1 Hasil Black-box Testing 53

4.3.2 Hasil pengujian aplikasi web terhadap Heartbleed dan Validasi SSL 56

4.3.3 Hasil pengujian aplikasi Mobile terhadap Kelemahan OpenSSl 58

BAB 5KESIMPULAN DAN SARAN 60

5.1 Kesimpulan 60

5.2 Saran 61


(5)

x

DAFTAR TABEL

Tabel 2.1 Penelitian Terdahulu 26

Tabel 4.1 sampel alamat website 52

Tabel 4.2 sampel aplikasi android 53

Tabel 4.3 hasil pengujian terhadap aplikasi Website 54 Tabel 4.4 hasil pengujian terhadap aplikasi browser 54 Tabel 4.5 sampel hasil pengujian terhadap aplikasi android 54


(6)

xi

DAFTAR GAMBAR

Gambar 2.1 21

Gambar 2.2 21

Gambar 3.1 Arsitektur Umum Aplikasi 28

Gambar 3.2 Proses Handshake URL Website 31

Gambar 3.3 Proses Penyerangan 32

Gambar 3.4 Proses Validasi SSL 33

Gambar 3.5 Proses Pengumpulan Informasi 34

Gambar 3.6 Proses identifikasi kelemahan 35

Gambar 3.7 Proses Identifikasi Kelemahan device 36

Gambar 3.8 Proses testing Heartbleed 37

Gambar 3.9 flowchart validasi SSL 40

Gambar 3.10 Proses Scan device 41

Gambar 3.11 Rancangan Halaman Utama 44

Gambar 3.12 Rancangan Halaman Scan URL 45

Gambar 3.13 Rancangan Halaman Scan device 46

Gambar 3.14 Rancangan Halaman Tutorial 47

Gambar 4.1 Halaman Utama 49

Gambar 4.2 Halaman Scan URL 50

Gambar 4.3 Halaman Scan Device 51

Gambar 4.4 hasil testing heartbleed 57

Gambar 4.5 hasil testing tidak heartbleed 57