Lubang keamanan terburuk yang pernah Anda lihat? [Tutup]

Apa lubang keamanan terburuk yang pernah Anda lihat? Mungkin ide yang baik untuk menjaga detail tetap terbatas untuk melindungi yang bersalah.

Untuk apa nilainya, inilah pertanyaan tentang apa yang harus dilakukan jika Anda menemukan celah keamanan, dan yang lain dengan beberapa jawaban yang berguna jika perusahaan tidak (tampaknya) merespons.

Dari hari-hari awal toko online:

Dapatkan diskon 90% dengan memasukkan 0,1 di bidang kuantitas keranjang belanja. Perangkat lunak dengan tepat menghitung total biaya sebagai biaya .1 *, dan manusia yang mengemas pesanan hanya menutupi "." di depan kuantitas untuk berkemas :)

Lubang keamanan yang paling tidak bisa dimaafkan, dan sayangnya yang sangat umum dan mudah ditemukan pada saat itu, adalah peretasan Google . Inti masalah:

http://www.google.com/search?q=inurl%3Aselect+inurl%3A%2520+inurl%3Afrom+inurl%3Awhere

Sungguh menakjubkan berapa banyak halaman di Internet, situs pemerintah khususnya, melewatkan kueri SQL melalui string kueri. Ini adalah bentuk terburuk dari injeksi SQL, dan tidak membutuhkan usaha sama sekali untuk menemukan situs yang rentan.

Dengan sedikit perubahan, saya dapat menemukan instalasi phpMyAdmin yang tidak dilindungi, instalasi MySQL yang tidak dilindungi, string permintaan yang berisi nama pengguna dan kata sandi, dll.

Rekayasa Sosial:

<Cthon98> hey, if you type in your pw, it will show as stars
<Cthon98> ********* see!
<AzureDiamond> hunter2
<AzureDiamond> doesnt look like stars to me
<Cthon98> <AzureDiamond> *******
<Cthon98> thats what I see
<AzureDiamond> oh, really?
<Cthon98> Absolutely
<AzureDiamond> you can go hunter2 my hunter2-ing hunter2
<AzureDiamond> haha, does that look funny to you?
<Cthon98> lol, yes. See, when YOU type hunter2, it shows to us as *******
<AzureDiamond> thats neat, I didnt know IRC did that
<Cthon98> yep, no matter how many times you type hunter2, it will show to us as *******
<AzureDiamond> awesome!
<AzureDiamond> wait, how do you know my pw?
<Cthon98> er, I just copy pasted YOUR ******'s and it appears to YOU as hunter2 cause its your pw
<AzureDiamond> oh, ok.

Dari bash.org

Kisah nyata dari awal saya di Microsoft.

Anda belum tahu ketakutan sampai hari Anda bangun dan melihat berita utama di ZDNet.com pagi itu adalah " Lubang Keamanan Internet Explorer Terburuk Yang Pernah Ditemukan Di 'Blah' " di mana 'Blah' adalah kode yang Anda tulis sendiri enam bulan sebelumnya .

Segera setelah mulai bekerja saya memeriksa log perubahan dan menemukan bahwa seseorang di tim lain - seseorang yang kami percayai untuk melakukan perubahan pada produk - telah memeriksa kode saya, mengubah sekelompok pengaturan kunci registri keamanan tanpa alasan yang baik, memeriksanya kembali, dan tidak pernah mendapat ulasan kode atau memberi tahu siapa pun tentang hal itu. Sampai hari ini saya tidak tahu apa yang dia pikir dia lakukan; dia meninggalkan perusahaan tidak lama kemudian. (Dengan kemauannya sendiri.)

(PEMBARUAN: Beberapa tanggapan terhadap masalah yang muncul dalam komentar:

Pertama, perhatikan bahwa saya memilih untuk mengambil posisi amal bahwa perubahan kunci keamanan tidak disengaja dan didasarkan pada kecerobohan atau ketidaktahuan, daripada kedengkian. Saya tidak memiliki bukti satu atau lain cara, dan percaya bahwa adalah bijaksana untuk menghubungkan kesalahan dengan kesalahan manusia.

Kedua, sistem checkin kami jauh, jauh lebih kuat sekarang daripada dua belas tahun yang lalu. Misalnya, sekarang tidak mungkin untuk memeriksa kode tanpa sistem checkin mengirim email daftar perubahan ke pihak yang berkepentingan. Secara khusus, perubahan yang dilakukan pada akhir siklus kapal memiliki banyak "proses" di sekitar mereka yang memastikan bahwa perubahan yang tepat sedang dilakukan untuk memastikan stabilitas dan keamanan produk.)

