Contoh serangan yang ditemukan dalam log akses

 (nishtahir.com)
1 poin oleh GN⁺ 2024-01-29 | 1 komentar | Bagikan ke WhatsApp
  • Log akses dari IP publik yang telah self-hosting selama lebih dari 10 tahun memperlihatkan upaya serangan yang rutin diterima layanan yang terekspos ke internet, mulai dari pencarian kredensial hingga injeksi perintah yang menargetkan perangkat IoT
  • Pola yang paling umum adalah penelusuran file konfigurasi dan direktori seperti .env, .aws/credentials, .git/config, backup/, dan test/, dan sebagian permintaan memakai User-Agent dengan salah ketik seperti Mozlila/5.0
  • Upaya Shellshock menyisipkan payload berbentuk fungsi Bash ke User-Agent untuk membaca /etc/passwd, sambil berulang kali menebak berbagai jalur CGI
  • Serangan yang menargetkan LuCI dan Zyxel mencoba menyisipkan perintah ke antarmuka web router dan perangkat embedded untuk mengunduh serta menjalankan skrip jarak jauh dan biner untuk berbagai arsitektur
  • Perlu mengurangi hal yang diekspos ke internet publik, menerapkan autentikasi dan pembatasan IP pada alat atau direktori yang diperlukan, serta menjaga perangkat IoT tetap mutakhir dan, bila memungkinkan, memisahkannya dari jaringan publik

Trafik yang diterima layanan yang terekspos ke internet publik

  • Selama lebih dari 10 tahun melakukan self-hosting, penulis terus melanjutkan pengalaman memiliki data sendiri secara langsung dan mengurangi ketergantungan pada platform selain host cloud
  • Begitu sebuah IP terekspos ke internet publik, banyak trafik berbahaya langsung masuk, dan dari log akses dapat ditelusuri serangan apa saja yang baru-baru ini diterima
  • Analisis ini lebih merupakan pengamatan seorang developer yang penasaran daripada forensik oleh pakar keamanan
  • Alamat IP penyerang dan sebagian ungkapan menghina yang digunakan oleh beberapa penyerang disamarkan sebagai langkah kehati-hatian

Pencarian kredensial dan file konfigurasi

  • Serangan yang paling umum adalah upaya mencari kredensial melalui penelusuran direktori, dan permintaan terhadap file .env tampak sangat sering
    • Contoh jalur permintaan: /laravel/.env, /backend/.env, /api/.env, /.env, //.env, dan sebagainya
    • .env umumnya diperlakukan sebagai file yang menyimpan secret aplikasi
  • File terkait AWS dan konfigurasi repositori Git juga termasuk target penelusuran
    • Contohnya /aws.yml, /.env.bak, /info.php, /.aws/credentials, /config/aws.yml, /.git/config, dan sebagainya
  • Direktori umum yang mungkin tertinggal secara tidak sengaja juga diminta berulang kali
    • Contohnya /old/, /new/, /test/, /backup/, /temp/, dan sebagainya
  • Sebagian User-Agent memuat Mozlila/5.0, yang tampak seperti salah ketik dari Mozilla/5.0
    • Hasil pencarian GitHub mengisyaratkan bahwa salah ketik ini mungkin dibuat oleh alat yang umum dipakai lalu disalin-tempel
  • Permintaan yang mencari alat akses jarak jauh atau alat konfigurasi juga ikut teramati
    • Contohnya /actuator/gateway/routes, /hudson, /ui/login.action, /?XDEBUG_SESSION_START=phpstorm, dan sebagainya
  • Ke internet publik sebaiknya hanya mengekspos hal yang benar-benar minimum yang diperlukan, dan bila alat atau direktori harus diekspos, perlu ada lapisan autentikasi serta, jika memungkinkan, pembatasan ke IP tertentu

