it-swarm.com.de

Xenial: Seltsamer Code & Repo während des Updates

Hy!

Zunächst die Erklärung des Problems:

Canonicals IP 91.189.88.162 (eine der sechs IPs, zu denen security.ubuntu.com führt) gibt eine HTTP 302-Weiterleitung an " http://179.184.158.89:80/pdata/05f7e7f89ba2302b/security.ubuntu.com" zurück/ubuntu/dists/xenial-security/InRelease ". Diese IP gehört zu keinem offiziellen Ubuntu-Spiegel und die URI enthält eine Art von Kennung (es kann sich um einen Tracking-Code handeln, der sich bei jeder Anfrage ändert). Die Untersuchung ergab, dass es sich nicht um ein Software-/Betriebssystemproblem handelt (das problemlos von einem anderen Laptop reproduziert werden kann, der von einem mit Telefonicas Modem verkabelten Live-USB-Stick gebootet wurde. Es kann anscheinend nirgendwo anders reproduziert werden).

Sollen sich Canonicals Repositories unter allen Umständen so verhalten? Pcap-Beispiel am Ende dieser Nachricht angehängt. Manuelle HTTP-Anforderung imitiert "apt-get update":

[email protected]:~$ GET -USed -H "Host: security.ubuntu.com" -H "User-Agent: Debian APT-HTTP/1.3 (1.2.24)" http://91.189.88.162/ubuntu/dists/xenial-security/InRelease
GET http://91.189.88.162/ubuntu/dists/xenial-security/InRelease
Host: security.ubuntu.com
User-Agent: Debian APT-HTTP/1.3 (1.2.24)

302 Found
Cache-Control: no-cache
Connection: close
Location: http://179.184.158.89:80/pdata/05f4cdcfbada50fc/security.ubuntu.com/ubuntu/dists/xenial-security/InRelease
Content-Length: 0
Content-Type: text/html
Client-Date: Sat, 25 Nov 2017 20:44:04 GMT
Client-Peer: 91.189.88.162:80
Client-Response-Num: 1
X-Content-Type-Options: nosniff

GET http://179.184.158.89:80/pdata/05f4cdcfbada50fc/security.ubuntu.com/ubuntu/dists/xenial-security/InRelease
User-Agent: Debian APT-HTTP/1.3 (1.2.24)

200 OK
Cache-Control: max-age=1144, s-maxage=3300, proxy-revalidate
Connection: close
Date: Sat, 25 Nov 2017 20:13:04 GMT
Accept-Ranges: bytes
ETag: "18ef2-55ed440fdb600"
Server: nginx
Content-Length: 102130
Expires: Sat, 25 Nov 2017 21:05:00 GMT
Last-Modified: Sat, 25 Nov 2017 20:10:00 GMT
Client-Date: Sat, 25 Nov 2017 20:44:05 GMT
Client-Peer: 179.184.158.89:80
Client-Response-Num: 1
X-OC-Service-Type: re

Nun zur langen, umfassenden Version (gründliche Analyse, unnötige Lektüre, wenn Sie anhand der obigen Informationen herausgefunden haben, was falsch ist):

Bei einem Routinecheck gestern in einer meiner VMs ist mir etwas Merkwürdiges aufgefallen:

[email protected]:/# apt-get update ; apt-get upgrade -y
Hit:1 http://br.archive.ubuntu.com/ubuntu xenial InRelease
Get:2 http://br.archive.ubuntu.com/ubuntu xenial-updates InRelease [102 kB]                                                         
Get:3 http://br.archive.ubuntu.com/ubuntu xenial-backports InRelease [102 kB]                                                                 
Get:5 http://br.archive.ubuntu.com/ubuntu xenial-updates/main AMD64 Packages [668 kB]                                                                          
Ign:6 http://winswitch.org xenial InRelease                                                            
Get:7 http://br.archive.ubuntu.com/ubuntu xenial-updates/main i386 Packages [630 kB]
Hit:8 http://winswitch.org xenial Release                                                           
Get:10 http://br.archive.ubuntu.com/ubuntu xenial-updates/main AMD64 DEP-11 Metadata [307 kB]
Get:11 http://br.archive.ubuntu.com/ubuntu xenial-updates/main DEP-11 64x64 Icons [227 kB]
Get:4 http://179.184.158.91:80/pdata/03ee5d7e461a5049/security.ubuntu.com/ubuntu xenial-security InRelease [102 kB]**
Get:12 http://br.archive.ubuntu.com/ubuntu xenial-updates/universe AMD64 Packages [555 kB]            
Get:13 http://br.archive.ubuntu.com/ubuntu xenial-updates/universe i386 Packages [527 kB]   
Get:14 http://br.archive.ubuntu.com/ubuntu xenial-updates/universe AMD64 DEP-11 Metadata [185 kB]          
Get:16 http://br.archive.ubuntu.com/ubuntu xenial-updates/universe DEP-11 64x64 Icons [263 kB]                       
Get:17 http://br.archive.ubuntu.com/ubuntu xenial-updates/multiverse AMD64 DEP-11 Metadata [5.888 B]                                             
Get:18 http://br.archive.ubuntu.com/ubuntu xenial-backports/main AMD64 DEP-11 Metadata [3.324 B]                                                  
Get:19 http://br.archive.ubuntu.com/ubuntu xenial-backports/universe AMD64 DEP-11 Metadata [4.588 B]                                            
Get:15 http://179.184.158.91:80/pdata/03ee827eaa21046b/security.ubuntu.com/ubuntu xenial-security/main AMD64 DEP-11 Metadata [60,3 kB]          
Get:20 http://179.184.158.91:80/pdata/03ee977e21229dae/security.ubuntu.com/ubuntu xenial-security/main DEP-11 64x64 Icons [57,6 kB]
Get:21 http://179.184.158.91:80/pdata/03eeaa7e9723e1be/security.ubuntu.com/ubuntu xenial-security/universe AMD64 DEP-11 Metadata [51,4 kB]
Get:22 http://179.184.158.91:80/pdata/03eef57e5c24a1d6/security.ubuntu.com/ubuntu xenial-security/universe DEP-11 64x64 Icons [85,1 kB]**
Fetched 3.937 kB in 3s (1.115 kB/s)    
Reading package lists... Done
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Calculating upgrade... Done
...

Ich sehe nicht, woher das "179.184.158.91" kam, es ist nur ein nicht offizielles Repo in diesem VM (Winswitch) installiert, aber xenial-security nennt diese IP-Adresse. Darüber hinaus scheint es eindeutige Bezeichner wie "03ee827eaa21046b" zu tragen.

Zusätzliche Information:

Katze /etc/apt/sources.list

deb http://br.archive.ubuntu.com/ubuntu/ xenial main restricted
 deb-src http://br.archive.ubuntu.com/ubuntu/ xenial main restricted

deb http://br.archive.ubuntu.com/ubuntu/ xenial-updates main restricted
 deb-src http://br.archive.ubuntu.com/ubuntu/ xenial-updates main restricted
deb http://br.archive.ubuntu.com/ubuntu/ xenial universe
 deb-src http://br.archive.ubuntu.com/ubuntu/ xenial universe
deb http://br.archive.ubuntu.com/ubuntu/ xenial-updates universe
 deb-src http://br.archive.ubuntu.com/ubuntu/ xenial-updates universe

deb http://br.archive.ubuntu.com/ubuntu/ xenial multiverse
 deb-src http://br.archive.ubuntu.com/ubuntu/ xenial multiverse
deb http://br.archive.ubuntu.com/ubuntu/ xenial-updates multiverse
 deb-src http://br.archive.ubuntu.com/ubuntu/ xenial-updates multiverse

deb http://br.archive.ubuntu.com/ubuntu/ xenial-backports main restricted universe multiverse
 deb-src http://br.archive.ubuntu.com/ubuntu/ xenial-backports main restricted universe multiverse

deb http://security.ubuntu.com/ubuntu xenial-security main restricted
 deb-src http://security.ubuntu.com/ubuntu xenial-security main restricted
deb http://security.ubuntu.com/ubuntu xenial-security universe
 deb-src http://security.ubuntu.com/ubuntu xenial-security universe
deb http://security.ubuntu.com/ubuntu xenial-security multiverse
 deb-src http://security.ubuntu.com/ubuntu xenial-security multiverse

Katze /etc/apt/sources.list.d/*

[email protected]:~# cat /etc/apt/sources.list.d/*
deb http://winswitch.org/ xenial main

Keines der installierten Repos löst diese IP auf:

[email protected]:~$ Dig A security.ubuntu.com +short
91.189.91.23
91.189.88.149
91.189.91.26
91.189.88.152
91.189.88.162
91.189.88.161

[email protected]:~$ Dig A winswitch.org +short
78.129.163.65

Reverse IP-Lookup-Tools können auch keine FQDN-Adresse finden, die in diese IP aufgelöst wird.

Diese IP wird von meinem ISP (Telefonica) angekündigt, scheint aber von einem kleinen Anbieter verwendet zu werden, von dem ich bis jetzt noch nichts gehört habe:

[email protected]:~$ whois 179.184.158.91 | grep owner:
owner:       TELEFÔNICA BRASIL S.A

[email protected]:~$ Host 179.184.158.91
91.158.184.179.in-addr.arpa domain name pointer imaxima.static.gvt.net.br.

Ich habe sofort versucht, dieses Verhalten zu reproduzieren, aber diese IP-Adresse wurde beim Update von apt-get nicht mehr angezeigt.

In diesem VM (systemweit oder anwendungsspezifisch) befindet sich kein Proxy. Diese VM stellt über eine OPNSense-Firewall eine Verbindung zum Internet her. Es wird keine Filterung für ausgehende Nachrichten eingerichtet. Ich habe versucht, den Datenverkehr zu sichern, um die von apt-get gesendeten und empfangenen HTTP-Header zu überprüfen, sobald ich die verdächtige Adresse bemerkte, aber da ich dieses Verhalten nicht mehr reproduzieren konnte, würde nichts damit anfangen. Zum Glück habe ich letzte Nacht erneut ein Update für apt-get durchgeführt und diese seltsame IP wurde erneut angezeigt, obwohl diesmal nur in einer Zeile.

In diesem Moment feuerte ich Wireshark an und ging die gesamte Gefangennahme durch. Wie sich herausstellt, handelt es sich nicht um eine DNS-bezogene Anomalie (ich hatte dies zuvor durch Abfragen aller von mir hier eingerichteten Resolver bestätigt. Keiner von ihnen hat "179.184.158.89" zurückgegeben.) Mindestens eine der sechs IPs, die diese Sicherheit gewährleisten .ubuntu.com löst auf (91.189.88.162) gibt diesen unbekannten URI über HTTP 302 zurück. Hier ist die Liste, gegen die ich getestet habe:

security.ubuntu.com.    383     IN      A       91.189.88.149
security.ubuntu.com.    383     IN      A       91.189.88.162    X
security.ubuntu.com.    383     IN      A       91.189.88.152
security.ubuntu.com.    383     IN      A       91.189.91.26     
security.ubuntu.com.    383     IN      A       91.189.91.23
security.ubuntu.com.    383     IN      A       91.189.88.161

Ich kann das Verhalten jetzt konsequent manuell reproduzieren. Ich habe User-Agent auf "Debian APT-HTTP/1.3 (1.2.24)" gesetzt, um jede Art von Aufmerksamkeit von einem hypothetischen Honeypot abzulenken, der irgendwo dazwischen liegen könnte, nur für den Fall:

[email protected]:~$ GET -USed -H "Host: security.ubuntu.com" -H "User-Agent: Debian APT-HTTP/1.3 (1.2.24)" http://91.189.88.162/ubuntu/dists/xenial-security/InRelease
GET http://91.189.88.162/ubuntu/dists/xenial-security/InRelease
Host: security.ubuntu.com
User-Agent: Debian APT-HTTP/1.3 (1.2.24)

302 Found
Cache-Control: no-cache
Connection: close
Location: http://179.184.158.89:80/pdata/05f4cdcfbada50fc/security.ubuntu.com/ubuntu/dists/xenial-security/InRelease
Content-Length: 0
Content-Type: text/html
Client-Date: Sat, 25 Nov 2017 20:44:04 GMT
Client-Peer: 91.189.88.162:80
Client-Response-Num: 1
X-Content-Type-Options: nosniff

GET http://179.184.158.89:80/pdata/05f4cdcfbada50fc/security.ubuntu.com/ubuntu/dists/xenial-security/InRelease
User-Agent: Debian APT-HTTP/1.3 (1.2.24)

200 OK
Cache-Control: max-age=1144, s-maxage=3300, proxy-revalidate
Connection: close
Date: Sat, 25 Nov 2017 20:13:04 GMT
Accept-Ranges: bytes
ETag: "18ef2-55ed440fdb600"
Server: nginx
Content-Length: 102130
Expires: Sat, 25 Nov 2017 21:05:00 GMT
Last-Modified: Sat, 25 Nov 2017 20:10:00 GMT
Client-Date: Sat, 25 Nov 2017 20:44:05 GMT
Client-Peer: 179.184.158.89:80
Client-Response-Num: 1
X-OC-Service-Type: re

Alle diese fünf verbleibenden IPs geben HTTP 200 zurück, was meines Wissens das erwartete Verhalten für alle von ihnen ist. Zum Beispiel:

[email protected]:~$ GET -USed -H "Host: security.ubuntu.com" -H "User-Agent: Debian APT-HTTP/1.3 (1.2.24)" http://91.189.88.161/ubuntu/dists/xenial-security/InRelease
GET http://91.189.88.161/ubuntu/dists/xenial-security/InRelease
Host: security.ubuntu.com
User-Agent: Debian APT-HTTP/1.3 (1.2.24)

200 OK
Cache-Control: max-age=1271, s-maxage=3300, proxy-revalidate
Connection: close
Date: Sun, 26 Nov 2017 23:34:48 GMT
Accept-Ranges: bytes
ETag: "18ef2-55eeac2604300"
Server: Apache/2.4.18 (Ubuntu)
Content-Length: 102130
Expires: Sun, 26 Nov 2017 23:56:00 GMT
Last-Modified: Sun, 26 Nov 2017 23:01:00 GMT
Client-Date: Sun, 26 Nov 2017 23:33:34 GMT
Client-Peer: 91.189.88.161:80
Client-Response-Num: 1

Wie Sie sehen, gibt Canonicals IP 91.189.88.162 selbst eine HTTP 302-Weiterleitung an diese verdächtige IP zurück. Da diese Anomalie von einer meiner VMs und sogar von einem Live-Betriebssystem auf einem alten Laptop reproduzierbar ist, den ich gerade mit Telefonicas Modem verbunden habe, bin ich zu dem Schluss gekommen, dass dies auch nicht mit meiner Firewall zusammenhängt. Obwohl Telefonicas Ausrüstung in meinem Wohnzimmer steht, befindet sie sich außerhalb des sicheren Bereichs meines Netzwerks, sodass sie nicht überprüft wird. In beiden Fällen glaube ich nicht, dass dies der Schuldige ist, da es sich um einen spottbilligen DSL-2730E ADSL2 + Router handelt, für den keine benutzerdefinierten statischen Routen konfiguriert wurden. Ich werde versuchen, es eines Tages zu überbrücken, um zu sehen, ob sich die Dinge ändern.

Seltsamerweise trägt diese 302-Antwort im Gegensatz zu allen anderen Anfragen nicht die Webserversignatur, was mich zu der Annahme veranlasste, dass etwas dazwischen möglicherweise Pakete an dieser bestimmten IP und diesem bestimmten Port abfängt. Hier ist ein Beispiel von einem Server, den ich in Kanada besitze und in dem der Header "Server" deutlich zu sehen ist:

[email protected]:~# GET -USed -H "Host: security.ubuntu.com" -H "User-Agent: Debian APT-HTTP/1.3 (1.2.24)" http://91.189.88.162/ubuntu/dists/xenial-security/InRelease
GET http://91.189.88.162/ubuntu/dists/xenial-security/InRelease
Host: security.ubuntu.com
User-Agent: Debian APT-HTTP/1.3 (1.2.24)

200 OK
Cache-Control: max-age=0, s-maxage=3300, proxy-revalidate
Connection: close
Date: Mon, 27 Nov 2017 05:48:29 GMT
Accept-Ranges: bytes
ETag: "18ef2-55eef9eebc700"
Server: Apache/2.4.18 (Ubuntu)
Content-Length: 102130
Expires: Mon, 27 Nov 2017 05:48:29 GMT
Last-Modified: Mon, 27 Nov 2017 04:49:00 GMT
Client-Date: Mon, 27 Nov 2017 05:48:29 GMT
Client-Peer: 91.189.88.162:80
Client-Response-Num: 1

Um es kurz zu machen, konnten weitere Versuche, den Server hinter 91.189.88.162 mit Fingerabdrücken zu versehen, nicht beweisen, dass der Datenverkehr manipuliert wird. TCPtraceroute und mtr geben beide die erwartete Route an. Die HTTP-Latenz liegt innerhalb einer Spanne von 5% im Vergleich zu 91.189.88.161 (einer der sechs, der sich ebenfalls in London befindet). Nmap Nachprüfungen deuten auch darauf hin, dass ich den Canonical-Server erreiche (es sei denn, es handelt sich um einen sehr sorgfältig ausgearbeiteten MITM-Angriff, der anscheinend nicht der Fall ist). Ich sehe auch keine Beweise für die Entführung von BGP und die Route ist in Ordnung:

show route protocol bgp 91.189.88.162 | no-more 

inet.0: 688953 destinations, 2269968 routes (688942 active, 0 holddown, 4860 hidden)
+ = Active Route, - = Last Active, * = Both

91.189.88.0/24     *[BGP/170] 2w0d 17:19:51, MED 0, localpref 85, from 94.142.108.190
                      AS path: 3356 41231 I, validation-state: unverified
                      to 5.53.3.85 via ae11.0
                      to 5.53.3.79 via ae17.0
                    > to 5.53.3.223 via et-9/3/0.0
                    [BGP/170] 2w0d 17:20:31, MED 0, localpref 85, from 94.142.108.210
                      AS path: 3356 41231 I, validation-state: unverified
                      to 5.53.3.85 via ae11.0
                      to 5.53.3.79 via ae17.0
                    > to 5.53.3.223 via et-9/3/0.0
                    [BGP/170] 5d 02:34:24, MED 0, localpref 85, from 94.142.108.193
                      AS path: 3356 41231 I, validation-state: unverified
                      to 5.53.3.85 via ae11.0
                      to 5.53.3.79 via ae17.0
                    > to 5.53.3.223 via et-9/3/0.0

Tcptraceroute gegen Port 80:

[email protected]:/$ tcptraceroute -w1 91.189.88.162 80
Selected device enp0s3, address 10.4.4.119, port 47917 for outgoing packets
Tracing the path to 91.189.88.162 on TCP port 80 (http), 30 Hops max
 1  10.4.4.200  0.295 ms  0.220 ms  0.306 ms
 2  192.168.25.1  1.938 ms  2.106 ms  1.883 ms
 3  gvt-b-sr01.cta.gvt.net.br (179.184.120.13)  20.106 ms  22.429 ms  19.890 ms
 4  201.22.69.21.dynamic.adsl.gvt.net.br (201.22.69.21)  20.087 ms  20.514 ms  20.716 ms
 5  201.22.64.99.dynamic.dialup.gvt.net.br (201.22.64.99)  27.391 ms  28.520 ms  28.410 ms
 6  213.140.39.82  27.475 ms  28.178 ms  27.646 ms
 7  5.53.3.143  143.486 ms  142.026 ms  142.533 ms
 8  * * *
 9  ae-126-3512.Edge5.london1.Level3.net (4.69.166.45)  271.503 ms  268.769 ms  268.715 ms
10  SOURCE-MANA.Edge5.London1.Level3.net (212.187.138.82)  291.886 ms  271.616 ms  273.050 ms
11  yukinko.canonical.com (91.189.88.162) [open]  281.588 ms  273.400 ms  273.496 ms

Als ich anfing, mich mit diesem Thema zu befassen, ging der Strom in meiner Nachbarschaft aus (was für sich genommen äußerst selten ist. Go Murphy!). Sobald es 3 Stunden später zurückkam, startete ich alle meine VMs zurück, mit Ausnahme einer, die nicht richtig bootete. Ratet mal welche? Das stimmt.

Das ist übrigens das einzige Ubuntu 16.04 VM, das ich zu Hause habe. Diese Art von Ausfall ist für alle meine VMs beispiellos, was es zu einer Hölle des Zufalls macht. Ich machte sofort einen Schnappschuss seiner Festplatte und stellte die besagte VM außer Betrieb, um später eine eingehende forensische Analyse durchzuführen, nur um auf der sicheren Seite zu sein. Anscheinend ist ein X11-Server kaputt gegangen, der zuletzt am 07.11.2017 aktualisiert wurde. Ich werde es später untersuchen, aber ich kann nicht sehen, wie diese Umleitung alleine dazu führen würde, dass dies geschieht.

Es sollte beachtet werden, dass, sobald die Stromversorgung wieder hergestellt wurde, ich nicht mehr mit diesem Problem konfrontiert war, das heißt, jede Anfrage an die sechs IPs würde HTTP 200 zurückgeben, wie es sollte. Deshalb habe ich heute früher mein Modem gezwungen, die PPPoE -Authentifizierung neu zu starten, um eine neue dynamische IP-Adresse zu erhalten. Anschließend habe ich erneut diese 6 IP-Adressen überprüft, um festzustellen, ob dieses Verhalten erneut auftritt. 11 verbindet sich später wieder, Bingo! 91.189.88.162 hat angefangen, mir HTTP 302 zuzuweisen. Hier ist die Liste der IP-Adressen, die ich nach jeder erneuten Verbindung verwendet habe (für den Fall, dass es in Canonicals Frontend eine Zugriffssteuerungsliste gibt, die das Verhalten basierend auf der Quell-IP aus irgendeinem Grund gezielt manipuliert). Bis auf den allerersten und letzten trat bei security.ubuntu.com kein Problem auf:

191.250.187.149 (The one I was using when I started this topic)
177.132.10.0
187.112.57.37
186.212.197.62
177.132.109.6
187.112.135.18
201.86.5.226
201.86.5.226
201.86.5.226
189.115.80.207
177.133.196.249
177.16.143.235
177.204.139.117
179.182.184.0/24 (The IP I'm using now belongs to this subnet)  

Ich habe die sechs IP-Adressen von Canonical von einem anderen ISP in Brasilien sowie von mehreren Servern weltweit abgefragt und dabei immer 5 Abfragen pro Ziel-IP durchgeführt, um Inkonsistenzen auszuschließen. Keiner von ihnen hat dieses HTTP 302 zurückgegeben. Nicht ein einziges Mal. Bei meiner Heimverbindung führt jedoch jeder einzelne Versuch gegen 91.189.88.162 zu HTTP 302, es sei denn, ich versuche es im Abstand von einigen Sekunden. In diesem Fall wird HTTP 200 zurückgegeben, als würde ich eine Art Cache umgehen, obwohl "Cache- Control: no-cache "ist in der 302-Antwort gesetzt. Komisch, was?

Ich lade jeden ein, zu versuchen, dieses Verhalten zu reproduzieren. Bitte lassen Sie mich wissen, wenn Sie auf diese Weiterleitung stoßen:

GET -USed -H "Host: security.ubuntu.com" -H "User-Agent: Debian APT-HTTP/1.3 (1.2.24)" http://91.189.88.162/ubuntu/dists/xenial-security/InRelease

Ich muss noch einmal betonen, dass diese Ziel-IP in meinem Fall (179.184.158.89) keinem Unternehmen in Ubuntus Mirrors-Liste gehört. Ich verstehe nur nicht, warum sie mir die InRelease-Datei liefern soll . Diese Adresse wird einem kleinen ISP in einem anderen Bundesstaat zugewiesen, der 400 km + von hier entfernt ist.

Fazit ist: Wenn dies absichtlich eingerichtet ist, um Statistiken zu sammeln (was nicht einmal viel Sinn macht), kann man mit Sicherheit sagen, dass dies äußerst schlecht implementiert wurde, da es ziemlich unberechenbar ist und nur für eine der 6 IPs (welche) funktioniert werden nach dem Zufallsprinzip oder im Round-Robin-Verfahren ausgewählt, da sie nicht verwalten können, wie der lokale DNS-Client mit ihnen umgeht, und alle 6-A-Datensätze dieselbe TTL verwenden. Dies lässt viel Raum für Spekulationen.

Für den Fall, dass jemand es sehen möchte, ist hier die pcap-Datei, die während eines apt-get-Updates erstellt wurde. Der Einfachheit halber habe ich alles andere als HTTP-Anfragen herausgefiltert, aber ich werde das Ganze gerne hochladen, falls dies für das Debugging erforderlich ist. Pakete von Interesse sind # 6, # 7 und # 9:

https://mega.nz/#!NORi2ALA!njJRKZ4i26GHXaET_ZA6Z4ymWYKhccTGNiEBCcGtwbA

SHA256: 40fc995e505ee2dcaf9aa3e23961a757f628224e3fca83d0deed6374ba9a3fbe

Ich muss etwas übersehen haben ... PS: Ich gehe davon aus, dass dies eher ein Datenschutzproblem als ein Sicherheitsvorfall ist. In beiden Fällen ist dieses Verhalten nicht dokumentiert (Google findet nichts Ähnliches). Ich habe mich daher entschlossen, mich bei Ihnen zu erkundigen nur um auf der sicheren Seite zu sein.

Jede Hilfe wird sehr geschätzt! Danke, dass du so weit gekommen bist! :)

3
Mr.Ash

Der X-OC-Service-Typ gibt an, dass die Antwort von einem Open Cache-Knoten stammt.

ISPs verwenden Open-Cache-Server von Unternehmen wie Qwilt als transparente Caching-Proxys in ihren Netzwerken. Ihre Anforderung wurde von ihrem Routingknoten abgefangen und an einen Cache-Knoten umgeleitet. Auf dem Cache-Knoten wurde das Objekt nicht zwischengespeichert ('re' = Relais für Fehler; bei einem Treffer wäre es 'lo' = lokal). Daher wurde theoretisch der ursprüngliche Host + -Pfad verwendet, den Sie zum Abrufen des Objekts angefordert haben.

Es ist möglich, dass es sich tatsächlich um eine Art böswilliges Abfangen handelte, aber ich vermute, es war nur der Proxy des ISP.

2
Taylor