$query = "SELECT username FROM login WHERE username=?"; $stmt = $conn->prepare($query); $stmt->execute(array($username)); $username = $stmt->fetchColumn(); if($username == FALSE) { die(" !"); } 

1. Kehidupan sesi terlalu lama. Setahun penuh banyak. Jika cookie berhasil dibajak, akses panjang ke akun pengguna oleh penyerang dimungkinkan.
2. Bendera httpHanya hilang. Jika diatur ke TRUE, cookie hanya akan dapat diakses melalui protokol HTTP. Artinya, cookie dalam hal ini tidak akan tersedia untuk bahasa scripting seperti JavaScript.
3. Tidak ada hashing cookie.
4. Kurangnya pengaturan bendera aman. Bendera aman menunjukkan bahwa cookie harus dikirim dari klien melalui koneksi HTTPS yang aman. Jika diatur ke TRUE, cookie dari klien akan dikirim ke server hanya jika koneksi aman dibuat.

 $query = htmlentities($query, ENT_QUOTES, "UTF-8"); 

 header("Content-Type: text/html; charset=utf-8"); 

  $query = "SELECT sessions FROM login WHERE sessions=?"; $stmt = $conn->prepare($query); $stmt->execute(array($_COOKIE["user"])); $session = $stmt->fetchColumn(); if($session == TRUE) { do_login($_COOKIE["user"]); } 

Pertanyaan pertama yang ditanyakan oleh kuisioner magang di masa mendatang adalah kerentanan web yang utama dan dikenal luas. Satu-satunya kesulitan di sini adalah perlunya melihatnya dalam kode sumber di PHP. Namun, tidak ada yang mengatur tugas "menyembunyikan bug".

Berikut adalah daftar kerentanan yang dapat dideteksi dalam daftar ini berdasarkan frekuensi deteksi mereka:

Pembuatan kata sandi menggunakan algoritma MD5 bahkan diketahui oleh kandidat yang jauh dari web. Namun, ada juga nuansa yang menarik, misalnya, banyak kandidat menggunakan istilah yang sangat salah, mencoba menggambarkan masalah dengan kata-kata mereka sendiri. "Algoritma kerentanan", "fungsi satu arah", "keberadaan tabrakan" dan belokan aneh lainnya pergi ke pertempuran, setelah diperiksa lebih dekat, mereka ternyata tidak lebih dari satu set kata-kata besar yang tidak mengungkapkan esensi. Tentu saja, di sini kami pergi ke sebuah pertemuan dan tidak menemukan kesalahan dengan orang-orang yang baru saja bersiap untuk memulai jalan untuk mempelajari kebijaksanaan keamanan informasi. Untuk mendapatkan "set-off", menyebutkan ancaman akan cukup, bahwa dalam kasus kompromi database, hash MD5 dapat disortir oleh penyerang dalam waktu yang dapat diterima dan kata sandi (atau string yang setara) dapat diperoleh dalam teks yang jelas. Dan, tentu saja, banyak yang menyebutkan kekurangan garam dan kekerasan berdasarkan penggunaan meja pelangi. Kami juga menerima komentar seperti itu secara positif, terutama jika responden menjelaskan mengapa ini merupakan ancaman.

Potensi injeksi SQL. Sulit untuk menambahkan sesuatu; saat membuat panggilan ke database, input pengguna login dan kata sandi secara langsung digabungkan dengan permintaan. Jika Anda tidak dapat memanipulasi nilai kata sandi pada tahap ini (hash diambil darinya), maka memasukkan injeksi ke nama pengguna tidak akan menyulitkan penyerang potensial.

