it-swarm-id.com

Mengapa pertahanan kebingungan OS terhadap "Ini adalah sistem Unix!" tidak diimplementasikan secara luas?

The Adegan Jurassic Park yang dirujuk dalam judul terkenal karena betapa menggelikannya terdengar bagi mereka yang melek teknologi. Tetapi itu juga menggambarkan apa yang menurut saya merupakan lubang yang sangat besar dalam keamanan web, khususnya perangkat IoT - segera setelah penyerang mengetahui server atau kamera atau monitor bayi sedang menjalankan linux, mereka langsung tahu banyak tentang cara kerjanya. Mereka tahu bahwa perintah seperti Sudo adalah target besar dan mereka tahu bahwa akses Shell akan membawa sekumpulan alat yang bermanfaat seperti ls dan cat.

Jadi mengapa OS tidak lebih membingungkan? Saya tidak berbicara tentang hanya menyembunyikan versi di header web. Mirip dengan JavaScript minifikasi atau kebingungan, saya sedang berbicara tentang mengubah nama binari dan filepath di OS itu sendiri. Bukankah seluruh kelas serangan akan sia-sia jika OS memiliki ha7TrUO dan RRI6e29 perintah alih-alih Sudo dan ls? Bayangkan seorang hacker yang entah bagaimana memperoleh akses root jarak jauh - apa yang akan mereka lakukan jika mereka tidak tahu perintah?

Implementasi akan cukup mudah untuk kompiler. Ambil kasus paling sederhana "ganti nama fungsi ini dan semua panggilan ke sana." Anda bisa memberikan kompiler OS dan kompiler aplikasi nama acak yang sama dan mereka akan dapat berbicara satu sama lain. Tetapi bahkan jika aplikasi memiliki keamanan yang buruk dan rentan terhadap injeksi bash, serangan seperti itu tidak akan membuahkan hasil.

Jelas teknik ini tidak dapat digunakan di semua skenario. Mengesampingkan skenario seperti server yang dikelola oleh sysadmin manusia, bagi saya tampaknya setiap perangkat atau server yang dikelola oleh otomatisasi adalah kandidat utama untuk pertahanan ini.

Saya kira pertanyaannya harus lebih konkret:

  1. Apakah OS kebingungan seperti yang dijelaskan digunakan secara luas dan saya belum menemukannya?
  2. Jika tidak digunakan secara luas, apa hambatan praktis atau teknis untuk penggunaan?
156
Indigenuity

Sebelum saya memisahkan ide Anda, izinkan saya mengatakan bahwa itu adalah ide yang sangat menarik dan itu sangat menyenangkan untuk dipikirkan.

Silakan lanjutkan berpikir di luar kotak dan ajukan pertanyaan menarik!

Baiklah, mari kita lakukan ini!


Mari kita mundur dan bertanya mengapa monitor bayi itu menjalankan Linux? Bagaimana jika tidak ada sistem operasi dan aplikasi ditulis dalam kode mikrokontroler telanjang (pikirkan kode Arduino)? Maka tidak akan ada Sudo atau ls atau bahkan Shell untuk digunakan penyerang, bukan?

Saya bukan ahli di sini, tetapi saya berharap bahwa kita, sebagai sebuah industri, telah tertarik untuk menempatkan Linux pada sesuatu yang cukup besar untuk menjalankannya terutama untuk kenyamanan pengembang:

  1. Mengurangi waktu dev: Saat membuat whizpopper self-patching cloud-syncing yang diadministrasikan-WiFi-dan-Bluetooth-mampu-rumah Anda dengan pendamping Android dan aplikasi iOS, Linux dilengkapi dengan semua perpustakaan, utilitas, dan driver yang perlu Anda lakukan bahwa.
  2. Meningkatkan testabilitas: Jika perangkat menjalankan bash atau busybox dengan port SSH, maka sangat mudah untuk terhubung dan mencari tahu apa yang salah selama fase pengujian produk Anda.

Agar ide kebingungan Anda bekerja, Anda harus mengaburkan tidak hanya nama-nama utilitas baris perintah seperti Sudo dan ls, tetapi juga setiap API kernel Linux untuk mencegah penyerang menjatuhkan biner yang dikompilasi sendiri yang memanggil kernel secara langsung. Jadi mari kita lihat lagi ide Anda:

Implementasi akan cukup mudah untuk kompiler. Ambil kasus paling sederhana "ganti nama fungsi ini dan semua panggilan ke sana." Anda bisa memberikan kompiler OS dan kompiler aplikasi nama acak yang sama dan mereka akan dapat berbicara satu sama lain.

