it-swarm-eu.dev

Perché la difesa dell'offuscamento del sistema operativo è contro "È un sistema Unix!" non ampiamente implementato?

Il Jurassic Park scene a cui si fa riferimento nel titolo è tristemente famoso per quanto risulti ridicolo per coloro che sono esperti di tecnologia. Ma illustra anche quello che a me sembra essere un enorme buco nella sicurezza del web, in particolare i dispositivi IoT - non appena gli aggressori scoprono che un server o una videocamera o un baby monitor eseguono Linux, sanno immediatamente i volumi su come funziona. Sanno che comandi come Sudo sono grandi obiettivi succosi e sanno che l'accesso alla Shell porterà con sé una serie di strumenti utili come ls e cat.

Quindi perché l'offuscamento del sistema operativo non è più una cosa? Non sto parlando di nascondere la versione nelle intestazioni web. Simile alla minimizzazione o all'offuscamento di JavaScript, sto parlando di cambiare i nomi di binari e percorsi di file nel sistema operativo stesso. Intere classi di attacchi non sarebbero praticamente inutili se il sistema operativo avesse ha7TrUO e RRI6e29 comandi invece di Sudo e ls? Immagina un hacker che in qualche modo ha ottenuto l'accesso remoto alla radice - cosa faranno anche se non conoscono alcun comando?

L'implementazione sarebbe abbastanza semplice per i compilatori. Prendi il caso più semplice di "rinomina questa funzione e tutte le chiamate ad essa". Potresti dare a un compilatore del sistema operativo e un compilatore dell'applicazione gli stessi nomi casuali e sarebbero in grado di parlare tra loro. Ma anche se l'applicazione ha una scarsa sicurezza ed è vulnerabile all'iniezione bash, tali attacchi sarebbero inutili.

Ovviamente questa tecnica non può essere utilizzata in tutti gli scenari. Mettendo da parte scenari come i server gestiti da amministratori di sistema umani, mi sembra che qualsiasi dispositivo o server gestito dall'automazione sia il candidato principale per questa difesa.

Immagino che le domande debbano essere un po 'più concrete:

  1. L'offuscamento del sistema operativo come descritto è ampiamente utilizzato e non l'ho mai riscontrato?
  2. Se non ampiamente utilizzati, quali sono gli ostacoli pratici o tecnici all'utilizzo?
156
Indigenuity

Prima di separare la tua idea, lasciami dire che è un'idea davvero interessante ed è stato molto divertente pensarci.

Continua a pensare fuori dagli schemi e fai domande interessanti!

Bene, facciamolo!


Facciamo un passo indietro e chiediamo perché in primo luogo quel baby monitor esegue Linux? E se non esistesse un sistema operativo e l'applicazione fosse scritta in un codice microcontrollore nudo (pensa al codice arduino)? Quindi non ci sarebbero Sudo o ls o anche una Shell da usare per l'attaccante, giusto?

Non sono un esperto qui, ma mi aspetto che, come industria, abbiamo gravitato verso il mettere Linux su qualcosa di abbastanza grande da eseguirlo in gran parte per comodità degli sviluppatori:

  1. Riduzione del tempo di sviluppo: durante la creazione di un whizpopper con auto-patching con sincronizzazione cloud gestita sul Web e compatibile con WiFi e bluetooth con compagno Android e app iOS, Linux viene fornito con tutte le librerie, utility e autisti che devi fare.
  2. Maggiore testabilità: se il dispositivo esegue bash o busybox con una porta SSH, è super facile connettersi e capire cosa è andato storto durante la fase di test del prodotto.

Perché la tua idea di offuscamento funzioni, dovresti offuscare non solo i nomi delle utility della riga di comando come Sudo e ls, ma anche ogni API del kernel Linux per impedire all'attaccante di cadere nel proprio binario compilato che chiama direttamente il kernel. Quindi diamo un'altra occhiata alla tua idea:

