Bagaimana Matasano diretas?


10

dari: http://seclists.org/fulldisclosure/2009/Jul/0388.html

Jika saya mengerti yang terbaik dari posting dari: http://news.ycombinator.com/item?id=723798 orang -orang Matasano meninggalkan internet sshd diakses - ada solusi yang diusulkan untuk ini (dari sudut pandang pemrograman)?


Nah, jika log itu benar, maka itu adalah masalah konfigurasi layanan terbuka dan tidak ada hubungannya dengan pemrograman apa pun.
blowdart

Jawaban:


34

Bagaimana Matasano diretas?

Itu tidak mungkin dijawab dari informasi di pos ke Pengungkapan Penuh. Namun selalu menarik untuk berspekulasi, karena mereka memberikan sedikit info -

# ./th3_f1n4l_s0lut10n www.matasano.com
[-] Menghubungkan ke 69.61.87.163:22 ..
[/] Mencari pengguna non-root yang valid .. adam
******** R3D4CT3D h4h4h4h4 ********

Mereka menjalankan " th3_f1n41_s01ut10n" biner mereka terhadap server Matasano, yang terhubung ke port ssh. Ia menemukan pengguna non-root yang valid melalui beberapa cara yang tidak diketahui, dan sisa output dihapus.

# ./th3_f1n4l_s0lut10n -u adam -t 3 www.matasano.com
[*] Pendengar Connectback pada 209.112.118.10:3338 ..
[!] SSH2_MSG_SERVICE_ACCEPT [OpenSSH_4.5p1, OpenSSL 0.9.8g 19 Okt 2007] 

Biner dijalankan lagi menggunakan nama pengguna yang ditemukan, yang masuk dan menghubungkan kembali ke server mereka pada port 3338 (harap itu tidak terdaftar atas nama mereka ...).

adam_at_www: ~ $ uname -a
Linux www 2.6.20.1-1-686 # 1 SMP Sun Mar 4 12:44:55 UTC 2007 i686 GNU / Linux
**** h4h4h4hh4h4h4 l3tz us3 m0r3! 0D4Y! H4H4H4H4H4H4H4 ****

Mereka mungkin menyiratkan mereka memiliki 0 hari terhadap kernel ini, yang cukup lama ketika Anda mempertimbangkan stock-in-trade perusahaan ini.

adam_at_www: ~ $ cd / tmp
*********** B0R1NG ***********
root_at_www: ~ # cat / etc / shadow 

Whoops - tiba-tiba pengguna sekarang root. Mereka memiliki exploit privilege eskalasi lokal di / tmp yang mungkin merupakan 0-hari yang mereka maksud.

Jadi setidaknya ada dua eksploitasi yang terjadi di sini - eksploitasi OpenSSH untuk mendapatkan pengguna non-root yang valid pada sistem, dan login sebagai pengguna itu, dan kemudian eskalasi privilege lokal.

Menimbang bahwa OpenSSH memiliki beberapa masalah keamanan yang diketahui sejak versi 4.5:

Dari halaman keamanan OpenSSH :

  • OpenSSH sebelum versi 5.2 rentan terhadap kelemahan protokol yang dijelaskan dalam CPNI-957037 "Plaintext Recovery Attack Against SSH". Namun, berdasarkan informasi terbatas yang tersedia, tampaknya serangan yang dijelaskan ini tidak mungkin dilakukan di sebagian besar keadaan. Untuk informasi lebih lanjut, lihat penasehat cbc.adv dan catatan rilis OpenSSH 5.2.
  • OpenSSH 4.9 dan yang lebih baru tidak mengeksekusi ~/.ssh/rcuntuk sesi yang perintahnya telah ditimpa dengan sshd_config (5) arahan ForceCommand. Ini adalah perilaku yang didokumentasikan, tetapi tidak aman (dijelaskan dalam catatan rilis OpenSSH 4.9).
  • OpenSSH 4.7 dan yang lebih baru tidak jatuh kembali ke pembuatan cookie otentikasi X11 yang tepercaya ketika pembuatan cookie yang tidak tepercaya gagal (misalnya karena kehabisan sumber daya yang disengaja), seperti yang dijelaskan dalam catatan rilis OpenSSH 4.7.

Saya kira memiliki kernel Linux yang lebih tua ini dan daemon SSH yang lebih tua lakukan untuk mereka. Juga, itu berjalan di server www mereka, yang tersedia untuk Internet, yang merupakan hal yang cukup percaya diri untuk dilakukan menurut pendapat saya. Orang-orang yang masuk jelas ingin mempermalukan mereka.

Bagaimana cara mencegah serangan ini?