Anda harus melakukan kompilasi acak ini sendiri; kalau tidak, seseorang bisa mencari pemetaan di google.

Jadi, Anda harus membangun kernel dari sumber dengan "kompiler mengaburkan" Anda sehingga hanya Anda yang tahu pemetaan API kernel yang dikaburkan. (pernah membangun kernel linux dari source? Ini tentunya lebih banyak tugas daripada docker pull Alpine, yang merupakan arah yang tampaknya akan dituju oleh budaya dev) .

Tetapi sistem operasi lebih dari sekadar kernel. Anda ingin driver untuk chip wifi Broadcom BCM2837 yang datang pada perangkat mini-pc itu? Anda harus membangun driver itu terhadap kernel ofbuscated Anda dengan kompiler Anda, jika Broadcom bahkan akan memberi Anda kode sumber. Daripada Anda harus membangun seluruh wifi GNU dan tumpukan perangkat lunak jaringan. Berapa banyak hal lain yang perlu Anda cari sumbernya dan tambahkan apakah pipeline build Anda sebelum Anda memiliki OS yang berfungsi?

Oh, dan jika repo hulu dari hal-hal itu mengeluarkan tambalan, Anda sekarang bertanggung jawab untuk membangunnya kembali (dengan asumsi Anda menyimpan file pemetaan kebingungan penyusun yang cocok dengan binary kernel Anda) dan mendorongnya ke perangkat Anda karena - sesuai desain - perangkat Anda tidak dapat menggunakan patch binary yang diproduksi oleh vendor.

Oh, dan untuk menggagalkan peretas, tidak akan ada ini "Ini file biner untuk Whizpopper 1.4.7" , oh tidak, Anda Anda perlu membuat versi yang unik dari semuanya mulai dari kernel ke atas per perangkat yang Anda kirimkan.


Jadi untuk pertanyaan Anda:

  1. Apakah OS kebingungan seperti yang dijelaskan digunakan secara luas dan saya belum menemukannya?
  2. Jika tidak digunakan secara luas, apa hambatan praktis atau teknis untuk penggunaan?

Saya pikir jawabannya adalah bahwa apa yang Anda gambarkan cukup banyak benar-benar mengalahkan tujuan menggunakan komponen perangkat lunak yang sudah ada jika Anda perlu menemukan dan membangun semuanya dari sumber. Mungkin sebenarnya kurang usaha untuk membuang sistem operasi sepenuhnya, berpura-pura tahun 1960, dan menulis aplikasi Anda langsung dalam mikrokode CPU.

Saya lebih menyukai keamanan daripada kebanyakan pengembang, tetapi suka f * that .

235
Mike Ounsworth

Jawaban Mike mengatakan pada dasarnya semua yang saya tawarkan tentang mengapa ini adalah ide yang buruk dari perspektif pengembangan (dan, seperti komentar Ghedipunk, fitur keamanan yang tidak dapat digunakan tidak menyediakan keamanan). Jadi sebagai gantinya, saya akan berbicara tentang mengapa dari perspektif keamanan , Anda tidak akan pernah melakukan ini.

Jawabannya sebenarnya sangat sederhana: itu buang-buang waktu, dan ada opsi yang lebih baik. Setiap doodad IoT bodoh (ingat, "s" di "IoT" adalah singkatan dari Secure) yang tidak repot untuk mengimplementasikan fitur-fitur seperti itu pasti tidak akan pergi dengan pendekatan seperti yang Anda sarankan.

  1. Seluruh ide tidak akan berfungsi untuk membatasi panggilan sistem. Seorang penyerang hanya dapat mengatur beberapa register dan menjalankan opcode dan boom, mereka berada di kernel yang menjalankan syscall pilihan mereka; siapa yang peduli apa nama simbolis itu? Tentu, Anda dapat mengutak-atik tabel syscall untuk memperumit ini (jika Anda tidak keberatan perlu mengkompilasi ulang semuanya dan menjadikan debugging kernel khusus Anda sebagai bentuk yang sangat sulit) tetapi itu seperti mengaburkan OS yang digunakan; mengapa repot-repot ketika ada begitu sedikit kandidat, bagaimana pun? Bahkan jika penyerang tidak ingin merekayasa balik kode yang ada pada sistem, brute-forcing harus dimungkinkan kecuali ruang pencarian indeks panggilan yang dapat digunakan lebih luas daripada yang pernah saya lihat pada sistem tertanam.
  2. Mengapa mengaburkan nama perintah ketika Anda bisa membuatnya sepenuhnya tidak dapat diakses? A chroot tidak akan berfungsi untuk built-in Shell jika Anda menjalankan Shell , tetapi berfungsi dengan baik untuk semua yang lain dan sungguh, mengapa aplikasi serba guna yang dibuat khusus Anda menjalankan shell? Maksudku, unit dev akan memiliki satu diinstal, untuk tujuan pengujian, dan mungkin itu tidak dihapus dalam gambar ritel Anda karena Anda malas atau berpikir Anda akan membutuhkannya lagi. Tetapi seorang penyerang tidak akan bisa menjalankannya dari konteks yang dijalankan oleh aplikasi tersebut. chroot sederhana (atau kotak pasir/penjara/wadah yang lebih rumit) dapat membuat program tidak dapat dijalankan - atau bahkan mengakses - file apa pun di luar yang diperlukan untuk pekerjaannya.
  3. Mengapa mengaburkan API kernel ketika Anda bisa menghapus aksesnya? Ada sejumlah sistem kotak pasir yang dapat membatasi apa yang bisa disebut proses (atau turunannya ... jika diizinkan untuk membuat apa pun) dapat membuatnya. Lihat https://stackoverflow.com/questions/2146059/limiting-syscall-access-for-a-linux-application
