Können Downloads manipuliert werden?

BFF schrieb:
Auch die Zeiten sind vorbei, persönlich :)



BFF schrieb:
Zumal sehr wenig wirklich oeffentlich publiziert wird,
Wurden sie nie wirklich.
War davon abhängig, in welchen Kreisen man sich befand 😉🫣


BFF schrieb:
kann man sich eigentlich nicht mehr wirklich vorstellen.
Was spannendes zu berichten?
Ernst gemeinte Frage, bin da schon seeehr lange raus aus dem Thema...
 
Zuletzt bearbeitet:
Skudrinka schrieb:
Was spannendes zu berichten?

Ich persoenlich bin da auch raus aus den Tiefen. Einfach zu alt. 🤷‍♀️
Mein Sohnemann ist da mehr aktiv.
 
  • Gefällt mir
Reaktionen: Skudrinka
@leute
Ihr habt gelesen, daß er fragte, ob ein aktiv laufender Download manipuliert und ausgetauscht werden kann?
CyborgBeta schrieb:
Oder wäre so etwas durch Prüfsummen, etc. mathematisch ausgeschlossen, dass ein Download "on the fly" kompromittiert würde?
Download per HTTP, HTTPS, FTP (was ja manchmal versteht dahinter steht....)?

Ein Download on the fly zu manipulieren ist so laut meinen Netzwerkkenntnissen unmöglich.

Nach OSI-Modell müßte man auf Layer 3 und 4 abgreifen. Das ist einerseits die Vermittlungsschicht für das Umbiegen der Verbindung (das könnte man noch hinbekommen mit entsprechender Technik), aber auf Layer 4 Transportschicht wäre Ende, weil die Datenpaket entsprechend mit eigenen Prüfsummen abgesichert werden, da kannst Du nicht einfach bei einem bereits begonnenen Datenstrom Datenpakete austauschen oder neue hinzufügen. Layer 7 wie HTTP/S, usw. hat ebenso noch sowas wie Komprimierung drin. Und erst recht nicht on-the-fly eine Zip-Datei manipulieren, die selbst noch eine Prüfsumme hat. Das wäre ja fatal, wenn das so einfach ginge, und TCP/IP ist ein sehr zuverlässiges und robustest Protokoll. Und bei HTTPS mit TLS ist es eh schon vorbei, da wäre mir nichts bekannt, was man hier on the the fly manipulieren könnte.

Man muß nur mal überlegen, da kommen ein paar Datenpakete mit einer Zip-Datei, die noch unvollständig sind, und tauscht dann Datenpakete gegen eine andere Zip-Datei aus, und am Ende soll dann eine gültige Zip-Datei insgesamt rauskommen? Schon beim ersten Pakettausch würde der auf unterer Layerebene 4 mit Fehler unterbrochen werden, weil die neuen Datenpakete zu den vorherigen Paketen nicht passt.

Ansonsten möchte ich hier denjenigen kennenlernen, der das hinbekommen will. Selbst dann müßte man bei Man-in-the-Middle (der Angriff auf diese Weise eher als On-Path-Attacke zu bezeichnen) - wenn die Quelle beispielsweise eine legale Quelle wäre - auch sofort die Prüfsumme austauschen, mit der Du den Download am Ende prüfen kannst, und spätestens dann würdest Du die Manipulation bemerken. Vor dem Download, wenn Du den http-Request GET absetzt, den könnte man natürlich vor dem Download abfagen um umleiten. Und man könnte Dir natürlich einen Download vorgaukeln, das ist aber was ganz anderes.

Bevor die Datenübertragung stattfindet, ja, da wäre einiges möglich, aber nicht, wenn sie bereits läuft.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: CyborgBeta und Lee Monade
mykoma schrieb:
beim Thema bleiben
🫡

@nutrix Danke für deine ausführliche Erklärung. Das war auch mein Verdacht, dass sich ein laufender SSL/TLS Strom nicht einfach ohne Abbrüche austauschen lässt. Andererseits ist die Downloadgröße doch vorher nicht bekannt?

Aber sei's drum, vermutlich wird schon vorher eine andere Datei vorgegaukelt, also bevor der Download der "Nutzdaten" beginnt - einfach, weil dies viel einfacher wäre, unter der Annahme, dass ein bestimmtes File irgendwann von irgendwem heruntergeladen wird.
 
Ist ein sehr häufiges Problem z.b. klick
Solche Berichte über manipulationen les ich ca. einmal im Monat.

Aber wer Windows nutzt hat eh keine Changse und muss sich daher keine Gedanken machen.
 
