Quale attacco richiede gli URL "wp-admin" senza i cookie di accesso?

2

Guardando attraverso i miei file di log di Apache (formato di file di registro "combinato"), vedo un gran numero di richieste di URL che terminano con "wp-admin". Questo è piuttosto strano, dal momento che il mio server non esegue WordPress. Ho anche un documento 404 che è un programma PHP che registra $ _REQUEST, $ _SERVER, $ _COOKIE e $ _FILES. Apparentemente ho cancellato un po 'di quell'output, ma in quello che ho conservato, nessuna delle richieste per gli URL di "wp-admin" ha i cookie di accesso di WordPress.

Per quanto posso dire, questo è un nuovo attacco, non ne ho traccia dalla scorsa estate.

Cosa sta succedendo qui? Una vera installazione di WordPress reindirizza al login di WordPress. Un WordPress non configurato fornisce semplicemente un messaggio di errore. Cosa diavolo puoi ricavare da queste informazioni?

UPDATE : aggiungi ulteriori informazioni richieste da un risponditore. Questo è da una sonda "tipica".

URL completo richiesto: link

Nessun cookie, nemmeno il "wordpress_test_cookie" che WordPress "wp-login.php invia con la sua schermata iniziale di login HTML, HTTP GET, nessun parametro GET. Nessuna stringa User-Agent. Connessione: Chiudi.

p0f dice che viene da "Linux 2.6 (più recente, 10) (possibilmente Ubuntu 11.04)".

In altre richieste di questo tipo, l'URL può terminare in /blog/wp-admin/ , /wordpress/wp-admin/ o /wp/wp-admin/ . e in pochissimi casi, /wordpress/wordpress/wp-admin/ . Ogni richiesta condivide la mancanza di cookie, nessuna stringa User-Agent, metodo GET e nessun parametro GET sull'URL, insieme a "Connection: Close". Dovrei fare del lavoro che richiede molto tempo per ottenere un intervallo di numero di porta TCP di un mittente e una raccolta migliore di ciò che p0f pensa che sia il sistema operativo mittente.

    
posta Bruce Ediger 24.02.2014 - 18:40
fonte

1 risposta

1

Senza conoscere l'URL richiesto completo (e qualsiasi post o ottenere vars) è impossibile dirlo con certezza.

Ci sono molte cose che potrebbero provare. Potrebbe come Gray suggerire qualcuno che trasporta scansioni per accertare quali domini eseguono wordpress (tuttavia ottenere queste informazioni da Google sarebbe una prospettiva molto più semplice).

Un'altra possibilità è che qualcuno abbia erroneamente identificato il tuo dominio come wordpress in esecuzione (ha mai usato wordpress?). Potrebbero eseguire la scansione del tuo sito usando qualcosa come wpscan. Se wpscan è in uso, mi aspetterei molte altre richieste nello stesso periodo alla ricerca di altri file (ad esempio la cartella dei plug-in).

Come suggerisci potrebbero anche essere alla ricerca di una vulnerabilità specifica. Tuttavia, senza sapere quali script stanno cercando di raggiungere e se ci sono post o ottenere vars, non sarebbe possibile per noi accertarlo.

    
risposta data 21.05.2014 - 17:59
fonte

Leggi altre domande sui tag