Microsoft SQL Server merupakan aplikasi yang populer dan handal diantara aplikasi berbasis database lainnya – memiliki fitur luar biasa dengan kemampuan multi-access, sistem keamanannya menyeluruh dan dengan mudah ditransfer ke platform database lainnya. Artikel ini bertujuan untuk mengidentifikasi jenis bahaya tertentu yang mungkin diakibatkan dari manajemen yang tidak sesuai pada Microsoft SQL Server.Sayangnya, potensi tersebut tidak direalisasikan – sekalipun menggunakan royalty gratis MSDE (Microsoft Database Engine yang dioptimasikan bagi individu atau solusi perusahaan kecil) jika perlindungan keamanan yang memadai pada database tidak tersedia. Mengapa harus memiliki teknologi ini? Karena kapabilitas tinggi SQL server yang dikombinasikan dengan fleksibilitas yang tinggi pula dan terlalu banyak fleksibilitas menyebabkan gangguan jika digunakan dengan cara yang salah. Artikel ini bertujuan untuk mengungkap beberapa jenis bahaya yang diakibatkan dari manajemen Microsoft SQL Server yang salah. Jika dikonfigurasi dengan sesuai, SQL Server mengjinkan seluruh user untuk mengakses master databasenya, yang berisikan seluruh setting SQL Server – dan seluruh informasi yang SQL Server gunakan untuk membuka database tersebut. Yang berisikan seluruh SQL Login ID, data yang terhubung ke server dan sebagainya. Tentu saja, user “biasa” tidak diijinkan mengakses seluruh sumber informasi. Gambar 1 menunjukkan bagaimana perilaku server jika seseorang berusaha mengakses daftar account – sebagaimana yang terlihat, server mencegah user tersebut membaca password. Meskipun demikian, nama account dan database (termasuk informasi yang tersimpan didalamnya) mungkin saja diakses oleh user yang tidak berhak.
1> select name,dbid from sysdatabases
2> go
name dbid
-------------------------------------- ----------------------
master 1
tempdb 2
model 3
msdb 4
pubs 5
Northwind 6
pages 7
(7 rows affected)
1>
Sebagaimana yang terlihat sangat sulit menjaga keamanan data dari mata para hacker.
Meskipun Demikian…Tentu saja, para pembaca mungkin akan berkata, “ah tidak seluruhnya benar, user kami tidak diijinkan menjalankan ad hoc query pada SQL Server!” biarpun begitu, pengujian tertutup menunjukkan hal ini menjadi klaim yang sangat meragukan, karena hal yang mungkin atau mustahil menempatkan dengan sengaja menempatkan query dalam aplikasi SQL Server dan menerapkan aturan yang sama validnya pada server itu sendiri! Meskipun melalui sebuah aplikasi tertentu mencegah terjadinya situasi seperti ini, saya sarankan pada anda untuk mempertimbangkan ulang ide ini bahwa seluruh script yang dilindungi terhadap serajgan SQL Injection”. Bagaimana jika user tersebut, saat menentukan kondisi query, mungkin melampirkan table untuk menghasilkan sesuatu? Dan bagaimana dengan skema otentikasi server yang diterapkan pada pengguna potensial? Bahkan anggapan bahwa aplikasi terlindungi dengan baik terhadap akses ilegal pada data, user itu sendiri tidak dapat menjalankan tool komuniksi standar apda komputer ini untuk terhubung ke SQL Server – osql.exe, VBScript yang menggunakan ADO, atau porgram lain yan gmenjalankan ODBC (atau OLEDB) secara langsung ke database server. Pengetahuan SQL Server password hanyalah prasyarat. Masih dalam halini, pada sebagian situasi, kemungkinan otentikasi pengguna local network dalam Directory Service sudah cukup. Jangan biarkan paranoia terbentuk – kita harus menerima bahwa kemungkinan otentikasi user dengan SQL Server yang terkait dengan hak otomatis dalam meminta probe, atau bahkan tindakan yang teledor.
Apa kesimpulannya?Biar kita lihat sekali lagi contoh diatas dari query yang mengembalikan nama account – beberapa dinataranya ditentukan pada SQL Server dan dikenali dengan nilai 0 pada kolom “isntname”. Jika dikonfigurasi untuk melakukan otentikasi pada Mixed Authentication Mode, SQL Server akan menerima usaha login pada account ini, ketika tidak di disable account tersebut dari usaha berulang-kali. Hal ini merupakan kilas balik mekanisme dimana koneksi Otentikasi SQL Server dalam Mixed Mode. Sayangnya, hal ini berupa opsi dan bahkan kalaupun ada, tidak direkomendasikan, karena menjadikan seseorang melakukan serangan brute force dimana setiap kemungkinan key atau password dicoba hingga berhasil. Tentu saja, seorang hacker dapat melakukan hal ini dengan program yang sesuai untuk otomatisasi pekerjaannya (saya, tidak akan menyertakan rincian ini utuk alasan tertentu). Kebanyakan di apresiasikan dengan account “sa” (System Administrator), yang memiliki akses ke segala sesuatu yang dibuat khusus pada SQL Server (mirip dengan root pada Linux atau LocalSystem pada Windows NT). Memiliki hak untuk mengatur database apa pun (termasuk “master” database), akses penuh untuk melakukan berbagai fungsi pada SQL Server dan bahkan untuk menjalankan proses yang diberikan oleh layanan server, yang dikenal dengan proses SQLSERVR.EXE. lebih dari itu, dalam sebagian instalasi, SQL Server dijalankan dalam konteks keamanan “administrator” – dengan demikian user “sa” dapat mengatur sebuah computer yang didalamnya terinstall MS SQL Server service, terpisah dari pengaturan seluruh database. Saat bekerja dengan MSDE, situasinya bahkan lebih buruk – service yang terinstall pada LocalSystem, dengan account “sa” defaultnya adalah BLANK password! Gambar 3 menunjukkan dua upaya terkait guna menghack account “sa”, usaha yang satu gagal, sedangkan usaha yang lainnya berhasil. GAMBAR3: Dua serangan pada account “sa” dengan blank password – usaha kedua berhasil dengan baik.
Menggunakan Account System Administrator Pertama-tama dan lebih dahulu, user “sa” memiliki kendali seluruh data SQL Server, skema dan setup. Tidak diperlukan penjelasan lebih lanjut disini, karena daftar akses system administrator mencakup segala sesuatunya. Sebaiknya kita berfokus pada usaha tertentu – dari jenis serangan malicious. Satu hal paling sederhana adalah membuat account baru dengan hak akses yang sama dengan user “sa”. Daftar dibawah ini sebagai contoh: 1> sp_addlogin 'hacked','h4xor' 2> go New login created. 1> sp_addsrvrolemember 'hacked','sysadmin' 2> go 'hacked' added to role 'sysadmin'. 1> quit C:\>osql -U hacked -P h4xor -Q "SELECT DB_NAME(),USER_NAME()" -------- ------- master dbo (1 row affected) C:\> sebagai pengganti prosedur “sp_addlogin” seseorang dapat menggantinya dengan yang lain, sebagai contoh “sp_gratlogin” – yang terakhir ini akan menciptakan account otentik oleh sistem operasi yang menjalankan SQL Server. Saya akan mencatat, bahwa sangatlah mudah mendapatkan hak akses “sa” – hanya dengan menandai sysadmin role terhadap account user yang dipilih (atau kelompok user yang ditentukan pada phase setup SQL Server). Terpisah dari “role” ini, SQL Server service memungkinkan untuk mengeksploitasi fitur lainnya, meski tidak dapat digunakan untuk mengatur secara total server tersebut. Saya lebih tertarik pada bagian ini, yakni, tidak dapat diijinkan bahwa administrator akan mendeteksi sebuah account (bahkan jika nama tersebut tidak ada sebagai hal yang luarbiasa). Jika begitu, seorang hacker tidak memiliki pilihan selain menggunakan account yang ada – cara sederhana adalah memodifikasi prosedur pemberian password “sp_password”. Jika seorang intruder berupaya menyembunyikan jejaknya, dia berusaha untuk menguraikan password tersebut, yan gmemberikannya akses user ke server. Seseorang berharap mengingat hal ini menunjukkan bahwa dalam otentikasi mode mixed, SQL Server bisa menggunakan mekanisme otentikasinya sendiri yang menyimpan informasi tidak hanya pada nama-nama account (mirip dengan otentikasi berbasis sistem operasi) tapi juga password. Hal ini ditempatkan dalam kolom “password” pada tabel sysxlogins – yang berisikan hash dari password user yang dibuat oleh fungsi pwdencrypt(). Fakta luar biasa ini digambarkan secara briliant oleh David Litchfield. Tools yang sering digunakan untuk serangan brute force telah dijelaskan. Jika SQL server anda tidak di konfigurasi terhadap otentikasi SQL Server, anda tidak perlu khawatir akan dihack menurut cara diatas. Beberapa intruder perusak mungkin berusaha menginstall backdoor. Dua kemungkinan tersebut digambarkan dibawah ini.
Prosedur Penyimpanan Yang DiperluasFitur SQL Server kemungkinan menjalankan prosedur user-written. Kedua prosedur ini ditulis dalam bahasa SQL dan tersimpan pada berbagai database, atau berupa Dynamic Link Libraries (DLLs) yang SQL Server bisa secara dinamis meload dan mengeksekusinya jika diperlukan. Bagian terakhir ini dikenal sebagai “extended stored procedures” (Prosedur Penyimpanan yang diperluas) yang artinya bahwa prosedur tersebut memiliki karakteristik tertentu: mereka ditambahkan secara langsung ke SQL Server dan membagi konteks keamanan SQL Server executable. Dalam prakteknya, prosedur ini bisa dibuat untuk menjalankan hak akses “sa” pada database. Mereka bisa dibuat hanya pada “master” database dimana mereka bisa ditambahkan pada database hanya oleh administrator (user “sa”). Konfigurasi default SQL Server berisikan banyak sejumlah besar prosedur, meski banyak diantara mereka tidak terdokumentasikan. Prosedur Penyimpanan yang diperluas dapat dibuat untuk menjalankan skema otentikasi yang berlainan – prosedur tertentu dibuat untuk kemampuan mengakses seluru user secara default atau karena fungsi server sangat dibutuhkan. Hanya system administrator bisa menjalankan prosedur penyimpanan diperluas lainnya. Hal ini menciptakan sejumlah operasi yang sukar bagi administrator terutama dalam mendeteksi prosedur “khusu” yang mungkin saja ditambahkan pada server oleh intruder. Hal ini cukup untuk meload file DLL yang dipersiapkan sebelumnya pada komputer tersebut (menggunakan Open Data Service API, yang secara opsional terinstall pada SQL Server), kemudian memanggil prosedur “sp_addextendedproc” dengan argumen yang berturut-turut, diikuti dengan hak akses mengeksekusi prosedur ini bagi seluruh user (seperti untuk public user group). Sebagaimana prosedur yang mungkin digunakan oleh seorang hacker untuk mengeksekusi operasi secara sengaja dengan hak akses “sa” dari berbagai tingkatan user account.
Mengapa tidak Me-Revoke Otorisasinya?Chris Anley dalam dokumennya yang berjudul “Violating Database – Enforced Security Mechanisms” menjelaskan sebuah pendekatan keamanan tingkat lanjut, yang terkait dengan modifikasi fungsi SQL Server untuk mengabaikan query dari siapapun selain user “sa”. Penemuan ini didasarkan pada ide tentang penanganan prosedur otorisasi tanpa kecuali dengan kode SQL Server. “Ketimbang mengusahakan sebuah analisa statis pada codebase SQL Server yang ada, sedikit debug kedepat mungkin akan menunjukkan kami pada arah yang benar”. Tentu saja sebuah perubahan adalah mudah pada kndisi tertentu – salah satunya dengan memanipulasi file executable yang berisikan codebase SQL Server atau dengan menciptakan operasi pada memory image – dalam kedua kasus ini, hanya System Administrator SQL Server sajalah yang berhak melakukan hal ini. Meski begitu, hal ini pada situasi yang sederhana. Kenyataannya jarang begitu. Sebelum memasukkan rincian lebih jauh, biar saya ingatkan anda bahwa pengamatan pada buletin keamanan terkini adalah sangat penting, dengan kata lain mungkin terjadi buffer overflow. Mengapa masalah buffer overrun menjadi pertimbangan? Sebagaimana yang anda perhatikan, SQL Server memiliki banyak Extended Stored Prosedur default seperti fungsi DLL yang ada pada SQL Server. Mereka ditulis dalam bahasa tingkat tinggi (seperti bahasa C) dan dikompilasi sebagai DLL. Pada saat mulai menjalankan, mereka membaca parameter user pada memory buffer. Apapun alasannya, para programmer mungkin mungkin lupa untuk mengenkripsi pemeriksaan data yang ditempatkan kedalam berbagai macam program – dan jika seorang attacker mengirim terlalu banyak data, kemungkinan terjadi “overflow” pada ukuran tertentu dan menulis data disekitar area buffer komputer. Dengan Buffer Overflow ini mungkin saja malicious user menjalankan perintah kewenangan pada remote system. (lihat artikel “Analysis of Buffer Overflow Attacks” yang ditulis oleh Piotr Frej dan Maciej Ogorkiewicz). Masalah tersebut adalah bahwa MS SQL Server berisikan prosedur yang rentan terhadap serangan buffer overflow. Kedua hal ini sebelumnya telah dijelaskan pada Extended Stored Procedures sama halnya dengan fungsi yang diimplementasikan dalam Transact-SQL Language (lihat fungsi “pwdencrypt). Hal ini mungkin terjadi pada OLEDB libraries, dimana obyek COM diload pada proses client tersebut. Mengingat bahwa dalam konteks COM, setiap program berbasis komponen menjadi sebagai client. Kapapun perintah OPENROWSET diaktifkan, SQL Server menjadi client dari data provider, yang menciptakan secara otomatis kerentanan pada kesalahan kode pada OLEDB tertentu. Untuk lebih jauhnya, mungkin anda ingin membaca berbagai macam buletin keamanan lebih rinci tentang masalah dan solusi yang ditawarkan. Jika begitu, waspadalah bahwa kesuksesan serangan buffer overflow berarti bahwa setiap user menjalankan kode kewenangan pada SQL server dalam konteks account local administrator. Dan mungkin dia telah mengetahui, bahwa hak akses “sa” memungkinkan untuk memanipulasi kewenangan SQL service, meski begitu kami masih menyisakan masalah berkut ini – seberapa jauh kewenangan hak akses “sa” dalam konteks sistem operasi? Mereka sama kuatnya pada SQL service dan, dalam istilah keamanan, hak akses ini terkait pada seluruh proses SQLSERVR.EXE. Dengan default “standar”, SQL Server menyertakan beberapa kemampuan Extende Stored Prosedur untuk berkomunikasi dengan sistem operasi. Beberapa diantaranya adalah: “xp_cmdshell”, “sp_OACreate”, “xp_regwiret”, “xp_instance_regwrite”, “xp_adsirequest”. Meski beberapa diantaranya didokumentasikan (xp_cmdshell dan sp_OACreate), kami masih tidak bisa memastikan akibat prosedur lainnya. Dengan menggunakan prosedur ini, administrator SQL Server bisa berinteraksi dengan sistem operasi terbatas pada otorisasi MS SQL Service. Jika ada kasus mengenai dijalankannya service ini pada account LocalSystem, “sa” akan menjadi hak akses puncak untuk mengakses Desktop namun tidak pada direktori jaringan. Sang attacker mungkin menggunakan hak akses seperti yang digambarkan pada gambar 4 ini. GAMBAR 4: Menggunakan account “sa” untuk menguplad program dari Internet ke server.
LocalSystem default?Microsoft SQL Server 2000 Desktop Edition (MSDE 2000), versi terakhir dari MSDE yang terinstal dengan account LocalSystem sebagai defaultnya. Tentu saja, hal ini menjadikan celah potensial untuk serangan seperti yang dijelaskan diatas. Secara alami, melakukan patch SQL Server ke SP 3 enhaces security – selain SQL Server service itu sendiri, bukan mesin yang menjalankannya. Sebagai gantinya, dengan menginstall SP3, anda bisa menangani maslaah jika server tersebut dijalankan di manapun ketimbang LocalHost. Hal ini merupakan konsekuensi dari permisi yang ditentukan pada registry key dan file system yang terinstall SP3. Tentu saja, meminimalisir hak akses yang tidak diinginkan merupakan faktor positif selain melakukan pendekatan ini dengan dokumentasi yang tidak memadai adalah praktek yang buruk. Berikut ini beberapa informasi dasar guna membantu seseorang melengkapi dokumentasi yang diperlukan. Untuk mengurangi MSDE – yang terkait dengan hak akses dalam sistem operasi:
- Mengganti kedua account MSSQLServer DAN SQLServerAgent service (serta LocalSystem) dengan sebuah account yang dipilih
- Menyediakan account baru dengan langsung membaca pada direktori C:\Program Files\Microsoft SQL Server\MSSQL, ingatlah untuk memeriksa opsi “Reset permissions on all child objects” pada kotak dialog Advanced.
- Memberikan hak akses penuh pada subdirektori DATA dan LOG pada account baru ini
- Jalankan registry dengan menggunakan regedt32.exe (seperti mengijinkan untuk mengedit hak akses menggunakan regedit.exe pada Windows XP) dan berikan permisi penuh pada account pada regsitry key: HKLM\SOFTWARE\Microsoft\MSSQLServer. Jalankan kembali opsi "Reset permissions on all child objects ..."
- Berikan permisi READ pad account tersebut (hanya READ) dalam registry key HKLM\SYSTEM\CurrentControlSet\Services\MSSQLSERVER
- Jalankan MSSQLServer service
- Tambahkan account service pada sysadmin server role (untuk mendukung SQLServerAgent service), dengan menggunakan perintah berikut ini: 1> sp_grantlogin 'COMPUTER\account_sql' 2> go Granted login access to 'COMPUTER\account_sql'. 1> sp_addsrvrolemember 'COMPUTER\account_sql','sysadmin' 2> go 'COMPUTER\account_sql' added to role 'sysadmin'.
- Jalankan SQLServerAgent service\
Perintah SQL dapat dijalankan dengan menggunakan program osql.exe pada account system administrator dengan spesifikasi parameter E. Tentu saja, anda harus menentukan real name pada SQL service account yang harus diproses dengan nama mesin. Jika anda tidak ingin memberikan akses terhadap MSDE server dari jaringan, disable registry berikut ini: HKLM\SOFTWARE\Microsoft\MSSQLServer\MSSQLServer\SuperSocketNetLib Untuk alasan tertentu, langkah yang baik untuk mengekspor registry ini ke file .reg sebelumnya. Jika masalah muncul saat menjalankan MSDE service, gunakan program FileMon dan RegMon yang tersedia pada www.sysinternals.com – kedua tool ini sangat bermanfaat saat menganalisa dan mengurangi kesulitan yang diakibatkan ketidakleluasaan dalam mengubah registry key atau file system. Hal ini juga telah dijelaskan pada dokumentasi SQL Server 2000.
0 komentar:
Posting Komentar