Ngomong-ngomong, bugnya adalah bahwa sebuah objek yang TIDAK aman untuk digunakan dari Internet Explorer telah secara tidak sengaja dirilis sebagai ditandai "aman untuk skrip". Objek itu mampu menulis file biner - perpustakaan tipe OLE Automation, pada kenyataannya - ke lokasi disk sewenang-wenang. Ini berarti bahwa penyerang dapat membuat pustaka jenis yang berisi string tertentu dari kode permusuhan, menyimpannya ke jalur yang dikenal sebagai lokasi yang dapat dieksekusi, memberinya ekstensi sesuatu yang akan menyebabkan skrip dijalankan, dan berharap bahwa entah bagaimana pengguna secara tidak sengaja akan menjalankan kode. Saya tidak tahu ada serangan "dunia nyata" yang berhasil yang menggunakan kerentanan ini, tetapi dimungkinkan untuk membuat eksploitasi yang berhasil dengannya.

Kami mengirimkan tambalan yang sangat cepat untuk yang itu, izinkan saya memberi tahu Anda.

Saya menyebabkan dan kemudian memperbaiki lebih banyak celah keamanan di JScript, tetapi tidak ada satupun yang bisa mendapatkan publisitas yang dekat.

Saya harap Anda dapat menemukan apa yang salah di sini. (Sebenarnya sangat salah):

String emailBody = "";

for (int i = 0; i < subscribers.Count; i++)
{
    emailBody += "Hello " + subscribers[i].FirstName + ",";
    emailBody += "this is a reminder with your account information: \n\n:";
    emailBody += "Your username: " + subscribers[i].Username + "\n";
    emailBody += "Your password: " + subscribers[i].Password + "\n";
    emailBody += "Have a great day!";

    emailDispatcher.Send(subscribers[i].EmailAddress, emailBody);
}

Penerima terakhir adalah yang paling bahagia;)

Terminal bodoh IBM System 36 yang lama memiliki kombinasi keyboard yang memulai perekaman makro. Jadi, ketika terminal tidak masuk, Anda bisa mulai merekam makro dan membiarkannya di posisi itu. Lain kali seseorang masuk, penekanan tombol akan direkam di makro dan rekaman akan berakhir secara otomatis ketika kunci maksimum yang diizinkan direkam. Cukup kembali lagi nanti dan memutar ulang makro ke autolog-in.

Lubang keamanan terburuk yang pernah saya lihat benar-benar dikodekan oleh Anda dan menyebabkan Google Bot menghapus seluruh database saya.

Kembali ketika saya pertama kali belajar ASP Klasik, saya membuat kode aplikasi blog dasar saya sendiri. Direktori dengan semua skrip admin dilindungi oleh NTLM pada IIS. Suatu hari saya pindah ke server baru dan lupa untuk melindungi kembali direktori di IIS (oops).

Halaman beranda blog memiliki tautan ke layar admin utama, dan layar admin utama memiliki tautan DELETE untuk setiap catatan (tanpa konfirmasi).

Suatu hari saya menemukan setiap catatan dalam database dihapus (ratusan entri pribadi). Saya pikir beberapa pembaca telah masuk ke situs dan dengan jahat menghapus setiap catatan.

Saya datang untuk mencari tahu dari log: Google Bot telah merayapi situs, mengikuti tautan admin, dan melanjutkan untuk mengikuti semua DELETE LINKS, dengan demikian menghapus setiap catatan dalam database. Saya merasa layak menerima penghargaan Dumbass of the Year karena secara tidak sengaja dikompromikan oleh Google Bot.

Untungnya saya punya cadangan.

Lubang terburuk yang pernah saya lihat adalah bug dalam aplikasi web di mana memberikan nama pengguna dan kata sandi kosong akan mencatat Anda sebagai administrator :)

