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

Continua a pensare fuori la scatola e fai domande interessanti!

Va bene, facciamolo!

Facciamo un passo indietro e chiediamoci perché baby monitor esegue Linux in primo luogo? E se non ci fosse un sistema operativo e l'applicazione fosse scritta nel codice del microcontrollore nudo (pensa al codice arduino)? Quindi non ci sarebbe sudo o ls o anche una shell da utilizzare per l'attaccante, giusto?

Non sono un esperto qui, ma Mi aspetto che noi, come industria, abbiamo gravitato verso mettere Linux su qualcosa di abbastanza grande da eseguirlo principalmente per comodità degli sviluppatori:

1. Riduzione dei tempi di sviluppo: quando si costruisce il WiFi e il Bluetooth compatibili Whizpopper di auto-patching con sincronizzazione cloud amministrata dal Web con app Android e iOS complementari, Linux viene fornito con tutte le librerie, le utilità e i driver necessari per farlo.
2. Aumento della testabilità: se il dispositivo esegue bash o busybox con una porta SSH, è semplicissimo connettersi e capire cosa è andato storto durante la fase di test del prodotto.

Perché la tua idea di offuscamento funzioni, dovresti è necessario offuscare non solo i nomi delle utilità della riga di comando come sudo e ls , ma anche ogni API del kernel Linux per evitare che l'aggressore cada nel proprio binario compilato che ca carica direttamente il kernel. Quindi diamo un'altra occhiata alla tua idea:

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

Avrai bisogno di fare questa compilazione casuale da solo; altrimenti qualcuno potrebbe cercare le mappature su google.

Quindi, dovrai compilare il kernel dai sorgenti con il tuo "compilatore offuscante" in modo che solo tu conosca le mappature delle API del kernel offuscate. (hai mai costruito il kernel linux dai sorgenti? È sicuramente più un lavoro di routine di docker pull alpine , che è la direzione in cui la cultura dev sembra andare) .

Ma un sistema operativo è più del semplice kernel. Vuoi i driver per il chip wifi Broadcom BCM2837 che arriva su quel dispositivo mini-pc? Avrai bisogno di compilare quel driver sul tuo kernel ofbuscato con il tuo compilatore, se Broadcom ti darà anche il codice sorgente. Allora avrai bisogno di costruire l'intero stack di software GNU wifi e di rete. Di quante altre cose avrai bisogno per trovare la fonte e aggiungere alla tua pipeline di build prima di avere un sistema operativo funzionante?

