08 January 2016

Java, being Developer

It's five months from my latest post where I'm still a university students and doing the research for my thesis. But right now, before the celebrate of the graduation in my University, I was hired by new comers of e-commerce company in my country named JD.id as Java Developer. Although my major in the University is Engineering Physics, but I'm not eligible to be an engineer especially at physics scope, because I'm still doing hard to understand about fluid mechanics, thermodynamics, transport phenomenon, automatics control, modern control, signal processing and another topics that correlated with physics. It's why I'm not at a good confident level when applying an engineering physics vacancy of the company, but I prefer to applying IT vacancy with more good confident level. And I was hired as Java Developer.
So it's the occupation which I've dreamed before. Without going to Computer Science or IT major I can go to there. So it's good to start my professional career at IT background, especially to be a professional developer (red: a hacker). For most people which work on IT, the networking skill and developing skill is separated, you can't mixed these skill into one person. So the infrastructure specialist don't have a good developing skill, otherwise. Yes this is my chance to have a good networking and developing skill at the same time.
Full Team of JD.id
It's too early to say that I'm a professional developer, but the small step to get achieved and expand my knowledge, my career which I'm doing consequently. With the past I have a C++ programming experience, python, and right now I need to learn more about Java, because Java is not only a programming, it's a technology that bring solutions for the most critical problem at enterprise. So it's time to starting, never ending to learning new thing. But one month passed, I was miss something which often discussed on the labs, especially on image processing and artificial intelligence. Arghhh... stay focus on your work right now, Java...

27 August 2015

Who Play? "Internet Banking"