Upaya Shellshock

  • Sejumlah permintaan tampak menargetkan kerentanan Shellshock
  • Serangan ini menargetkan eksekusi perintah arbitrer pada web server yang menjalankan skrip CGI dengan versi Bash yang rentan
    • Saat program CGI dimulai, variabel lingkungan diatur dari isi permintaan, dan HTTP_USER_AGENT adalah salah satunya
    • Jika ada karakter seperti () { :; };, Bash menafsirkannya sebagai fungsi yang harus dijalankan
  • User-Agent dalam log nyata berisi payload seperti berikut
    • () { ignored; }; echo Content-Type: text/html; echo ; /bin/cat /etc/passwd
    • () { ignored; }; adalah bentuk definisi fungsi Bash
    • echo Content-Type: text/html; echo ; mencetak Content-Type respons HTTP dan satu baris kosong
    • /bin/cat /etc/passwd adalah perintah untuk menampilkan isi /etc/passwd yang berisi informasi akun pengguna
  • Jika serangan berhasil, hal itu dapat berlanjut pada akses ke kredensial pengguna dan eksekusi kode arbitrer di server
  • Seperti pada penelusuran direktori, penyerang menebak jalur umum seperti /cgi-bin/status, /cgi-bin/stats, /cgi-bin/test, /cgi-bin/status/status.cgi, /test.cgi, /debug.cgi, /cgi-bin/test-cgi

Injeksi perintah yang menargetkan LuCI

  • Satu permintaan tampak menargetkan LuCI, antarmuka web untuk router OpenWRT
  • URL serangan disusun untuk menyisipkan perintah ke field country agar dapat mengunduh dan menjalankan skrip shell tenda.sh dari server jarak jauh
    • Setelah URL didekode, perintahnya mengikuti alur berpindah ke /tmp, menghapus file, mengambil skrip dengan wget, memberi izin eksekusi, lalu menjalankannya
  • Skrip yang diunduh berisi isi untuk mengunduh dan menjalankan biner tambahan
    • Tercantum nama yang tampak sebagai arsitektur target seperti mips, mpsl, x86_64, arm, arm5, arm6, arm7, i586, i686, powerpc, sh4, m68k, sparc
    • Pendekatan mencoba biner untuk banyak arsitektur tampak dimaksudkan untuk memperluas cakupan serangan saat penyerang tidak mengetahui arsitektur perangkat target
  • Untuk penyelidikan lanjutan, penulis mengunduh biner yang tidak kompatibel dengan lingkungannya lalu memeriksanya dengan Ghidra
    • Awalnya hanya ada 3 fungsi dan tidak banyak data string
    • Di area data yang besar ditemukan string $Info: This file is packed with the UPX executable packer dan UPX 3.94
  • Itu adalah biner ELF yang dikompresi dengan UPX, dan jika header UPX atau packed binary tidak dimodifikasi, biner dapat dibuka dengan upx -d
    • Memang, setelah menjalankan upx -d mips, ukuran file bertambah dari 34932 menjadi 93732, dan lebih banyak string dapat diperiksa
  • Di dalam string biner yang telah dibuka terdapat M-SEARCH * HTTP/1.1, ST: urn:dial-multiscreen-org:service:dial:1, dan payload XML untuk upgrade perangkat Huawei
    • Ini tampak sebagai perintah UPnP untuk mencari perangkat di jaringan yang mendukung protokol DIAL
    • Payload XML itu tampak dikonfigurasi untuk memindai perangkat Huawei yang rentan terhadap injeksi perintah
    • Perilaku ini tampaknya telah diidentifikasi sebagai bagian dari botnet Mirai
  • File yeye.mips yang dirujuk tidak tersedia saat dicoba diambil
    • Hasil menjalankan nmap pada server hanya menemukan port terbuka 22/tcp ssh dan 646/tcp filtered ldp