88
CBHacking

Jika tujuan Anda adalah untuk menghilangkan penyerang ls dan cat, ada alternatif yang lebih baik untuk kebingungan: jangan menginstal utilitas itu.

Meskipun saya tidak akan mengatakan ini adalah pendekatan implementasi secara luas , setidaknya ini adalah implementasi. Sebagai contoh pertimbangkan distroless , koleksi gambar buruh pelabuhan dengan tidak ada apa-apa di dalamnya. Beberapa dari mereka (seperti yang pergi) benar-benar tidak memiliki di dalamnya. Serangan pada sistem yang berjalan dalam wadah seperti itu tidak bisa mendapatkan akses Shell karena tidak ada Shell yang dijalankan.

Satu-satunya cara untuk mendapatkan akses Shell dengan menyerang aplikasi dalam wadah tersebut adalah dengan menghindari runtime kontainer, yang dirancang untuk mencegah hal itu.

Sementara saya memberi contoh gambar buruh pelabuhan, konsep yang sama dapat diterapkan pada sistem operasi secara umum. Sebagai contoh, ls dan cat adalah bagian dari paket coreutils dalam Debian. Anda dapat menjalankan apt-get remove coreutils dan yakinlah seorang penyerang tidak akan dapat menggunakan ls atau cat sebagai bagian dari serangan. Tentu saja ini berarti Anda tidak dapat menggunakannya juga, dan mungkin ada banyak hal lain yang bergantung pada coreutils yang juga harus dihapus, tetapi untuk perangkat tertanam atau server yang melakukan hanya satu hal itu mungkin oke.

Prinsip umum adalah mengurangi "permukaan serangan": semakin banyak "barang" yang dimiliki target, semakin mudah untuk dikompromikan. Barang-barang itu bisa berupa port jaringan terbuka, baris kode, atau binari yang diinstal. Jika meningkatkan keamanan adalah tujuannya, maka menghapus semua "barang" yang tidak perlu adalah awal yang baik.

30
Phil Frost

Karena kebingungan bukanlah keamanan dan karena kebingungan OS pada dasarnya adalah omong kosong.

Hanya ada begitu banyak OS umum, dan begitu banyak cara untuk membuat tebakan yang terpelajar. Jika Anda mendeteksi bahwa saya menjalankan IIS atau MSSQL Server, Anda memiliki satu tebakan pada OS apa yang berjalan di bawahnya.

Bahkan jika saya entah bagaimana berhasil menjalankan tumpukan yang tidak memberi tahu Anda tentang OS yang mendasarinya, dan juga menutupi setiap petunjuk lainnya (sidik jari adalah suatu hal), saya masih belum menang banyak.

Dari segi keamanan, Anda tahu bahwa saya menjalankan Linux, atau bahkan saya menjalankan Debian 8, tidak memberi Anda banyak hal untuk dikerjakan atau saya terlalu khawatir. Jika saya dikeraskan dan ditambal dengan benar, Anda bisa tahu apa pun yang Anda inginkan. Jika saya berada di level patch yang telah diterapkan ke museum perangkat lunak kemarin, rangkaian serangan Anda akan membuat saya terbuka lebar hanya dengan mencoba semuanya, dan mengaburkan OS saya hanya memaksa Anda untuk mencoba beberapa eksploitasi yang tidak berguna lagi. Dalam serangan otomatis, itu akan memperlambat Anda semua beberapa detik.