Output dari informasi debug yang tidak perlu yang mengarah ke serangan XSS. Dengan membaca daftar dengan hati-hati, orang dapat memperhatikan panggilan gema, yang menampilkan permintaan yang dihasilkan ke database dalam komentar HTML pada halaman. Tentu saja, kesimpulan informasi tambahan pada halaman tersebut sepenuhnya opsional dan, kemungkinan besar, hanya dilupakan oleh pengembang setelah melakukan tes. Informasi tambahan semacam itu sangat bermanfaat bagi penyerang dan memungkinkan pemahaman yang jauh lebih baik tentang cara kerja aplikasi. Namun, sayangnya, ini hanya setengah dari masalah. Faktanya adalah bahwa seorang penyerang dapat memanipulasi isi dari variabel kueri, dan isinya tidak dapat disaring atau melarikan diri sebelum ditampilkan kepada pengguna - ada potensi serangan XSS. Namun, eksploitasinya mungkin menjadi sakit kepala karena fungsi strtoupper yang buruk. Vektor yang disuntikkan oleh penyerang akan menjadi huruf besar, dan jika ini bukan masalah untuk tag HTML, maka Javascript sangat tersinggung oleh banding seperti itu. Ini dapat dengan mudah diverifikasi menggunakan konsol browser.



Yah, setidaknya, tampaknya, penyerang harus beralih ke apa yang disebut "serangan tanpa script" atau teknik canggih untuk memotong penyaringan (dalam hal ini, JSFUCK akan melakukannya), sehingga fakta risiko keamanan tidak membatalkan ini.

Kesalahan dalam logika mekanisme manajemen sesi adalah bagian yang paling menarik dari tugas tersebut. Penemuannya diperlukan tidak hanya untuk membaca sumber baris demi baris, tetapi juga untuk memahami logika seluruh daftar. Orang bisa merasakan ada sesuatu yang salah dengan memperhatikan pengaturan cookie yang berisi id pengguna yang dikodekan base64 di blok ingat-saya. Analisis lebih lanjut dari logika mekanisme ini membawa kita pada pemikiran: "Ternyata penyerang yang mengetahui atau melewati id dapat masuk ke akun apa pun tanpa memasukkan nama pengguna dan kata sandi?!". Ya, memang, seorang penyerang dapat secara mandiri menghasilkan pengguna cookie di sisinya dan memberikan nilai id apa pun yang dikodekan oleh base64. Mengirim permintaan dengan cookie seperti itu tanpa nama pengguna dan kata sandi akan memicu fungsi do_login dan masuk ke akun orang lain.

Penyebutan 4 kerentanan ini dalam respons kandidat secara langsung memengaruhi skor mereka.

Namun, banyak tergantung pada kualitas respons. Menyebutkan cara-cara untuk memperbaiki situasi, mengomentari faktor-faktor tambahan yang memengaruhi kelayakan serangan, penggunaan istilah-istilah yang tepat dan kemampuan untuk menyusun pemikiran Anda, mengomentari kelemahan tambahan atau ancaman potensial - semua ini menghangatkan hati kami dan menyebabkan peningkatan peringkat akhir.

Dalam pekerjaan auditor sering harus berurusan dengan teknologi baru, dan kemampuan untuk memahaminya sangat penting. Termasuk pertanyaan ini dalam kuesioner, kami berasumsi bahwa sebagian besar kandidat hampir tidak mendengar tentang teknologi token JWT kecuali untuk namanya. Karena itu, pertanyaan ini, pertama-tama, ditujukan pada kemampuan untuk mencari dan menganalisis informasi dari sumber-sumber publik. Akibatnya, seseorang yang melewatkan penerbitan Google atas permintaan "JWT" ​​dan "jwt kerentanan" bisa sampai pada kesimpulan berikut:

1. Token ini tidak memiliki algoritme tanda tangan, sehingga penyerang dapat memodifikasi bidang apa pun di dalam token, yang tidak diasumsikan oleh konsep token JWT.

2. Bidang di dalam token berisi kata sandi pengguna dalam teks yang jelas, menyimpan informasi tersebut di token, setidaknya, merupakan praktik yang buruk. Dalam kebanyakan kasus, Anda dapat menolak keputusan seperti itu dan dengan demikian meningkatkan tingkat keamanan Anda.