Injeksi perintah yang menargetkan Zyxel

  • Permintaan lain berisi perintah shell di dalam URL GET, dan setelah substitusi shell ${IFS} dihapus, bentuknya menjadi lebih mudah dibaca
    • Perintah yang telah dirapikan mengikuti alur berpindah ke /tmp, menghapus file *mips*, mengunduh huhu.mips, memberi izin eksekusi, lalu menjalankannya dengan argumen zyxel.selfrep
  • Serangan ini tampak menargetkan eksploit zhttpd pada perangkat Zyxel
  • Biner kali ini tidak dalam keadaan packed, sehingga string-nya bisa langsung diperiksa di Ghidra
    • String yang terlihat mencakup M-SEARCH * HTTP/1.1, header ST terkait DIAL, skyljne.arm, skyljne.arm5, skyljne.arm6, skyljne.arm7, skyljne.mips, skyljne.mpsl, skyljne.x86_64, skyljne.sh4, dan sebagainya
    • Juga ada payload XML yang menargetkan perangkat Huawei untuk mengunduh huhu.mips dan menjalankannya sebagai selfrep.huawei
  • String lain memuat perintah untuk mengirim POST ke /goform/set_LimitClient_cfg
    • Bersama header Cookie: user=admin, perintah itu mencoba menyisipkan perintah ke parameter mac untuk mengunduh dan menjalankan huhu.mpsl
    • Menurut tulisan Akamai, kerentanan ini menargetkan router dan dapat dieksploitasi tanpa autentikasi sebelumnya karena tidak ada pemeriksaan autentikasi maupun otorisasi yang memadai
  • Biner ini sangat mungkin merupakan agen botnet Mirai
    • Sebagian sumber juga menyebut kemungkinan keterkaitannya dengan Linux Medusa

Respons dari sudut pandang operasional

  • Log yang diperiksa hanyalah sebagian dari keseluruhan, dan masih banyak eksploit lain yang dicoba setiap hari
  • Penting untuk menjaga perangkat, terutama perangkat IoT, tetap mutakhir
  • Jika memungkinkan, perangkat IoT sebaiknya tidak diekspos langsung ke internet publik
  • Jika memang harus diekspos, sebaiknya diisolasi ke VLAN terpisah sejauh mungkin

Bacaan terkait