Lama tidak mengubek-ubek masalah keamanan, beberapa hari lalu saya menemui kejadian-kejadian tidak wajar. Pertama kondisi Internet Banking (IB) salah satu Bank milik Pemerintah (M*ndiri) yang tidak bisa diakses, saya tidak begitu ingat kenapa waktu itu server tidak bisa diakses, padahal saya ingin melakukan transaksi. Saya mencurigai ini dikarenakan koneksi modem saya (S*mpati), kemudian saya hubungkan Laptop saya ke Wifi di kamar yang menggunakan Sm*rtfren, namun hasilnya sama saja, terpaksa jadi harus mlipir ke ATM. Padahal menurut saya Bank ini menempati posisi teratas dari segi keamanan bertransaksi di dunia maya dilihat dari segi SDM nya dan berbagai macam transaksi yang dapat dilakukan, sehingga tidak mungkin Manajemen Bank ini tidak merekrut orang-orang yang terbaik dari yang terbaik, karena apabila tidak tentu akan sangat membahayakan sistem yang ada.
Ilustrasi "403 Forbidden"
Sore hari, saya mencoba mengakses lagi Internet Banking Bank ini, ladalah sepertinya terjadi perebutan hak akses server dari orang lain oleh administrator atau memang sedang maintenance sehingga server tidak bisa diakses. Kemudian saya mencoba mengakses Internet Banking Bank sebelah yang milik Pemerintah juga (BN*), Internet Bankingnya bisa diakses, berarti memang Internet Banking M*ndiri sedang maintenance, pikir saya.
Malam hari sebelum tidur saya mencoba mengakses IB Bank M*ndiri lagi melalui Nokia N9, namun masih saja tidak bisa. Saya mencoba mencari berita terkait maintenance ini, yang saya dapatkan malah cerita salah satu nasabah Bank M*ndiri yang terkuras saldo rekeningnya (baca di sini) beberapa bulan lalu. Ringkasnya, nasabah ini terkuras saldo rekeningnya setelah mencoba melakukan login IB Bank M*ndiri dan gagal, padahal seharusnya meskipun username dan password sudah terendus oleh attacker masih ada verifikasi Token yang diperlukan untuk setiap transaksi.
Beberapa komentar dari postingan nasabah tersebut ada yang membahas mengenai MITM (Man In The Middle), yakni serangan dengan mengelabuhi Komputer korban yang mengharuskan melewatkan segala koneksi ke Komputer attacker. Namun tetap saja menurut saya itu tidak akan berhasil dilakukan pada kasus nasabah tersebut, sebab meski username dan password sudah tertangkap, sekali lagi masih ada verifikasi Token yang diperlukan setiap transaksi, padahal nasabah tersebut tidak berhasil login, sehingga logikanya dia tidak mengakses token miliknya saat itu. Nasabah tersebut juga mempostingkan Compression Side Channel Attack, namun menurut saya itu tidak terkait dengan kasus yang dia alami.
Ilustrasi MITM
Belum sempat saya tertidur, saya malah bangun dan menyalakan Laptop, saya teringat dengan kondisi Laptop saya beberapa hari terakhir ada yang aneh. Ya, berbeda dengan sebagian orang lain, saya sangat menjaga kondisi Laptop saya supaya tetap prima dari segi hardware maupun software. Dalam cakupan software, dari Action Center yang none message, Antivirus, Driver, Start-up dll saya perhatikan semua sampai hal-hal yang mendetil, sehingga perubahan kecil akan dapat saya sadari segera. Yap, waktu itu Laptop saya tidak seperti biasanya, saat saya memutar video, terjadi delay yang lumayan lama dari waktu video player terbuka hingga video diputar, padahal load CPU, Memory, Disk saat itu terpantau normal pada Task Manager. Selain itu, saya tidak bisa mengakses fitur safely remove yang biasa saya lakukan sebelum mencabut flashdisc atau media penyimpanan eksternal lainnya. Juga tidak terdengar bunyi beep khas Windows saat mengatur volume pada taskbar. Beberapa keanehan ini bagi orang lain mungkin tidak akan terasa dan dianggap normal-normal saja, namun tidak bagi saya. Saya melakukan checking dari Device Manager, Firewall, Smart-Screen, Antivirus, Registry, dll. Semuanya menunjukkan normal, tetapi saya terus mencari hingga perhatian saya tertuju pada Windows Credentials. Pada Generic Windows Credentials, terdapat sebuah isian berupa virtualapp/didlogical yang berisi username dan password yang tidak saya kenali. Segera saya menghapusnya dan Laptop saya restart. Kemudian Laptop saya kembali seperti semula kembali. Tidak berhenti sampai disitu, saya mencari tahu mengenai virtualapp/didlogical, banyak yang mengatakan itu adalah sertifikat dari aktivitas Windows Live, namun ada dugaan backdoor pada sertifikat ini (baca di sini). Kejadian ini memaksa saya untuk mengubah semua password saya mulai dari Internet Banking, Social Media, E-mail, Akun Portal Akademik, dll. Hingga pukul 03.00 WIB barulah semua akun yang saya ingat, saya ubah password nya.
Kembali lagi pada masalah Internet Banking, saat ini IB Bank M*ndiri sudah bisa diakses lagi, namun sepertinya terjadi perubahan rule pada server, dulu dengan mengakses https://ib.bankmandiri.co.id saja kita akan di direct ke halaman login, namun sekarang apabila Anda mengakses url tersebut maka akan 403 Forbidden. Mengapa di awal-awal saya sangat bersikukuh kalo metode MITM atau yang lainnya sangat tidak mungkin terjadi pada kasus nasabah yang di atas? Satu jawabannya ialah verifikasi Token. Andaikata SSL atau dan yang lainnya jebol hingga membuat username dan password tertangkap oleh attacker, tentu verifikasi Token merupakan dinding tebal yang tidak mudah begitu saja ditembus. Silahkan baca postingan berikut untuk membantu memahami cara kerja Token.
Ilustrasi Token Internet Banking
Kemungkinan yang terjadi pada kasus nasabah tersebut menurut saya ialah, jebol nya sistem IB Bank M*ndiri atau jebol nya Token. Jebol nya sistem IB Bank M*ndiri tentu sangatlah susah namun tidak mungkin tidak terjadi, apabila ini terjadi maka attacker dapat dengan leluasa melakukan apapun pada sistem, dan tentu akan "mengerikan" sekali apabila ini terjadi. Kemungkinan kedua ialah jebol nya Token. Ini tentu sangat berbeda dengan kasus beberapa waktu lalu, seperti "Sinkronisasi Token".
Setelah membaca artikel yang saya sertakan di paragraf atas, yang dimaksud jebol nya Token di sini ialah attacker mampu meniru model Token yang dimiliki oleh nasabah, sehingga saat username dan password sudah didapat, maka tak sulit untuk melakukan transaksi. Konsepnya ialah membangun sebuah model yang mampu menerima input berupa challenge code yang menghasilkan kode tertentu yang berubah terhadap variabel waktu untuk Mode Challenge/Response, sementara model yang akan langsung menghasilkan kode tertentu yang berubah terhadap variabel waktu untuk Mode Self Generated. Namun yang pernah saya lakukan antara satu token dengan token lain berbeda generated kode nya meski dalam waktu bersamaan (Mode Self Generated). Ini menjadikan kesulitan untuk membangun model Token yang general, sehingga akan diperlukan model yang spesifik untuk satu akun IB.
Kesimpulannya, terdapat berbagai macam pengamanan untuk melindungi transaksi perbankan secara online, namun bukan tidak mungkin berbagai macam pengamanan yang berlapis-lapis tersebut ditembus oleh seseorang yang tidak bertanggung jawab, sehingga menimbulkan dampak merugikan bagi orang lain. Tertembusnya sistem IB sebuah Bank tentunya sangat sulit, tapi bukan tidak mungkin terjadi, selain itu pembuatan model Token yang mampu meniru perilaku Token asli adalah salah satu kekhawatiran, apabila username dan password sudah didapatkan, maka dengan model Token tersebut siapa saja dapat melakukan transaksi. Tetapi kesulitannya ialah pembuatan model Token itu sendiri, selain itu antara satu Token dan Token lain mempunyai algoritma yang berbeda, terbukti dengan generated kode berbeda meski dalam waktu yang bersamaan.
Demikian tulisan ini saya buat, semoga menjadi pembelajaran kita bersama agar lebih waspada dalam menggunakan fasilitas di dunia maya, terlebih lagi dalam perbankan.