Kebingungan tidak berhasil. Orang-orang dapat memindai Anda, sidik jari Anda, atau hanya membuang seluruh pustaka eksploitasi mereka untuk melihat apa yang berhasil.

Jika Anda membuang waktu untuk apa yang bisa Anda habiskan untuk pengerasan yang sebenarnya, Anda sebenarnya membahayakan keamanan Anda.

Pekerjaan pengerasan yang tepat. Saya katakan di atas bahwa "Anda bisa tahu apa pun yang Anda inginkan" . Saya telah memposting alamat IP saya dan kata sandi root di konferensi keamanan tempat saya memberikan pidato. SSH dengan login root jarak jauh dan sekelompok layanan diaktifkan. Mesin SELinux yang dikeraskan dengan serius. Tidak ada yang pernah berhasil mengganggu pembicaraan saya, meskipun satu orang pernah berhasil menjatuhkan file teks ke direktori root ketika kebijakan saya belum sempurna.


Tambahan: Titik awal Anda adalah film. Kebingungan adalah alat film yang hebat karena wahyu seperti itu memberi tahu pemirsa bahwa pahlawan (atau penjahat) menemukan beberapa informasi dan dengan demikian membuat kemajuan. Ini komputer yang setara dengan mencari tahu di mana brankas itu berada, meskipun Anda masih membutuhkan kodenya. Tidak masalah apakah itu benar secara faktual, jika itu menyampaikan pesan emosional yang tepat kepada audiens.

13
Tom

Untuk contoh yang sangat luas, Intel Management Engine, yang memiliki OS sendiri, melakukan sesuatu seperti itu, di mana terdapat mekanisme pembaruan firmware, tetapi firmware harus dalam format yang sangat spesifik dengan rincian yang dirahasiakan. Tampaknya melibatkan pengodean Huffman dengan parameter yang tidak diketahui. Demikian pula dengan proposal Anda (yang pada dasarnya adalah enkripsi firmware simetris), ME memerlukan modifikasi spesifik pada waktu persiapan firmware dan memiliki penyimpangan yang cocok dari mekanisme standar pada waktu pelaksanaan.

7
Roman Odaisky

Apa yang Anda gambarkan disebut "Keamanan melalui Kekaburan" dan merupakan keamanan yang dikenal luas antipattern . Berarti itu bukan ide baru, melainkan itu adalah ide lama dan buruk, bahwa orang-orang yang belum mengetahui filosofi keamanan harus dididik agar tidak jatuh ke dalam.

Bayangkan Anda merancang rumah agar aman, dan mengira ketidakjelasan adalah strategi yang menjanjikan. Semua rumah dibangun dari lorong dan kamar, pintu dengan gagang pintu, sakelar lampu, dll. Karena ini sudah umum diketahui, Anda mungkin berpendapat bahwa ini tidak aman karena penyusup dapat dengan mudah menavigasi rumah dengan elemen-elemen konstruksi yang dikenal umum ini. Anda dapat mencoba mendesain ulang prinsip-prinsip konstruksi dari awal, mengganti kenop pintu dengan batu rubiks, membuat langit-langit setinggi setengahnya untuk membingungkan pengganggu dll. Anda berakhir dengan sebuah rumah yang mengerikan untuk ditinggali, tidak dapat dipertahankan karena tidak ada kontraktor yang menginginkan apa pun. harus dilakukan dengan itu, dan yang terburuk dari semuanya itu tidak ada artinya karena setiap penyusup, begitu masuk, dapat melihat-lihat dengan matanya dan menggunakan otaknya untuk mencari tahu. Peretas adalah pecandu puzzle.

Solusi untuk mengamankan rumah Anda adalah tidak memiliki konstruksi yang tidak standar, itu harus memiliki kunci yang lebih baik, jendela yang aman, sistem keamanan yang tepat, dll. Anda tidak ingin menyembunyikan emas Anda di lorong rahasia, karena pada akhirnya Abbas dan Costello akan bersandar pada kandil itu dan membukanya secara tidak sengaja. Letakkan emas Anda di brankas dengan kombinasi rahasia yang baik dan alarm perusak. Setara komputer memiliki akses kredensial terbatas oleh kriptografi kunci publik, peran akses pengguna terbatas, sistem pemantauan, mengurangi luas permukaan yang terbuka, mitigasi vektor ancaman masuk, dll.

Upaya untuk membuat sistem komputer lebih tidak jelas hanya membuat sistem Anda semakin jauh dari dukungan, lebih sulit diperoleh keamanan tambalan, lebih sulit untuk digunakan dengan cara yang aman .

Sunting: Terkadang, beberapa keamanan melalui ketidakjelasan dapat diterima, bila digunakan selain keamanan yang sebenarnya. Contoh umum menjalankan SSH pada port tinggi seperti 30000 sesuatu. SSH dienkripsi, dan akses berada di belakang otentikasi kredensial, itulah keamanan Anda yang sebenarnya. Tetapi memilikinya pada port yang tinggi hanya membuatnya kurang terlihat untuk memulai jika seseorang melakukan pemindaian cepat. Apa pun yang lebih berbelit-belit dari ini, seperti mencoba mengaburkan OS Anda, hanya akan membuatnya menjadi mimpi buruk operasional, yang akan membuat langkah-langkah keamanan aktual (seperti up to date di patch) lebih sulit.

5
user1169420

Pikirkan useability

  • Coba jelaskan kepada sysadmin baru Anda bahwa ia harus menekan ha7TrUO insetead of Sudo, RRI6e29 alih-alih ls dan seterusnya ... Ya, ada daftar terjemahan yang harus Anda pelajari !
  • menjelajah jaringan lokal juga tidak mungkin: Anda harus memelihara daftar kertas untuk menjaga tampilan keseluruhan !?

  • Jika Anda mengganti nama semua perintah penting, Anda harus mengendarainya untuk melakukan peningkatan sistem!

  • Dan sebagai Nick2253 komentar , Jika Anda mencoba membangun sistem embed, maka lakukan kebingungan sebelum menerbitkan produk akhir, Anda harus menguji produk akhir.

    • Anda harus membuat home made skrip untuk mengikat semuanya untuk kebingungan.
    • Jika terjadi kesalahan, debugging akan menjadi rumit.
    • Anda harus membuat home made skrip deobfuscation, agar dapat melakukan debugging.
    • Umpan balik khusus (dengan file log) harus juga terhapus.

    Dengan melakukan itu, Anda akan menambahkan lapisan pekerjaan penting dengan potensi bug baru.

    Untuk sedikit peningkatan keamanan, lihat lebih lanjut

Ketidakjelasan dapat membahayakan diri Anda sendiri.

Pikirkan level lebih rendah

  • Bahkan jika Anda mencoba untuk mengganti nama file, berfungsi pada level aplikasi dan os, semua ini akan menggunakan perpustakaan standar yang akan dipanggil secara langsung jika penyerang mengirim file biner yang dapat dieksekusi. Anda bahkan dapat mempertimbangkan mengaburkan semua perpustakaan standar! (Termasuk sistem file, protokol jaringan ...)

  • Saat Anda menggunakan kernel yang tidak dimodifikasi, mereka akan menggunakan standar variabel dan ruang nama. Jadi, Anda harus membuat versi yang dikaburkan dari kernel ...

... Kalau begitu ikat semuanya!

Yah, bahkan ketika semuanya dikaburkan, aplikasi harus berurusan dengan internet. Kebingungan tidak akan mencegah bug konsep tentang hal ini!

Tidak jelas Jika tidak di semua tingkatan, tidak akan meningkatkan keamanan.

Ketidakjelasan penuh Tidak benar-benar mungkin, karena kebutuhan menggunakan protokol standar untuk dapat berurusan dengan Internet.

Pikirkan lisensi

Jika Anda berencana untuk mendistribusikanGNU/Linux , Anda harus berbagi kode sumber seperti yang dijelaskan dalam GNU GENERAL PUICIC LICENSE GPLv3 GPLv dan/atau - GNU LESSER GENERAL PUICIC LICENSE LGPLv (tergantung pada aplikasi dan librairi yang digunakan). Ini akan berarti publikasi metode kebingungan bersama dengan setiap produk didistribusikan.

Menjawab dua pertanyaan Anda dengan ketat:

Saya sesuatu yang ahli, tetapi dengan fokus yang sangat kecil. Bekerja pada banyak infrastruktur bisnis kecil yang berbeda, saya telah melakukan beberapa pilihan beberapa tahun yang lalu. Evolusi dan sejarah tampaknya menegaskan pilihan saya, tetapi itu hanya poin pribadi saya.

Apakah OS kebingungan seperti yang dijelaskan digunakan secara luas dan saya belum menemukannya?

Jadi saya benar-benar tidak tahu dalam kebingungan proporsi adalah luas digunakan, tapi saya tidak menggunakan keamanan oleh ketidakjelasan = dan merekomendasikan untuk tidak.

Jika tidak digunakan secara luas, apa hambatan praktis atau teknis untuk penggunaan?

