Isu penyalahgunaan aplikasi absensi pegawai di satuan pemerintah daerah sudah cukup marak terdengar di media sosial, awalnya saya mendengar kabar penyalahgunaan ini di tahun 2025 atau setahun yang lalu.
Namun akhir-akhir ini makin banyak terdengar, apalagi sampai terdapat sindikat untuk menerobos keamanan aplikasi presensi pemerintah, seperti berita pada web media Detik bulan Mei kemarin.
 |
| Berita absensi fiktif yang dilakukan oleh ribuan ASN. |
Mendengar betapa cukup masifnya aksi kurang terpuji ini, saya yang awalnya mungkin tidak ingin mengeluarkan tulisan baru pada akhirnya penasaran dan berniat untuk kembali mengisi blog saya ini.
Dan satu hal pertanyaan mendasar akan timbul:
Mengapa aplikasi absensi ini begitu rentan dimanipulasi?
Tulisan ini akan mengulas cara kerjanya, proteksi apa saja yang telah diterapkan pengembang sampai dengan potensi celah yang bisa dimanfaatkan oleh pada sindikat ataupun oknum pegawai yang tidak jujur ini berdasarkan kacamata keamanan siber.
Disclaimer: Artikel ini ditulis semata-mata untuk tujuan pembelajaran keamanan siber. Analisis yang saya lakukan murni hanya membedah kode aplikasinya saja dari luar secara pasif. Segala bentuk penyalahgunaan atas informasi teknis dalam tulisan ini adalah tindakan ilegal dan sepenuhnya berada di luar tanggung jawab penulis.
Anatomi Aplikasi Absensi Mobile
Sebelum masuk ke analisa yang lebih teknis. Ada baiknya kita memahami dulu konsep dasarnya. Secara sederhana, aplikasi absensi adalah perangkat lunak (dalam konteks tulisan ini perangkat lunak berbasis seluler) yang berfungsi untuk pencatatan atau mengelola kehadiran seorang pegawai, dan ini hanya bentuk digitalisasi dari mesin atau cara absensi konvensional seperti mesin absensi berbasis kartu ataupun sidik jari.
 |