Ini bisa dicegah dengan administrasi proaktif - memastikan semua layanan yang dihadapi internet ditambal, dan membatasi jumlah orang yang dapat terhubung daripada memungkinkan orang untuk terhubung dari mana saja. Episode ini menambah pelajaran bahwa mengamankan sistem administrasi sulit, dan membutuhkan dedikasi dari bisnis untuk menyediakan waktu bagi TI untuk menjaga hal-hal yang ditambal - pada kenyataannya, bukan sesuatu yang terjadi dengan mudah, setidaknya di perusahaan kecil.

Menggunakan pendekatan sabuk-dan-kawat gigi adalah yang terbaik - menggunakan otentikasi kunci publik, masuk daftar putih pada ssh daemon, otentikasi dua faktor, pembatasan IP, dan / atau meletakkan segala sesuatu di belakang VPN adalah rute yang memungkinkan untuk menguncinya.

Saya rasa saya tahu apa yang akan saya lakukan di tempat kerja besok. :)


2
Memerlukan kunci publik yang valid untuk dapat masuk melalui OpenSSH. Bukan bukti bodoh, tetapi membantu. Posting bagus btw.
Andrioid

Poin bagus, ditambahkan :)
Cawflands

1
Perlu ditunjukkan bahwa string versi OpenSSH masih jauh dari panduan yang dapat diandalkan mengenai apakah vunerabilites telah ditambal, karena berbagai perbaikan backporting versi linux. Juga, tidak ada bug di sini yang memungkinkan pengguna untuk masuk tanpa beberapa pembobol lain yang cukup serius.
Cian

3

Orang suka membuat FUD lebih dari itu, tetapi tampaknya mereka tahu bahwa pengguna adam sudah ada di sana dan tahu kata sandinya juga (mungkin melalui brute force atau metode lain). Namun, mereka ingin terlihat keren dan membuat keributan di seluruh.

Hal lain yang menarik untuk dicatat adalah bahwa pengguna adam belum masuk ke kotak itu selama lebih dari setahun:

(output dari lastlog)

 adam             pts/1    ool-4350ab48.dyn Sat Jul 26 20:45:18 -0400 2008

Jadi dia mungkin menyimpan kata sandi itu (mungkin yang buruk) untuk sementara waktu.

* Jika mereka benar-benar memiliki alat untuk menemukan nama pengguna melalui SSH, mereka bisa menggunakan semua pengguna lain untuk mendapatkan akses jarak jauh, tetapi mereka menggunakan nama pengguna yang paling umum di dalam kotak itu (mudah ditebak).


2

Mengapa Anda mencoba dan menyelesaikan ini dari sudut pandang pemrograman?

Anda sebaiknya menyelesaikannya dari sudut pandang server pintar-administrator. Ada beberapa saran bagus di komentar dari tautan yang Anda poskan, seperti menggunakan daftar putih.

Saya juga ingin menambahkan itu, karena Anda bertanya di sini, kemungkinan besar Anda bukan ahli keamanan, dan apa pun yang Anda pikirkan untuk ditulis hanya akan menambah lebih banyak lubang. Ini sebenarnya bukan pertanyaan pemrograman sama sekali.


satu saran adalah daftar putih?

yang masih bukan masalah pemrograman, ini masalah konfigurasi
blowdart


@Sneakyness Saya bukan ahli keamanan dengan cara apa pun - tapi terima kasih telah menunjukkannya - itulah saya ajukan pertanyaan ini, jadi saya bisa belajar - dan terima kasih karena berusaha menghalangi saya dari menulis tentang sesuatu yang ingin saya pelajari - apakah ini adalah pemrograman atau bukan pertanyaan progamming - Saya akan menyerahkannya kepada pakar keamanan untuk menjawab - Anda termasuk (Saya berasumsi Anda adalah orang yang didasarkan pada komentar pendidikan Anda)
user14898

2

Lindungi perangkat lunak Anda dari serangan 0 hari ... yang tidak mungkin.

Mungkin salah satu pendekatan yang baik adalah dengan mengklaim bahwa perangkat lunak Anda tidak dapat dibongkar, yang akan menyebabkan whitehats untuk mencobanya dan mengungkapkan semuanya secara penuh, meninggalkan lebih sedikit lubang. Oracle 10 memiliki klaim ini, kemudian pada hari berikutnya seperti 9 lubang baru ditemukan. Cukup aman sekarang.

Kemungkinan besar, peretas menyalahgunakan konfigurasi perangkat lunak yang sangat baik


Kami yakin ini bahkan nol hari?
Josh Brower

2

itu mengejutkan saya bahwa mereka memiliki begitu banyak pengguna dengan cangkang pada mesin itu. begitulah cara mereka dimiliki, semua yang lain adalah herring merah yang dimaksudkan untuk mengalihkan perhatian. salah satu dari mereka mendapatkan klien ssh mereka di pintu belakang pada beberapa mesin shell lain yang paling mungkin dan kemudian game usai. memberi semua orang akun shell dan membuat dunia sshdil diakses hanya malas dan bodoh.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.