3. Mengingat kurangnya tanda tangan dan kemampuan kami untuk memodifikasi bidang di dalam token, masuk akal untuk berasumsi bahwa mengubah nilai isAdmin dapat meningkatkan hak istimewa kami menjadi hak istimewa administrator.

4. Gagasan menarik lainnya yang hanya beberapa orang yang disebutkan dalam jawaban mereka berkaitan dengan fakta kemampuan untuk mentransfer input pengguna di bidang token JWT. Dalam situasi normal, penyerang tidak dapat mempengaruhi data dalam token dengan cara apa pun, yang berarti bahwa pengembang sering dapat mengabaikan pengenalan cek tambahan dalam kode penangan. Ini memunculkan ide sederhana: tapi mari kita coba melakukan serangan klasik bukan melalui parameter GET / POST, tetapi melalui bidang token. Ini bisa memberikan hasil yang baik secara tak terduga. Pendekatan kreatif semacam itu dengan justifikasi tindakan kami yang benar sangat kami hargai dalam menilai hal ini dan masalah lainnya.

Banyak kandidat dalam jawaban mereka mengatur pengulangan singkat tentang bagaimana token JWT disusun, dan di mana digunakan, itu menarik bagi kita untuk membaca, namun, pertama-tama, kita mengevaluasi aspek-aspek jawaban mengenai keamanan.

 <ifmodule mod_headers.c> Header always set Access-Control-Allow-Origin: "https://whitelist.domain.ru" Header always set Access-Control-Allow-Methods "PUT" </ifmodule> 

 <?php header('Access-Control-Allow-Origin: “https://whitelist.domain.ru”); header('Access-Control-Allow-Methods: PUT'); ?> 

Mari kita perhatikan, secara berurutan, apa masalah utama yang terlihat pada pertanyaan yang diberikan:

1) Memang, karena pengidentifikasi angka pengguna "10012" diamati dalam permintaan, langkah pertama adalah memeriksa apakah mungkin untuk mengubah kata sandi untuk pengguna lain? Bisakah cukup menentukan id orang lain ?
Kerentanan kelas IDOR cukup mudah untuk dieksploitasi dan seringkali memiliki tingkat kritikalitas tinggi.

2) Permintaan untuk mengubah kata sandi terjadi dengan metode POST, token CSRF tidak diamati, dan jenis kontennya adalah "teks / polos". Ada kemungkinan memalsukan permintaan seperti itu.

Akibatnya, untuk mengubah kata sandi korban, cukup bagi penyerang meyakinkan mereka untuk hanya mengunjungi tautan "jahat".

3) Di header respons, server mengungkapkan versi perangkat lunak yang digunakan . Ini bisa disebut kerentanan pada bentangan, tetapi lebih baik menyembunyikan spanduk tersebut - penyerang dapat dengan mudah menemukan eksploitasi 1 hari yang terkenal pada mereka, ditambah nilai perangkat lunak yang digunakan sangat menyederhanakan perencanaan serangan lebih lanjut.

4) Kami akan sangat senang melihat kalimat "Apa yang akan terjadi jika kami mengubah format data dari JSON ke XML ?"

Faktanya adalah bahwa kerangka kerja modern cerdas, omnivora dan dapat memproses data dalam format yang berbeda. Dan ketika parsing XML, kerentanan XXE yang berbahaya sering diizinkan. Dengan bantuannya, penyusup dapat "pergi" ke jaringan internal, dapat membaca file konfigurasi dari server, dan kadang-kadang menjalankan RCE.

5) Saya juga ingin melihat komentar seperti "Mengapa pengetahuan orang tua tidak diperiksa saat mengganti kata sandi?"

Adapun "Varian No. 2", ada "jebakan" di dalamnya - header CORS digunakan di sini, dan Tipe-Konten dari permintaan sudah diatur ke "application / json".

Kesalahan yang dibuat oleh sebagian besar kandidat adalah jawaban dari formulir "-Itu tanda bintang di Allow-Origin, yang berarti Anda dapat mengirim permintaan dari situs mana pun!"