| Perbedaan mesin absensi konvensional dan berbasis seluler/mobile. |
Berbeda dengan mesin absensi konvensional. Aplikasi absensi mobile ini umumnya mengandalkan tiga komponen utama dalam cara kerjanya, diantara-Nya:
1. Sensor GPS yang bertugas untuk mendapatkan data koordinat garis lintang serta bujur dari perangkat untuk memastikan pegawai berada di radius lokasi kantor yang telah ditentukan.
2. Kamera untuk mengambil swafoto pegawai yang sering kali ditambahkan fitur verifikasi wajah agar memastikan foto yang diambil adalah benar foto pegawai itu sendiri juga memastikan foto yang dikirim asli, yaitu bukan foto hasil cetakan.
3. Koneksi ke API untuk mengirim semua data koordinat, sampel foto, waktu, dan berbagai data ke server absensi untuk disimpan.
Begitulah gambaran dasar cara kerjanya, namun karena objektif saya adalah mengetahui lebih dari itu, maka pendekatan yang lebih teknis menjadi hal yang mesti dilakukan seperti mencoba melihat kode dibalik layar atau biasa disebut static analysis.
Setelah bagian ini saya akan memulai menjelaskannya dengan sedikit lebih teknis, namun saya usahakan untuk tetap menyampaikan dengan semudah mungkin.
Di Balik Layar: Lapisan Proteksi Sisi Klien
Saya menggunakan salah satu aplikasi absensi yang digunakan di suatu pemerintah daerah untuk dijadikan sampel, dan setelah beberapa waktu melihat serta mencoba memahami kode sumbernya, Terlihat dari pihak pengembang aplikasi sebenarnya sudah menerapkan beberapa lapisan perlindungan di dalam aplikasi, seperti:
1. Deteksi Root
Aplikasi akan melakukan pemindaian terhadap perangkat pengguna apakah sistem operasinya sudah diubah ke superuser/root.
public static boolean DeviceRooted() {
try {
return findBinary("su") || isRooted() || isPackageInstalled("eu.chainfire.supersu", BA.applicationContext)
|| new File("/system/app/Superuser.apk").exists();
} catch (Throwable unused) {
return false;
}
}
public void checkAndEnforceSecurity(Activity currentActivity) {
boolean isDeviceRooted = DeviceRooted();
if (isDeviceRooted) {
Common.ToastMessageShow("ROOT DETECTED! Maaf aplikasi tidak dapat berjalan pada rooted device.", true);
if (currentActivity != null) {
currentActivity.finish();
}
}
}
Kemudian jika salah satu method bernilai benar maka perangkat tersebut ialah perangkat yang memiliki akses super user. dan selanjutnya akan melakukan pengecekan kondisi jika nilai dari isDeviceRooted bernilai true maka pesan “ROOT DETECTED! Maaf aplikasi ini tidak dapat berjalan pada rooted device”, lalu menutup aplikasi.
Kenapa Ini Penting?
Sebagai pembaca, Anda mungkin bertanya.
“Mengapa mesti ada pengecekan ini?”
Jawabannya, ada banyak alasan mengapa aplikasi ini melakukan pemeriksaan akses superuser, namun satu hal yang mesti diketahui, yaitu perangkat yang memiliki akses superuser/root memiliki akses penuh terhadap sistem operasi.
2. Deteksi Mock Location
Selain mendeteksi apakah perangkat yang digunakan memiliki akses superuser, aplikasi ini juga sudah melakukan pengecekan untuk memastikan fitur mock location-Nya nonaktif.
JavaObject javaObject = (JavaObject) AbsObjectWrapper.ConvertToWrapper(new JavaObject(), this._location1.getObject());
this._ismock = BA.ObjectToBoolean(javaObject.RunMethod("isFromMockProvider", (Object[]) Common.Null));
if (this._ismock) {
Common.ToastMessageShow("Silahkan matikan Fake GPS/Location terlebih dahulu!", true);
presensi2.mostCurrent._activity.Finish();
}
Namun ternyata jika mock locationnya aktif aplikasinya akan menampilkan pesan “Silahkan matikan Fake GPS/Location terlebih dahulu!” kemudian menutup aplikasi.
Fitur mock ini harus dipastikan dalam keadaan nonaktif karena aplikasi seperti fake gps yang beredar umumnya mengharuskan agar fitur mock location pada perangkat harus aktif.
3. Deteksi Emulator
Pengembang juga melakukan antisipasi jika terdapat pengguna menggunakan perangkat selain handphone seperti laptop atau komputer yang mencoba menggunakan emulator untuk melakukan absensi, dengan menerapkan beberapa kombinasi seperti pengecekan direktori spesifik dari beberapa emulator dan penggunaan pustaka pendeteksi tingkat lanjut.
public static boolean checkBluestacksDirectory() {
return File.Exists(File.getDirRootExternal(), "Android/data/com.bluestacks.home");
}
public static boolean checkIsEmulator() {
boolean isEmulatorFound = false;
if (checkBluestacksDirectory()) {
isEmulatorFound = true;
}
EmulatorDetector.with(context)
.addPackageName("com.bluestacks") // Deteksi Bluestacks
.addPackageName("com.bignox.app") // Deteksi Nox Player
.addPackageName("com.mumu.store") // Deteksi MEmu / MuMu Player
.addPackageName("com.android.ld.appstore") // Deteksi LDPlayer
.detect(new OnEmulatorDetectorListener() {
@Override
public void onResult(boolean isEmulator) {
if (isEmulator) {
// isEmulatorFound = true;
}
}
});
return isEmulatorFound;
}
Common.WaitFor("complete", main.processBA, this, starter.checkIsEmulator());
this._boolhasil = ((Boolean) objArr[0]).booleanValue();
if (this._boolhasil == true) {
Common.ToastMessageShow("EMULATOR DETECTED! Maaf aplikasi tidak dapat berjalan pada emulator.", true);
main.mostCurrent._activity.Finish();
return;
}
Ilusi Keamanan : Kenapa Semua Cara Di Atas Bisa Runtuh?
Dari beberapa lapisan keamanan yang sudah dilakukan oleh pengembang cukup terlihat kuat bukan?
Iyakan?
Sialnya ini hanya kelihatan kuat, namun ada beberapa celah yang bisa dimanfaatkan oleh oknum yang tidak bertanggungjawab untuk mengakali diantara-Nya:
Ini Hanya Sebatas Benar atau Salah
Semua proteksi yang telah dibahas seperti deteksi root, mock location, dan emulator memiliki satu kesamaan fatal.
“Semuanya dieksekusi di sisi perangkat pengguna”
Pemeriksaan keamanan tersebut pada dasarnya hanyalah pertanyaan bersyarat yang meminta jawaban apakah benar atau salah dan akan melakukan berdasarkan kondisinya.
Sebagai contoh pada pemeriksaan fake gps, aplikasi ini akan mencoba bertanya ke sistem android dan akan melihat jawabannya melalui variabel _ismock.
if (this._ismock) {
Common.ToastMessageShow("Silahkan matikan Fake GPS/Location terlebih dahulu!", true);
presensi2.mostCurrent._activity.Finish();
}
Jika para oknum tercela ini mengubah nilai ismock menjadi selalu salah/false melalui bentuk bahasa mesin atau biasanya disebut smali patching, maka setiap aplikasi bertanya ke sistem android seperti “Hey android, apakah mock locationnya aktif?” maka jawaban yang selalu diterima aplikasinya ialah “Tidak, mock locationnya tidak aktif!”.
Begitu juga pada bagian proteksi seperti pendeteksi root, dengan ini aplikasi akan selalu merasa bahwa perangkat yang digunakan dalam keadaan tidak memiliki akses superuser/root. Namun kenyataannya adalah sebaliknya.
Dengan ini para oknum tersebut akan bisa melakukan beberapa hal seperti dapat mengubah nilai dari suatu variabel di memori, membaca isi data apa saja yang dikirim menggunakan framework tertentu seperti Frida atau Xposed. atau menyuntikan aplikasi dengan kamera palsu menggunakan modul LPosed tertentu untuk mencurangi face recognition atau bahkan liveness detection.
Menembak API Adalah Cara Alternatif
Jika para oknum ini merasa modifikasi seperti smali patching dirasa terlalu merepotkan, ada celah yang jauh lebih berbahaya dari sebatas mengubah nilai suatu variabel: kelemahan pada jalur komunikasi datanya!
Dari ketiga komponen utama di awal, saya sudah membahas mulai dari aplikasi ini akan mengumpulkan data seperti koordinat dari sensor gps, foto dari kamera, dan beberapa data yang akan dikumpulkan untuk dikirim ke server api untuk disimpan, untuk detailnya silakan lihat contoh source berikut:
Map data = new Map();
data.Put("timezone", this._tz);
data.Put("latt", Double.valueOf(this._latt)); // Titik Lintang GPS
data.Put("lng", Double.valueOf(this._lng)); // Titik Bujur GPS
int isWfh = 0;
if (presensi.isWfhModeAktif) {
isWfh = 1;
}
data.Put("workfrom", isWfh);
data.Put("checkintype", this._ct);
data.Put("address", this._alamat);
data.Put("kesehatan", "");
data.Put("devicetype", "0");
data.Put("accu", this._acu); // Tingkat akurasi GPS
data.Put("fg", 0);
String jsonPayload = new JSONGenerator(data).ToString();
HttpJob httpJob = new HttpJob();
String urlEndpoint = starter.ws_endpoint + "/absence";
httpJob.PostString(urlEndpoint, jsonPayload);
httpJob.setHeader("Content-Type", "application/json");
String sessionId = starter.checkParam("session_id");
httpJob.setHeader("Cookie", "absence_session" + sessionId + "; Path=/; Domain=api.absensi.com;");
Common.WaitFor("jobdone", presensi.processBA, this, httpJob);
Terlihat data yang dikirim ke server backend adalah zona waktu, koordinat (nilai garis lintang dan bujur), apakah pengguna memiliki status bekerja dari rumah jika iya maka data wfh juga akan dikirimkan, tipe absensi (absensi datang dan pulang), alamat, kesehatan, tipe perangkat, tingkat akurasi sensor GPS dan fg yang kemungkinan adalah flag atau penanda untuk diproses lebih lanjut di server backend dalam format JSON.
Permasalahannya karena data tersebut dikirim secara mentah tanpa adanya pengamanan seperti SSL Pinning ataupun tanda tangan kriptografi seperti HMAC, apalagi alamat endpoint APInya juga disimpan dalam bentuk plainteks tanpa adanya usaha untuk menyamarkan isi source code.
Akibatnya maka para oknum dapat memanfaatkan celah ini dengan hanya perlu mengetahui sessionIdnya lalu menembak langsung dengan data yang telah dimanipulasi ke server tanpa melalui perantara aplikasi, dan bahayanya lagi jika server backend menerima permintaan tersebut karena mengira semua permintaan sah yang dikirim berasal dari aplikasi.
Temuan Tambahan Lainnya
Tidak hanya alamat endpoint yang terlihat jelas, di dalam aplikasi tersebut juga menyimpan informasi kredensial secara mentah seperti username dan password di dalam file lokal.
Mungkin Lupa
Tambahan kedua tidak kalah menarik, setelah mencoba analisis aplikasi ini, pihak pengembang sepertinya lupa untuk menghilangkan satu blok kode yang cukup menggelitik sebenarnya: terdapat kredensial yang dihardcoded dalam aplikasi.
if (this._user.equals("makoli_innaka_yama_gufron") && this._password.equals("semua_sandi_milik_allah_swt")) {
starter._accountInfo("isdemo", "1");
starter._accountInfo("nama", "Demo Account");
}Catatan: data kredensial ini hanyalah contoh, bukan kredensial yang sebenarnya.
“Tapi kan itu hanya akun buat demonstrasi, apa salahnya jika dimasukkan?”
Memang, blok kode tersebut diadakan pasti untuk keperluan uji coba, namun meninggalkan kredensial secara mentah dalam aplikasi dalam versi produksi atau yang dirilis ke publik adalah suatu kecerobohan yang cukup berbahaya.
Dengan adanya informasi ini, pihak seperti sindikat di awal tulisan ini bisa mendapatkan beberapa informasi tambahan yang cukup berguna karena mereka tidak harus melakukan usaha lebih seperti mencari kredensial yang bocor ataupun melakukan aksi brute force untuk bisa masuk lalu memeriksa beberapa fungsi di dalam aplikasi.
Mitigasi: Apa Yang Mesti Dilakukan Oleh Pengembang?
Melihat beberapa bagian yang rentan pada aplikasi absensi di satuan pemerintah daerah yang mana terlalu percaya dengan perangkat pengguna, ada baiknya dari pihak pengembang atau instansi terkait untuk memperkuat sistem aplikasi ini, diantara-Nya:
1. Gunakan Sesuatu Yang Lebih Baik
Pengecekan seperti root/super user, mock location dan emulator sebenarnya cukup baik. Namun, jangan hanya berharap dengan itu.
Tambahkan beberapa proteksi yang lebih baik seperti Google Play Integrity API untuk memastikan aplikasi berjalan di perangkat yang bersih dan sah, ini juga bisa untuk menghindari modifikasi seperti smali patching yang telah saya bahas di atas, pihak pengembang mungkin bisa membuat server backend hanya mau menerima permintaan dari aplikasi yang sudah teruji menurut aturan google play integrity ini.
Jadinya aplikasi akan meminta sejenis token ke google, lalu google akan memeriksa apakah perangkat yang digunakan dalam keadaan bersih atau tidak, lalu jika perangkatnya aman, google akan mengembalikan token yang telah terenkripsi berisi status keasliannya.
Lalu token dari google tersebut juga akan dikirim bersama request api yang ada ke server backend.
{
"timezone": "Asia/Jakarta",
"latt": -7.5446651,
"lng": 110.8052415,
"workfrom": 0,
"checkintype": 0,
"address": "Jl. Kutai Utara No.1",
"kesehatan": "",
"devicetype": "0",
"accu": 5,
"fg": 0,
"integrity_token": "eyJhbGciOiJSUzI1NiIsImtpZCI6IjRiY...Wx1ZXN0YWNrcy5ob2ll"
}Tidak hanya sampai situ disisi server pun juga dilakukan validasi untuk mengecek apakah token yang dikirim bersama request tersebut adalah token yang valid dan beberapa informasi tambahan seperti apakah aplikasinya asli, serta apakah perangkatnya aman?
 |
