Richieste HTTP non valide con protocollo ripetuto (GET /https://https://www.DOMAIN.com) nei registri di Apache: quale vulnerabilità stanno cercando?

Question

Richieste HTTP non valide con protocollo ripetuto (GET /https://https://www.DOMAIN.com) nei registri di Apache: quale vulnerabilità stanno cercando?

#1 da (1 voti)

8

Circa una volta al giorno, sto visualizzando le seguenti serie di richieste nei miei log httpd di Apache 2.4 e sto cercando di capire per quale tipo di vulnerabilità viene eseguita la scansione. Ogni occorrenza di queste scansioni ha uno schema identico (ha sostituito il mio nome di dominio con DOMAIN):

89.123.16.10 - - [20/Dec/2017:05:35:37 +0000] "GET /https://https://www.DOMAIN.com HTTP/1.1" 301 236
89.123.16.10 - - [20/Dec/2017:05:35:37 +0000] "GET /https://https://https://www.DOMAIN.com HTTP/1.1" 301 236
89.123.16.10 - - [20/Dec/2017:05:35:38 +0000] "GET /https://https://https://https://www.DOMAIN.com HTTP/1.1" 301 236
89.123.16.10 - - [20/Dec/2017:05:35:38 +0000] "GET /https://https://https://https://https://www.DOMAIN.com HTTP/1.1" 301 236
89.123.16.10 - - [20/Dec/2017:05:35:38 +0000] "GET /https://https://https://https://https://https://www.DOMAIN.com HTTP/1.1" 301 236
89.123.16.10 - - [20/Dec/2017:05:35:39 +0000] "GET /https://https://https://https://https://https://https://www.DOMAIN.com HTTP/1.1" 301 236
89.123.16.10 - - [20/Dec/2017:05:35:39 +0000] "GET /https://https://https://https://https://https://https://https://www.DOMAIN.com HTTP/1.1" 301 236
89.123.16.10 - - [20/Dec/2017:05:35:39 +0000] "GET /https://https://https://https://https://https://https://https://https://www.DOMAIN.com HTTP/1.1" 301 236
89.123.16.10 - - [20/Dec/2017:05:35:39 +0000] "GET /https://https://https://https://https://https://https://https://https://https://www.DOMAIN.com HTTP/1.1" 301 236
89.123.16.10 - - [20/Dec/2017:05:35:39 +0000] "GET /https://https://https://https://https://https://https://https://https://https://https://www.DOMAIN.com HTTP/1.1" 301 236
89.123.16.10 - - [20/Dec/2017:05:35:39 +0000] "GET /https://https://https://https://https://https://https://https://https://https://https://https://www.DOMAIN.com HTTP/1.1" 301 236
89.123.16.10 - - [20/Dec/2017:05:35:39 +0000] "GET /https://https://https://https://https://https://https://https://https://https://https://https://https://www.DOMAIN.com HTTP/1.1" 301 236
89.123.16.10 - - [20/Dec/2017:05:35:40 +0000] "GET /https://https://https://https://https://https://https://https://https://https://https://https://https://https://www.DOMAIN.com HTTP/1.1" 301 236
89.123.16.10 - - [20/Dec/2017:05:35:40 +0000] "GET /https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://www.DOMAIN.com HTTP/1.1" 301 236
89.123.16.10 - - [20/Dec/2017:05:35:40 +0000] "GET /https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://www.DOMAIN.com HTTP/1.1" 301 236
89.123.16.10 - - [20/Dec/2017:05:35:40 +0000] "GET /https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://www.DOMAIN.com HTTP/1.1" 301 236
89.123.16.10 - - [20/Dec/2017:05:35:40 +0000] "GET /https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://www.DOMAIN.com HTTP/1.1" 301 236
89.123.16.10 - - [20/Dec/2017:05:35:41 +0000] "GET /https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://www.DOMAIN.com HTTP/1.1" 301 236
89.123.16.10 - - [20/Dec/2017:05:35:41 +0000] "GET /https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://www.DOMAIN.com HTTP/1.1" 301 236
89.123.16.10 - - [20/Dec/2017:05:35:41 +0000] "GET /https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://www.DOMAIN.com HTTP/1.1" 301 236
89.123.16.10 - - [20/Dec/2017:05:35:41 +0000] "GET /https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://www.DOMAIN.com HTTP/1.1" 301 236
89.123.16.10 - - [20/Dec/2017:05:35:41 +0000] "GET /https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://www.DOMAIN.com HTTP/1.1" 301 236
89.123.16.10 - - [20/Dec/2017:05:35:42 +0000] "GET /https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://www.DOMAIN.com HTTP/1.1" 301 236
89.123.16.10 - - [20/Dec/2017:05:35:42 +0000] "GET /https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://www.DOMAIN.com HTTP/1.1" 301 236

Le richieste provengono dai seguenti host:

103.194.169.16 - Netherlands (Java 1.8 client running on an IIS 8.5 Windows Server)
109.102.111.66 - Bucharest, Romania (Java 1.6 client, banned by one service)
109.102.111.67 - Bucharest, Romania (Java 1.6 client, banned by several services, dictionary attacks, spam house)
109.102.111.76 - Bucharest, Romania (Java 1.7 client, banned by several services)
109.102.111.84 - Bucharest, Romania (Java 1.6 client, banned by one service)
109.102.111.89 - Bucharest, Romania (Java 1.6 client, banned by one service)
109.102.111.92 - Bucharest, Romania (Java 1.6, 1.8 clients, banned by several services, dictionary attacks, spam house)
172.111.130.9 - Bucharest, Romania (Java 1.6 client, banned by one service)
172.111.200.61 - Frankfurt, Germany (Java 1.6 client, banned by one service)
23.227.201.194 - [Swiftway Cloud - swiftwaycloud.com] Chicago, United States (Java 1.6 client running on an IIS 7.5 ASP.NET server, banned by one service)
79.5.128.38 - Piansano, Lazio, Italy (Java 1.6 client, banned by several services)
89.123.14.74 - Bucharest, Romania (Java 1.6 client, banned by several services, spam house)
89.123.16.10 - Bucharest, Romania (Java 1.6 client, banned by several services)
89.123.20.221 - Bucharest, Romania (Java 1.6 client, banned by several services, spam house)
89.123.31.76 - Bucharest, Romania (Java 1.6 client, banned by several services, dictionary attacks, spam house)
89.136.31.222 - Bucharest, Romania (possibly a home broadband address, Java 1.6 client, banned by several services, dictionary attacks, spam house)

La maggior parte degli host sono rumeni, quindi presumo che la fonte di queste scansioni sia basata lì. Inoltre, l'unico modello che riesco a distinguere nei tempi di richiesta è che queste richieste non si sono mai verificate dalle 09:00 UTC alle 12:00 UTC, che sarebbero le 23:00 alle 3:00 in Romania. Ogni altro blocco di 30 minuti di tempo è stato coperto, con un numero massimo di occorrenze di 4 al giorno e un minimo di 1 al giorno.

Come menzionato nei commenti, utilizzo una regola di reindirizzamento per inoltrare richieste HTTP a HTTPS:

RedirectMatch permanent ^ https://www.DOMAIN.com

Vale la pena notare che queste richieste vengono visualizzate solo nei registri non SSL. La configurazione del mio server restituisce un 301 (spostato in modo permanente), che reindirizza le richieste non SSL al link . Gli indirizzi IP che eseguono queste scansioni non effettuano mai richieste tramite HTTPS e solo eseguono scansioni di questo tipo.

Ho riprodotto il registro esatto usando curl:

C:\>curl -s -D - http://www.DOMAIN.com/https://https://www.DOMAIN.com
HTTP/1.1 301 Moved Permanently
Date: Thu, 21 Dec 2017 15:49:58 GMT
Server: Apache
Location: https://www.DOMAIN.com
Content-Length: 236
Content-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>301 Moved Permanently</title>
</head><body>
<h1>Moved Permanently</h1>
<p>The document has moved <a href="https://www.DOMAIN.com">here</a>.</p>
</body></html>

Risultati nella voce di registro (sostituito il mio dominio e l'indirizzo IP):

192.168.1.5 - - [21/Dec/2017:14:29:57 +0000] "GET /https://https://www.DOMAIN.com HTTP/1.1" 301 236

Riepilogo

Richiesta iniziale non valida dall'host remoto:

GET http://www.DOMAIN.com/https://https://www.DOMAIN.com

Il mio server ritorna:

301 https://www.DOMAIN.com

L'URL precedente non viene mai richiesto dall'host remoto.

Seconda richiesta non valida dall'host remoto:

GET http://www.DOMAIN.com/https://https://https://www.DOMAIN.com

Il mio server ritorna (vedi esempio di arricciatura sopra per la risposta esatta del server):

301 https://www.DOMAIN.com

L'URL precedente non viene mai richiesto dall'host remoto.

E così via, per 24 iterazioni. Il fatto che il mio server restituisca sempre https://www.DOMAIN.com indica che gli URL malformati vengono creati deliberatamente dall'host remoto.

Esiste una specifica vulnerabilità nota o un'errata configurazione del server per cui si sta eseguendo la scansione?

Credo che qualsiasi problema con i certificati SSL possa essere escluso semplicemente basandosi sul fatto che non vengono mai fatte richieste SSL da questi host (a meno che le scansioni non siano compartimentate per evitare di implicare altri host).

Ho trovato solo un altro caso simile di questo (aprile 2016):

Impossibile mappare GET / https: /// https: /// https: / https: /// https: / https: / https: / ...

Ho aggiunto i metadati da Project Honeypot e Qual è la mia lista nera di indirizzi IP . Tutti questi host utilizzano tutti i client Java, da Java 1.4 a Java 1.8.

apache vulnerability-scanners

posta vallismortis 21.12.2017 - 15:45

fonte

1 risposta

Leggi altre domande sui tag apache vulnerability-scanners

I CIRT maturi raccolgono informazioni sui loro aggressori. Quali fonti e metodi sono usati per questo? Come ottenere privacy e autenticità con DNS?

score 1 · Accepted Answer

Ho aggiornato la domanda per aggiungere informazioni sugli host remoti che hanno fatto queste richieste. Si scopre che tutti tranne uno sono già in blacklist pubbliche per una serie di motivi (attacchi di dizionario, spam, scansione del sito non corretta). Le richieste sono state fatte da una varietà di macchine virtuali Java obsolete, che potrebbero indicare che tutti questi host sono compromessi (tuttavia, poiché la maggior parte proviene da un singolo paese, questo potrebbe fungere da contrappunto a tale argomento).

È interessante notare che due dei tre host non rumeni stanno eseguendo server IIS (v7.5 e v8.5) - sospetto strongmente che questi siano host compromessi. Solo per i calci, ho tentato le stesse richieste HTTP malformate contro quei server e ho semplicemente ricevuto 404 errori. Gli host rumeni non sono (apparentemente) in esecuzione su IIS, ma sono (apparentemente) in esecuzione su versioni antiche di Java.

Il punto su come effettuare queste richieste con versioni precedenti di Java (da 1.4 a 1.6) è che quelle versioni non supportano alcun SSL comune implementato sul web. Java 1.6 supporta SSLv3 e TLS 1.0 , né supportano SNI . Questo è lo stesso server che ho descritto nella domanda SNI Hole .

In definitiva, potrebbe essere stato rilevato un loop di reindirizzamento da parte del client remoto, non a causa di una configurazione errata, ma più probabilmente a causa della mancanza di supporto SNI nelle loro vecchie macchine virtuali Java. Le richieste passerebbero al mio host predefinito (www.DOMAIN.com) solo tramite l'indirizzo IP, che poi reindirizzerà al nome host predefinito. In sostanza, il mio server restituisce un nome host SNI ma il loro client non lo capisce.

Presumo che la ragione per cui queste richieste provengono da una varietà di vecchie macchine virtuali Java è che sono state compromesse da alcune vulnerabilità note di Java e / o vulnerabilità di IIS note.

L'accumulo di "/ https: //" negli URL reindirizzati è potenzialmente dovuto al fatto che il protocollo non è supportato nel codice Java del crawler / scanner, il che avrebbe senso poiché lo stesso codice è (probabilmente) in esecuzione su Java 1.4 (no SSL, no SNI, minimo comune denominatore), 1.6 SSLv3 + TLS1.0, 1.7 (SSL + SNI) e 1.8 (SSL + SNI). Se il codice è pensato per essere eseguito su Java VM antiche, non vi è alcun motivo reale per supportare o addirittura comprendere SSL nel codice, quindi potrebbe aver considerato un URL del protocollo HTTPS essere relativo anziché assoluto.

In definitiva, per determinare la natura esatta di queste richieste, avrei bisogno di una copia del file WAR, JAR o di classe che viene utilizzato per fare queste richieste. Ho contattato Swiftway Cloud per vedere se potevano fornire una copia dal loro server compromesso a Chicago che partecipa a questa attività.

Aggiornamento: Swiftway Cloud ha risposto che non è stato possibile identificare alcuna attività "dannosa" sul loro host, anche con le informazioni fornite qui. Questo è un problema, perché la separazione delle responsabilità ("innocuo" scansione / sondaggio contro spamming "dannoso"), anche con chiare prove di complicità tra gli host, sembra aver portato a un punto in cui non è possibile convincere il cloud fornitori di adottare misure reattive per un problema documentato.