Cosa potrebbe fare un hacker con il mio wp-config.php

11

Sto cercando di proteggere il mio blog wordpress. Ho letto alcuni post sul Web che dovrei cambiare il mio table_prefixe nascondere il mio wp-config.php. Tuttavia, non capisco? Cosa potrebbe fare un attaccante con il mio wp-config.php?

Voglio dire, ci sono le mie configurazioni db, ma l'attaccante ha bisogno del mio DB_HOSTper esempio, che non è così facile da ottenere, per connettersi al mio db? (Nel mio caso è: define('DB_HOST', 'localhost');che l'attaccante non poteva usare per connettersi al mio db )

O mi manca sth?

Apprezzo molto la tua risposta!

plugins security wp-config

— Kare
fonte

Immagino che sarà facile per lui iniettare SQL. Ha recitato. In attesa che gli esperti rispondano a questo.

— Robert hue,

Puoi anche pubblicarlo su Programming Puzzles & Code Golf beta e vedere cosa viene in mente alla gente. :)

— Joshua Taylor

1

@JoshuaTaylor Per favore no. A parte le ovvie questioni etiche, non è questo il nostro sito: ci piacciono solo le domande che sono in grado di avere un criterio vincente oggettivo per decidere quale soluzione vince, non solo "Ehi, scriviamo tutti il codice e divertiamoci! Yaaaay!"

— Doorknob,

@Doorknob Beh, ovviamente sarebbe un concorso di popolarità. Ma sul serio, speravo che il ":)" avrebbe comunicato che non ero serio. Se qualcuno ha provato a pubblicare i propri file wp-config di conseguenza, accetta le mie scuse.

— Joshua Taylor,

9

localhostsi riferisce alla macchina su cui è in esecuzione. Ad esempio, sul mio sito tomjn.com localhost è 127.0.0.1come sempre. Questo non significa che l'hacker non sa dove collegare, significa che la sostituisce di hacker localhostcon tomjn.com.

Naturalmente se avessi un proxy seduto davanti non funzionerebbe, ma tieni presente che se l'attaccante ha accesso al mio wp-config.php, quello stesso accesso consentirebbe loro di fare altre cose su quella macchina.

Quindi ora l'attaccante ha i dettagli del tuo database e può leggere wp-config.php. Ora hanno accesso a tutto nel tuo database e possono cambiare qualsiasi cosa nel tuo database.

A seconda della sicurezza dell'installazione, possono creare un utente autonomamente, accedere, caricare un plug-in tramite zip con uno script PHP Shell e iniziare a emettere comandi o utilizzare il sito come parte di una rete bot.

Hanno anche i tuoi sali e le tue chiavi segrete (se non ne hai una, cattiva, cattiva), quindi forzare brutalmente le password degli utenti diventa notevolmente più semplice. Hanno anche accesso alle loro e-mail.

Basti dire che ottenere wp-config.phpè una delle peggiori cose che potrebbero accadere. Molte altre cose possono essere fatte con esso, ma ci vorrebbero mesi per scrivere ogni possibile attacco derivante da questo.

Nel caso in cui wp-config.phpvenga acquisito, è probabile che lo abbia fatto uno script di attacco automatico, non una persona reale. Modifica tutti i tuoi dati, reimposta tutte le password e chiudi la buca.

— Tom J Nowell
fonte

2

Questo non significa che l'hacker non sa dove collegare, significa che la sostituisce di hacker localhostcon tomjn.com. > Presumo che tu abbia la porta sul database accessibile al mondo esterno. Non saresti al sicuro se hai chiuso la porta nelle regole del firewall, consentendo solo ai computer sulla rete locale (incluso il computer che esegue Wordpress stesso) di connettersi al database?

— IQAndreas,

1

Sarebbe comunque la posizione corretta, ma sì, le porte sono rilevanti, miravo principalmente alla nota originale nella domanda

— Tom J Nowell

2

Se si accetta l'accesso al database solo da localhost(questo non si ottiene definendo DB_HOSTcome localhost)? Non troppo da solo (il caso peggiore sarebbe un utente malintenzionato che subentra nell'account amministratore), ma in combinazione con altre vulnerabilità potrebbe essere utile per un utente malintenzionato avere accesso alla propria configurazione.

Credenziali di accesso

Le persone riutilizzano i loro nomi utente e password. Un utente malintenzionato verificherà se il nome utente e la password del database (o varianti di essi) funzionano per l'installazione di wordpress, per il tuo hoster, per la tua e-mail, ecc.

Per lo meno, un utente malintenzionato ha un'idea del tipo di password utilizzate (totalmente casuale, solo minuscole / numeri, lunghezza, ecc.).

Prefisso tabella

Se è possibile un'iniezione SQL, un utente malintenzionato deve conoscere i nomi delle tabelle. A seconda del database, questo potrebbe essere molto semplice o potrebbe implicare un'ipotesi. Se implica indovinare, è meglio avere il prefisso della tabella.

Chiavi e Sali

Ho trovato questo articolo che suggerisce che davvero non vuoi che siano trapelate (in pratica, chiunque potrebbe subentrare al tuo account amministratore), anche se non so quanto sia aggiornato.

Set di database

Alcune iniezioni di SQL dipendono dal set di caratteri, quindi è bene che un aggressore lo sappia.

Sommario

Se non si consente l'accesso esterno al database, se non si riutilizzano le password e se non si hanno iniezioni SQL da nessuna parte, la preoccupazione principale sarebbe la chiave e i sali.

— Tim
fonte

Quell'articolo è abbastanza aggiornato. Non vuoi che i tuoi sali e le tue chiavi perdano. Quelle sono informazioni private. Se si sospetta addirittura che siano stati resi disponibili, cambiarli immediatamente in qualche altro set di dati casuali. Non c'è alcun aspetto negativo nel cambiarli, ti disconnetterà semplicemente dal sito Web e dovrai accedere di nuovo. Puoi ottenere un nuovo set casuale di chiavi e sali da qui: api.wordpress.org/secret-key/1.1/salt

— Otto

1

Presumo che tu stia chiedendo l'accesso in lettura, poiché l'accesso in scrittura è fondamentalmente l'accesso per iniettare il proprio codice per fare tutto ciò che gli piace con il tuo sito.

Il tuo presupposto che le informazioni del DB non siano sensibili è sbagliato. Supponiamo che il tuo sito sia ospitato su godaddy. godaddy AFAIK sta usando un server mysql dedicato a cui probabilmente è possibile accedere solo dai propri server, ma se conosco i tuoi dettagli quanto è difficile per me creare un account godaddy e scrivere uno script che acceda al tuo database? Nel caso di DB locali è più difficile da sfruttare, ma sui server di hosting condiviso potresti avere 100 siti che condividono il server con te, puoi fidarti di loro per essere abbastanza sicuro che Mr Evil non può entrare in loro e usarli per attaccare il tuo sito?

— Mark Kaplun
fonte