Setelah melihat ini di URL situs web.

http://www.somewebsite.com/mypage.asp?param1=x&param2=y&admin=0

Mengubah parameter terakhir menjadi admin = 1 memberi saya hak admin. Jika Anda akan mempercayai input pengguna secara membuta setidaknya jangan mengirim telegraf bahwa Anda melakukannya!

Saya melihat ini di The Daily WTF .

<script language="javascript">
<!--//
/*This Script allows people to enter by using a form that asks for a
UserID and Password*/
function pasuser(form) {
    if (form.id.value=="buyers") { 
        if (form.pass.value=="gov1996") {              
            location="http://officers.federalsuppliers.com/agents.html" 
        } else {
            alert("Invalid Password")
        }
    } else {  
        alert("Invalid UserID")
    }
}
//-->
</script>

Tidak ada yang bisa mengalahkan IMHO ini.

Di universitas tidak kurang, yang akan tetap tanpa nama, mereka memiliki semua kueri tindakan yang dilewatkan melalui URL alih-alih formulir yang diposting.

Masalahnya berhasil sampai Google Bot datang dan menelusuri semua URL mereka dan menghapus database mereka.

Terkejut tidak ada yang mengungkit rekayasa sosial, tetapi saya berhasil menendang artikel ini .

Ringkasan: pengguna jahat dapat membeli beberapa lusin flash drive, memuatnya dengan virus atau trojan yang dijalankan secara otomatis, kemudian memercikkan flash drive tersebut di tempat parkir perusahaan larut malam. Keesokan harinya, semua orang muncul untuk bekerja, tersandung pada perangkat keras, berbentuk permen, tak tertahankan dan berkata pada diri mereka sendiri "oh wow, flash drive gratis, saya ingin tahu ada apa di dalamnya!" - 20 menit kemudian seluruh jaringan perusahaan disemprot.

"Pedo mellon a minno" , "Bicaralah teman dan masuk", di gerbang Moria.

Microsoft Bob
(Kredit: Abandonware Abad ke-20 Dan )

Jika Anda memasukkan kata sandi yang salah untuk ketiga kalinya, Anda ditanya apakah Anda lupa kata sandi.

http://img132.yfrog.com/img132/8397/msbob10asignin15.gif

Tetapi alih-alih memiliki keamanan, seperti terus meminta kata sandi yang benar sampai kata sandi itu dimasukkan atau mengunci Anda setelah beberapa upaya salah, Anda dapat memasukkan kata sandi baru dan itu akan menggantikan yang asli! Siapa pun dapat melakukan ini dengan akun Microsoft Bob yang dilindungi kata sandi.

Tidak diperlukan otentikasi sebelumnya. itu berarti User1 dapat mengubah kata sandi mereka sendiri hanya dengan salah ketik kata sandi mereka tiga kali lalu memasukkan kata sandi baru untuk keempat kalinya - tidak pernah harus menggunakan "ubah kata sandi."

Ini juga berarti bahwa User1 dapat mengubah kata sandi User2, User3 ... dengan cara yang persis sama. Setiap pengguna dapat mengubah kata sandi pengguna lain hanya dengan salah ketik tiga kali lalu memasukkan kata sandi baru saat diminta - dan kemudian mereka dapat mengakses akun.

http://img132.yfrog.com/img132/9851/msbob10asignin16.gif

Saya memiliki alamat rumah mantan Joe X, dan perlu tahu alamatnya yang sekarang lebih baru di kota yang sama, tetapi tidak memiliki cara untuk menghubunginya. Saya pikir dia menerima tumpukan katalog pesanan surat harian, jadi saya secara sewenang-wenang memanggil nomor 800 untuk Permen See's (sebagai lawan dari Victoria's Secret, atau Swiss Colony, atau pengirim surat besar lainnya):

Saya: "Hai, saya Joe X. Saya pikir Anda sudah memasukkan saya ke mailing list dua kali, di alamat lama dan alamat baru saya. Apakah komputer Anda menunjukkan kepada saya di [alamat lama] atau di [alamat palsu] ? "

Operator: "Tidak, kami tunjukkan di [alamat baru]."

Memberi 1 = 1 dalam kotak teks mencantumkan semua pengguna dalam sistem.

Menjadi konsultan keamanan aplikasi untuk mencari nafkah ada banyak masalah umum yang memungkinkan Anda mendapatkan admin di situs web melalui sesuatu. Tetapi bagian yang sangat keren adalah ketika Anda dapat membeli kaus kaki bernilai satu juta dolar.

Itu adalah teman saya yang mengerjakan pertunjukan ini, tetapi intinya adalah bahwa harga untuk barang-barang di toko buku online tertentu yang sekarang sangat populer (dan yang lainnya) disimpan dalam HTML itu sendiri sebagai bidang tersembunyi. Kembali pada hari-hari awal bug ini menggigit banyak toko online, mereka baru saja mulai mencari tahu web. Kesadaran keamanan sangat kecil, maksud saya benar-benar siapa yang akan mengunduh HTML, mengedit bidang tersembunyi dan mengirim ulang pesanan?

Tentu saja kami mengubah harga menjadi 0 dan memesan 1 juta pasang kaus kaki. Anda juga dapat mengubah harga menjadi negatif tetapi melakukan ini membuat beberapa bagian dari buffer overflow penagihan perangkat lunak akhir mereka mengakhiri transaksi.

Jika saya bisa memilih yang lain itu akan menjadi jalur masalah kanonikisasi dalam aplikasi web. Sangat menyenangkan bisa melakukan foo.com?file=../../../../etc/passwd

Melakukan password root database ke kontrol sumber secara tidak sengaja. Itu sangat buruk, karena itu adalah kontrol sumber pada Sourceforge.

Tidak perlu dikatakan kata sandi diubah dengan sangat cepat.

Tidak mengubah kata sandi admin ketika karyawan TI utama meninggalkan perusahaan.

Meskipun ini bukan lubang keamanan terburuk yang pernah saya lihat. Tapi ini setidaknya yang terburuk yang kutemukan:

Toko online yang cukup sukses untuk buku audio menggunakan cookie untuk menyimpan informasi identifikasi pengguna saat ini setelah otentikasi berhasil. Tetapi Anda dapat dengan mudah mengubah ID pengguna dalam cookie dan mengakses akun lain dan membelinya.

Tepat di awal era .com, saya bekerja untuk pengecer besar di luar negeri. Kami menyaksikan dengan penuh minat ketika pesaing kami meluncurkan toko online berbulan-bulan sebelum kami. Tentu saja, kami pergi untuk mencobanya ... dan dengan cepat menyadari bahwa gerobak belanja kami sedang campur aduk. Setelah bermain dengan string kueri sedikit, kami menyadari bahwa kami dapat saling membajak sesi. Dengan waktu yang tepat, Anda dapat mengubah alamat pengiriman tetapi meninggalkan metode pembayaran sendiri ... semua itu setelah mengisi keranjang dengan barang favorit Anda.

Ketika saya pertama kali bergabung dengan perusahaan tempat saya bekerja saat ini, bos saya mencari situs web e-commerce yang ada dari calon klien baru. Ini pada hari-hari awal IIS dan e-commerce, dan keamanannya, harus kita katakan, kurang ketat.

Untuk mempersingkat cerita, dia mengubah URL (hanya karena penasaran), dan menyadari bahwa penelusuran direktori tidak dimatikan, jadi Anda bisa memotong nama halaman di bagian akhir URL dan melihat semua file di server web.

Kami akhirnya menjelajahi folder yang berisi database Access, yang kami unduh. Itu adalah seluruh basis data pelanggan / pesanan e-commerce, penuh dengan beberapa ribu nomor kartu kredit yang tidak dienkripsi.

Orang-orang memposting kata sandi mereka di situs web publik ...

Ketika saya berusia 13 tahun sekolah saya membuka jejaring sosial untuk para siswa. Sayangnya untuk mereka saya menemukan bug keamanan di mana Anda dapat mengubah URI ke userID lain seperti "? UserID = 123" dan menjadi masuk untuk pengguna itu. Jelas saya memberi tahu teman-teman saya, dan pada akhirnya jaringan sosial sekolah dipenuhi dengan porno.

Tidak akan merekomendasikan hotel ini.