nutrix schrieb:
Ein Download on the fly zu manipulieren ist so laut meinen Netzwerkkenntnissen unmöglich.
Natuerlich ist das nicht unmoeglich. Du brauchst nur einen "Man in the Middle".
Der ganze OSI Layer Kram ist da eigendlich irrelevant. Es stimmt zwar alles, aber in der Praxis spielt das keine Rolle.
Nichts hindert eine Blackbox daran, den Datenstrom komplett zu terminieren, zu manipulieren, und neu zu verpacken. Dafuer muss die Blackbox natuerlich von Anfang an da sein, aber dann redest du im Endeffekt zu keinem einzigen Zeitpunkt direkt mit dem Server, sondern ausschliesslich mit der Blackbox, welche dann mit dem Server redet.
Bei unverschluesseltem Traffic ist das ganze trivial, und fuegt nur ein bisschen Latenz hinzu.

Fuer State-Actors ist auch SSL kein Hindernis. Wenn du ein trusted Root CA Zertifikat auf den Rechner bekommst, kannst du automatisch entsprechende Zertifikate ausstellen. Wenn du als State-Actor sogar eine oeffentliche CA unter Kontrolle hast, faellt das nicht mal auf. :p
Solche Konstrukte sind Gang und Gaebe in der IT. Ein paar Stichworte dazu: Proxy, SSL-Inspection, Next-Gen-Firewall.
Moderne Firewalls ziehen dir on-the-fly Malware aus dem Datenstrom, auch bei SSL Verbindungen.

nutrix schrieb:
Man muß nur mal überlegen, da kommen ein paar Datenpakete mit einer Zip-Datei, die noch unvollständig sind, und tauscht dann Datenpakete gegen eine andere Zip-Datei aus, und am Ende soll dann eine gültige Zip-Datei insgesamt rauskommen?
Du tauschst natuerlich die ganze Datei aus, bzw. packst sie aus, manipulierst die Daten, und packst sie wieder zusammen.
Auch wieder so eine Sache die NG-Firewalls problemlos hinbekommen.
Persoenliche Anekdote dazu: Ich wollte ein ISO File mit einem Update herunterladen. Download hat funktioniert, aber das Update mit dem ISO hat nicht funktioniert. Ne Weile rumgesucht, dann einen Checksummenvergleich gemacht: Passte nicht. Huh...
Dann hab ich mir das ISO genauer angeschaut, und es war auch ein bisschen kleiner als beim Download angegeben. Dann habe ich mir das noch genauer angeschaut, und dann fiel mir auf, dass saemtliche .sh Dateien im ISO fehlten. Ich wusste dass da welche sein muessen, weil es nicht das erste Mal war das ich solche Updates gemacht habe.
Nach ein paar Telefonaten war dann das Resultat: Regelaenderungen an unserer Firewall haben dafuer gesorgt das diese beim Malwarescan etwas uebereifrig war, und dann hat sie die .sh Dateien aus dem ISO File entfernt.
 
Hm, klingt danach, als würde das iso file jedes mal erst "zur Laufzeit" generiert werden.

entropie88 schrieb:
Aber wer Windows nutzt hat eh keine Changse und muss sich daher keine Gedanken machen.

Windows nutze ich nur, um eine ssh-Verbindung zum Server herzustellen.

Btw. Ich muss mir glaube ich auch mal so ein cooles Profilbild zulegen und mich dem Ton anpassen. :D Vielleicht etwas mit Grün?
 
CyborgBeta schrieb:
Hm, klingt danach, als würde das iso file jedes mal erst "zur Laufzeit" generiert werden.
Halte ich nicht fuer unmoeglich, aber doch ziemlich unwahrscheinlich. Das war ein Download im Supportportal eines grossen Netzwerkausruesters, ein Update fuer Standardhardware von denen.
Das wuerde keinen Sinn machen die ISOs erst beim Download zu erstellen, die sind nicht angepasst.
Und selbst wenn, das haette ja keinen Unterschied gemacht. Der Firewallkollege hat ja in den Logs gesehen, dass die Dateien geflaggt und entfernt worden sind.
 
CyborgBeta schrieb:
Windows nutze ich nur, um eine ssh-Verbindung zum Server herzustellen.

Das ist der Angriffspunkt. Woher weisst du das es der richtige Server ist und nicht ein squid?