| Alur implementasi play integrity (yang disederhanakan). |
Jika request yang dikirim berasal dari aplikasi sah dan perangkat yang aman maka server akan menerima permintaan untuk melakukan proses absensi lalu mengembalikan status "Absensi berhasil dicatat!".
Namun jika request yang dikirim berasal dari aplikasi hasil modifikasi ataupun perangkatnya tidak aman, maka server akan menolak permintaan tersebut secara langsung.
2. Amankan Jalurnya
Selain hal melakukan pemeriksaan pada integritas aplikasi, dari pihak terkait juga bisa melakukan pengamanan pada jalur komunikasi dengan menerapkan SSL Pinning secara ketat untuk menghindari terjadinya aksi penyadapan/intercept pada jaringan.
Lengkapi juga pengiriman data dengan tanda tangan digital seperti HMAC atau cara sejenis agar setiap paket yang lewat tidak dapat dimanipulasi di tengah jalan.
3. Pindahkan Semua Prosesnya ke Server
Ini adalah kebalikan dari celah yang dimanfaatkan oleh mereka para oknum itu dengan menambahkan “Jangan buat”.
Dari “Semuanya dieksekusi di sisi perangkat pengguna”.
Menjadi
“Jangan buat semuanya dieksekusi di sisi perangkat pengguna”.
Aplikasi ini seharusnya hanya untuk mengumpulkan data seperti data wajah dan koordinat, semua proses seperti validasi jarak, pemeriksaan keaslian waktu, sampai dengan verifikasi wajah diproses dan diputuskan sepenuhnya pada server.
4. Bersihkan Yang Tidak Perlu
// Contoh hasil obfuscation profesional menggunakan DexGuard / ProGuard tingkat lanjut
if (X9a.m3122(this.f102a, "\x9f\x42\x88\x11...[ciphertext acak]...")
&& X9a.m3122(this.f103b, "\x33\x7a\x91\xff...[ciphertext acak]...")) {
C0142z.m5412(1192, 0x14f);
}
Sebelum merilis ke publik, pastikan informasi seperti akun demo, endpoint API, serta informasi penting lainnya disamarkan agar para pegawai ataupun oknum nakal ini lebih sulit untuk menganalisis atau mendapatkan informasi sensitif.
Penutup Cerita
Semoga tulisan hasil iseng saya ini bisa membantu para pihak terkait untuk mengevaluasi ataupun masyarakat untuk lebih mengenal bagaimana gambaran cara para oknum bisa menyalahgunakan sebuah celah pada aplikasi. Dan bisa menjadi bacaan yang menarik dan bermakna bagi semua pembaca.
Akhirnya, pertanyaan mendasar di awal telah terjawab, yaitu:
“Karena aplikasi absensi yang digunakan masih mempercayai sisi dari pengguna. Celah tersebut bisa dimanfaatkan oleh para pegawai dan oknum nakal untuk bisa melakukan absensi fiktif.”
Sebenarnya berbagai cara yang telah dijabarkan tidak seratus persen bisa menutup celah yang ada, namun itulah kenyataan dari keamanan siber, bukan untuk mengamankan secara menyeluruh karena tidak ada hal yang benar-benar aman secara mutlak, tapi membuat para penjahat siber ini lebih rumit dan mahal untuk melakukan kejahatannya.
Tapi selain memperbaiki integritas sebuah sistem aplikasi, ada juga hal yang lebih penting dari itu semua.
“Integritas pegawai negerinya sendiri”.
%20Via%20Google%20Earth.png)