Tidak, kamu tidak bisa. Pertama, Bolehkan-Kredensial: Header benar tidak ada, yang berarti bahwa browser harus menjalankan permintaan "dengan cookie", sehingga permintaan akan anonim, tanpa sesi. Dan kedua, bahkan jika tajuk seperti itu ada, browser tetap akan melarang pengiriman cookie - hanya karena "tanda bintang". Kombinasi mereka dilarang, dan peramban diabaikan.

Tujuan dari pertanyaan ini adalah untuk menentukan keakraban peserta pelatihan dengan teknik modern (dan tidak demikian) untuk melakukan serangan MitM. Mari kita lihat skenario potensial berdasarkan dump lalu lintas yang ada:

1) spoofing ARP
Spoofing ARP adalah cara tertua dan termudah untuk mengimplementasikan serangan MitM. Ini terdiri dari mengirimkan permintaan ARP gratis untuk menjadi tuan rumah A.

Alamat IP host B adalah alamat IP, dan alamat MAC kami adalah alamat MAC. Permintaan semacam itu memungkinkan Anda untuk memodifikasi tabel ARP pada host A, memaksanya untuk mengirim permintaan ke perangkat kami ketika mencoba menghubungi host B. Host B biasanya merupakan gateway default.

Alat yang Disarankan: bettercap, arpspoof

2) LLMNR, spoofing NBNS
Link-Local Multicast Name Resolution dan NetBIOS Name Service adalah protokol yang digunakan untuk menyelesaikan nama host di jaringan lokal. Berbeda dengan protokol DNS, tidak ada server khusus yang menyimpan semua informasi, sebaliknya, permintaan disiarkan ke semua host di jaringan, jika nama host dalam permintaan cocok dengan nama host perangkat, itu akan mengirim respons.

Seperti yang telah dicatat dengan benar dalam jawaban, penyerang dapat menanggapi permintaan tersebut dengan mengirimkan alamat IP-nya di respons, yang akan mengarah pada fakta bahwa di masa depan korban akan menghubungi perangkat penyerang, alih-alih perangkat yang nama hostnya muncul dalam permintaan. Selain itu, penyerang dapat meminta otentikasi NTLM dari korban, yang menyebabkan perangkat korban mengirim hash NTLM, yang selanjutnya dapat digunakan untuk brute force.

Alat yang Disarankan: Responder

3) WPAD spoofing
Spoofing WPAD dapat dikaitkan dengan kasus khusus dari spoofing LLMNR dan NBNS. Protokol Penemuan Auto Proksi Web digunakan untuk mengkonfigurasi server proxy HTTP secara otomatis.

Perangkat mengirim permintaan LLMNR / NBNS dengan nama host wpad, menerima alamat IP yang sesuai, dan mencoba mengakses file wpad.dat melalui HTTP, yang menyimpan informasi tentang pengaturan proxy.

Akibatnya, penyerang dapat melakukan spoofing LLMNR / NBNS dan memberikan file wpad.dat kepada korban, sebagai akibatnya, semua lalu lintas HTTP dan HTTPS akan melewati penyerang.

Alat yang Disarankan: Responder, mitm6

4) Iklan Router
Seperti yang Anda lihat dari dump, ada perangkat dengan IPv6 diaktifkan di jaringan. Saat berada di jaringan, Anda dapat mencoba mengirim pesan ke Iklan Router IPv6 korban untuk mengubah gateway default atau server DNS.

Pesan Router Advertising (RA) adalah bagian dari mekanisme SLAAC (Stateless Address Autoconfiguration), yang diperlukan untuk secara otomatis mendapatkan alamat IPv6 di jaringan, tanpa menggunakan server DHCPv6, atau bersamaan dengan itu. Ini dicapai dengan secara berkala mengirim pesan RA multicast ke router, yang berisi alamat gateway default, awalan jaringan, alamat server DNS, awalan domain.

Alat yang Direkomendasikan: paket mentah