Tidak ada hambatan! Hanya kontra-produktif. Biaya waktu menjadi cepat besar dan peningkatan keamanan adalah daya tarik.

Tentu saja, beberapa hal minimal yang harus dilakukan:

  • Jangan memulai ssh server jika tidak diperlukan
  • Jangan menginstal Sudo, gunakan izin yang tepat, grup dan struktur yang koheren.
  • Tetap perbarui infrastruktur global Anda !!!

Sampel kecil when light come over obscurity

  • Mengamankan ssh: dua arah.

    • Pindahkan port ssh dari 22 ke 34567

      • ringan dan cepat dilakukan, tetapi

      jika penyerang menemukan mereka, mereka dapat menggunakan kekuatan kasar yang halus terhadap port ini banyak waktu sampai pengguna akhir menemukannya.

    • instal firewall

      • Lebih kuat, membutuhkan lebih banyak pengetahuan, tetapi.

      Lebih aman saat terkini.

4
F. Hauri

Bukankah seluruh kelas serangan praktis tidak berguna jika OS memiliki perintah ha7TrUO dan RRI6e29, bukan Sudo dan ls? Bayangkan seorang hacker yang entah bagaimana memperoleh akses root jarak jauh - apa yang akan mereka lakukan jika mereka tidak tahu perintah?

Alternatif yang lebih baik adalah dengan tidak menginstal perintah ini sejak awal. Saya tidak percaya Anda sebenarnya perlu Shell untuk menjalankan kernel Linux, walaupun ini menyiratkan bahwa proses start-up Anda adalah sesuatu selain sysV-init atau systemd.

Namun, seperti yang telah dicatat orang lain, ini merupakan pertukaran antara keamanan dan kemudahan pembangunan. Sayangnya, banyak pembuat perangkat lebih peduli tentang yang terakhir daripada yang pertama.

Implementasi akan cukup mudah untuk kompiler. Ambil kasus paling sederhana "ganti nama fungsi ini dan semua panggilan ke sana." Anda bisa memberikan kompiler OS dan kompiler aplikasi nama acak yang sama dan mereka akan dapat berbicara satu sama lain. Tetapi bahkan jika aplikasi memiliki keamanan yang buruk dan rentan terhadap injeksi bash, serangan seperti itu tidak akan membuahkan hasil.

Saya tidak yakin Anda memerlukan bantuan kompiler sama sekali. Saya pikir Anda sebagian besar dapat mencapai ini dengan memodifikasi tautan ¹ untuk menerapkan pengacakan ke semua nama simbol. Mungkin hanya menerapkan fungsi hash dengan garam yang hanya diketahui produsen saja sudah cukup. Saya tidak yakin Anda bahkan memerlukan kode sumber untuk melakukan ini, mis. Saya berpikir Anda dapat menerapkan mangling ke kode yang sudah dikompilasi.

(¹ Saya pikir ini adalah suatu kebohongan. Anda mungkin perlu memodifikasi kode objek untuk mengganti nama simbol, tetapi ini masih lebih seperti tingkat assembler, yaitu, a) Anda tidak melakukan semua bit hard dari kompilasi C/C++/etc. kode dan b) Anda tidak memerlukan C/C++/kode sumber apa pun. OTOH Saya tidak yakin Anda dapat melakukan hal semacam ini sama sekali jika kode perangkat Anda adalah sesuatu seperti Python.)

Namun, masih ada beberapa kemungkinan untuk merekayasa balik proses tersebut, dan terlebih lagi hal ini dapat melanggar GPL² (terutama GPLv3) kecuali Anda memberikan garam, yang akan mengalahkan tujuannya.

Bahkan, "karena GPL" mungkin merupakan alasan utama mengapa Anda tidak melihat ini; akan sulit untuk diterapkan dengan cara yang sebenarnya berguna selain membuat setiap perangkat berbeda . OTOH, itu setidaknya berarti bahwa penyerang hanya dapat menargetkan perangkat tertentu daripada mengeksploitasi kerentanan pada " perangkat apa pun yang menjalankan Linux x.y.z".