Oh, e se i repository upstream di una di queste cose emettono una patch, ora sei responsabile della ricostruzione (supponendo che tu abbia salvato i file di mappatura dell'offuscamento del compilatore che corrispondono al tuo binario del kernel ) e distribuendolo ai tuoi dispositivi perché, in base alla progettazione, i tuoi dispositivi non possono utilizzare i binari di patch prodotti dal fornitore.

Oh, e per sventare gli hacker, non ce ne sarà nessuno di questo "Ecco i file binari per Whizpopper 1.4.7" , oh no, dovrai creare una versione offuscata in modo univoco di tutto dal kernel fino per dispositivo che spedisci.

Quindi, alle tue domande:

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

Penso che la risposta sia che ciò che stai descrivendo sconfigge praticamente completamente il scopo di utilizzare componenti software preesistenti se è necessario trovare e creare letteralmente tutto dalla fonte. In realtà potrebbe essere meno impegnativo abbandonare completamente il sistema operativo, fingere che sia il 1960 e scrivere la tua applicazione direttamente nel microcodice della CPU.

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

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

La risposta è in realtà sorprendentemente semplice: è una perdita di tempo e ci sono opzioni decisamente migliori. Ogni stupido scarabocchio IoT (ricorda, la "s" in "IoT" sta per Secure) che non si preoccupa di implementare tali funzionalità di sicuro non andrebbe con un approccio come suggerisci tu.

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 boom, sono nel kernel che eseguono la syscall di loro scelta; chi se ne frega qual è il nome simbolico? Certo, puoi manomettere la tabella syscall per complicare la cosa (se non ti dispiace dover ricompilare tutto e rendere il debug del tuo kernel personalizzato una forma di inferno totale) ma è come offuscare il sistema operativo in uso; perché preoccuparsi quando ci sono così pochi candidati, comunque? Anche se l'autore dell'attacco non vuole decodificare il codice esistente sul sistema, il brute-force dovrebbe essere possibile a meno che lo spazio di ricerca degli indici di chiamata utilizzabili non sia più ampio di quanto io abbia mai visto su un sistema embedded.
2. Perché offuscare i nomi dei comandi quando puoi semplicemente renderli completamente inaccessibili? Un chroot non funzionerà per i built-in della shell se stai eseguendo una shell , ma funziona bene per tutto il resto e davvero, perché il tuo singolo personalizzato a scopo di app-in-a-box eseguire una shell? Voglio dire, le unità di sviluppo ne avrebbero uno installato, a scopo di test, e forse questo non viene rimosso nella tua immagine di vendita al dettaglio 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ò impedire al programma 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 un processo (o i suoi discendenti ... se è consentito crearne) può fare. Vedi https://stackoverflow.com/questions/2146059/limiting-syscall-access-for-a-linux-application

Se il tuo obiettivo è privare un utente malintenzionato di ls e cat , esiste un'alternativa ancora migliore all'offuscamento: non installare queste utilità.

Anche se non direi che questo è un approccio di implementazione ampiamente , è almeno implementabile. Ad esempio, considera distroless, una raccolta di immagini docker con praticamente nulla al loro interno. Alcuni di loro (come quello per andare) letteralmente non contengono niente . Un attacco a un sistema in esecuzione in un tale contenitore non può ottenere l'accesso alla shell perché non c'è nessuna shell da eseguire.

L'unico modo per ottenere l'accesso alla shell attaccando un'applicazione in tale contenitore è quindi per aggirare il runtime del contenitore, che è progettato per impedire proprio questo.

Anche se ho fornito un esempio di 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. Puoi eseguire apt-get remove coreutils ed essere sicuro che un utente malintenzionato non sarà in grado di utilizzare 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 che potrebbe andare bene.

Il principio generale è ridurre la "superficie di attacco": più "cose" ha un obiettivo, 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.

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

Ci sono solo così tanti sistemi operativi comuni e così tanti modi per fare ipotesi plausibili. Se rilevi che sto eseguendo IIS o MSSQL Server, puoi indovinare quale sistema operativo è in esecuzione sotto.

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

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

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

Se perdi tempo in quello che avresti potuto spendere per un effettivo rafforzamento, stai effettivamente danneggiando la tua sicurezza .

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

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

Per un esempio estremamente diffuso, Intel Management Engine, che ha il 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 Huffman con parametri sconosciuti. Analogamente alla tua proposta (che è fondamentalmente una crittografia simmetrica del firmware), ME richiede modifiche specifiche al momento della preparazione del firmware e presenta una deviazione di corrispondenza dai meccanismi standard al momento dell'esecuzione.

Ciò che stai descrivendo si chiama "Security through Obscurity" ed è un antipattern di sicurezza ampiamente noto. Significa che non è un'idea nuova, piuttosto è un'idea vecchia, cattiva, che le persone che non sono iniziate nella filosofia della sicurezza devono essere istruite in modo da non cadere.

Immagina di progettare una casa per essere sicuro, e l'oscurità del pensiero era una strategia promettente. Tutte le case sono costruite con corridoi e stanze, porte con maniglie, interruttori della luce, ecc. Poiché sono comunemente noti, si potrebbe pensare che ciò non sia sicuro poiché un intruso potrebbe facilmente spostarsi nella casa grazie a questi elementi di costruzione comunemente noti. Potresti provare a ridisegnare i principi della costruzione da zero, sostituire i pomelli delle porte con cubi di rubik, realizzare soffitti a mezza altezza per confondere l'intruso, ecc. Ti ritroverai con una casa in cui è terribile vivere, non può essere mantenuta perché nessun imprenditore vuole nulla a che fare con esso, e peggio di tutto è per niente perché qualsiasi intruso, una volta dentro, può guardarsi intorno con gli occhi e usare il cervello per capirlo. Gli hacker in fondo sono dipendenti dai puzzle.

La soluzione per mettere in sicurezza la tua casa non è avere una costruzione non standard, ma avere serrature migliori, finestre protette, un sistema di sicurezza adeguato, ecc. Non voglio nascondere il tuo oro in un passaggio segreto, perché alla fine Abate e Costello si appoggeranno a quel candelabro e lo apriranno accidentalmente. Metti il ​​tuo oro in una cassaforte con una buona combinazione segreta e un allarme antimanomissione. L'equivalente del computer è avere accesso limitato alle credenziali tramite crittografia a chiave pubblica, ruoli di accesso utente limitati, sistemi di monitoraggio, riduzione dell'area di superficie esposta, mitigazione dei vettori delle minacce di ingresso, ecc.

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

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

Pensa useability

• Prova a spiegare al tuo nuovo amministratore di sistema che deve premere ha7TrUO all'inizio di sudo , RRI6e29 invece di ls e così via ... Sì, c'è un elenco di traduzioni che devi solo imparare!

• navigare nella rete locale non deve essere possibile: devi mantenere un elenco cartaceo per mantenere una visione d'insieme !?

• Se rinomini tutti i comandi critici, dovrai guidarlo per aggiornare il sistema!

• E come commento di Nick2253, se tu prova a creare un sistema incorporato, quindi offuscare prima di pubblicare il prodotto finale, dovrai testare il prodotto finale.

  • Devi creare uno script fatto in casa per associare tutto offuscamento.
  • Se qualcosa va storto, il debug diventerà complicato.
  • Devi creare script di deoffuscamento fatti in casa , per poter fare alcuni debug.
  • Feed-back personalizzato (con log fi les) dovrà essere deoffuscato .

  In questo modo, aggiungerai uno strato di lavoro importante con nuovi potenziali bug.

  Per pochissimi miglioramenti della sicurezza, guarda oltre

L'oscurità potrebbe farti del male.

Pensa a livello inferiore

• Anche se provi a rinominare file, funzioni a livello di applicazione e sistema operativo, tutto ciò utilizzerà le librerie standard che verranno chiamate direttamente se l'attaccante inviare file eseguibili binari. Potresti anche considerare di offuscare tutte le librerie standard! (Inclusi filesystem, protocolli di rete ...)

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

... Quindi collegare 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 è realmente possibile, a causa della necessità di utilizzare protocolli standard per poter gestire Internet.

Pensa a license

Se hai intenzione di distribuire GNU / Linux, devi condividere il codice sorgente come descritto in GNU GENERAL PUBLIC LICENSE GPLv3 e / o GNU LESSER GENERAL PUBLIC LICENSE LGPLv3 (a seconda dell'applicazione e librairies usate). Ciò implicherà la pubblicazione del metodo di offuscamento insieme a ogni prodotto distribuito .

Rispondendo rigorosamente alle tue due domande:

Sono un esperto, ma con un fuoco molto piccolo. Lavorando su molte infrastrutture diverse per 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 incontrato?

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

Se non ampiamente utilizzato, quali sono le barriere pratiche o tecniche all'uso?

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

Ovviamente, alcune cose minime sono da fare:

• Non avviare ssh server se non necessario
• Non installare sudo , usa permessi , gruppi corretti e una struttura coerente.
• Mantieni aggiornata la tua infrastruttura globale !!!”

Piccolo campione quando la luce viene sopra l'oscurità

• Protezione di ssh : bidirezionale.

  • Sposta la porta ssh da 22 a 34567

    • leggero e fatto velocemente, ma

    se un utente malintenzionato li trova, potrebbe esercitare una forza bruta regolare contro questa porta per molto tempo prima che l'utente finale li scopra.

  • installa firewall

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

    Più sicuro mentre aggiornato.

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

Un'alternativa migliore sarebbe semplicemente non installare questi comandi in il primo posto. Non credo che tu abbia bisogno di una shell per eseguire un kernel Linux, anche se questo implica che il tuo processo di avvio sia qualcosa di diverso da sysV-init o systemd.

As altri hanno notato, tuttavia, che si tratta di 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 facile per i compilatori. Prendiamo il caso più semplice di "rinominare 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 di bash, tali attacchi sarebbero inutili.

Non sono sicuro che tu abbia bisogno dell'aiuto del compilatore a tutti. Penso che tu possa ottenere questo risultato principalmente modificando il linker ¹ per applicare una randomizzazione a tutti i nomi dei 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 farlo, cioè penso che potresti applicare la manipolazione a codice già compilato.

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

C'è ancora qualche possibilità di decodificare il processo, tuttavia, e inoltre questo potrebbe violare la GPL² (specialmente 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 aggressori possono prendere di mira solo dispositivi specifici anziché essere in grado di sfruttare una vulnerabilità su " qualsiasi dispositivo che esegue Linux xyz".

(² Per semplicità, Userò solo "GPL" dappertutto, ma nota che questo in genere si applica anche per le cose con L GPL.)

Detto questo, nota che la GPL non ti richiede pubblicare il sale perché hai "modificato" le fonti. Se la randomizzazione del nome del simbolo avviene in fase di compilazione, non hai modificato i sorgenti. Il motivo per cui dovresti pubblicare il salt è perché la GPL richiede che gli utenti possano sostituire le proprie versioni di una libreria GPL, cosa che non possono fare se non conoscono il salt. (Come notato, potresti essere in grado di liberarti di questo con GPLv2, ma gli effetti tecnici sono simili a "eseguire solo software firmato", per cui GPLv3 è stata specificatamente scritta.)

In definitiva , potrebbe esserci qualche vantaggio qui, ma non renderai nessun sistema particolare notevolmente più sicuro (è risaputo che la "sicurezza attraverso l'oscurità" generalmente non è una sicurezza affatto). Ciò che puoi ottenere è rendere più difficile il targeting di molti sistemi tramite un singolo vettore.

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

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

Ora, se avessi la possibilità di ricostruire da zero per macchina, cosa 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 punta anche al famoso scambio in cui Linus Torvalds lo chiama teatro della sicurezza, ma l'autore del progetto (che lavora per Google) commenta: "Bene, Facebook e Google non pubblicano le loro build del kernel. :)"

Ciò porta alla conclusione che almeno Google lo fa e lo considera utile. Possiamo fare più tipi di rimescolamento su un set chiuso? Al livello più fondamentale, perché un virus Windows non funziona su Linux o su un 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 così diversi come Windows lo è per Linux. Ma non è impossibile, e non è nemmeno così difficile. Prendi l'approccio di KSPP e applicalo alle chiamate di sistema, quindi ricompila tutto in cima a quelle chiamate di sistema. Sarà molto difficile da rompere, almeno non in un flyby.

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 una volta per tutte le iniezioni di codice PHP. Nonostante ciò che HackerNews vorrebbe farti credere, le iniezioni di codice PHP non sono un problema risolto al di fuori delle bacheche Internet. Gli sviluppatori, gli amministratori e gli utenti PHP della vita reale sono esposti a un numero continuo di iniezioni di codice.

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

Condividiamo questo pubblicamente per sollecitare il feedback e gestiamo due siti web, polyscripted.com e nonpolyscripted.com, che fanno esattamente quello che ti aspetteresti in base ai loro nomi. Abbiamo anche assunto pentestri per cercare di romperlo.

E sto appena iniziando a sperimentare con librerie condivise eseguibili e rinominare i simboli esportati su un insieme chiuso (in un contenitore docker, per esempio). Personalmente non penso che questo aggiunga tanto valore, ma aggiungerà un po '? Credo di si. Quindi si tratta di costi. Se puoi ottenere poco valore a un costo ancora più basso, perché non farlo e basta? Questo è esattamente il motivo per cui abbiamo tutti ASLR: non è esattamente la più grande difesa dai tempi del 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 è stato tentato da molte persone (inclusi Google, Facebook, il kernel Linux, ecc.), insieme a molti accademici nel campo della difesa dei bersagli mobili e una manciata di aziende come i nostri che stanno cercando di renderlo banalmente consumabile come ASLR.

Vorrei dire come la vedo dal punto di vista degli hacker.

Sicuramente, se rinominerete tutte le utilità, mi renderà le cose molto più difficili e meno comode, ma cosa potrei fare?

1. Se ho già accesso alla shell sul sistema, caricarei solo busybox (tutte le utilità di base in un binario) o il set completo di binari di cui ho 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.). L'hacker non può caricare tali file (a meno che non sia già root). Il mio semplice piccolo sistema Linux ha solo 24 binari suid. È molto facile provare ciascuno di essi manualmente.

Ma comunque, sono d'accordo, questo renderebbe più difficile l'hacking di questa scatola. Sarebbe doloroso usare (hackerare) questo sistema, ma possibile. E l'hacker lavora sul sistema per ora, giorno o mese ... ma l'amministratore / utente può lavorare sul sistema per anni e non può ricordare i nomi ha7TrUO e RRI6e29. Forse nessuno tenterà nemmeno di hackerare il sistema, ma l'amministratore ne soffrirà ogni giorno.

Ma ... se rendi la sicurezza troppo alta ma scomoda per l'utente / amministratore, spesso stai abbassando la sicurezza. Ad esempio, se imponi password complesse con più di 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 i buoni utenti. E dovranno fare alcune cose per semplificare la loro vita. Ad esempio, possono caricare il loro binario busybox. Temprorary. E se ne dimenticheranno o lo lasceranno lì intenzionalmente (perché hanno intenzione di usarlo poco dopo).

In realtà succede, perché le connessioni ssh sono crittografate. Cambiare i nomi di alcuni binari principali non fa altro che questo. Inoltre causerebbe molto caos: ad es. qualsiasi script che fa affidamento su queste utilità viene reso inutilizzabile, oppure è necessario disporre di una sorta di "deoffuscatore" proxy, che finirebbe sicuramente come vettore di attacco. Tuttavia ho visto alcuni server in circolazione che non consentono il login di root, costringendo invece a utilizzare sudo. I nomi utente dei sudoer rimangono in qualche modo segreti. Non sono sicuro di quanto sia sicuro, ma non sono un esperto.

Perché non tutte le porte hanno dieci buchi della serratura, solo uno dei quali funzionava effettivamente come chiave o grimaldello? Risposta: per lo più il fastidio non vale i dieci secondi extra del tempo di un ladro.

Se ci fossero milioni di codice sorgente unico creato in isolamento sistemi operativi, l'oscuramento potrebbe essere comune. In pratica, tuttavia, abbiamo circa quattro basi di codice univoche in uso comune: tutte le informazioni sulle perdite su se stesse in base alla temporizzazione degli eventi e per diverse funzioni del sistema operativo di basso livello in cui i produttori di chip forniscono sequenze di bitcode della macchina prescritte per attivare o accedere a determinate funzionalità della CPU, essi probabilmente hanno tutte brevi sequenze contenenti esattamente lo stesso codice.

Se offuschi GNU / Linux su un dispositivo IoT distribuito al pubblico sarai costretto a pubblicare il tuo codice perché è sotto la GPL, o ritirare il dispositivo dal mercato.

Offuscare il software GPL - una strategia che dipende dalla segretezza - non è un'idea praticabile.

Non sono sicuro del motivo per cui questo è sottovoto; ma se le obiezioni sono nella vena dei commenti di Charles: semplicemente rinominare le utilità principali non funzionerà (per un semplice inizio, dovrai modificare gli script di inizializzazione GPL). Sospetto fortemente che dovrai anche ricompilare molti binari che interagiscono con altri binari come il driver del compilatore gcc, ld.so, sh / bash ecc. Tutti gli script di shell e molti file di configurazione devono conoscere i nomi e le posizioni di binari, quindi devono essere modificati.

Tutto questo è GPL e sarai costretto a pubblicare i sorgenti, gli script e i file di configurazione modificati, vanificando così gli sforzi di offuscamento. Se utilizzi il dispositivo solo internamente non c'è alcun obbligo di pubblicare i sorgenti, ma allo stesso tempo il motivo dell'offuscamento è molto più debole: frustrerai soprattutto te stesso.

I compilatori (in realtà, i linker) lo fanno già. È uno dei motivi principali per cui il reverse engineering è difficile.

Nel tuo codice sorgente potresti avere queste funzioni:

  void print_hello () {printf ("Hello! \ N ");} void print_hello_twice () {print_hello (); print_hello ();}  

Ecco come si occupano di essere compilati in un programma:

  0x400582 push rbp0x400583 mov rbp, rsp0x400586 mov edi, 0x4006340x40058b chiama 0x4004900x400590 nop0x400591 pop rbp0x400592 ret0x400593 premi rbp0x400594 mov rbp, rsp0x400597 chiama 0x4005820x40059c chiama 0x4005820x4005a1 nop0x4005a2 pop rbp0x4005a3 mov rbp, rsp0x400597 chiama 0x4005820x40059c chiama 0x4005820x4005a1 nop0x4005a2 pop rbp0x4005a3  0x400582 ,  printf  ora si chiama  0x400490  e  print_hello_twice  ora si chiama  0x400593 . A tutte le chiamate sono stati dati anche gli stessi nomi casuali, in modo che le funzioni siano in grado di chiamarsi a vicenda.  
 Tuttavia, il linker è in grado di farlo solo all'interno di un programma, poiché collega un programma alla volta .