1 komentar

 
GN⁺ 2024-01-29
Komentar Hacker News

  • Menariknya, sebagian penyerang tampaknya memantau log Certificate Transparency untuk mencari sertifikat yang baru diterbitkan.
    Jika server baru dibiarkan berjalan di IP baru selama lebih dari seminggu, log akses hanya menunjukkan beberapa pemindaian acak. Namun, sekitar satu jam setelah mendapatkan sertifikat Let’s Encrypt, beberapa kali pernah terjadi ratusan permintaan seperti yang disebutkan dalam artikel datang membanjir.
    Kesimpulannya, layanan baru harus dibuat aman secepat mungkin, idealnya sebelum diekspos ke internet.

    • Rasanya sejak detik pertama diekspos ke publik, setidaknya harus ada sesuatu seperti basic authentication di depannya.
      Atau bisa juga memakai certificate authority sendiri, lalu menggunakan sertifikat self-signed dan mTLS sampai saat peralihan.
      Misalnya, jika suatu software mengekspos begitu saja layar instalasi awal seperti pembuatan akun admin atau koneksi DB, itu menjadi lebih berisiko dibandingkan menetapkannya sejak awal lewat environment variable, file konfigurasi, atau tool khusus pengelolaan secret.
    • Baru-baru ini saya melihat log Certificate Transparency, dan penasaran apakah ada tool atau cara yang nyaman untuk mengkueri log CT.
      Misalnya mencari domain dalam periode tertentu.
      Merkle Town[0] dari Cloudflare berguna untuk melihat gambaran umum, tetapi saya belum menemukan cara mudah untuk mengkueri log CT, dan ct-woodpecker[1] juga terlihat menjanjikan.
      [0] https://ct.cloudflare.com/
      [1] https://github.com/letsencrypt/ct-woodpecker
    • Lebih banyak memakai sertifikat wildcard juga berguna. Dengan hanya log CT, penyerang jadi lebih sulit mengetahui subdomain spesifik yang bisa diserang.
    • Dalam banyak kasus, ini bukan penyerang, melainkan layanan seperti urlscan.io yang memantau log CT sambil merayapi web untuk mencari malware.
    • Saya meng-host sendiri beberapa layanan, tetapi sudah sepenuhnya menyerah untuk mengeksposnya langsung ke internet.
      VPN sekarang sudah sangat bagus sehingga lebih menenangkan, dan untuk hal seperti hosting foto atau backup, saya khususnya tidak ingin mengeksposnya secara publik.

  • Saat mulai mengelola situs yang saya host sendiri, saya juga melihat log akses, dan untuk sementara memakai sistem deteksi intrusi yang mengumpulkan data serta menampilkan percobaan serangan yang masuk.
    Pada akhirnya saya berhenti meninjau log secara proaktif maupun membayar biaya sistem deteksi intrusi; itu buang-buang waktu dan mengalihkan perhatian.
    Materi yang merangkum kerentanan dan serangan umum mudah ditemukan, jadi itu bisa dijadikan standar administrasi server. Untuk setiap teknologi web server yang umum ada banyak panduan best practice, dan dengan menjalankan semuanya 100%, Anda sudah jauh lebih maju daripada hampir semua penyerang.
    Setelah itu, cara terbaik menggunakan waktu dan sumber daya adalah memprioritaskan siklus patch secepat mungkin. Sebagian besar serangan menargetkan kerentanan yang sudah dipublikasikan.
    Log terutama berguna saat mendiagnosis setelah masalah terjadi. Software analisis log membantu 2–3 kali untuk menyimpan, mencari, dan menemukan akar penyebab serangan yang berhasil, dan setiap kali penyebabnya adalah kerentanan yang sudah diketahui tetapi dipatch terlalu terlambat.

    • Jika semua kasus adalah kerentanan yang sudah diketahui tetapi terlambat dipatch, maka pendekatan yang hanya mengandalkan patch pasti akan gagal suatu hari nanti. Bisa saja itu kerentanan zero-day, atau penyerangnya lebih cepat.
      Solusinya adalah pertahanan berlapis, dan untuk layanan pribadi yang di-host sendiri, kebanyakan cukup mudah diterapkan.
      Letakkan firewall di depan atau sembunyikan di balik VPN/Tailscale, dan sembunyikan di subfolder seperti /mawer/phpmyadmin/ alih-alih /phpmyadmin/ yang ditargetkan serangan otomatis, maka 99,9% tidak akan menemukannya. Ini disebut security by obscurity dan tidak boleh menjadi satu-satunya andalan, tetapi sangat berguna sebagai lapisan tambahan.
      Masukkan aplikasi ke sandbox dan isolasi server agar meski disusupi, sulit bergerak ke tempat lain, serta simpan log agar bisa memastikan apakah terjadi serangan dan apakah serangan itu berhasil.
      Intinya, jangan bergantung hanya pada satu sarana pertahanan, baik itu patch maupun firewall. Pada akhirnya salah satunya akan gagal.
    • Saya penasaran dengan bagian memprioritaskan siklus patch tercepat. Ingin tahu apakah Anda memakai tool untuk menentukan kapan harus patch, atau berdasarkan interval waktu.
      Saat ini saya mencoba memperbarui paket setiap kuartal[0], tetapi akan bagus jika ada tool yang memberi tahu kerentanan yang diketahui sehingga bisa segera ditangani.
      [0] Di sini “mencoba” berarti jika ada breaking change yang sulit diterapkan ke versi terbaru, atau rilis X.0.0 yang belum saya percayai, saya tidak bisa langsung upgrade.

  • Karena penulis mengatakan bukan pakar keamanan, untuk memperbaiki bagian kecil: contoh di awal adalah pencarian kredensial dan konfigurasi, bukan directory traversal.
    Setahu saya, directory traversal adalah istilah untuk teknik ketika penyerang “keluar” dari web root atau menipu server agar menyajikan file di luar direktori normal.

    • Secara teknis bisa jadi keduanya jika caranya adalah menyertakan file yang memang tidak seharusnya di-host. Misalnya "/../../passwd/etc".

  • Setidaknya menurut pengalaman saya, poin pentingnya adalah banyak serangan seperti ini berasal dari aktor negara yang bermusuhan.
    Mungkin kontroversial, tetapi memblokir seluruh rentang IP dari negara bermasalah yang tidak akan Anda ajak bertransaksi bisa berguna. Dengan cara ini saya pernah memblokir 100% percobaan pemindaian yang masuk ke satu layanan baru.

    • Itu bukan masalah utamanya; banyak orang hanya tidak ingin ikut memblokir pengguna sah dari wilayah tersebut.
    • Akan menyenangkan kalau aktor negara sama sekali tidak punya cara membeli server di negara lain lalu menjalankan serangan dari sana.
    • Lebih dari 15 tahun lalu, saat melihat log server bisnis lokal kecil yang kami host, kami menyimpulkan bahwa semua alamat IP APNIC boleh diblokir.
    • Pemblokiran berdasarkan wilayah pada akhirnya hanya memblokir trafik sah, dan penyerang yang punya niat tinggal memakai proxy, bukan?
    • Kalau begitu, Anda harus memblokir Amerika Serikat dan Belanda.
      Sebagian besar pemindaian yang masuk ke server saya berasal dari Amerika Serikat, dan jauh di posisi kedua adalah Belanda. Mungkin sebagian besar berasal dari AWS dan data center lain.

  • Saya bekerja di bidang keamanan aplikasi/produk, dan selama bertahun-tahun mengelola WAF untuk perusahaan bernilai miliaran dolar
    Cukup pindahkan DNS ke Cloudflare dan pasang beberapa aturan WAF di situs. Misalnya, jika skor bot di bawah 2, berikan managed challenge, atau tangani saat skor serangan mencapai nilai tertentu. Kemungkinan biayanya juga nyaris tidak ada, dan banyak masalah akan teratasi
    Namun sebelum dipindahkan ke produksi, wajib diuji. Memiliki satu domain uji juga bagus. WAF bukan solusi mujarab, lebih dekat ke penanganan sementara; kalau aplikasi itu sendiri tidak diperkuat agar tahan serangan, WAF secanggih apa pun atau proteksi bot tidak akan bisa menyelamatkannya

    • Untuk yang belum familiar, saya tinggalkan ini: https://blog.cloudflare.com/waf-for-everyone/
      Free Managed Ruleset sepertinya didistribusikan secara default, dan Cloudflare menyimpan changelog di sini: https://developers.cloudflare.com/waf/change-log
    • Dari sisi self-hosting, saya memakai WAF CloudFlare dan aturan mutual TLS untuk hanya meloloskan caller sah yang saya kenal
      Berjalan sangat baik. Karena yang mengakses hanya keluarga, konfigurasinya juga mudah, dan masing-masing mendapat sertifikat unik yang bisa dicabut bila perlu
    • Belakangan ini saya biasanya hanya mengelola aplikasi internal, jadi attack surface-nya jauh lebih kecil daripada layanan publik
      Sepertinya Anda paham bidang ini, jadi saya penasaran apakah Anda pernah mengelola solusi yang memakai infrastruktur Azure bersama Cloudflare; kalau pernah, selain hal umum seperti OWASP, apakah ada hal-hal yang sering terlewat orang?
    • Ini cocok untuk situs WordPress standar, lalu tambahkan plugin GuardGiant dan Sucuri sebagai lapisan tambahan
    • Menganggap urusan selesai hanya karena menaruh WAF di depan aplikasi tidak ada bedanya dengan memakaikan lipstik pada babi
      Kalau suatu perusahaan, karena alasan tertentu, benar-benar harus menjalankan sesuatu yang tidak mutakhir, mungkin itu diperlukan, tetapi pada akhirnya tetap hanya penanganan sementara

  • Saya sudah sekitar setahun melakukan self-hosting server HTTP/S 400 baris yang saya rancang sendiri, dan jumlah trafik serangan yang masuk lewat 3 port terbuka (22, 80, 443) sungguh mengejutkan
    Namun saya belum meluangkan waktu untuk menganalisis apa yang sebenarnya coba dilakukan penyerang, dan tulisan ini mengisi banyak kekosongan
    Akan menarik juga kalau hal-hal aneh yang terlihat di /var/log/auth.log dianalisis dengan cara yang sama
    Semua kodenya open source dan tidak ada state di sisi server, jadi rasanya aneh kalau penyerang sengaja menargetkan saya. Hal terbaik yang bisa didapat penyerang hanyalah akses root ke VPS seharga 5 dolar per bulan dan defacement sementara pada domain yang tak dikunjungi siapa pun

    • Itu semua bot otomatis. Bukan ada orang yang sengaja peduli
      Kalau membuka 3 port paling terkenal, koneksi pasti masuk; mereka bahkan tidak tahu dan tidak peduli apa yang Anda jalankan
    • Kalau bisa mengakses VPN Anda, itu bagus untuk dijadikan titik awal menyerang mesin lain, dan menambah satu lapisan lagi untuk menyembunyikan jejak
      Mereka juga bisa meng-host malware atau menjalankan penambang kripto
    • Untuk port 22, layak dipertimbangkan hanya mengizinkan IP sendiri dan memblokir sisanya
      ISP saya sebenarnya jarang sekali mengubah IP, dan kalau berubah saya bisa login ke panel admin web hosting lalu memperbarui aturannya

  • Saya selalu menjalankan fail2ban di setiap server, dan juga menambahkan jail kustom untuk menangkap serangan yang disesuaikan dengan jenis fitur situs yang diekspos
    Namun sudah lama saya tidak memastikan apakah default lain dari fail2ban masih cukup untuk menahan serangan umum. Sepertinya tautan ini perlu saya bookmark agar bisa dilihat nanti

    • Jika sistem Anda mengekspos kerentanan yang semudah itu dijadikan target, fail2ban tidak akan menyelamatkan Anda

  • Saya juga memeriksa access log dari layanan yang saya self-host, dan ada detail yang terasa cukup mencolok absen dari analisis ini
    Sebagian besar request berbahaya hanyalah orang biasa yang menjalankan security scanner yang mudah didapat di tempat seperti GitHub. Umumnya serangannya tidak canggih, dan instance proyek semacam ini menghantam server tanpa melihat respons dan tanpa peduli apakah sudah dibatasi atau belum
    Beberapa serangan tidak menargetkan IP secara langsung, melainkan memantau domain dan subdomain, lalu secara berkala mengulang scan yang sama dari rentang IP yang sama
    Di tempat kerja lama, scan berulang terus datang dari satu IP statis di Turki sampai tim mulai menyebutnya “orang Turki”, dan ketika melihat pola request aneh, langkah pertama dalam respons insiden adalah memeriksa apakah orang itu sedang mengutak-atik layanan kami

  • Kalau Anda melihat log seperti ini di AWS, tolong sebaiknya pasang AWS WAF di depan VPC
    Tidak mahal, dan dalam situasi seperti ini cukup membantu mengurangi banyak kerepotan. Meski tidak bisa memblokir semua hal yang mencapai layanan, itu tetap bisa sangat membantu

    • Saran yang bagus, tetapi hati-hati dengan set aturan default. Kami mengaktifkan AWS WAF karena kepatuhan SOC 2
      Beberapa aturan yang terlalu agresif diam-diam merusak sebagian aplikasi
      Ada aturan body request yang memblokir jika body request berisi "localhost", dan ada juga aturan yang memblokir request tanpa header User-Agent. Karena sebelumnya kami tidak mewajibkan User-Agent untuk request API, seluruh API sebagian pengguna rusak sampai kami menemukan penyebabnya
    • Serangan yang disebutkan di tulisan itu seharusnya tidak menjadi masalah bagi aplikasi web modern mana pun. Jadi saya tidak paham mengapa harus menambahkan WAF
    • Menggunakan aturan default AWS WAF tidak semudah itu. Di aplikasi kami, banyak request dan IP yang sah ikut terblokir
      Anda harus tahu apa yang diblokir dan memverifikasinya terlebih dahulu; kalau tidak, dalam kasus tertentu Anda bisa kehilangan pelanggan
    • Kenyataannya, WAF sering kali lebih banyak merugikan daripada membantu
      Mudah dilewati tetapi memberi ilusi bahwa sudah aman, biaya performanya juga besar, dan kemungkinan memblokir trafik sah pun cukup tinggi: https://www.macchaffee.com/blog/2023/wafs/
    • WAF cenderung memblokir secara luas, dan kadang alasannya tidak jelas
      Misalnya, para peneliti di universitas kami meneliti data Twitter, tetapi IP universitas diblokir oleh sebagian besar WAF hanya karena mereka mengikuti tautan dari sampel kecil tweet yang acak

  • Kadang terpikir bahwa akan menarik membuat server Express yang merespons salah satu serangan seperti ini dengan benar, agar membuang-buang waktu seseorang
    Namun jika begitu, waktu saya juga ikut terbuang