Saya pikir bidang nama pengguna / kata sandi kosong untuk akses pengguna super sejauh ini adalah yang terburuk. Tapi yang saya lihat sendiri adalah

if (password.equals(requestpassword) || username.equals(requestusername))
{
    login = true;
}

Sayang sekali satu operator membuat perbedaan besar.

Milik saya akan untuk bank saya adalah pelanggan. Saya tidak bisa masuk, jadi saya menelepon layanan pelanggan. Mereka menanyakan nama pengguna saya dan tidak ada yang lain - tidak mengajukan pertanyaan keamanan atau mencoba memverifikasi identitas saya. Kemudian alih-alih mengirim setel ulang kata sandi ke alamat email yang mereka miliki di file, mereka bertanya kepada saya apa alamat email untuk mengirimnya. Saya memberi mereka alamat yang berbeda dari yang saya miliki di file, dan dapat mengatur ulang kata sandi saya.

Jadi intinya, yang dibutuhkan seorang hacker adalah nama pengguna saya, dan dia kemudian dapat mengakses akun saya. Ini untuk bank besar yang akan didengar oleh setidaknya 90% orang di Amerika Serikat. Ini terjadi sekitar dua tahun lalu. Saya tidak tahu apakah itu perwakilan layanan pelanggan yang kurang terlatih atau apakah itu prosedur standar.

Saya akan membagikan yang saya buat. Agak.

Bertahun-tahun yang lalu perusahaan tempat saya bekerja ingin pengindeksan di situs web ASP mereka. Maka saya pergi dan mengatur Server Index, mengecualikan beberapa direktori admin dan semuanya baik-baik saja.

Namun tidak diketahui oleh saya, seseorang telah memberi orang penjualan akses ftp ke server web sehingga ia dapat bekerja dari rumah, ini adalah hari-hari dialup dan itu adalah cara termudah baginya untuk bertukar file .... dan ia mulai mengunggah sesuatu, termasuk dokumen yang merinci markup pada layanan kami .... yang server indeks diindeks dan mulai melayani ketika orang mencari "Biaya".

Ingat anak-anak, daftar putih bukan daftar hitam.

Salah satu yang paling sederhana, namun benar-benar layak biaya adalah:

Sistem pembayaran yang menggunakan mesin seperti PayPal dapat cacat karena respons balik dari PayPal setelah pembayaran berhasil tidak diperiksa sebagaimana mestinya.

Sebagai contoh:

Saya bisa pergi ke beberapa situs web pembelian CD dan menambahkan beberapa konten ke troli, lalu selama tahap checkout biasanya ada formulir pada halaman yang telah diisi dengan bidang untuk paypal, dan tombol kirim ke "Bayar" ..

Menggunakan Editor DOM saya bisa masuk ke formulir "hidup" dan mengubah nilai dari £899.00ke £0.01dan kemudian klik kirim ...

Ketika saya berada di sisi PayPal, saya dapat melihat bahwa jumlahnya adalah 1 sen, jadi saya membayarnya dan PayPal mengalihkan beberapa parameter ke situs pembelian awal, yang hanya memvalidasi parameter seperti payment_status=1, dll., Dll. Dan tidak memvalidasi jumlah yang dibayarkan.

Ini bisa mahal jika mereka tidak memiliki cukup penebangan di tempat atau produk dikirim secara otomatis.

Jenis situs terburuk adalah situs yang mengirimkan aplikasi, perangkat lunak, musik, dll.

Bagaimana dengan manajer dokumen online, yang diizinkan untuk mengatur setiap izin keamanan yang dapat Anda ingat ...

Itu sampai Anda tiba di halaman unduh ... unduh.aspx? DocumentId = 12345

Ya, documentId adalah ID basis data (peningkatan otomatis) dan Anda bisa mengulang setiap nomor dan siapa pun bisa mendapatkan semua dokumen perusahaan.

Ketika diberitahu untuk masalah ini, respons manajer proyek adalah: Oke, terima kasih. Tapi tidak ada yang memperhatikan ini sebelumnya, jadi mari kita simpan apa adanya.

Pengiriman pizza Norwegia memiliki celah keamanan di mana Anda dapat memesan pizza negatif dalam jumlah banyak di portal internet baru dan mengkilap dan mendapatkannya secara gratis.