Edit: was ist es den nun eine http/https Verbindung oder eine ssh Verbindung?
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: CyborgBeta
Ranayna schrieb:
Natuerlich ist das nicht unmoeglich. Du brauchst nur einen "Man in the Middle".
Bei einer kompletten Verbindung ja, aber nicht mittendrin. Du kannst nicht einen bereits gestarteten laufenden Datenstrom mit der Übertragung einer Zipdatei (der zudem noch per TLS verschlüsselt ist) diesen in der Mitte unterbrechen, dann die Zipdatei manipulieren, neue Dateien reinmachen, und dann damit weiterlaufen lassen. Spätestenz beim Auspacken der Zipdatei würde man bemerken, daß die Datei vermurkst ist (oder wurde, bei einem Angriff).

Du kannst überall da angreifen, wo zwischengespeichert wird und dann austauschen. Oder umleiten, wenn der Download begonnen wird, aber NICHT mittendrin. Das würde sofort meines Wissens nach auf Layer 4 einen Abbruch hervorrufen.
Ranayna schrieb:
Der ganze OSI Layer Kram ist da eigendlich irrelevant. Es stimmt zwar alles, aber in der Praxis spielt das keine Rolle.
Nichts hindert eine Blackbox daran, den Datenstrom komplett zu terminieren, zu manipulieren, und neu zu verpacken.
Ja, aber man würde sehr wohl von der Terminierung im Client etwas mitbekommen.
Ranayna schrieb:
Moderne Firewalls ziehen dir on-the-fly Malware aus dem Datenstrom, auch bei SSL Verbindungen.
Ja, weiß ich als FW Admin, der das tagtäglich macht. Das ist was anderes, weil sie zwischenspeichern und als Proxy fungierten, genauso wie IPS/IDS-Systeme.
Ranayna schrieb:
Du tauschst natuerlich die ganze Datei aus, bzw. packst sie aus, manipulierst die Daten, und packst sie wieder zusammen.
Auch wieder so eine Sache die NG-Firewalls problemlos hinbekommen.
Richtig, aber Du kannst nur erst dann auspacken, wenn die Datei komplett übertragen wurde und im Proxy, Firewall, IPS-System zwischengespeichert werden, und sie zudem nicht verschlüsselt und geschützt sind. Sobald eine Zipdatei verschlüsselt mit Kennwort vorliegt, würde die Firewall oder das IPS-System einfach die Datei die Weiterleitung an den Client blockieren, wenn es so eingestellt wurde. Beispielsweise arbeiten hier heute E-Mail Server in einigen Firmen und Behörden so, daß solche E-Mails sofort in eine Sandbox umgeleitet werden, wenn die Dateien nicht auspackbar sind.
Ranayna schrieb:
Persoenliche Anekdote dazu:
"Normales" Verhalten solcher Systeme, wenn sie entsprechend scharf konfiguriert wurden. Das bekommst Du aber dann auch mit Prüfsummentest des ISOs raus, daß die Datei manipuliert wurde.
 
  • Gefällt mir
Reaktionen: CyborgBeta und areiland
Schadsoftware kommt auf vielen Wegen auf den PC.
Oftmals ist so ein Anhang auch keine .zip-Datei sondern eine .exe.
Weil Windows blendet in der Standardkonfiguration ja die Endungen von bekannten Dateitypen aus.
Eine Datei mit dem Namen "Geheim.exe" würde also als "Geheim" angezeigt.
Wenn die Datei aber "Geheim.zip.exe" heisst, dann entfernt Windows die Dateiendung .exe und zeigt als Name "Geheim.zip" an.
In Wirklichkeit ist es aber keine .Zip-Datei sondern die .Exe-Datei.
Und wenn man diese nun per Doppelklick öffnen möchte, führt man den Virus schon aus.
https://www.munker.info/allgemein/achtung-verschlusselungstrojaner
 
  • Gefällt mir
Reaktionen: areiland
entropie88 schrieb:
Edit: was ist es den nun eine http/https Verbindung oder eine ssh Verbindung?

hab ich doch schon geschrieben. ich verbinden mich (windows pc) mit ssh mit meinen server und lade dann von einem anderen server via wget https ein zip file auf meinen server herunter.

und von dem ganzen gerede, ein jeder windows pc sei auf jeden fall mit viren verseucht, halte ich nur wenig. sogar der kreml nutzt windows. ;)
 
Das Problem bei Windows fängt schon dabei an einen DNS Server einzurichten der DoH und DNSSEC nutzt wobei einige Adressen via Tor aufgelöst werden sollen. Nur so als Beispiel.
 
entropie88 schrieb:
Das Problem bei Windows fängt schon dabei an einen DNS Server einzurichten
Ich nutze meinen Provider-DNS...
 
Zurück
Oben