(² Untuk kesederhanaan, saya hanya akan menggunakan "GPL" di seluruh, tetapi perhatikan bahwa ini umumnya berlaku bahkan untuk [~ # ~] l [~ # ~] Barang GPL.)

Yang mengatakan, perhatikan bahwa GPL tidak mengharuskan Anda untuk mempublikasikan garam karena Anda "memodifikasi" sumber. Jika pengacakan nama simbol terjadi pada waktu kompilasi, Anda belum memodifikasi sumber. Alasan Anda perlu menerbitkan garam adalah karena GPL mengharuskan pengguna dapat mengganti versi mereka sendiri dari pustaka GPL, yang mereka dapat ' t lakukan kecuali mereka tahu garam. (Seperti yang disebutkan, Anda mungkin dapat keluar dari ini dengan GPLv2, tetapi efek teknisnya mirip dengan "hanya menjalankan perangkat lunak yang ditandatangani", yang secara khusus ditulis untuk mengatasi masalah dengan GPLv3.)


Pada akhirnya, mungkin ada beberapa keuntungan di sini, tetapi Anda tidak akan membuat tertentu sistem yang terutama lebih aman (diketahui bahwa "keamanan melalui ketidakjelasan" umumnya tidak ada keamanan sama sekali). Apa yang Anda dapat capai membuatnya lebih sulit untuk menargetkan banyak sistem melalui satu vektor.

4
Matthew

Pengungkapan yang Adil: Saya adalah CTO dari perusahaan yang membangun ini. Tidak bias untuk semua yang Anda inginkan.

It IS memang mungkin untuk sepenuhnya membangun sistem kernel-up, driver perangkat, paket, seluruh stack PER Host, beberapa kali per hari, dan itu bisa sangat efektif. Itulah tepatnya yang kami lakukan , dan kami membantu pelanggan kami. Kami bukan satu-satunya - kami dapat menyimpulkan bahwa setidaknya Google melakukan ini untuk semua mesin mereka juga (referensi segera hadir.)

Sekarang jika Anda memiliki kemampuan untuk membangun kembali per-mesin dari awal apa saja hal-hal yang dapat Anda ubah?

Proyek Proteksi Diri Kernel sudah memungkinkan untuk hal ini melalui penyusunan ulang struktur kernel secara acak: https://lwn.net/Articles/722293/ . Artikel ini juga menunjuk ke pertukaran yang terkenal di mana Linus Torvalds menyebutnya teater keamanan, tetapi penulis proyek (yang bekerja di Google) berkomentar, "Yah, Facebook dan Google tidak mempublikasikan pembuatan kernel mereka. :)"

Hal ini mengarahkan kepercayaan pada kesimpulan bahwa setidaknya Google melakukan ini dan menganggapnya berguna. Bisakah kita melakukan LEBIH BANYAK jenis pengacakan atas set tertutup? Pada tingkat paling mendasar mengapa virus Windows tidak berjalan di Linux atau Mac? Karena formatnya berbeda. Semuanya x86 di bawahnya, namun tidak sama. Nah bagaimana jika dua Linux berbeda dengan cara yang sama? Windows vs Linux bukan "kebingungan" hanya karena kita tidak memiliki banyak cara untuk membuat Linux berbeda seperti Windows terhadap Linux. Tapi itu bukan tidak mungkin, dan itu bahkan tidak terlalu sulit. Ambil pendekatan KSPP dan terapkan ke syscalls, kemudian kompilasi ulang semua yang ada di atas syscalls tersebut. Itu akan menjadi hal yang sulit untuk dilanggar - setidaknya tidak dengan cara terbang.

Pertanyaan Anda adalah tentang penggantian nama simbol (nama executable, library, dll.) Ini memiliki dua aspek: (a) apakah ini berguna? (B) Bisakah itu dilakukan dengan andal?

Kami sedang mencari cara untuk menyelesaikan PHP injeksi kode sekali dan untuk semua. Terlepas dari apa HackerNews ingin Anda percaya , PHP suntikan kode bukan masalah terpecahkan di luar papan pesan internet. Kehidupan nyata PHP pengembang, admin dan pengguna terkena sejumlah suntikan kode terus menerus.

Jadi kami berangkat untuk mencoba Polyscripting (Open Source berlisensi MIT): https://github.com/polyverse/polyscripted-php

Kami membagikan ini secara publik untuk meminta umpan balik, dan kami menjalankan dua situs web, polyscripted.com dan nonpolyscripted.com , yang melakukan persis apa yang Anda harapkan berdasarkan nama mereka. Kami juga menyewa pentester untuk mencoba memecahkannya.

Dan saya baru saja mulai bereksperimen dengan executable, shared library, dan simbol-diekspor yang diganti nama menjadi perangkat tertutup (misalnya, dalam wadah buruh pelabuhan). Saya pribadi tidak berpikir ini menambah nilai, tetapi apakah itu akan menambah sedikit? Aku pikir begitu. Jadi turun ke biaya. Jika Anda bisa mendapatkan sedikit nilai bahkan untuk biaya yang lebih murah, mengapa tidak lakukan saja? Itulah mengapa kita semua memiliki ASLR - ini bukan pertahanan terbaik sejak mengiris roti, tetapi jika Anda sudah memiliki kode yang dapat dipindahkan, dan Anda tetap akan memesan ulang, mengapa TIDAK Dorong ke batas dan acakkan?

Singkatnya, pendekatan yang Anda gambarkan sedang dicoba oleh banyak orang (termasuk Google, Facebook, kernel Linux, dll.), Bersama dengan banyak akademisi di bawah bidang Moving Target Defense, dan beberapa perusahaan seperti kami yang ' sedang mencoba membuatnya sepele seperti ASLR.

2
Archis Gore

Saya akan mengatakan bagaimana saya melihat ini dari sudut pandang hacker.

Jelas, jika Anda akan mengganti nama semua utilitas - itu akan membuat segalanya lebih sulit dan kurang nyaman bagi saya, tetapi apa yang bisa saya lakukan?

  1. Jika saya sudah mendapatkan akses ke Shell pada sistem, saya hanya akan mengunggah busybox (semua utilitas dasar dalam satu biner) atau set lengkap binari yang saya butuhkan untuk operasi dasar.

  2. Untuk meningkatkan hak istimewa lebih lanjut, saya mungkin perlu mencari binari suid-root, dan hanya ada beberapa di antaranya (Sudo, mount, dll.). Peretas tidak dapat mengunggah file seperti itu (kecuali ia sudah di-root). Sistem linux kecil saya yang sederhana hanya memiliki 24 binari suid. Sangat mudah untuk mencoba masing-masing secara manual.

Tapi bagaimanapun, saya setuju, ini akan membuat peretasan kotak ini lebih sulit. Akan susah menggunakan (hack) sistem ini, tetapi memungkinkan. Dan peretas bekerja pada sistem selama berjam-jam atau sehari atau sebulan ... tetapi admin/pengguna dapat bekerja pada sistem selama bertahun-tahun dan tidak dapat mengingat nama ha7TrUO dan RRI6e29. Mungkin tidak ada yang akan mencoba meretas sistem, tetapi admin akan menderita setiap hari.

Tapi ... jika Anda membuat keamanan terlalu tinggi tetapi tidak nyaman untuk pengguna/admin - seringkali Anda membuat keamanan lebih rendah sebenarnya. Seperti jika Anda menerapkan kata sandi kompleks dengan 20+ karakter - kemungkinan besar kata sandi akan ditulis pada catatan post-it di monitor. Jika Anda membuat sistem seperti itu dikaburkan - akan sangat sulit untuk mengerjakannya untuk pengguna yang baik. Dan mereka harus melakukan beberapa hal untuk membuat hidup mereka lebih mudah. Misalnya, mereka dapat mengunggah binary busybox mereka. Sementara. Dan mereka akan melupakannya atau membiarkannya di sana dengan sengaja (karena mereka berencana untuk menggunakannya nanti).

1
yaroslaff

Ini sebenarnya terjadi, karena koneksi ssh dienkripsi. Mengubah nama beberapa binari inti tidak mencapai apa-apa selain ini. Juga akan menyebabkan banyak kekacauan: mis. skrip yang mengandalkan utilitas ini tidak dapat digunakan, atau Anda harus memiliki semacam "deobfuscator" proksi, yang pasti akan berakhir sebagai vektor serangan. Namun saya telah melihat beberapa server di alam bebas yang tidak mengizinkan login root, memaksa untuk menggunakan Sudo sebagai gantinya. Nama pengguna sudo tetap agak rahasia. Saya tidak yakin seberapa aman itu, tapi saya bukan ahli.

0
galaktycznyseba

Mengapa tidak semua pintu memiliki sepuluh lubang kunci, hanya satu yang benar-benar berfungsi untuk kunci atau kunci pick? Jawaban: sebagian besar gangguan tidak bernilai sepuluh detik ekstra dari waktu pencuri.

Jika ada jutaan nikdibuat terpisah sistem operasi kode sumber, penyamaran mungkin biasa terjadi. Sebagai hal yang praktis, kami memiliki sekitar empat basis kode unik yang umum digunakan - semua info kebocoran tentang diri mereka sendiri berdasarkan waktu kejadian, dan untuk beberapa fungsi OS tingkat rendah di mana produsen chip memberikan urutan bitcode mesin yang ditentukan untuk mengaktifkan atau mengakses fitur cpu tertentu, mereka semua kemungkinan memiliki urutan pendek yang berisi kode yang persis sama.

0
Dusty