5) DHCP spoofing
Juga, dalam dump, permintaan DHCP Discover dari perangkat yang sama diulangi pada beberapa interval. Anda dapat menarik kesimpulan tentang tidak adanya server DHCP di jaringan ini dan menanggapi permintaan Temukan berikutnya dengan menetapkan korban sebagai gateway default ke perangkat.

Alat yang Disarankan: Yersinia

6) Spoofing HSRP
Selain itu, paket HSRP dapat dilihat di dump. Hot Standby Router Protocol dapat meningkatkan ketersediaan router yang bertindak sebagai gateway default. IP-, -. Hello - , . HSRP, , , HSRP .

: Yersinia

7) STP-
Spanning Tree Protocol L2- . BPDU-, , . BPDU-, , , , , , , , STP, , .

: Yersinia

, . nginx , web-, nginx web- /. nginx , , , .

, , , . , . , , .

gixy .

Gixy 4 :

1) Alias travesal:

80 :

 location /static { alias /prod_static/; } 

- , . : //host/static../etc/passwd. - alias: , /static, /prod_static/, : /prod_static/../etc/passwd, /etc/passwd. alias traversal

2) Http Splitting (CRLF injection)
nginx , , . HTTP-.
: github.com/yandex/gixy/blob/master/docs/ru/plugins/httpsplitting.md

3) -
75 «rigin» . , - , , production.host.evil.com .
: github.com/yandex/gixy/blob/master/docs/ru/plugins/origins.md

4) add_header
nginx : add_header, , , , . CSP .
: github.com/yandex/gixy/blob/master/docs/ru/plugins/addheaderredefinition.md

---

, gixy, . :

1) 17 default_type text/html. : , , nginx Content-Type, default_type. , Content-Type: text/html. HTML- , , , XSS- .

2) POST-
29-30 , . , “” POST-. . Tapi! SSRF , , , , .

3) php-fpm
48 , FastCGI- unix , 9000. , , . , PHP-.

4) “” CSP
production.host Content-Security-Policy, Javascript, .

5) “” CORS
76-77 CORS, , cookie .

6) , 86 . secured /managed.

7) , , , -. , , , /user/{userid} IDOR.

, , , .

, :

• ACL
• capabilities

, , :
“ , root” .

, Linux/Unix .
, “ ” — .
, , funky_test.txt

 -rwxrw-rx 1 alice interns 12  4 13:00 funky_test.txt 

, Linux/Unix :

• - — “rwx” alice
• — “rw” interns
• — “rx” others

read, write, execute .

, — , :

• , read
• , read
• read

, read . , execute .

, .

, , . :

1. , ls.

2. — POSIX Access Control Lists .

c .

1

, alice interns . funny_test.txt :

 $ whoami alice $ id uid=1001(alice) gid=1001(alice) groups=1001(alice),1002(interns) $ ls -la ----rwx--- 1 alice interns 12  4 13:00 funky_test.txt $ cat funky_test.txt cat: funky_test.txt: Permission denied $ 

2

— funky_test.txt 604. bob , interns :

 $ whoami bob $ id uid=1002(bob) gid=1003(bob) groups=1003(bob),1002(interns) $ ls -la funky_test.txt -rw----r-- 1 alice interns 12  4 13:00 funky_test.txt $ cat funky_test.txt cat: funky_test.txt: Permission denied 

alice , . , permission_denied :

 $ id uid=1001(alice) gid=1001(alice) groups=1001(alice),1002(interns) $ ls -la ----rwx--- 1 alice interns 12  4 13:00 funky_test.txt $ chmod 777 funky_test.txt $ ls -la funky_test.txt -rwxrwxrwx 1 alice interns 12  4 13:00 funky_test.txt $ cat funky_test.txt secret_pass 

bob .

, « », :

• ID effective UID —
• GID effective GID —
• others.

, — , “” , , , :

• , , others
• , , others

.

POSIX Access Control Lists

— /. , ACL, , “ + ”

POSIX ACLs, — , . ACL, .

Contoh

. alice funky_test.txt ,

 -rwxrw-rx 1 alice interns 12  4 13:00 funky_test.txt 

