Database modern menyimpan semua jenis data. Dari yang sepele hingga yang sangat sensitif. Restoran yang sering kami kunjungi, lokasi peta kami, kredensial identitas kami, (misalnya, Nomor Jaminan Sosial, Alamat, Catatan Medis, Info Perbankan, dll...), dan segala sesuatu di antaranya kemungkinan besar disimpan dalam database di suatu tempat. Tidak heran jika data sangat berharga.
Teknologi database maju dengan kecepatan yang sangat tinggi. Inovasi, kemajuan, integritas, dan peningkatan berlimpah berada di garis depan sebagai hasil langsung dari kerja keras para insinyur, pengembang, dan komunitas tangguh yang cerdas dan berdedikasi yang mendukung vendor tersebut.
Namun ada sisi lain dari koin. Sayangnya, hal itu hidup berdampingan di dunia yang digerakkan oleh data ini dalam bentuk malware, virus, dan eksploitasi dalam skala besar yang besar sepanjang masa.
Data juga berharga bagi pihak-pihak di sisi operasi itu. Tapi untuk alasan yang berbeda. Salah satu dari mereka bisa tetapi tidak terbatas pada kekuasaan, pemerasan, keuntungan finansial dan akses, kontrol, kesenangan, pranks, kedengkian, pencurian, balas dendam ... Anda mendapatkan idenya. Daftarnya tidak ada habisnya.
Sayangnya, kita harus beroperasi dengan pola pikir keamanan. Tanpa pola pikir ini, kami membiarkan sistem kami rentan terhadap jenis serangan ini. PostgreSQL rentan terhadap kompromi, penyalahgunaan, pencurian, akses/kontrol tidak sah seperti halnya bentuk perangkat lunak lainnya.
Jadi, Tindakan Apa yang Dapat Kami Ambil untuk Mengurangi Jumlah Risiko pada Pemasangan PostgreSQL Kami?
Saya sangat merasa bahwa mempromosikan kesadaran tentang ancaman yang diketahui ada di luar sana, adalah tempat yang baik untuk memulai. Pengetahuan adalah kekuatan dan kita harus menggunakan semua yang kita miliki. Selain itu, bagaimana kita bisa mengawasi hal yang bahkan tidak kita sadari untuk memperketat keamanan pada instance PostgreSQL tersebut dan melindungi data yang ada di sana?
Saya baru-baru ini mencari 'kekhawatiran' dan 'ancaman' keamanan yang diketahui, yang menargetkan lingkungan PostgreSQL. Pencarian saya mencakup laporan, artikel, dan posting blog terbaru dalam kuartal pertama tahun 2018. Selain kerangka waktu tertentu, saya menjelajahi kekhawatiran lama yang terkenal yang masih menjadi ancaman saat ini (yaitu SQL Injection), meskipun tidak dipoles atau dicap sebagai 'baru saja ditemukan '.
Peluang Foto
Menyelam Jauh ke dalam Serangan Basis Data [Bagian III]:Mengapa Gambar Scarlett Johansson Membuat Basis Data Postgres Saya Mulai Menambang Monero
Berita tentang serangan malware licik ini menghasilkan 'hits' terbanyak dari hasil pencarian objektif saya.
Kami akan mengunjungi salah satu dari beberapa posting blog yang bagus dan ikhtisar isinya. Saya juga menyertakan posting blog tambahan menjelang akhir bagian ini jadi pastikan dan kunjungi juga yang merinci intrusi ini.
Pengamatan
Informasi dari Imperva, melaporkan database honeypot mereka (StickyDB) menemukan serangan malware di salah satu server PostgreSQL mereka. Honeypot net, sebagaimana Imperva menamai sistemnya, dirancang untuk mengelabui penyerang agar menyerang database sehingga mereka (Imperva) dapat mempelajarinya dan menjadi lebih aman. Dalam contoh khusus ini, payloadnya adalah malware yang mengcrypt Monero, yang disematkan di foto Scarlett Johansson.
Payload dibuang ke disk saat runtime dengan fungsi lo_export. Tapi ternyata, ini terjadi karena lo_export adalah entri di pg_proc versus panggilan langsung biasa (lo_export).
Detail menarik langsung dari posting blog di sini untuk kejelasan yang ekstrem (lihat artikel yang dikutip),
Sekarang penyerang dapat menjalankan perintah sistem lokal menggunakan satu fungsi sederhana – fun6440002537. Fungsi SQL ini adalah pembungkus untuk memanggil fungsi bahasa C, “sys_eval”, fungsi ekspor kecil di “tmp406001440” (biner berdasarkan sqlmapproject), yang pada dasarnya bertindak sebagai proxy untuk menjalankan perintah shell dari klien SQL.
Jadi apa langkah serangan selanjutnya? Beberapa pengintaian. Jadi ini dimulai dengan mendapatkan detail GPU dengan menjalankan lshw -c video dan dilanjutkan ke cat /proc/cpuinfo untuk mendapatkan detail CPU (Gambar 3-4). Meskipun ini terasa aneh pada awalnya, masuk akal jika tujuan akhir Anda adalah menambang lebih banyak cryptocurrency favorit Anda, bukan?
Dengan kombinasi akses database dan kemampuan untuk mengeksekusi kode dari jarak jauh, semuanya 'terbang di bawah radar ' dari solusi pemantauan, penyusup kemudian mengunduh muatan melalui foto Scarlett Johansson.
(Catatan:Sejak saat itu foto telah dihapus dari lokasi yang dihostingnya. Lihat artikel penautan untuk penyebutan.)
Menurut laporan itu, muatannya dalam format biner. Kode biner itu ditambahkan ke dalam foto agar lolos ke foto sebenarnya selama pengunggahan, memungkinkan gambar yang dapat dilihat.
Lihat Gambar 6 posting untuk SQL yang bertanggung jawab untuk memanfaatkan wget, dd, dan mengeksekusi chmod untuk izin pada file yang diunduh. File yang diunduh itu kemudian membuat executable lain yang bertanggung jawab untuk benar-benar menambang Monero. Tentu saja, pembersihan dan pembersihan diperlukan setelah semua pekerjaan jahat ini.
Gambar 7 menggambarkan kinerja SQL.
Imperva merekomendasikan untuk memantau daftar area pelanggaran potensial ini di bagian penutup:
- Hati-hati dengan panggilan PostgreSQL langsung ke lo_export atau panggilan tidak langsung melalui entri di pg_proc.
- Hati-hati dengan fungsi PostgreSQL yang memanggil binari bahasa C.
- Gunakan firewall untuk memblokir lalu lintas jaringan keluar dari database Anda ke Internet.
- Pastikan database Anda tidak ditetapkan dengan alamat IP publik. Jika ya, batasi akses hanya ke host yang berinteraksi dengannya (server aplikasi atau klien yang dimiliki oleh DBA).
Imperva juga melakukan berbagai tes antivirus bersama dengan perincian tentang bagaimana penyerang berpotensi menemukan server PostgreSQL yang rentan. Meskipun saya tidak memasukkannya di sini untuk singkatnya, lihat artikel untuk detail lengkap tentang temuan mereka.
Bacaan yang Disarankan
- Imperva memiliki 2 artikel sebelumnya yang menyertai Bagian 3 (yang dibahas di sini). Meskipun mereka tidak menargetkan PostgreSQL secara berat seperti yang baru saja kita bahas, bacaan tersebut sangat informatif:
- Bagian 1
- Bagian 2
- Serangan malware Scarlett Johansson PostgreSQL
- Peretas Menargetkan DB PostgreSQL Dengan Coinminer Tersembunyi di Gambar Scarlett Johannsson
- Utas Berita Peretas tentang eksploitasi.
Detail, Laporan, dan Kerentanan CVE
Saya mengunjungi situs ini, yang memposting ancaman keamanan terbaru berdasarkan vendor dan menemukan 4 kerentanan di Q1 tahun 2018. Halaman Informasi Keamanan PostgreSQL juga mencantumkannya, jadi silakan berkonsultasi dengan sumber tersebut.
Meskipun sebagian besar dari mereka telah dibahas, saya merasa penting untuk memasukkannya ke dalam posting ini untuk membawa kesadaran kepada pembaca yang mungkin belum mengetahuinya. Saya merasa kita bisa belajar dari mereka semua. Terutama dalam cara yang berbeda untuk menemukan kerentanan.
Mereka tercantum di bawah ini dalam urutan tanggal diterbitkan:
Aku. CVE-2018-1052 tanggal diterbitkan 2018-02-09 :Tanggal Pembaruan 3/10/2018
Ikhtisar:
Kerentanan pengungkapan memori dalam partisi tabel ditemukan di PostgreSQL 10.x sebelum 10.2, memungkinkan penyerang yang diautentikasi untuk membaca byte memori server yang berubah-ubah melalui penyisipan yang dibuat khusus ke tabel yang dipartisi.
Kerentanan ini telah diperbaiki dengan rilis PostgreSQL 10.2 yang dikonfirmasi di sini. Versi 9.x yang lebih lama juga telah diperbaiki, jadi kunjungi tautan itu untuk memeriksa versi spesifik Anda.
II. CVE-2018-1053 tanggal diterbitkan 2018-02-09 :Tanggal Pembaruan 15/3/2018
Ikhtisar:
Di PostgreSQL 9.3.x sebelum 9.3.21, 9.4.x sebelum 9.4.16, 9.5.x sebelum 9.5.11, 9.6.x sebelum 9.6.7 dan 10.x sebelum 10.2, pg_upgrade membuat file di direktori kerja saat ini yang berisi output dari `pg_dumpall -g` di bawah umask yang berlaku saat pengguna memanggil pg_upgrade, dan tidak di bawah 0077 yang biasanya digunakan untuk file sementara lainnya. Ini dapat memungkinkan penyerang yang diautentikasi untuk membaca atau memodifikasi satu file, yang mungkin berisi kata sandi database terenkripsi atau tidak terenkripsi. Serangan tidak dapat dilakukan jika mode direktori memblokir penyerang yang mencari direktori kerja saat ini atau jika umask yang berlaku memblokir penyerang yang membuka file.
Seperti CVE-2018-1052 sebelumnya, PostgreSQL 10.2 memperbaiki bagian kerentanan ini:
Pastikan semua file sementara yang dibuat dengan "pg_upgrade" tidak dapat dibaca di seluruh dunia
Banyak versi PostgreSQL yang lebih lama terpengaruh oleh kerentanan ini. Pastikan dan kunjungi tautan yang disediakan untuk semua versi yang terdaftar.
III. CVE-2017-14798 tanggal terbit 2018-03-01 :Update Date 26/3/2018
Ikhtisar:
Kondisi balapan dalam skrip init PostgreSQL dapat digunakan oleh penyerang yang dapat mengakses akun PostgreSQL untuk meningkatkan hak istimewa mereka untuk melakukan root.
Meskipun saya tidak dapat menemukan halaman tautan yang menyebutkan PostgreSQL versi 10, banyak versi lama yang disebutkan, jadi kunjungi tautan itu jika menjalankan versi lama.
Pengguna Suse Linux Enterprise Server mungkin tertarik dengan 2 artikel tertaut di sini dan di sini di mana kerentanan ini telah diperbaiki untuk skrip init versi 9.4.
IV. CVE-2018-1058 tanggal publish 2018-03-02 :Update Date 22/3/2018
Ikhtisar:
Sebuah cacat ditemukan dalam cara PostgreSQL mengizinkan pengguna untuk mengubah perilaku kueri untuk pengguna lain. Penyerang dengan akun pengguna dapat menggunakan kelemahan ini untuk mengeksekusi kode dengan izin pengguna super dalam database. Versi 9.3 hingga 10 terpengaruh.
Rilis pembaruan ini menyebutkan kerentanan ini dengan dokumen tertaut yang menarik yang harus dikunjungi semua pengguna.
Artikel ini memberikan panduan fantastis dari komunitas berjudul A Guide to CVE-2018-1058:Protect Your Search Path yang memiliki banyak sekali informasi mengenai kerentanan, risiko, dan praktik terbaik untuk memeranginya.
Saya akan melakukan yang terbaik untuk meringkas, tetapi kunjungi panduan untuk keuntungan, pemahaman, dan pemahaman Anda sendiri.
Ikhtisar:
Dengan munculnya PostgreSQL versi 7.3, skema diperkenalkan ke dalam ekosistem. Peningkatan ini memungkinkan pengguna untuk membuat objek di ruang nama yang terpisah. Secara default, ketika pengguna membuat database, PostgreSQL juga membuat skema publik di mana semua objek baru dibuat. Pengguna yang dapat terhubung ke database juga dapat membuat objek dalam skema publik database tersebut.
Bagian langsung dari panduan ini sangat penting (lihat artikel yang dikutip):
Skema memungkinkan pengguna untuk menamai objek, sehingga objek dengan nama yang sama dapat berada dalam skema yang berbeda dalam database yang sama. Jika ada objek dengan nama yang sama dalam skema yang berbeda dan pasangan skema/objek tertentu tidak ditentukan (yaitu schema.object), PostgreSQL memutuskan objek mana yang akan digunakan berdasarkan pengaturan search_path. Pengaturan search_path menentukan urutan pencarian skema saat mencari objek. Nilai default untuk search_path adalah $user,public di mana $user mengacu pada nama pengguna yang terhubung (yang dapat ditentukan dengan menjalankan SELECT SESSION_USER;).
Poin penting lainnya ada di sini:
Masalah yang dijelaskan dalam CVE-2018-1058 berpusat di sekitar skema "publik" default dan bagaimana PostgreSQL menggunakan pengaturan search_path. Kemampuan untuk membuat objek dengan nama yang sama dalam skema yang berbeda, dikombinasikan dengan cara PostgreSQL mencari objek dalam skema, memberikan kesempatan bagi pengguna untuk mengubah perilaku kueri untuk pengguna lain.
Di bawah ini adalah daftar tingkat tinggi yang direkomendasikan panduan penerapan praktik-praktik ini sebagaimana ditetapkan untuk mengurangi risiko kerentanan ini:
- Jangan izinkan pengguna membuat objek baru di skema publik
- Setel jalur_telusur default untuk pengguna basis data
- Setel search_path default di file konfigurasi PostgreSQL (postgresql.conf)
Injeksi SQL
Semua 'bertema keamanan ' Posting blog atau artikel SQL tidak dapat melabeli dirinya sendiri seperti itu tanpa menyebutkan injeksi SQL. Meskipun metode serangan ini sama sekali bukan imajinasi 'anak baru di blok ', itu harus disertakan.
SQL Injection selalu menjadi ancaman dan mungkin lebih dari itu di ruang aplikasi web. Basis data SQL apa pun -termasuk PostgreSQL- berpotensi rentan terhadapnya.
Meskipun saya tidak memiliki dasar pengetahuan yang mendalam tentang SQL Injection -juga dikenal sebagai SQLi- saya akan melakukan yang terbaik untuk memberikan ringkasan singkat, bagaimana hal itu berpotensi mempengaruhi server PostgreSQL Anda, dan pada akhirnya bagaimana mengurangi risiko menjadi mangsa. untuk itu.
Lihat tautan yang disediakan di akhir bagian ini, yang semuanya berisi banyak informasi, penjelasan, dan contoh di area yang tidak dapat saya komunikasikan secara memadai.
Sayangnya, ada beberapa jenis injeksi SQL dan semuanya memiliki tujuan yang sama untuk menyisipkan SQL ofensif ke dalam kueri untuk dieksekusi di database, mungkin awalnya tidak dimaksudkan atau dirancang oleh pengembang.
Input pengguna yang tidak bersih, pemeriksaan tipe yang dirancang dengan buruk atau tidak ada (validasi AKA), bersama dengan input pengguna yang tidak lolos, semuanya berpotensi membuat pintu terbuka lebar bagi calon penyerang. Banyak API pemrograman web memberikan perlindungan terhadap SQLi:misalnya, ORM (Object Relational Mapper), kueri berparameter, pemeriksaan tipe, dll... Namun, pengembang bertanggung jawab untuk melakukan segala upaya dan mengurangi skenario utama untuk injeksi SQL dengan menerapkan pengalihan dan mekanisme yang mereka miliki.
Berikut adalah saran penting untuk mengurangi risiko injeksi SQL dari Lembar Cheat Pencegahan Injeksi SQL OWASP. Pastikan dan kunjungi untuk detail lengkap tentang contoh penggunaan dalam praktik (lihat artikel yang dikutip).
Pertahanan Utama:
- Opsi 1:Penggunaan Pernyataan yang Disiapkan (dengan Kueri Berparameterisasi)
- Opsi 2:Penggunaan Prosedur Tersimpan
- Opsi 3:Validasi Masukan Daftar Putih
- Opsi 4:Keluar dari Semua Masukan yang Diberikan Pengguna
Pertahanan Tambahan:
- Juga:Menegakkan Hak Istimewa Terkecil
- Juga:Melakukan Validasi Input Daftar Putih sebagai Pertahanan Sekunder
Bacaan yang Disarankan:
Saya telah menyertakan artikel tambahan dengan banyak informasi untuk studi dan kesadaran lebih lanjut:
- Apa itu injeksi SQL? Barang lama tapi bagus ini bisa membuat aplikasi web Anda sakit
- Injeksi SQL (Wikipedia)
- Injeksi SQL (CLOUDFLARE)
- Injeksi SQL (w3schools.com)
- Lembar Curang Pencegahan Injeksi SQL
- Menguji Injeksi SQL
- Kerentanan Injeksi SQL dan Cara Mencegahnya
- Lembar Cheat Injeksi SQL
Hak Istimewa Peran Pascagres
Kami memiliki pepatah untuk sesuatu di sepanjang baris "Kami adalah musuh terburuk kami sendiri ."
Kami pasti dapat menerapkannya untuk bekerja dalam lingkungan PostgreSQL. Pengabaian, kesalahpahaman, atau kurangnya ketekunan juga merupakan peluang untuk serangan dan penggunaan yang tidak sah seperti yang sengaja diluncurkan.
Bahkan mungkin lebih dari itu, secara tidak sengaja memungkinkan akses, rute, dan saluran yang lebih mudah untuk dimanfaatkan oleh pihak yang melanggar.
Saya akan menyebutkan area yang selalu membutuhkan penilaian ulang atau penilaian ulang dari waktu ke waktu.
Hak istimewa peran yang tidak beralasan atau asing.
- PENGGUNA SUPER
- CREATROLE
- DIBUAT
- HIBAH
Penggabungan hak istimewa ini pasti layak untuk dilihat. SUPERUSER dan CREATROLE adalah perintah yang sangat kuat dan akan lebih baik disajikan di tangan DBA dibandingkan dengan analis atau pengembang, bukan begitu?
Apakah peran tersebut benar-benar membutuhkan atribut CREATEDB? Bagaimana dengan HIBAH? Atribut tersebut berpotensi disalahgunakan di tangan yang salah.
Pertimbangkan semua opsi sebelum mengizinkan peran atribut ini di lingkungan Anda.
Strategi, Praktik Terbaik, dan Pengerasan
Di bawah ini adalah daftar posting blog, artikel, daftar periksa, dan panduan berguna yang kembali untuk 'tahun lalu' (pada saat penulisan ini) dari hasil pencarian. Mereka tidak terdaftar dalam urutan kepentingan apa pun dan masing-masing menawarkan saran yang patut diperhatikan.
- Cara Sederhana untuk Melindungi Server Postgres Anda dari Vektor Serangan yang Tidak Mungkin:Gambar Jahat Scarlett Johansson
- Membantu Mengamankan Database PostgreSQL Anda
- Jangan keras kepala... Perkuat database PostgreSQL Anda untuk memastikan keamanan
- Cara Mengamankan Database PostgreSQL Anda - 10 Tips
- Mengamankan PostgreSQL Dari Serangan Eksternal
- Keistimewaan dan Keamanan PostgreSQL - Mengunci Skema Publik
Kesimpulan
Di blog ini, kami telah membahas masalah keamanan yang menjadi perhatian administrator PostgreSQL di seluruh dunia:termasuk injeksi SQL yang merupakan cawan suci dari semua insiden keamanan, kesalahan dalam pendekatan dasar untuk menangani data dengan aman seperti gagal mengencangkan izin dengan benar di seluruh infrastruktur Anda, dan juga beberapa masalah keamanan yang kurang diketahui yang mungkin diabaikan. Ketika menyangkut keamanan data kami, sangat penting bagi kami untuk mengambil dan menerapkan saran dari pihak tepercaya seperti Imperva dan sejenisnya yang memberi kami cara untuk melindungi diri kami sendiri baik dari serangan dasar maupun dari 0-hari (eksploitasi yang belum dikenal sebelumnya), karena saran yang bereputasi baik berarti masa depan yang baik untuk basis data dan infrastruktur kami secara keseluruhan.
Perlu diingat bahwa tindakan keamanan yang perlu kita ambil akan sangat bergantung pada kerentanan yang ingin kita lawan, tetapi secara umum, mengetahui semua pertahanan yang diperlukan untuk menangkis injeksi SQL, menggunakan dengan benar hak istimewa, dan selalu berusaha untuk mengurangi tingkat risiko kami yang berkaitan dengan kerentanan sangat penting. Tetap up-to-date dengan apa yang terjadi di ruang keamanan PostgreSQL akan membuat kami heran juga:kami hanya dapat mempertahankan server kami (dan, akibatnya, data kami) dengan baik jika kami tahu apa yang mungkin diincar penyerang.
Jika Anda mencari lebih banyak praktik terbaik untuk meningkatkan postur keamanan atau kinerja instalasi PostgreSQL Anda, buka ClusterControl:karena alat ini dikembangkan oleh pakar database terkemuka dari seluruh dunia, alat ini akan membuat database Anda bernyanyi dalam waktu singkat. Produk ini juga dilengkapi dengan uji coba gratis 30 hari, jadi pastikan Anda tidak ketinggalan untuk mencoba semua fitur yang dapat ditawarkan ClusterControl untuk bisnis Anda dan mencobanya hari ini.
Untuk konten lebih lanjut tentang bagaimana Anda harus mengamankan instance database PostgreSQL Anda, buka blog Somenines untuk mendapatkan saran:mempelajari cara mengotomatiskan audit keamanan untuk PostgreSQL pasti akan menjadi langkah ke arah yang benar. Pastikan untuk mengikuti kami di Twitter, LinkedIn, dan berlangganan umpan RSS kami untuk pembaruan lebih lanjut, dan sampai jumpa di yang berikutnya.