L'implementazione sarebbe abbastanza semplice per i compilatori. Prendi il caso più semplice di "rinomina questa funzione e tutte le chiamate ad essa". Potresti dare a un compilatore del sistema operativo e un compilatore dell'applicazione gli stessi nomi casuali e sarebbero in grado di parlare tra loro.

Dovrai fare questa compilazione randomizzata tu stesso; altrimenti qualcuno potrebbe cercare le mappature su google.

Quindi, dovrai compilare il kernel dal sorgente con il tuo "compilatore offuscato" in modo che solo tu sappia i mapping delle API del kernel offuscate. (hai mai creato il kernel linux dal sorgente? È sicuramente più un lavoro ingrato di docker pull Alpine, che è la direzione in cui la cultura dev sembra andare) .

Ma un sistema operativo è molto più di un semplice kernel. Volete i driver per il chip wifi Broadcom BCM2837 che arriva su quel dispositivo mini-pc? Dovrai compilare quel driver sul tuo kernel ofbuscated con il tuo compilatore, se Broadcom ti fornirà persino il codice sorgente. Quindi dovrai costruire l'intero GNU stack di software di rete e wifi. Per quante altre cose dovrai trovare la fonte e aggiungere la tua pipeline di costruzione prima di avere un sistema operativo funzionante?

