Che tipo di attacco era questo?

Question

Che tipo di attacco era questo?

#1 da (13 voti)
#2 da (13 voti)
#3 da (5 voti)

11

Quindi il nostro sito Web è stato violato e queste sono le cose che sono state fatte:

Alcune voci nel database sono state modificate. Non so se ciò avvenisse tramite SQL injection, o accesso diretto al database (solo a root è consentito apportare modifiche al database, è possibile emulare root o ottenere la sua password?) O attraverso il CMS del sito. La mia ipotesi è che fosse attraverso il CMS.
Il codice della pagina dell'indice è stato modificato in una significativa dichiarazione di successo hacking da parte dell'hacker.

Ho appena ottenuto una scansione gratuita eseguita da Qualys ( link ) che dice che SSL Server Allows Anonymous Authentication Vulnerability . Questo è probabilmente vero perché ogni volta che accedo a FTP, mi dice che alcuni certificati non sono validi, ma io ignoro sempre e premo "Continua". Sto usando un account VPS (non condiviso) sul server della mia società di hosting.

Quali sono le prime cose che dovrei cercare di sistemare?

Modifica n. 1

Ho appena trovato alcuni file strani aggiunti sul server, incluso un "wso.php" che sembrava accedere ai cookie e ad altre cose con le password di sistema. Poi nella cartella public_html ho trovato una nuova cartella che non avevo mai visto prima, chiamata sym , e quando l'ho aperta, ecco che c'era una cartella chiamata root che era fondamentalmente un clone ricorsivo della mia intera cartella radice e accanto ad esso un .htaccess che diceva quanto segue:

 Options all 
 DirectoryIndex Sux.html 
 AddType text/plain .php 
 AddHandler server-parsed .php 
 AddType text/plain .html 
 AddHandler txt .html 
 Require None 
 Satisfy Any

Ho alcune domande -

Ciò fornisce ulteriori indizi su quale tipo di attacco fosse?
Sono questi contenuti "cattivi" .htaccess?
Uno dei file era boy.php.jpg. Dato che una delle forme del sito consente agli utenti di caricare immagini, memorizzare i loro percorsi di file e quindi attraverso un CMS con DB di accesso accede a quelle immagini caricate, potrebbe essere stata un'iniezione SQL in cui è stato caricato un file dannoso vestito come un'immagine e poi accesso come contenuto regolare della pagina?

La mia azienda è infastidita dall'hack ma devo ammettere che sono un po 'eccitato per questo mistero! (un principiante alla sicurezza come probabilmente puoi dire)

Modifica n. 2

Ancora un altro aggiornamento. Ho scoperto questa pagina: link

Cos'è questa e qualche idea su come funziona? Il mio sito web è uno di quelli elencati, quindi forse la shell è stata "caricata" come file jpg?

Modifica # 3

Per qualche ragione non mi è venuto in mente di menzionarlo prima, ma il mio database MySQL è stato violato - quando sfoglio le tabelle tramite phpMyAdmin, alcune delle colonne ID di alcune tabelle sono piene di righe come cat /etc/pwd e %codice%. Questo significa che il punto di ingresso è stato sicuramente un'iniezione SQL?

sql-injection permissions web-application tls known-vulnerabilities

posta user961627 14.05.2013 - 10:53

fonte

3 risposte

Leggi altre domande sui tag sql-injection permissions web-application tls known-vulnerabilities

La denominazione delle cose sensibili fornisce discretamente protezione? Come posso verificare quale tipo di crittografia in modalità blocco viene utilizzata quando non è disponibile alcun codice sorgente?

score 13 · Answer 1

Ottieni una versione pulita e nota del tuo sito e identifica le differenze tra il codice noto e il codice di produzione corrente (compromesso). Studia come possono essere state apportate le modifiche e le riparazioni.
Aggiorna le password.
Correzione del problema del certificato FTP: prendere in considerazione l'utilizzo dell'autenticazione a 2 fattori.
Trova un modo per scansionare il tuo codice alla ricerca di vulnerabilità - peer review o analisi automatizzata.
Abilita la registrazione, quindi se ciò accade di nuovo hai i file di registro. Se hai già una registrazione decente, guarda i file a cui hai accesso e controlla se c'è un'iniezione tramite l'URL.
Considera l'utilizzo di un firewall per applicazioni Web.
Informa il tuo ufficio legale, la polizia, i partner, i clienti se ritieni che i loro dati siano stati rubati o compromessi

score 13 · Answer 2

Se l'unico utente sul database che può modificare i record è root e il CMS utilizza l'utente root per eseguire query, si ha un problema. Il tuo utente root dovrebbe mai essere utilizzato da un sito web.

Ottieni un utente limitato che può accedere solo alle tabelle e ai record di cui ha bisogno per accedere limitato con le giuste autorizzazioni. Se non ha bisogno di eliminare o aggiornare, quindi non dare tale accesso. Questo è noto come il principio del privilegio minimo:

In information security, computer science, and other fields, the principle of least privilege (also known as the principle of minimal privilege or the principle of least authority) requires that in a particular abstraction layer of a computing environment, every module (such as a process, a user or a program depending on the subject) must be able to access only the information and resources that are necessary for its legitimate purpose.

Controlla anche che gli utenti anonimi non possano accedere al tuo server FTP, assicurati di cambiare la configurazione del tuo ftp. Per evitare comunicazioni in chiaro, evitare TLS_RSA_WITH_NULL_MD5 e TLS_RSA_WITH_NULL_SHA , in quanto questi due pacchetti di crittografia hanno 0 Simmetric Key Strength.
Ottieni anche un server syslog remoto in modo da poter vedere almeno le richieste fatto e scoprire cosa è successo.
Ottieni un firewall per l'applicazione web
Installa un HIDS sul tuo server come OSSEC che bloccherà gli utenti e ti avviserà quando è stato scoperto un tentativo di entrare nel tuo server.
Potrebbe voler presentare un reclamo formale alla polizia.

E soprattutto:

Nuke dall'orbita, è l'unico modo per essere sicuro : ripristina il tuo computer da un backup, è stato compromesso e non può più essere considerato attendibile.

score 5 · Answer 3

Questo è molto probabilmente un attacco LFI (Local File Inclusion) PHP. La "foto" .php.jpg contiene effettivamente un codice PHP valido che viene poi analizzato da un altro script sul tuo sito che è vulnerabile a LFI.

Gli altri file trovati sono stati eliminati dopo lo sfruttamento dopo che la vulnerabilità LFI è stata sfruttata.

Puoi postare il ragazzo.php.jpg per ulteriori analisi. Ospitalo da qualche altra parte nella sua forma grezza quando pubblichi un link perché questo sito potrebbe modificare le immagini pubblicate e le stringhe di attacco sono probabilmente in dati EXIF che potrebbero essere rimosse.

Consiglia di auditare il tuo codice .PHP e la configurazione della distribuzione PHP per le vulnerabilità. Mentre un "firewall per applicazioni web" è una buona misura, non sostituisce la necessità di controllare il tuo codice per i difetti di sicurezza.