ACL. getfacl , , ACL, , ls .

 $ getfacl funky_test.txt # file: funky_test.txt # owner: alice # group: interns user::rwx group::rw- other::rx 

, ACL . , bob :

 setfacl -mu:bob:rwx funky_test.txt 

“ + ”

 ls -l funky_test.txt -rwxrwxr-x+ 1 alice interns 12  4 13:00 funky_test.txt 

:

 getfacl funky_test.txt # file: funky_test.txt # owner: alice # group: interns user::rwx user:bob:rwx group::rw- mask::rwx other::rx 

ACL . :

1. . effective UID effective GID — . , ACL, . , , , , , .
2. ACL mask , ACL owner, group, others

, , , — .

, ACL, , :

• ACL, ;
• , ACL, .

 1)User - 1 Account: IEUser Domain: WIN7 Host: WIN7 hex dump session key - 49 0c 38 3e f8 eb 63 88 79 0f 62 84 09 84 d2 dc 2) User - 2 Account: winwin Domain: WIN7 Host: WIN7 hex dump session key - 8d f6 1b 35 79 a3 78 d3 2e 81 09 f1 95 4f 71 0a 3) User - 3 Account: 192.192.192.29 Domain: WIN7 Host: WIN7 hex dump session key - c3 19 e0 21 1b e2 63 c6 03 9e e7 38 1b 56 f0 d1 

, , :

1. ( )
2. — /
3. ,

, :

Wireshark, Protocol Hierarchy Statistics Conversations .

Protocol Hierarchy Statistics — .



Conversations — , .





:

1. (60%) — TCP, , , SMB. Protocol hierarchy SMB 40%, TCP, , 20% SMB.
2. 192.192.192.128 192.192.192.129. SMB .

.

— SMB.

, — wireshark — ExportObject .
tcp stream . , , tcp stream , . , .

, , , , . , .

.
SMB .

NTLM- “ntlmssp”. info , 3 :



, .







Net-NTLMv2-, :

• challenge
• response

Net-NTLMv2 hashcat .

, WIN7\winwin WIN7\192.192.192.129 — , . WIN7\IEUser — , , , , , SMB.

Net-NTLM , , Wireshark. , PCredz (https://github.com/lgandx/PCredz)



IEUser ( ) hashcat.



, .

6, , SMB/NTLM , DNS .

, , NT LM NTLMv1 (Net-NTLMv1) , NTLMv2 (Net-NTLMv2) ( ).

- NT LM NTLM , NTLM NTLMv1 NTLMv2 . , . .

, NTLMv1/NTLMv2 — challenge-response . , .

NT LM — “ ” — .

:

• PassTheHash — , , . Tapi , NT . PassTheHash NTLMv2 — . , “” , , .
• NTLM Relay — , , NTLM. , .
• Spoofing, Windows: LLMNR, NetBios
• : MS17-010, / , .

:

• ( )
• ,
• eternalBlue
• NTLM relay
• NTLM relay — SMB
• , (ARP-spoofing, DNS )

, , , Pivoting. , , , , , .

, ping , ARP- (arp -a), (route). , netcat (nc -h), , (nc -vnz 10.0.20.3 0-1000). , , , , , , - bash, python .

— SSH-, SOCKS- SSH, .
ssh -D 1337 user@10.0.20.5 -f -N

. nmap SOCKS- proxychains .

proxychains nmap 10.0.20.0/24
nmap 10.0.20.0/24 --proxy socks4://10.0.20.5:1337

nmap - SOCKS-. SYN- ( nmap ) SOCKS-, SOCKS- TCP- , SYN- , SYN, SYN ACK. CONNECT- (-sT), nmap SOCKS-.

nmap -sT 10.0.20.0/24 --proxy socks4://10.0.20.5:1337

, - , , . , Linux-, nmap -sT , , , , , , .

, MITM HTTPS .

, Proxy WiFi. ProxyDroid, iptables .

, Root , , ?

SSL-Pinning, , , “Frida+Objection”. , :)