Oh, e se i repository upstream di una di queste cose generano una patch, ora sei responsabile di ricostruirla (supponendo che tu abbia salvato i file di mappatura dell'offuscamento del compilatore che corrispondono al tuo binario del kernel) e trasferendolo ai tuoi dispositivi perché, per impostazione predefinita, i tuoi dispositivi non possono utilizzare i binari di patch prodotti dal fornitore.

Oh, e per sventare gli hacker, non ci sarà nulla di tutto questo "Ecco i file binari per Whizpopper 1.4.7" , oh no, tu dovremo creare una versione univoca e offuscata di tutto, dal kernel per dispositivo che spedite.


Quindi alle tue domande:

  1. L'offuscamento del sistema operativo come descritto è ampiamente utilizzato e non l'ho mai riscontrato?
  2. Se non ampiamente utilizzati, quali sono gli ostacoli pratici o tecnici all'utilizzo?

Penso che la risposta sia che ciò che stai descrivendo praticamente sconfigge completamente lo scopo di utilizzare componenti software preesistenti se hai bisogno di trovare e costruire letteralmente tutto dalla fonte. In realtà potrebbe essere meno sforzo abbandonare completamente il sistema operativo, fingere che sia il 1960 e scrivere l'applicazione direttamente nel microcodice della CPU.

Mi piace la sicurezza più della maggior parte degli sviluppatori, ma mi piace f * that .

235
Mike Ounsworth

La risposta di Mike dice sostanzialmente tutto ciò che ho da offrire sul perché questa è una cattiva idea dal punto di vista dello sviluppo (e, come dice il commento di Ghedipunk, una funzione di sicurezza inutilizzabile non fornisce sicurezza). Quindi, invece, parlerò del perché dal punto di vista della sicurezza , non lo faresti mai.

La risposta è in realtà sorprendentemente semplice: è una perdita di tempo e ci sono opzioni strettamente migliori. Ogni stupido scarabocchio dell'IoT (ricorda, la "s" in "IoT" sta per Secure) che non si prende la briga di implementare tali funzionalità in modo sicuro che l'inferno non seguirebbe un approccio come suggerisci.

  1. L'intera idea non funzionerà per limitare le chiamate di sistema. Un utente malintenzionato può semplicemente impostare alcuni registri e invocare un codice operativo e un boom, sono nel kernel che eseguono il syscall di loro scelta; a chi importa quale sia il suo nome simbolico? Certo, puoi manomettere la tabella di syscall per complicare ciò (se non ti dispiace dover ricompilare tutto e rendere il debug del tuo kernel personalizzato una forma di inferno assoluto) ma è come offuscare il sistema operativo in uso; perché preoccuparsi quando ci sono così pochi candidati, comunque? Anche se l'attaccante non vuole decodificare il codice esistente sul sistema, la forza bruta dovrebbe essere possibile a meno che lo spazio di ricerca degli indici di chiamata utilizzabili sia più ampio di quanto abbia mai visto su un sistema incorporato.
  2. Perché offuscare i nomi dei comandi quando puoi renderli completamente inaccessibili? Un chroot non funzionerà per gli incorporati Shell se stai eseguendo una Shell , ma funziona bene per tutto il resto e davvero, perché la tua app monouso costruita su misura dovrebbe eseguire una shell? Voglio dire, le unità di sviluppo ne avrebbero installata una, a scopo di test, e forse ciò non verrà rimosso nella tua immagine commerciale perché sei pigro o pensi di averne bisogno di nuovo. Ma un utente malintenzionato non sarebbe in grado di eseguirlo dal contesto in cui viene eseguita la sua app. Un semplice chroot (o un sandbox/jail/container più complicato) può rendere il programma in grado di eseguire - o addirittura accedere a - qualsiasi file oltre a quelli richiesti per il suo lavoro.
  3. Perché offuscare le API del kernel quando puoi semplicemente rimuovere l'accesso ad esse? Esistono numerosi sistemi di sandboxing che possono limitare ciò che può fare un processo (o i suoi discendenti ... se è persino consentito crearne uno). Vedi https://stackoverflow.com/questions/2146059/limiting-syscall-access-for-a-linux-application
88
CBHacking

Se il tuo obiettivo è quello di privare un attaccante di ls e cat, c'è un'alternativa ancora migliore all'offuscamento: semplicemente non installare quelle utility.

Anche se non direi che questo è un approccio ampiamente , è almeno un attrezzo. Ad esempio, considera distroless , una raccolta di immagini docker con praticamente nulla in esse. Alcuni di essi (come quello per andare) non contengono letteralmente nulla . Un attacco a un sistema in esecuzione in un contenitore di questo tipo non può ottenere l'accesso Shell perché non esiste alcuna Shell da eseguire.

L'unico modo per ottenere l'accesso Shell attaccando un'applicazione in un tale contenitore è quindi quello di aggirare il tempo di esecuzione del contenitore, che è progettato per impedirlo proprio.

Mentre ho dato un esempio di un'immagine docker, lo stesso concetto può essere applicato ai sistemi operativi in ​​generale. Ad esempio, ls e cat fanno parte del pacchetto coreutils in Debian. Potresti eseguire apt-get remove coreutils e sii certo che un attaccante non sarà in grado di usare ls o cat come parte di un attacco. Ovviamente questo significa che non puoi nemmeno usarli, e probabilmente ci sono molte altre cose che dipendono da coreutils che dovranno essere rimosse, ma per un dispositivo incorporato o un server che fa solo una cosa potrebbe essere OK.

Il principio generale è ridurre la "superficie di attacco": più "roba" ha un bersaglio, più facile è scendere a compromessi. Il materiale potrebbe essere porte di rete aperte, righe di codice o binari installati. Se l'obiettivo è aumentare la sicurezza, rimuovere tutte le "cose" non necessarie è un buon inizio.

30
Phil Frost

Perché l'offuscamento non è sicurezza e perché l'offuscamento del sistema operativo è fondamentalmente senza senso.

Esistono solo così tanti sistemi operativi comuni e tanti modi per fare ipotesi ponderate. Se rilevi che sto eseguendo IIS o MSSQL Server, hai una supposizione su quale sistema operativo stia funzionando sotto.

Anche se in qualche modo riesco a eseguire uno stack che non ti dice nulla sul mio sistema operativo sottostante e anche a mascherare ogni altro suggerimento (l'impronta digitale è una cosa), non ho ancora vinto molto.

Per quanto riguarda la sicurezza, sapendo che sto eseguendo Linux, o anche che sto eseguendo Debian 8, non ti dà molto su cui lavorare, né molto di cui preoccuparmi. Se sono adeguatamente indurito e rattoppato, potresti sapere quello che vuoi. Se sono a un livello di patch che è stato applicato ieri al museo del software, la tua suite di attacchi mi spalancerà semplicemente provandoli tutti e offuscare il mio sistema operativo ti costringe solo a provare un paio di exploit inutili di più. In un attacco automatico, ti rallenterà per alcuni secondi.

L'offuscamento non funziona. Le persone possono scansionarti, darti delle impronte digitali o semplicemente lanciare la loro intera libreria di exploit per vedere cosa funziona.

Se perdi tempo in quello che avresti potuto spendere per il vero indurimento, stai effettivamente danneggiando la tua sicurezza.

Indurimento adeguato. Ho detto sopra che "potresti sapere quello che vuoi" . Ho pubblicato il mio indirizzo IP e password di root nelle conferenze sulla sicurezza in cui ho tenuto un discorso. SSH con accesso root remoto e numerosi servizi abilitati. Macchina SELinux seriamente indurita. Nessuno è mai riuscito a interrompere il mio discorso, anche se una volta una persona è riuscita a rilasciare un file di testo nella directory principale quando la mia politica non era ancora perfetta.


Addendum: il tuo punto di partenza era un film. L'offuscamento è un ottimo dispositivo cinematografico perché una rivelazione del genere dice agli spettatori che l'eroe (o il cattivo) ha trovato alcune informazioni e quindi sta facendo progressi. È l'equivalente del computer per scoprire dove si trova la cassaforte, anche se è ancora necessario il codice. Non importa se è effettivamente corretto, se trasmette il giusto messaggio emotivo al pubblico.

13
Tom

Per un esempio estremamente diffuso, Intel Management Engine, che ha un proprio sistema operativo, fa qualcosa del genere, dove esiste un meccanismo di aggiornamento del firmware, ma il firmware deve essere in un formato molto specifico i cui dettagli sono riservati. Sembra coinvolgere la codifica di Huffman con parametri sconosciuti. Analogamente alla tua proposta (che è fondamentalmente la crittografia simmetrica del firmware), ME richiede modifiche specifiche al momento della preparazione del firmware e presenta una deviazione corrispondente dai meccanismi standard al momento dell'esecuzione.

7
Roman Odaisky

Quello che stai descrivendo si chiama "Sicurezza attraverso l'oscurità" ed è un antipattern di sicurezza ampiamente noto . Significa che non è una nuova idea, piuttosto è una vecchia, cattiva idea, che le persone che non sono iniziate nella filosofia della sicurezza devono essere educate in modo da non cadere.

Immagina di progettare una casa per essere sicura e che l'oscurità era una strategia promettente. Tutte le case sono costruite da corridoi e stanze, porte con maniglie, interruttori della luce, ecc. Dato che questi sono comunemente noti, potresti pensare che questo non sia sicuro poiché un intruso potrebbe facilmente navigare nella casa con questi elementi di costruzione comunemente noti. Potresti provare a ridisegnare da zero i principi della costruzione, sostituire le manopole delle porte con cubi di rubik, creare soffitti a mezza altezza per confondere l'intruso, ecc. Si finisce con una casa in cui è terribile vivere, non può essere mantenuta perché nessun imprenditore vuole qualcosa avere a che fare con ciò, e la cosa peggiore è che non c'è nulla perché qualsiasi intruso, una volta dentro, può guardarsi intorno con gli occhi e usare il cervello per capirlo. Gli hacker sono appassionati di puzzle.

La soluzione per proteggere la tua casa non è quella di avere una costruzione non standard, è quella di avere serrature migliori, finestre protette, un sistema di sicurezza adeguato, ecc. Non vuoi nascondere il tuo oro in un passaggio segreto, perché alla fine l'Abate e Costello si appoggerà a quel candelabro e lo aprirà per sbaglio. Metti il ​​tuo oro in una cassaforte con una buona combinazione segreta e un allarme antimanomissione. L'equivalente del computer ha un accesso limitato alle credenziali mediante crittografia a chiave pubblica, ruoli di accesso dell'utente limitati, sistemi di monitoraggio, riduzione della superficie esposta, mitigazione dei vettori di minacce di ingresso, ecc.

Gli sforzi per rendere un sistema informatico più oscuro rendono il sistema più lontano dal supporto, più difficile da ottenere sicurezza patch, più difficile da usare in modo sicuro .

Modifica: a volte, alcuni sicurezza attraverso l'oscurità è accettabile, se utilizzata oltre alla sicurezza effettiva. Un esempio comune è l'esecuzione di SSH su una porta alta come 30000 qualcosa. SSH è crittografato e l'accesso è dietro un'autenticazione con credenziali, questa è la tua vera sicurezza. Ma averlo su una porta alta rende meno evidente all'inizio se qualcuno sta eseguendo scansioni rapide. Qualunque cosa più complicata di questa, come cercare di offuscare il tuo sistema operativo, lo renderebbe solo un incubo operativo, il che renderebbe più difficili le effettive misure di sicurezza (come essere aggiornati sulle patch).

5
user1169420

Pensa usabilità

  • Prova a spiegare al tuo nuovo amministratore di sistema che deve premere ha7TrUO all'interno di Sudo, RRI6e29 invece di ls e così via ... Sì, c'è un elenco di traduzioni che devi solo imparare !
  • navigazione nella rete locale non deve essere possibile anche: devi mantenere un elenco cartaceo per mantenere una visione d'insieme !?

  • Se rinominate tutti i comandi critici, dovrete guidare questo per effettuare l'aggiornamento del sistema!

  • E come commento di Nick225 , Se si tenta di creare un sistema incorporato, quindi eseguire l'offuscamento prima di pubblicare il prodotto finale, sarà necessario testare il prodotto finale.

    • Devi creare fatto in casa script per legare tutto per l'offuscamento.
    • Se qualcosa va storto, il debug diventerà complicato.
    • Devi creare fatto in casa script di deobfuscation, per poter fare un po 'di debug.
    • Il feed-back personalizzato (con file di registro) dovrà essere deobfuscato anche.

    In questo modo, aggiungerai un livello di lavoro importante con nuovi potenziali bug.

    Per pochissimi miglioramenti della sicurezza, vedere oltre

L'oscurità potrebbe farti del male.

Pensa livello inferiore

  • Anche se si tenta di rinominare i file, funzionare a livello di applicazione e di sistema operativo, tutto ciò utilizzerà librerie standard che verrà chiamato direttamente se l'utente malintenzionato invia file eseguibili binari. Potresti anche considerare di offuscare tutte le librerie standard! (Compresi filesystem, protocolli di rete ...)

  • Mentre usi un kernel non modificato, useranno standard variabili e spazi dei nomi. Quindi, dovrai creare versione offuscata del kernel ...

... Quindi lega tutto insieme!

Bene, anche quando tutto è offuscato, l'applicazione dovrà occuparsi di Internet. L'offuscamento non impedirà bug concettuali su questo!

Oscurità Se non a tutti i livelli, non migliorerà la sicurezza.

Completa oscurità Non è proprio possibile, a causa della necessità di utilizzare protocolli standard per poter gestire Internet.

Pensa licenza

Se si prevede di distribuireGNU/Linux , è necessario condividere il codice sorgente come descritto in GNU GENERAL PUBLIC LICENSE GPLv e/o - GNU LESSER GENERAL PUBLIC LICENSE LGPLv (a seconda dell'applicazione e delle librerie utilizzate). Ciò implica la pubblicazione del metodo di offuscamento insieme a ogni prodotto distribuito.

Rispondere rigorosamente alle tue due domande:

Sono un esperto, ma con un focus molto piccolo. Lavorando su diverse infrastrutture di piccole imprese, ho fatto alcune scelte alcuni anni fa. L'evoluzione e la storia sembrano confermare le mie scelte, ma è solo il mio punto di vista personale.

L'offuscamento del sistema operativo come descritto è ampiamente utilizzato e non l'ho mai riscontrato?

Quindi davvero non so in quale proporzione l'offuscamento sia ampiamente usato, ma non uso sicurezza per oscurità = e raccomandare di non farlo.

Se non ampiamente utilizzati, quali sono gli ostacoli pratici o tecnici all'utilizzo?

Nessuna barriera! È controproducente. Il costo del tempo diventa rapidamente gigantesco e il miglioramento della sicurezza è un richiamo.

Certo, alcune cose minime sono da fare:

  • Non avviare ssh server se non necessario
  • Non installare Sudo, utilizzare corretto autorizzazioni, gruppi e struttura coerente.
  • Mantieni aggiornata la tua infrastruttura globale !!!

Piccolo esempio when light come over obscurity

  • Protezione di ssh: bidirezionale.

    • Sposta la porta ssh da 22 a 34567

      • leggero e fatto rapidamente, ma

      se un attaccante li avesse trovati, avrebbero potuto esercitare una forza bruta fluida contro questa porta per molto tempo fino a quando l'utente finale non li scoprisse.

    • installa firewall

      • Più forte, richiede più conoscenza, ma.

      Più sicuro mentre aggiornato.

4
F. Hauri

Intere classi di attacchi non sarebbero praticamente inutili se il sistema operativo avesse comandi ha7TrUO e RRI6e29 invece di Sudo e ls? Immagina un hacker che in qualche modo ha ottenuto l'accesso remoto alla radice - cosa faranno anche se non conoscono alcun comando?

Un'alternativa migliore sarebbe semplicemente non installare questi comandi in primo luogo. In realtà non credo che necessità una Shell per eseguire un kernel Linux, anche se questo implica che il processo di avvio è diverso da sysV-init o systemd.

Come altri hanno notato, tuttavia, è un compromesso tra sicurezza e facilità di sviluppo. Sfortunatamente, molti produttori di dispositivi si preoccupano molto di più del secondo rispetto al primo.

L'implementazione sarebbe abbastanza semplice per i compilatori. Prendi il caso più semplice di "rinomina questa funzione e tutte le chiamate ad essa". Potresti dare a un compilatore del sistema operativo e un compilatore dell'applicazione gli stessi nomi casuali e sarebbero in grado di parlare tra loro. Ma anche se l'applicazione ha una scarsa sicurezza ed è vulnerabile all'iniezione bash, tali attacchi sarebbero inutili.

Non sono sicuro che tu abbia bisogno dell'aiuto del compilatore. Penso che puoi raggiungere questo obiettivo principalmente modificando linker ¹ per applicare una randomizzazione a tutti i nomi di simboli. Probabilmente sarebbe sufficiente applicare una funzione hash con un sale noto solo al produttore. Non sono sicuro che tu abbia nemmeno bisogno del codice sorgente per fare questo, cioè io pensa potresti applicare la modifica al codice già compilato.

(¹ Penso che questa sia una specie di bugia. Potrebbe essere necessario modificare il codice oggetto per sostituire i nomi dei simboli, ma questo è ancora più simile al livello dell'assemblatore, vale a dire a) non stai facendo tutto difficile bit di compilazione C/C++/ecc. codice eb) non è necessario il C/C++/qualunque sia il codice sorgente. OTOH Non sono sicuro che puoi fare questo genere di cose se il tuo codice dispositivo è invece qualcosa come Python.)

C'è ancora qualche possibilità di decodificare il processo, tuttavia, e inoltre ciò potrebbe violare GPL² (in particolare GPLv3) a meno che non si distribuisca il sale, il che vanificherebbe lo scopo.

In effetti, "a causa della GPL" è probabilmente il motivo principale per cui non lo vedi; sarebbe difficile da implementare in un modo che sia effettivamente utile oltre a rendere ogni dispositivo diverso. OTOH, ciò significherebbe almeno che gli attaccanti possono solo prendere di mira dispositivi specifici invece di essere in grado di sfruttare una vulnerabilità su "any dispositivo che esegue Linux x.y.z".

(² Per semplicità, userò semplicemente "GPL" dappertutto, ma in genere ciò vale anche per L cose GPL.)

Detto questo, nota che la GPL non richiede di pubblicare il salt perché hai "modificato" le fonti. Se la randomizzazione del nome del simbolo avviene al momento della compilazione, non hai modificato le fonti. Il motivo per cui dovresti pubblicare il salt è perché la GPL richiede che gli utenti possano sostituire le loro versioni di una libreria GPL, cosa che non possono fare se non conoscono il salt. (Come notato, potresti essere in grado di sfuggire a questo con GPLv2, ma gli effetti tecnici sono simili a "esegui solo software firmato", che GPLv3 è stato specificamente scritto per indirizzare.)


In definitiva, ci potrebbe essere un vantaggio alcuni qui, ma non renderai alcun sistema particolare notevolmente più sicuro (è noto che la "sicurezza attraverso l'oscurità" generalmente non è sicurezza a tutti). Ciò che puoi realizzi è rendere più difficile il targeting di molti sistemi tramite un singolo vettore.

4
Matthew

Disclosure equo: sono il CTO di un'azienda che costruisce proprio questo. De-bias per quello che vuoi.

È IS davvero possibile creare completamente un kernel di sistema, driver di dispositivo, pacchetti, l'intero stack PER Host, più volte al giorno, e può essere abbastanza efficace. Questo è esattamente ciò che facciamo e aiutiamo i nostri clienti a farlo. Non siamo i soli - possiamo dedurre che almeno Google lo fa anche per tutte le loro macchine (riferimento in arrivo).

Ora, se hai avuto la possibilità di ricostruire da zero ogni macchina, quali sono alcune delle cose che puoi cambiare?

Il Kernel Self Protection Project lo consente già attraverso il riordino casuale delle strutture del kernel: https://lwn.net/Articles/722293/ . Questo articolo indica anche il famoso scambio in cui Linus Torvalds lo chiama teatro della sicurezza, ma l'autore del progetto (che lavora su Google) commenta: "Bene, Facebook e Google non pubblicano le loro build del kernel. :)"

Ciò porta la credenza all'inferenza che almeno Google fa questo e lo considera utile. Possiamo fare PIÙ tipi di rimescolamenti su un set chiuso? A livello fondamentale, perché un virus Windows non funziona su Linux o Mac? Perché i formati sono diversi. È tutto x86 sotto, eppure non è lo stesso. E se due Linux fossero diversi in modo simile? Windows vs Linux non è "offuscamento" semplicemente perché non abbiamo molti modi per rendere Linux diverso da quello che Windows ha rispetto a Linux. Ma non è impossibile e non è nemmeno così difficile. Adotta l'approccio del KSPP e applicalo alle syscalls, quindi ricompila tutto in cima con quelle syscalls. Sarà estremamente difficile da rompere - almeno non in modo sorvolato.

La tua domanda però riguardava la ridenominazione dei simboli (nomi di eseguibili, librerie, ecc.) Questo ha due aspetti: (a) è utile? (b) Può essere fatto in modo affidabile?

Stavamo cercando un modo per risolvere PHP iniezioni di codice una volta per tutte. Nonostante ciò HackerNews vorrebbe farti credere , PHP le iniezioni di codice non sono un problema risolto al di fuori delle bacheche di messaggi Internet. La vita reale PHP sviluppatori, amministratori e utenti sono esposti a un numero continuo di iniezioni di codice.

Quindi abbiamo deciso di provare il Polyscripting (permissivamente con licenza MIT Open Source): https://github.com/polyverse/polyscripted-php

Condividiamo pubblicamente questo per sollecitare feedback e gestiamo due siti Web, polyscripted.com e nonpolyscripted.com , che fanno esattamente ciò che ti aspetteresti in base al loro nome. Abbiamo anche assunto pentesteri per cercare di romperlo.

E sto appena iniziando a sperimentare eseguibili librerie condivise e rinominare i simboli esportati su un set chiuso (in un contenitore docker, ad esempio). Personalmente non penso che questo aggiunga tanto valore, ma aggiungerà un po '? Credo di si. Quindi si riduce al costo. Se riesci a ottenere poco valore per un costo ancora più piccolo, perché non farlo? Questo è esattamente il motivo per cui tutti abbiamo ASLR: non è esattamente la più grande difesa da quando il pane a fette, ma se hai già un codice trasferibile e lo riordinerai comunque, perché NON spingerlo al limite e randomizzarlo?

In breve, l'approccio che stai descrivendo viene tentato da molte persone (tra cui Google, Facebook, il kernel Linux, ecc.), Insieme a molti accademici nel campo del Moving Target Defense e una manciata di aziende come la nostra che " stai cercando di renderlo banalmente consumabile come ASLR.

2
Archis Gore

Direi come lo vedo dal punto di vista degli hacker.

Sicuramente, se rinominerai tutte le utility - renderà le cose molto più difficili e meno confortevoli per me, ma cosa potrei fare?

  1. Se avessi già avuto accesso a Shell sul sistema, avrei semplicemente caricato trafficbox (tutte le utility di base in un binario) o un set completo di binari di cui avevo bisogno per le operazioni di base.

  2. Per aumentare ulteriormente i privilegi, potrei aver bisogno di cercare i binari suid-root, e ce ne sono solo alcuni (Sudo, mount, ecc.). Il pirata informatico non può caricare tali file (a meno che non sia già root). Il mio semplice sistema Linux ha solo 24 binari di suid. Molto facile provarlo manualmente.

Ma comunque, sono d'accordo, questo renderebbe più difficile l'hacking di questa scatola. Sarebbe doloroso usare (hack) questo sistema, ma possibile. E l'hacker funziona sul sistema per ora o giorno o mese ... ma admin/utente potrebbe funzionare sul sistema per anni e non ricorda i nomi ha7TrUO e RRI6e29. Forse nessuno proverà nemmeno a violare il sistema, ma l'amministratore ne soffrirà tutti i giorni.

Ma ... se rendi la sicurezza troppo alta ma scomoda per l'utente/amministratore - spesso stai riducendo la sicurezza. Come se imposti password complesse con oltre 20 caratteri - molto probabilmente le password verranno scritte su post-it sul monitor. Se renderai il sistema così offuscato, sarà molto difficile lavorarci su per buoni utenti. E dovranno fare alcune cose per rendere la loro vita più semplice. Ad esempio, possono caricare il loro file binario busybox. Temprorary. E lo dimenticheranno o lo lasceranno lì intenzionalmente (perché hanno intenzione di usarlo poco dopo).

1
yaroslaff

In realtà succede, perché le connessioni ssh sono crittografate. La modifica dei nomi di alcuni file binari core non compie altro. Inoltre causerebbe molto caos: ad es. tutti gli script che si basano su queste utilità sono resi inutilizzabili, oppure è necessario disporre di una sorta di "deobfuscatore" proxy, che finirebbe sicuramente come un vettore di attacco. Tuttavia ho visto alcuni server in libertà che non consentono l'accesso come root, costringendo invece a usare Sudo. I nomi utente dei sudoer rimangono in qualche modo segreti. Non sono sicuro di quanto sia sicuro, ma non sono un esperto.

0
galaktycznyseba

Perché non tutte le porte hanno dieci fori, solo uno dei quali ha funzionato per chiavi o grimaldelli? Risposta: per lo più il disturbo non vale i dieci secondi in più del tempo di un ladro.

Se esistessero milioni di nivocicreati in isolamento sistemi operativi con codice sorgente, l'oscuramento potrebbe essere comune. In pratica, tuttavia, abbiamo circa quattro basi di codice univoche di uso comune: tutte perdono informazioni su se stesse tramite il timing degli eventi e per diverse funzioni del sistema operativo di basso livello in cui i produttori di chip forniscono sequenze di bitcode macchina prescritte per attivare o accedere a determinate funzionalità della CPU, esse tutti probabilmente hanno brevi sequenze contenenti esattamente lo stesso codice.

0
Dusty