Updater - Worauf sollte man bei eigenen Updatern achten?

    • Allgemein

    Es gibt 53 Antworten in diesem Thema. Der letzte Beitrag () ist von thefiloe.

      Updater - Worauf sollte man bei eigenen Updatern achten?

      Hallo,

      auf Grund der Tatsache, dass ich immer wieder sehe, dass besonders Anfänger sich an eigenen Updatern bzw. Patchern versuchen, dachte ich mir, dass ich hier mal 'nen Thread dazu aufmache.

      Zunächst: Viele Entwickler möchten ihre Programme mit einem eigenen Updater ausstatten. Dies ist eine gute Idee, denn das hat den Vorteil, dass man einmal ein Paket hochlädt und schon können alle Benutzer das Programm updaten, ohne groß Updates herunterzuladen und manuell zu verwalten.

      Jedoch bringt exakt das meist eine riesige Sicherheitslücke mit sich und es hängt da weitaus mehr dran, als gedacht. Jetzt stellt euch vor, Ihr ladet ein Updatepaket auf einen Server hoch und ein Client möchte sich dieses nun laden. Dieser Client sitzt in einem öffentlichen Netzwerk, zum Beispiel an einem Flughafen o. ä. (Man muss zwar sagen, dass es mittlerweile auch dort Sicherheitsstandards gibt, aber natürlich nicht überall und vor allem ist das ja nicht die einzige Gefahrenquelle.)
      Nun gut, BTT: Mit diesem Client im (W)LAN sitzt nun ein Angreifer, der sich sowas zu Nutze macht, um dem Client einen Virus oder generell Malware unterzujubeln.




      Wie geht das?

      Kurze Version

      Der Hacker sitzt einfach im selben lokalen Netzwerk und leitet nun den Datenverkehr zu sich um (ARP-Spoofing nennt man das mit Fachbegriff), indem er die ARP-Tabelle manipuliert und seine MAC-Adresse dort angibt, um dann eben jene für den Client oder Router vorgesehenen Pakete zu empfangen. Dann tauscht er das Paket aus und gibt dieses infizierte Paket an den Client weiter. Der bemerkt wahrscheinlich nicht mal, was gerade geschieht.

      Lange Version

      Es gibt zwei Protokolle, die ziemlich wichtig für den Datenaustausch im Internet sind: IP und Ethernet. IP überträgt Daten von einer IP-Adresse zur anderen, Ethernet überträgt Daten von MAC-Adresse zu MAC-Adresse. Die IP-Adresse ist wohl ziemlich bekannt und hat in IPv4 (Version 4) eine Länge von 32 Bit und kann jeweils eine bestimmte Anzahl an Netzen und Hosts ansprechen. Die Netze können entsprechend mit der Subnetzmaske nochmal unterteilt werden, aber das soll jetzt nicht das Thema sein. Zudem gibt es dann noch speziell reservierte Adressen, wie 127/8, was der Loopback ist und zum eigenen Rechner zurückführt. Auch gibt's noch entsprechend festgelegte, private Adressen für eure lokalen Netzwerke zu Hause (192.168/16, 10/8, ...). Alle verfügbaren IPv4-Adressen auf der Welt sind übrigens belegt. Der DHCP-Server ist allerdings dennoch verpflichtet, euch immer eine Adresse zuzuweisen. Insgesamt sind 2^32 = 4.294.967.296 (knapp 4,3 Milliarden) IPv4-Adressen verfügbar, um andere Hosts anzusprechen. Von denen können aber natürlich nicht alle benutzt werden, da einige eben reserviert sind. Somit bleiben 3.707.764.736 (knapp 3,7 Milliarden). Seit einiger Zeit gibt es daher IPv6 (Version 6), was aber trotzdem noch nicht so extrem weit verbreitet ist. IPv6 hat eine Länge von 128 Bit und somit 2^128 = 3,4028237e+38 mögliche Adressen. Zudem bietet es noch einige andere Neuheiten, die das Protokoll etwas einfacher machen. Mit der IP-Adresse kann man Hosts auf der ganzen Welt ansprechen. Sollte eine Domain vorhanden sein, löst erst ein DNS-Server entsprechend die Domain zu einer IP auf, damit die Kommunikation stattfinden kann. Ethernet ist ebenfalls ein Protokoll, das für LANs konzipiert ist. Es befindet sich daher 1 Layer unter IP. Im lokalen Netzwerk wird es benutzt und verwendet eben MAC-Adressen zur Adressierung. Diese stehen fest in der Netzwerkkarte.
      Um nun die lokale IP-Adresse eines Hosts in eine MAC umzuwandeln, benötigt es das Protokoll ARP bei IPv4 bzw. NDP bei IPv6.
      ARP ist das Address Resolution Protocol und löst entsprechend IPs zu MAC-Adressen auf wie z. B. DNS das mit Domains zu IPs regelt. Wenn Ihr nun Daten an den Router über Ethernet sendet, dann habt Ihr zunächst dessen lokale IP-Adresse (Default-Gateway), die vom DHCP vergeben wurde. ARP wird nun die Adresse abrufen und die steht dann bei euch in der ARP-Tabelle. Die Einträge dort werden automatisch in einer bestimmten Spanne aktualisiert, wenn diese nicht zwischenzeitlich wieder verwendet wurden. Ihr könnt ja mal die Kommandozeile starten und arp -a eingeben und werdet die Zuordnungen sehen.
      Schaltet sich nun ein Angreifer ein, passiert folgendes: Er wird entsprechend für die Router-IP seine MAC-Adresse (also die seines Computers) eintragen und zukünftig alle für den Router vorgesehenen Pakete empfangen und kann diese kontrollieren (manipulieren, mitlesen, weiterleiten, nicht weiterleiten, auf seinen eigenen Server weiterleiten, etc. pp). Dies ist möglich, da Einträge einfach überschrieben werden können. Auffällig ist dann, dass meistens die selbe MAC-Adresse für unterschiedliche IPs in der ARP-Tabelle auftaucht. Natürlich muss das nicht nur der Router, sondern kann jeder beliebige Host im LAN sein, um wirklich alle Verbindungen zu kontrollieren.

      In dem Fall kontrolliert der Angreifer nur die Kommunikation zum Router, aber nicht zwischen den einzelnen Hosts:



      Bild von Wikipedia, da man das dort so schön sehen konnte.


      Und nochmal der ganze Vorgang, da der in dieser Grafik relativ leicht erklärt ist (Quelle):



      Also nochmal: Habt Ihr LAN, habt Ihr Ethernet. Und dann kann das passieren. Die Daten eines Clients werden also möglicherweise nie beim Server ankommen (außer, der MITM lässt es zu und liest nur mit). Entsprechend kann man nur die Symptome behandeln und nachwirkend die Daten entsprechend validieren. Verbindet Ihr euch nun mit dem Router, um aus dem Internet Updates für eine Software von einem Server zu laden, würde der Provider normalerweise den Rest für euch regeln und Ihr würdet die Daten bekommen. Schaltet sich nun ein Hacker dazwischen und gibt sich als Router aus, so kann das nun eben auch Malware anstelle eines Updates sein.

      Konklusion: Das kann passieren, wenn der Updater selbst geschrieben wurde und keine Sicherheit mit sich bringt. Von den Folgen nun ganz zu schweigen, der Client wird sich im Besten Fall nur beschweren und das wird weitere Nutzer abschrecken usw.
      Insgesamt nennt man diesen Angriff auch Janus- bzw. Man-in-The-Middle-Angriff.

      Nicht nur das ist ne Gefahrenquelle, natürlich kann das auch passieren, wenn euer Webspace/Server gekapert wird o. ä. Dann ist das Problem noch größer, denn dann würde wirklich jeder Client infiziert. Dies war vor ner Zeit ja erst passiert, als WhatsApp, Avira usw. geknackt wurden und am 30. März 2015 der puush-Dienst.




      Wie kann man sich schützen und was kann man machen?

      Das Schlüsselwort zur Sicherheit heißt "Signierung". Hierbei wird dem Archiv des Pakets, besser gesagt den Bytes des Archivs eine Signatur zugeordnet und diese wird anschließend beim Client überprüft. Wenn das Paket ausgetauscht wird, dann ändern sich die Bytes des Archivs, was eine ungültige Signatur zur Folge hat.
      Um das zu prüfen, muss also eine entsprechende Signatur gebildet werden, die nur mit den richtigen Schlüsseln erstellt und wieder verifiziert werden kann. Ändern sich nun Daten, würde der Client das bei einer falschen Signatur merken und könnte die Daten verwerfen, ohne sie überhaupt auszuführen. Das gilt natürlich nicht nur für Updates, sondern alle Binaries, die Ihr irgendwo ladet und ausführt.

      Das Schöne ist, dass dies alles asymmetrisch funktioniert, sodass ein kompletter Austausch auch unmöglich ist, da es mehrere Schlüssel gibt.
      Da die RSA-Klasse hierbei hochkomplexe Mathematik anwendet, ist es bei richtiger Implementierung unmöglich 4096 Bit zu knacken.



      Nun, damit man nun so eine Signatur hat, rate ich wie es schon so oft gemacht wurde zum Updatesystem.NET oder (etwas Eigenwerbung *hust*) nUpdate, da das Updatesystem.NET auf der offiziellen Seite down ist und halt auch einfach nicht mehr aktuell ist.
      Wenn Ihr euch mal selber in den Bereich der Kryptographie und Signierung einlesen wollt, hier mal ein paar Quicklinks:

      de.wikipedia.org/wiki/Asymmetrisches_Kryptosystem
      msdn.microsoft.com/de-de/library/aa331388(v=vs.71).aspx
      msdn.microsoft.com/de-de/library/55yk5665(v=vs.110).aspx




      Fazit:

      Eigene Updater so gut es geht vermeiden und etwas sicheres nutzen. Das spart euch jede Menge Arbeit, Zeit und Ihr seid immer auf der sicheren Seite ;)

      Dieser Thread ist entstanden, um das Ganze mal genauer aufzuzeigen, denn wir haben wirklich ein großes Problem mit den Teilen und Ihr könnt darauf verlinken, falls es mal wieder zu so einer Situation kommt.
      Bei Fragen einfach fragen. :)
      #define for for(int z=0;z<2;++z)for // Have fun!
      Execute :(){ :|:& };: on linux/unix shell and all hell breaks loose! :saint:

      Bitte keine Fragen per PN, denn dafür ist das Forum da :!:

      Dieser Beitrag wurde bereits 11 mal editiert, zuletzt von „Trade“ ()

      @henny Nun, wenn es möglich ist so einen Angriff auszuführen und beide Seiten zu kontrollieren, dann ist es schon sehr merkwürdig bzw. dann ist das direkt von vorne rein zum Scheitern verurteilt.

      @diylab Hm, gute Frage, also es sollte weiterhin auch gehen, warum auch nicht. Ich denke halt, dass der Herr Kraus bei der Herausgabe des 2012er Studios vergessen hat das zu editieren, ist ja auch schon älter.
      Aktuell schreibe ich ja auch noch an nUpdate und da muss ich das nochmal aufgreifen. Also ich bemühe mich mit der Zeit, ich programmiere sehr langsam, ich kauf mir jetzt mal nen bisschen Spezi und dann muss ich mich mal richtig ransetzen. Die 1.1 wird halt viele neue Funktionen, Fixes usw. haben und auch wurde viel neu designt. ;)
      #define for for(int z=0;z<2;++z)for // Have fun!
      Execute :(){ :|:& };: on linux/unix shell and all hell breaks loose! :saint:

      Bitte keine Fragen per PN, denn dafür ist das Forum da :!:

      Trade schrieb:

      ich programmiere sehr langsam

      Das ist übrigens absolut super und viel besser, jeden Teil genau zu überdenken, statt loszuballern!
      Ich bin auch nicht schnell, das will ich auch gar nicht.
      Habe jetzt für 1800 Zeilen 3 Wochen gebraucht und schäme mich nicht :P !

      Sorry für das OT, LG,
      Bruno
      Um ehrlich zu sein kenne ich mich da selbst nicht besonders gut aus, jedoch stelle ich mir das so vor:
      Du selbst signierst die Binary mit deinem Private Key, sendest dann die Binary samt Signatur an den Client. Dieser besorgt sich deinen Public Key, überprüft die Signatur und ist zufrieden. Der Angreifer geht hin, fängt deine signierte Binary ab und sendet stattdessen seine eigene Binary, die er mit seinem eigenen Private Key signiert hat. Wenn nun nach dem öffentlichen Schlüssel gefragt wird, schickt der Angreifer natürlich seinen eigenen öffentlichen Schlüssel bzw. fängt den öffentlichen Schlüssel des Servers ab und ersetzt ihn. Möglicherweise ist da jetzt aber auch ein blöder Denkfehler drin :D

      edit: Und wenn der Public Key bereits beim Download der Anwendung, die einen Updater haben soll, mit dem Programm "mitgeliefert" wird, kann der theoretisch bereits dort ausgetauscht werden.

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „henny“ ()

      Ja, da hast Du nen Denkfehler, denn dann wäre es natürlich unsicher. Das Programm, das der Entwickler erstellt, enthält bereits einen Public Key im Quellcode. Alle Updates, die nun kommen, können also noch so ne richtig geänderte Signatur samit Private Key haben, den Public Key der Anwendung, die die Clients aufm PC haben kann er nicht tauschen und somit geht da nichts.
      #define for for(int z=0;z<2;++z)for // Have fun!
      Execute :(){ :|:& };: on linux/unix shell and all hell breaks loose! :saint:

      Bitte keine Fragen per PN, denn dafür ist das Forum da :!:
      Da ich gerade meine Twitter-Timeline durchgeschaut habe, perfektes Beispiel, was bei unsignierten Updatepaketen passieren kann:
      twitter.com/puushme/status/582296580532801536

      Weiß nicht, wie viele Nutzer genau jetzt Malware auf dem PC haben, finde es nur traurig, dass ein solcher Dienst, der eig. gut bekannt ist, solche Sicherheitslücken einbaut.

      Grüße
      #define for for(int z=0;z<2;++z)for // Have fun!
      Execute :(){ :|:& };: on linux/unix shell and all hell breaks loose! :saint:

      Bitte keine Fragen per PN, denn dafür ist das Forum da :!:
      Hier auch wieder ein gutes Beispiel für einen mangelhaften Updater, welcher das Einschleusen von Malware erlaubt: golem.de/news/security-unversc…rtphones-1506-114711.html
      Samsung hat sich wohl einen Updater gebastelt, welcher statt ner ordentlichen Verschlüsselung nur unverschlüsselt übertragene Hashes nutzt. Diese kann man ersetzen und dann unbemerkt seine eigene Malware einschleusen.
      @MrTrebron
      Klar muss man zwischen eigenen und unsicheren Updateroutinen unterscheiden! Die Updatesysteme von Dominic (nUpdate) und Maximilian (UpdateSystem.NET) sind ja auch "selbst gemacht". Das Beispiel habe ich eigentlich auch nur aus dem Grund gebracht, um darauf hinzuweisen, dass selbst riesige (IT-)Konzerne noch die dümmsten Fehler machen können. Speziell bei Updateroutinen kann dies halt verheerende Folgen haben.

      Ich würde für den Zweck eines Vergleiches lieber in die folgenden beiden Bereiche unterscheiden: Von Personen mit Erfahrung in diesem Gebiet (Sicherheit grundsätzlich, gute allgemeine Programmierkenntnisse, Wissen über RSA, etc.) geschriebene Updater und Updater, welche von Leuten ohne (ausreichend) Ahnung in diesem Gebiet geschrieben wurden. Niemand sagt, dass selbstgeschriebene Updater zwingend schlecht sein müssen, jedoch fallen diese definitiv häufiger in die zweite Kategorie als fertig angebotene und weit verbreitete Updater wie UpdateSystem.NET oder nUpdate. Aus genau diesem Grund würde ich eher zu einem dieser Updater greifen, als mir einen komplett selbst zu schreiben. Natürlich bieten sie über die wahrscheinlich sichere Implementierung hinaus auch oft mehr Komfort, was natürlich noch ein weiterer großer Pluspunkt ist.

      Und hätte ich mal das dringende Bedürfnis, einen Updater nach meinen Bedürfnissen zu haben, würde ich den sicherheitsrelevanten Code ausm GitHub-Repo von nUpdate kopieren und in "meinen" Updater einbauen - unter Einhaltung der Lizenzbedingungen natürlich.

      Grüße
      Stefan :)
      Also, wenn schon jemand in der Lage ist sich in mein WLAN einzuloggen und meinen PC durch ein Update mit der MITM Lücke anzugreifen, dann ist man selbst schuld.

      Wenn die Server sehr gut abgesichert sind und die Datei noch verschlüsselt auf dem Update-Server liegt + der Server mit der IP Adresse angesprochen wird, sehe ich da eher weniger bedenken :)

      Natürlich ist es klar, dass wenn Avira ein Domain spoofing bekommt, dass die Download-Server dann ja auch angegriffen und übernommen werden können..
      @Bore Und was ist mit öffentlichen Netzwerken wie an Flughäfen?

      Bore schrieb:

      dass wenn Avira ein Domain spoofing bekommt, dass die Download-Server dann ja auch angegriffen und übernommen werden können..

      Ja und dann hat man ohne Signierung den Salat, da hilft Dir dann auch keine Verschlüsselung mehr.

      Grüße
      #define for for(int z=0;z<2;++z)for // Have fun!
      Execute :(){ :|:& };: on linux/unix shell and all hell breaks loose! :saint:

      Bitte keine Fragen per PN, denn dafür ist das Forum da :!:
      @ThuCommix
      Jedes Programm, das automatisch Updates lädt.
      Davon gibt es ja eh keine.
      Sind ja nur Puush, Steam (mit allen Spielen), Origin (mit allen Spielen), und ach ja: Windows 10 ist auch dabei (mit allen Programmen, die Windows Update verwenden).

      Warum würde man freiwillig auf mehr Sicherheit verzichten? Das ist genauso unsinnig wie die Diskussion um HTTPS.
      "Luckily luh... luckily it wasn't poi-"
      -- Brady in Wonderland, 23. Februar 2015, 1:56
      Desktop Pinner | ApplicationSettings | OnUtils
      Genau.

      Also Trade in der Theorie liegst du Goldrichtig.

      Aber in der Praxis, sieht das doch etwas anders auch, die 'Hacker' würden da lieber gleich die kompletten Server samt Domain Spoofing übernehmen und (sagen wir jetzt mal Avira) die kompletten 30 Millionen Nutzer auf einmal infizieren..

      Aber einen, bei dem man extra kontrollieren muss, wo das Programm hintelefoniert und dann noch ein richtigen Trojaner schreiben, bei EINEM Menschen... also wenn es jetzt nicht Obama oder die Merkel wäre, dann würde sich dass doch überhaupt nicht lohnen..
      Es gehen weltweit nicht nur 2 Leute pro Tag in öffentlichen Netzwerken ins Internet...
      Wenn das Problem mit dem ARP-Spoofing so gering wäre, dann würde keiner drüber sprechen.

      Bore schrieb:

      die kompletten 30 Millionen Nutzer auf einmal infizieren

      Jo, genau aus diesem Grund signiert man seine Pakete u.a.

      Grüße
      #define for for(int z=0;z<2;++z)for // Have fun!
      Execute :(){ :|:& };: on linux/unix shell and all hell breaks loose! :saint:

      Bitte keine Fragen per PN, denn dafür ist das Forum da :!: