{"id":6284,"date":"2015-10-19T08:03:08","date_gmt":"2015-10-19T08:03:08","guid":{"rendered":"https:\/\/kasperskydaily.com\/germany\/?p=6284"},"modified":"2022-06-09T18:52:35","modified_gmt":"2022-06-09T16:52:35","slug":"security-week-42","status":"publish","type":"post","link":"https:\/\/www.kaspersky.de\/blog\/security-week-42\/6284\/","title":{"rendered":"Sicherheitswoche 42: SHA-1-Kollisionen, echter Router-Hack,  Android\/Sicherheit\/Tr\u00fcbsinn"},"content":{"rendered":"<p>Wenn man sich im Auge eines Sturms befindet, versteht man vielleicht gar nicht, was gerade passiert. Und wenn man mitten in einem Stau steht, wei\u00df man vielleicht gar nicht, dass ein Unfall die Ursache des Staus ist, bevor man an die Unfallstelle kommt und zwei Jet-Piloten sieht, deren Flugzeugwracks drei Fahrspuren blockieren. Bis dahin haben Sie nicht genug Informationen, um eine genaue Aussage treffen zu k\u00f6nnen.<\/p>\n<p>In der IT-Sicherheit passiert das die ganze Zeit: Es ist ein komplexes Thema mit vielen Details und Besonderheiten, und deshalb haben die Ergebnisse bestimmter Forschungsarbeiten manchmal starke Auswirkungen auf die Zukunft.<\/p>\n<p>Die drei wichtigsten Themen der vergangenen Woche haben nichts miteinander zu tun, abgesehen von ihrem unterschwelligen Kontext. Wenn man keine Branchenerfahrung hat, kann man die Wichtigkeit mancher Sicherheitsvorf\u00e4lle nicht richtig bewerten oder \u00fcbersieht manches wichtige Detail.<\/p>\n<p>Ich werde versuchen, dies mit den folgenden Beispielen zu erkl\u00e4ren, allerdings ist der unterschwellige Kontext vage und flexibel auslegbar, so dass ihn jeder unterschiedlich interpretiert. Kommen wir also zum aktuellen Wochenr\u00fcckblick. Wie immer w\u00e4hlte das <a href=\"http:\/\/www.threatpost.com\/\" target=\"_blank\" rel=\"noopener nofollow\">Threatpost<\/a>-Team drei wichtige Neuigkeiten aus, die ich hier ganz r\u00fccksichtslos kommentiere. Die \u00e4lteren Episoden finden Sie <a href=\"https:\/\/www.kaspersky.com\/blog\/tag\/security-week\/\" target=\"_blank\" rel=\"noopener nofollow\">hier<\/a>.<\/p>\n<h3>Die Suche nach der SHA-1-Kollision wird g\u00fcnstiger<\/h3>\n<p><a href=\"https:\/\/threatpost.com\/practical-sha-1-collision-months-not-years-away\/114979\/\" target=\"_blank\" rel=\"noopener nofollow\">Der Artikel<\/a>. Die <a href=\"https:\/\/www.schneier.com\/blog\/archives\/2012\/10\/when_will_we_se.html\" target=\"_blank\" rel=\"noopener nofollow\">Vorhersage<\/a> von Jesse Walker von vor drei Jahren. Die <a href=\"https:\/\/www.schneier.com\/blog\/archives\/2015\/10\/sha-1_freestart.html\" target=\"_blank\" rel=\"noopener nofollow\">neue Forschungsarbeit<\/a>, die die Sicht auf die Sicherheit dieses Algorithmus \u00e4nderte.<\/p>\n<p>Jeder, der Linux ein bisschen besser erforschtt und nicht nur Ubuntu installiert, wei\u00df, dass das System dazu auffordert, die Anleitung genau zu lesen. Ich meine, ich w\u00fcrde nat\u00fcrlich zun\u00e4chst ein Dokument googeln, das eine Reihe von Kommandos enth\u00e4lt, aber in manchen F\u00e4llen w\u00fcrde das Ganze nicht funktionieren und komplett zusammenbrechen.<\/p>\n<p>Dieser Fall hier ist \u00e4hnlich: Ohne zumindest eine kurze Orientierung, ist das Thema nicht so leicht zu verstehen. Aber auch wenn es das bisher komplexeste Thema in unserem regelm\u00e4\u00dfigen Wochenr\u00fcckblick ist, m\u00f6chte ich versuchen, es in einfachen Worten zu erkl\u00e4ren.<\/p>\n<div style=\"width: 330px\" class=\"wp-caption aligncenter\"><img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/media.kasperskydaily.com\/wp-content\/uploads\/sites\/96\/2015\/10\/06133848\/security-week-42-cat-jumps.gif\" alt=\"Nun, probieren wir einmal so etwas\" width=\"320\" height=\"291\"><p class=\"wp-caption-text\">Nun, probieren wir einmal so etwas<\/p><\/div>\n<p>SHA-1 ist ein kryptografischer Hashing-Algorithmus. Dieser Algorithmus kann eine unlimitierte Sequenz verarbeiten und ein 160 Bit gro\u00dfes Datenst\u00fcck produzieren, das dann dazu verwendet werden kann, die urspr\u00fcnglichen Daten zu verifizieren. Das ist unm\u00f6glich, wenn man nicht die urspr\u00fcnglichen Daten besitzt \u2013 denn nur damit kann man die Informationen des Hash-Werts wieder herstellen.<\/p>\n<p>Genauer gesagt, SOLLTE das auch unm\u00f6glich sein, selbst wenn man ein schlechtes Passwort wie \u201e123456\u201c nutzt. F\u00fcr so einen Algorithmus gibt es zwei Bedingungen: es ist unm\u00f6glich, die Originaldaten wieder herzustellen, wenn man nur den Hash-Wert hat, und es ist unm\u00f6glich, eine \u00dcbereinstimmung mit den Originaldaten zu haben, so dass beide den gleichen Hash-Wert besitzen.<\/p>\n<p>Es GIBT aber eine M\u00f6glichkeit f\u00fcr diese beiden Dinge. Aber dazu braucht man so viel Computerpower, dass es den Versuch nicht lohnt. Wenn man das mit einem Supercomputer machen w\u00fcrde, bek\u00e4me man 240 Jahre sp\u00e4ter die Antwort (zum Beispiel \u201e42\u201c), aber dann w\u00e4re das auch schon egal.<\/p>\n<p>Aber die Sache hat noch einen Haken: Zum einen werden PCs immer schneller, zum anderen suchen Forscher laufend nach Wegen, um kryptografische Algorithmen zu knacken. Es ist viel einfacher, eine Kollision bei einem Verschl\u00fcsselungsalgorithmus zu finden, als die urspr\u00fcnglichen Daten zu entschl\u00fcsseln.<\/p>\n<blockquote class=\"twitter-tweet\" data-width=\"500\" data-dnt=\"true\">\n<p lang=\"en\" dir=\"ltr\">Practical SHA-1 Collision Months, Not Years, Away via <a href=\"https:\/\/twitter.com\/threatpost?ref_src=twsrc%5Etfw\" target=\"_blank\" rel=\"noopener nofollow\">@threatpost<\/a> <a href=\"https:\/\/t.co\/fU5VQUjLI4\" target=\"_blank\" rel=\"noopener nofollow\">https:\/\/t.co\/fU5VQUjLI4<\/a><\/p>\n<p>\u2014 Kaspersky (@kaspersky) <a href=\"https:\/\/twitter.com\/kaspersky\/status\/652502642850144256?ref_src=twsrc%5Etfw\" target=\"_blank\" rel=\"noopener nofollow\">October 9, 2015<\/a><\/p><\/blockquote>\n<p><script async src=\"https:\/\/platform.twitter.com\/widgets.js\" charset=\"utf-8\"><\/script><\/p>\n<p>In der Zwischenzeit wird SHA-1 in verschiedenen Verschl\u00fcsselungssystemen und Autorisierungsl\u00f6sungen verwendet, um sicherzustelen, dass die Daten von zwei Seiten zueinander passen.\u00a0 Sobald in einem weniger m\u00fchseligen und teuren Prozess zwei oder mehr Datenreihen mit dem gleichen Hash-Wert entdeckt werden, ist der Algorithmus nicht mehr zuverl\u00e4ssig.<\/p>\n<p>An dieser Stelle m\u00f6chte ich Ihnen die unertr\u00e4gliche Algebra-Stunde ersparen und direkt zum Punkt kommen: Forscher kompilieren einen Algorithmus zur Suche so einer Kollision und dieser Algorithmus schafft es, diese einfacher zu finden, als eine Brute-Force-Attacke. Wir sprechen hier \u00fcber einen so genannten <a href=\"https:\/\/de.wikipedia.org\/wiki\/Kollisionsangriff#Geburtstagsangriff\" target=\"_blank\" rel=\"noopener nofollow\">Geburtstagsangriff<\/a>.<\/p>\n<p><em>Nun, diese einfache Erkl\u00e4rung war nun doch nicht so einfach, wie ich dachte.<\/em><\/p>\n<p>Die Forscher verbessern den Algortithmus dann und reduzieren damit die Zahl der Entschl\u00fcsselungsoperationen. Dadurch kann die Attacke, die vorher 240 Jahre gedauert h\u00e4tte, schon in nur 120 Jahren zum Erfolg f\u00fchren, sp\u00e4ter in 12 Jahren, und sp\u00e4ter in nur noch zwei Jahren. Wenn der Angriff dann nicht mehr zwei Jahrhunderte dauert, sondern nur noch zwei Monate, m\u00fcssen wir uns Sorgen machen.<\/p>\n<p>Und hier kommen wir zum aktuellen Fall: Vor drei Jahren sch\u00e4tzte der Intel-Kryptograph Jesse Walker, dass ein Kollisionsangriff auf SHA-1 im Jahr 2015 2<sup>11<\/sup> Server-Jahre dauern w\u00fcrde (eine seltsame Einheit, die auf einem typischen Server basiert).<\/p>\n<p>Dank Cloud-Diensten wie Amazon EC2 kann man sogar die Geldsumme kalkulieren, die in die Infrastruktur gesteckt werden muss, die f\u00fcr das Knacken des Hash-Werts ben\u00f6tigt wird. Mit 700.000 Dollar kann man theoretisch in recht kurzer Zeit eine digitale Signatur f\u00e4lschen.<\/p>\n<p>Doch diese Sch\u00e4tzung stammt aus dem Jahr 2013. Das bedeutet, dass SHA-1 sogar damals schon als nicht besonders zuverl\u00e4ssig eingesch\u00e4tzt wurde, allerdings konnten sich nur reiche staatliche Stellen leisten, den Algorithmus zu knacken.<\/p>\n<p>Und verst\u00e4ndlicherweise haben es solche Organisationen nicht eilig, ihre Erfolge bei ihrem Kampf gegen Verschl\u00fcselungen \u00f6ffentlich zu machen. Aber es ist enorm wichtig, einsch\u00e4tzen zu k\u00f6nnen, wann dieses \u201eWerkzeug\u201c auch f\u00fcr wohlhabene Cyberkriminelle zur Verf\u00fcgung stehen wird.<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter\" src=\"https:\/\/media.kasperskydaily.com\/wp-content\/uploads\/sites\/96\/2015\/10\/06133845\/security-week-42-dog.jpg\" alt=\"\" width=\"1280\" height=\"686\"><\/p>\n<p>K\u00fcrzlich ver\u00f6ffentlichte eine Gruppe von Forschern aus den Niederlanden, Singapur und Frankreich ein White Paper zu den Optimierungsmethoden, die ben\u00f6tigt werden, um die Kollision zu berechnen. Wenn ein Angreifer die Ergebnisse der Forscher in den H\u00e4nden halten w\u00fcrde, w\u00fcrde ein Angriff nur 75.000 Dollar (nach der Amazon-Berechnung) kosten und nur 49 Tage dauern.<\/p>\n<p>Es k\u00f6nnte sogar noch schneller gehen, vorausgesetzt es ist genug Geld vorhanden. Der renommierte Kryptograph Bruce Schneier geht davon aus, dass die Sch\u00e4tzung aus dem Jahr 2012 nur das <a href=\"https:\/\/de.wikipedia.org\/wiki\/Mooresches_Gesetz\" target=\"_blank\" rel=\"noopener nofollow\">Mooresche Gesetz<\/a> in Betracht gezogen hatte, allerdings nicht die Fortschritte bei Angriffsalgorithmen (etwa der Nutzung von GPUs f\u00fcr die Berechnung). Es ist unm\u00f6glich, eine genaue Sch\u00e4tzung dazu zu machen, was die Algorithmusoptimierung bringen k\u00f6nnte.<\/p>\n<p>Hier kommt die traditionelle Frage: Ist das eine echte Bedrohung? Nicht unbedingt. Aber wie werden solche \u201eSicherheitsl\u00fccken\u201c ausgenutzt? Es gibt ein sch\u00f6nes <a href=\"http:\/\/www.theregister.co.uk\/2014\/11\/05\/md5_hash_collision\/\" target=\"_blank\" rel=\"noopener nofollow\">Beispiel<\/a> basierend auf dem weniger sicheren MD5-Algorithmus: Man nimmt zwei verschiedene Dateien (im Beispielsfall zwei Fotos von Rockstars), modifiziert eines davon und bekommt dadurch zwei absolut identische Hash-Werte f\u00fcr zwei total unterschiedliche Fotos.<\/p>\n<p>Gibt es Beispiele aus der echten Welt? Ja, gibt es: Die ber\u00fcchtigte Hacker-Attacke <a href=\"https:\/\/securelist.com\/blog\/incidents\/33002\/flame-replication-via-windows-update-mitm-proxy-server-18\/\" target=\"_blank\" rel=\"noopener\">Flame<\/a> nutzte diese Methode, um eine sch\u00e4dliche Datei mit einem (damals) g\u00fcltigen Microsoft-Zertifikat zu signieren. Diese Signatur wurde eigentlich nur gef\u00e4lscht, doch die Hash-Werte stimmten \u00fcberein. <a href=\"https:\/\/threatpost.com\/what-have-we-learned-flame-malware-061512\/76701\/\" target=\"_blank\" rel=\"noopener nofollow\">Unabh\u00e4ngige Sch\u00e4tzungen<\/a> zeigen, dass so ein Trick, der sogar unzuverl\u00e4ssigere Algorithmen missbraucht, die T\u00e4ter etwa 200.000 bis 2.000.000 Dollar gekostet haben m\u00fcsste \u2013 verdammt teuer!<\/p>\n<p>Was ist also mit SHA-1? Den Algorithmus gibt es seit 1995 und schon im Jahr 2005 war klar, dass er nicht zu den zuverl\u00e4ssigsten geh\u00f6rt. Wenn man von den aktuellen Sch\u00e4tzungen ausgeht, sind praktikable SHA-1-Kollisions-Exploits noch ein Ding der Zukunft, und gleichzeitig wird SHA-1 bereits stetig durch zuverl\u00e4ssigere Hash-Algorithmen ersetzt.<\/p>\n<p>Bis zum Jahr 2017 werden die gro\u00dfen Browser-Entwickler SHA-1 nicht mehr verwenden. Es ist aber auch an der Zeit, dass sie sich beeilen, denn wenn die potenziellen Kosten so eines Angriffs in nur drei Jahren von 2.770.000 Dollar auf 100.000 Dollar gesunken sind, was kann dann im n\u00e4chsten Jahr passieren?<\/p>\n<blockquote class=\"twitter-tweet\" data-width=\"500\" data-dnt=\"true\">\n<p lang=\"en\" dir=\"ltr\"><a href=\"https:\/\/twitter.com\/hashtag\/Security?src=hash&amp;ref_src=twsrc%5Etfw\" target=\"_blank\" rel=\"noopener nofollow\">#Security<\/a> Experts Urge Web Owners to Upgrade From Insecure <a href=\"https:\/\/twitter.com\/hashtag\/SHA1?src=hash&amp;ref_src=twsrc%5Etfw\" target=\"_blank\" rel=\"noopener nofollow\">#SHA1<\/a> Algorithm: <a href=\"http:\/\/t.co\/K9jq9bITlC\" target=\"_blank\" rel=\"noopener nofollow\">http:\/\/t.co\/K9jq9bITlC<\/a> <a href=\"https:\/\/twitter.com\/hashtag\/SSL?src=hash&amp;ref_src=twsrc%5Etfw\" target=\"_blank\" rel=\"noopener nofollow\">#SSL<\/a> <a href=\"https:\/\/twitter.com\/hashtag\/infosec?src=hash&amp;ref_src=twsrc%5Etfw\" target=\"_blank\" rel=\"noopener nofollow\">#infosec<\/a> <a href=\"http:\/\/t.co\/ZDCZUYlwD7\" target=\"_blank\" rel=\"noopener nofollow\">pic.twitter.com\/ZDCZUYlwD7<\/a><\/p>\n<p>\u2014 AT&amp;T Cybersecurity (@attcyber) <a href=\"https:\/\/twitter.com\/attcyber\/status\/653942042805051392?ref_src=twsrc%5Etfw\" target=\"_blank\" rel=\"noopener nofollow\">October 13, 2015<\/a><\/p><\/blockquote>\n<p><script async src=\"https:\/\/platform.twitter.com\/widgets.js\" charset=\"utf-8\"><\/script><\/p>\n<p>In der Zwischenzeit ist die Erforschung von SHA-1-Sicherheitsl\u00fccken eine rein wissenschaftliche Angelegenheit. Sich die potenziellen Konsequenzen klar zu machen, ist so vage, wie nur aufgrund der Aussage \u201eAm 12. April 1961 wurden in der W\u00fcste von Kasachstan 250 Tonnen Raketentreibstoff verbrannt\u201c herauszufinden, dass ein Mensch in den Weltraum geflogen ist. Abwarten und Tee trinken.<\/p>\n<h3>Sicherheitsl\u00fccke in Netgear-Routern ist ausnutzbar<\/h3>\n<p><a href=\"https:\/\/threatpost.com\/disclosed-netgear-router-vulnerability-under-attack\/114960\/\" target=\"_blank\" rel=\"noopener nofollow\">Der Artikel<\/a>. Die <a href=\"http:\/\/seclists.org\/fulldisclosure\/2015\/Oct\/29\" target=\"_blank\" rel=\"noopener nofollow\">Beschreibung<\/a> der Sicherheitsl\u00fccke.<\/p>\n<p>In den Routern Netgear N300 wurde eine Sicherheitsl\u00fccke gefunden. Da haben wir also wieder einmal ein Loch in einem Router \u2013 anders, aber dennoch irgendwie das Gleiche. Wir <a href=\"https:\/\/www.kaspersky.com\/blog\/security-week-36\/9727\/\" target=\"_blank\" rel=\"noopener nofollow\">haben bereits<\/a> einige Fehler in Belkin-Routern besprochen. Aber bei Netgear sieht das Ganze recht d\u00fcster aus.<\/p>\n<p>Wenn man das Web-Interface des Routers \u00f6ffnet und das Passwort eingibt (ein falsches, da es nicht unser Router ist und wir das Passwort nicht kennen), kommt man auf die Zugriff-verweigert-Seite. Wenn man nun versucht, die Seite BRS_netgear_success.html zu \u00f6ffnen\u2026 bringt das gar nichts, zumindest nicht bei den ersten paar Versuchen. Macht man das mehrere Male, hat man damit Erfolg.<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter\" src=\"https:\/\/media.kasperskydaily.com\/wp-content\/uploads\/sites\/96\/2015\/10\/06133845\/security-week-42-netgear.jpg\" alt=\"\" width=\"800\" height=\"600\"><\/p>\n<p>Nat\u00fcrlich sollte man daf\u00fcr in das lokale Netzwerk eingeloggt sein, was die ganze Sache erschwert. Wenn der Router allerdings ein \u00f6ffentliches WLAN in einem Caf\u00e9 betreibt, ist es kein Problem, in das Netzwerk zu gelangen. Und wenn der Besitzer aus irgendeinem Grund beschlossen hat, den Zugriff auf das Web-Interface zu \u00f6ffnen, wird das Ganze noch viel einfacher.<\/p>\n<p>Wei\u00df \u00fcbrigens jemand, warum der Web-Zugriff \u00fcberhaupt f\u00fcr Au\u00dfenstehende ge\u00f6ffnet sein sollte? Und damit meinen wir den Zugriff auf den Router selbst, nicht auf irgendwelche Instanzen im lokalen Netzwerk. Ich denke, es gibt absolut keinen Grund, das zu machen, daf\u00fcr gibt es viele Gr\u00fcnde, es NICHT zu machen.<\/p>\n<blockquote class=\"twitter-tweet\" data-width=\"500\" data-dnt=\"true\">\n<p lang=\"en\" dir=\"ltr\">Disclosed <a href=\"https:\/\/twitter.com\/NETGEAR?ref_src=twsrc%5Etfw\" target=\"_blank\" rel=\"noopener nofollow\">@Netgear<\/a> Router Vulnerability Under Attack: <a href=\"https:\/\/t.co\/P5s6uItTjn\" target=\"_blank\" rel=\"noopener nofollow\">https:\/\/t.co\/P5s6uItTjn<\/a> via <a href=\"https:\/\/twitter.com\/threatpost?ref_src=twsrc%5Etfw\" target=\"_blank\" rel=\"noopener nofollow\">@threatpost<\/a> <a href=\"http:\/\/t.co\/RgFM9SGSGu\" target=\"_blank\" rel=\"noopener nofollow\">pic.twitter.com\/RgFM9SGSGu<\/a><\/p>\n<p>\u2014 Kaspersky (@kaspersky) <a href=\"https:\/\/twitter.com\/kaspersky\/status\/652184022597169153?ref_src=twsrc%5Etfw\" target=\"_blank\" rel=\"noopener nofollow\">October 8, 2015<\/a><\/p><\/blockquote>\n<p><script async src=\"https:\/\/platform.twitter.com\/widgets.js\" charset=\"utf-8\"><\/script><\/p>\n<p>Die Situation mit den Belkin-Routern entwickelte sich ganz gesetzestreu: Der Hersteller wurde dar\u00fcber benachrichtigt und innerhalb von zwei Monaten bot das Unternehmen eine Betaversion der neuen Firmware an. Es sah so aus, als w\u00e4re alles gut, doch dann kam die schlechte Nachricht: Die Sicherheitsl\u00fccke wurde bereits ausgenutzt.<\/p>\n<p>Die schweizerische Sicherheitsfirma Compass Security entdeckte nun einen gef\u00e4lschten Router mit ver\u00e4nderten Einstellungen: Der DNS-Server geh\u00f6rte nicht wie \u00fcblich zu einem Provider, sondern zu wem auch immer. Dieser unbekannte Agent erhielt alle DNS-Anfragen. Bei der Untersuchung stellte sich heraus, dass der Angriffs-Server \u00fcber 10.000 gehackte Router bediente.<\/p>\n<p>https:\/\/twitter.com\/NETGEARhelp\/status\/653682920540999680<\/p>\n<p>\u00dcbrigens versuchte Compass Security mehrmals, eine Antwort von Netgear zu bekommen. Als die Konversation endlich begann, stellte die Firma sogar schon eine Betaversion der neuen Firmware f\u00fcr einen Test zur Verf\u00fcgung. Doch dann tauchte pl\u00f6tzlich ein neuer Mitspieler auf: Eine Firma namens Shellshock Labs ver\u00f6ffentlichte ihre eigene Forschungsarbeit, ohne vorher mit irgendjemandem zu sprechen (was schlecht ist).<\/p>\n<p>Nat\u00fcrlich ist es cool, eine Forschungsfirma nach einem <a href=\"https:\/\/www.kaspersky.com\/blog\/what_is_the_bash_vulnerability\/6117\/\" target=\"_blank\" rel=\"noopener nofollow\">ber\u00fcchtigten Fehler in Bash<\/a> zu benennen, aber das setzt die Regel \u201ekeine Sch\u00e4den zuzuf\u00fcgen\u201c nicht au\u00dfer Kraft. Davon abgesehen halfen die \u201eShellshocker\u201c aber dabei, zu verstehen, woher der Fehler kommt. Der Firmware-Code macht es einmal beim ersten Start ohne Passwort m\u00f6glich, Zugriff auf das Webinterface zu bekommen. Um das auszuschalten, sollte eine Markierung vorhanden sein, war sie aber nicht. Und ja, die Firmware wurde schlie\u00dflich <a href=\"https:\/\/threatpost.com\/netgear-publishes-patched-firmware-for-routers-under-attack\/115006\/\" target=\"_blank\" rel=\"noopener nofollow\">aktualisiert<\/a>.<\/p>\n<h3>87 Prozent der Android-Ger\u00e4te sind unsicher<\/h3>\n<p><a href=\"https:\/\/threatpost.com\/researchers-find-85-percent-of-android-devices-insecure\/115030\/\" target=\"_blank\" rel=\"noopener nofollow\">Der Artikel<\/a>. Die <a href=\"http:\/\/androidvulnerabilities.org\/\" target=\"_blank\" rel=\"noopener nofollow\">Webseite zur Forschungsarbeit<\/a>, inklusive der Sicherheitsbewertung der Ger\u00e4te, nach Hersteller sortiert.<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter\" src=\"https:\/\/media.kasperskydaily.com\/wp-content\/uploads\/sites\/96\/2015\/10\/06133844\/security-week-42-lemur.jpg\" alt=\"\" width=\"800\" height=\"800\"><\/p>\n<p>Kaum zu glauben! Das ist noch nie passiert und jetzt geht es schon wieder los! Wir sprechen \u00fcber eine weitere wissenschaftliche Forschungsarbeit (zum Gl\u00fcck nicht so kompliziert wie die zu SHA-1). Forscher der University of Cambridge haben etwas Faszinierendes getan: Sie haben Daten zu 32 kritischen Android-Sicherheitsl\u00fccken ausgew\u00e4hlt, davon die 13 schlimmsten genommen und eine riesige Menge Ger\u00e4te verschiedener Hersteller auf deren Angreifbarkeit gepr\u00fcft.<\/p>\n<p>Die Forscher entwickelten eine Ger\u00e4teanalyse-App, um telemetrische Daten auf den ausgew\u00e4hlten Ger\u00e4ten zu sammeln, inklusive der Betriebssystemversion und der Ger\u00e4tenummer. Damit bekamen die Forscher Daten zu \u00fcber 20.000 Smartphones.<\/p>\n<p>Durch Vergleich der Betriebssystemversionen mit den Daten zu Sicherheitsl\u00fccken konnten die Forscher das Ausma\u00df des Problems einsch\u00e4tzen. Und das sieht so aus:<\/p>\n<p>Die Ergebnisse wurden normalisiert und zeigen, dass 87 Prozent der Ger\u00e4te \u00fcber die ein oder andere kritische Sicherheitsl\u00fccke angreifbar sind (in manchen F\u00e4llen sogar mehr als nur eine). Man muss noch das Wort \u201epotenziell\u201c hinzuf\u00fcgen: Wie man an der <a href=\"https:\/\/threatpost.com\/android-stagefright-flaws-put-950-million-devices-at-risk\/113960\/\" target=\"_blank\" rel=\"noopener nofollow\">Stagefright<\/a>-Geschichte sehen konnte, kann nicht einmal die gef\u00e4hrlichste Sicherheitsl\u00fccke aufgrund von praktischen Beschr\u00e4nkungen voll ausgenutzt werden.<\/p>\n<p>Die Forscher haben zudem sogar eine Wertung erstellt, mit der das Ma\u00df an \u201eGef\u00e4hrlichkeit\u201c bei verschiedenen Herstellern eingesch\u00e4tzt werden kann \u2013 diesen Wert nannten sie FUM-Wert. Dieser basiert auf der Zeit, die ein Hersteller braucht, um nach der Bekanntmachung eines neuen Fehlers einen finalen Patch auszuliefern.<\/p>\n<blockquote class=\"twitter-tweet\" data-width=\"500\" data-dnt=\"true\">\n<p lang=\"en\" dir=\"ltr\">Researchers find 85% of <a href=\"https:\/\/twitter.com\/hashtag\/Android?src=hash&amp;ref_src=twsrc%5Etfw\" target=\"_blank\" rel=\"noopener nofollow\">#Android<\/a> devices insecure: <a href=\"https:\/\/t.co\/YNbAdZKAAv\" target=\"_blank\" rel=\"noopener nofollow\">https:\/\/t.co\/YNbAdZKAAv<\/a> <a href=\"http:\/\/t.co\/1dYfutssgh\" target=\"_blank\" rel=\"noopener nofollow\">pic.twitter.com\/1dYfutssgh<\/a><\/p>\n<p>\u2014 Eugene Kaspersky (@e_kaspersky) <a href=\"https:\/\/twitter.com\/e_kaspersky\/status\/654692215587864577?ref_src=twsrc%5Etfw\" target=\"_blank\" rel=\"noopener nofollow\">October 15, 2015<\/a><\/p><\/blockquote>\n<p><script async src=\"https:\/\/platform.twitter.com\/widgets.js\" charset=\"utf-8\"><\/script><\/p>\n<p>Und die Gewinner sind hier nat\u00fcrlich Nexus-Ger\u00e4te: Sie bekommen neue Patches schneller als alle anderen. LG und Motorla liegen auf dem zweiten beziehungsweise dritten Platz dieser Wertung. Allerdings kann man sie alle kaum als Gewinner bezeichnen, da im Grunde alle Teilnehmer Verlierer sind.<\/p>\n<p>Die Wertung zieht den Anteil der aktualisierten Ger\u00e4te in Betracht, denn auch wenn ein Hersteller einen Patch ver\u00f6ffentlicht, m\u00fcssen die Anwender dennoch ihr Ger\u00e4t selbst aktualisieren. Je \u00e4lter das Ger\u00e4t, desto schlimmer: In einer separaten Wertung mit zwei bis drei Jahre alten Ger\u00e4ten waren die Werte be\u00e4ngstigend. Warum ist das so? Die Besitzer aktualisieren sie nie, benutzen sie aber noch.<\/p>\n<p>Die Forschungsarbeit enth\u00e4lt aber auch einige diskutierbare Annahmen sowie viel Spekulation, und das Ergebnis war eigentlich zu erwarten. Die Forscher sagen dazu, dass eines ihrer Ziele war, die Hersteller dazu zu motivieren, die Auslieferung der Patches zu verbessern. Wichtig ist aber, zu verstehen, dass dieses \u00d6kosystem nicht zu 100 Prozent sicher sein kann.<\/p>\n<blockquote class=\"twitter-tweet\" data-width=\"500\" data-dnt=\"true\">\n<p lang=\"en\" dir=\"ltr\">New study suggests 85% of Android devices exposed to at least one critical vulnerability: <a href=\"http:\/\/t.co\/vZAtW8JhiS\" target=\"_blank\" rel=\"noopener nofollow\">http:\/\/t.co\/vZAtW8JhiS<\/a><\/p>\n<p>\u2014 Gizmodo (@Gizmodo) <a href=\"https:\/\/twitter.com\/Gizmodo\/status\/654627155771527169?ref_src=twsrc%5Etfw\" target=\"_blank\" rel=\"noopener nofollow\">October 15, 2015<\/a><\/p><\/blockquote>\n<p><script async src=\"https:\/\/platform.twitter.com\/widgets.js\" charset=\"utf-8\"><\/script><\/p>\n<p>Android, das furchtbar segmentiert ist, ist das beste Beispiel f\u00fcr ein unsicheres \u00d6kosystem. Man kann nat\u00fcrlich sagen, dass iOS sicherer ist, aber die erste Meldung unseres R\u00fcckblicks zeigt, dass kein System, aus Budgetgr\u00fcnden, hunderprozentig sicher ist. Das ist ein wichtiger Punkt bei der Auswahl einer Sicherheitsstrategie.<\/p>\n<h3>Was sonst noch passiert ist:<\/h3>\n<p>Apple <a href=\"https:\/\/threatpost.com\/apple-removes-apps-that-expose-encrypted-traffic\/114992\/\" target=\"_blank\" rel=\"noopener nofollow\">s\u00e4uberte<\/a> den App Store von Apps, die Hackern halfen, verschl\u00fcsselten Datenverkehr durch die Installation von Root-Zertifikaten abzufangen und zu modifizieren \u2013 zur Blockierung von Adware oder Schlimmerem. Und wie ich es verstehe, wird es Apps mit solchen F\u00e4higkeiten auch nicht mehr geben. Warum war es f\u00fcr die ges\u00e4uberten Apps dann m\u00f6glich?<\/p>\n<blockquote class=\"twitter-tweet\" data-width=\"500\" data-dnt=\"true\">\n<p lang=\"en\" dir=\"ltr\">Apple Removes Apps That Expose Encrypted Traffic <a href=\"https:\/\/t.co\/fHQiLSCypy\" target=\"_blank\" rel=\"noopener nofollow\">https:\/\/t.co\/fHQiLSCypy<\/a> via <a href=\"https:\/\/twitter.com\/threatpost?ref_src=twsrc%5Etfw\" target=\"_blank\" rel=\"noopener nofollow\">@threatpost<\/a> <a href=\"http:\/\/t.co\/np2fFUmvc8\" target=\"_blank\" rel=\"noopener nofollow\">pic.twitter.com\/np2fFUmvc8<\/a><\/p>\n<p>\u2014 Kaspersky (@kaspersky) <a href=\"https:\/\/twitter.com\/kaspersky\/status\/652558957429567490?ref_src=twsrc%5Etfw\" target=\"_blank\" rel=\"noopener nofollow\">October 9, 2015<\/a><\/p><\/blockquote>\n<p><script async src=\"https:\/\/platform.twitter.com\/widgets.js\" charset=\"utf-8\"><\/script><\/p>\n<p>Die European Aviation Security Agency (EASA) hat Informationen zu einem Fehler in <a href=\"https:\/\/ru.wikipedia.org\/wiki\/ACARS\" target=\"_blank\" rel=\"noopener nofollow\">ACARS<\/a> <a href=\"https:\/\/threatpost.com\/european-aviation-agency-warns-of-aircraft-hacking\/114987\/\" target=\"_blank\" rel=\"noopener nofollow\">\u00a0<\/a><a href=\"https:\/\/threatpost.com\/european-aviation-agency-warns-of-aircraft-hacking\/114987\/\" target=\"_blank\" rel=\"noopener nofollow\">ver\u00f6ffentlicht<\/a> \u2013 das System wird f\u00fcr die Kommunikation zwischen Flugzeug und Bodenstation verwendet. Es ist recht einfach, gef\u00e4lschte Nachrichten \u00fcber das System zu versenden, das keine Paketverifizierung voraussetzt.<\/p>\n<blockquote class=\"twitter-tweet\" data-width=\"500\" data-dnt=\"true\">\n<p lang=\"en\" dir=\"ltr\">European Aviation Agency Warns of Aircraft Hacking: <a href=\"https:\/\/t.co\/PDcT6J5ENg\" target=\"_blank\" rel=\"noopener nofollow\">https:\/\/t.co\/PDcT6J5ENg<\/a> via <a href=\"https:\/\/twitter.com\/threatpost?ref_src=twsrc%5Etfw\" target=\"_blank\" rel=\"noopener nofollow\">@threatpost<\/a> <a href=\"https:\/\/twitter.com\/hashtag\/planehack?src=hash&amp;ref_src=twsrc%5Etfw\" target=\"_blank\" rel=\"noopener nofollow\">#planehack<\/a> <a href=\"http:\/\/t.co\/nC1x5JLR0p\" target=\"_blank\" rel=\"noopener nofollow\">pic.twitter.com\/nC1x5JLR0p<\/a><\/p>\n<p>\u2014 Kaspersky (@kaspersky) <a href=\"https:\/\/twitter.com\/kaspersky\/status\/652509465900658696?ref_src=twsrc%5Etfw\" target=\"_blank\" rel=\"noopener nofollow\">October 9, 2015<\/a><\/p><\/blockquote>\n<p><script async src=\"https:\/\/platform.twitter.com\/widgets.js\" charset=\"utf-8\"><\/script><\/p>\n<p>Nat\u00fcrlich erlaubt diese Sicherheitsl\u00fccke nicht das \u00dcbernehmen der Flugkontrollen, kann aber verwendet werden, um irref\u00fchrende Nachrichten an die Piloten zu schicken. Der Fehler in ACARS wurde bereits im Jahr 2013 (in verschiedenen PDF-Dateien) <a href=\"https:\/\/conference.hitb.org\/hitbsecconf2013ams\/materials\/D1T1%2520-%2520Hugo%2520Teso%2520-%2520Aircraft%2520Hacking%2520-%2520Practical%2520Aero%2520Series.pdf\" target=\"_blank\" rel=\"noopener nofollow\">besprochen<\/a>, aber ausschlie\u00dflich von Sicherheitsforschern; diesmal ist es eine Aufsichtsbeh\u00f6rde, die das Problem anspricht. Das ist eine gute Nachricht!<\/p>\n<p><strong>Oldies:<\/strong><\/p>\n<p>Indicator-734<\/p>\n<p>Ein gef\u00e4hrlicher, residenter Virus. Er infiziert .COM-Dateien, wenn diese in den Speicher geladen werden. Der Virus verschl\u00fcsselt den Anfang der Dateien und nutzt daf\u00fcr 10h Byte des BIOS. Das bedeutet, dass die Dateien nur auf einem Computer mit dem gleichen BIOS entschl\u00fcsselt und gestartet werden k\u00f6nnen. Wenn der Anfang der Datei nicht entschl\u00fcsselt werden kann, blockiert der Virus die Operationen der Datei (int 20h), da er seinen Z\u00e4hler vorher gestartet hat. Je nach Z\u00e4hlerstand (ungef\u00e4hr einmal pro Stunde), malt der Virus ein rotes Kreuz auf den Bildschirm mit dem Logo \u201eVindicator\u201c in dessen Mitte. Der Virus \u00fcbernimmt int 1Ch, 21h.<\/p>\n<p><em>Zitat aus \u201eMS-DOS-Computerviren\u201c von Eugene Kaspersky, 1992, Seite 70.<\/em><\/p>\n<p><em>Hinweis: Diese Kolumne spiegelt die pers\u00f6nliche Meinung des Autors wider. Diese kann, muss aber nicht mit der Position von Kaspersky Lab \u00fcbereinstimmen. Das ist Gl\u00fccksache.<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"<p>In dieser Folge unseres Wochenr\u00fcckblicks geht es um die Resultate gro\u00dfer Fehler der Technologie-Giganten.<\/p>\n","protected":false},"author":53,"featured_media":6286,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[2711,6],"tags":[55,109,380,1592,979,1653,1598],"class_list":{"0":"post-6284","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-threats","8":"category-news","9":"tag-android","10":"tag-apple","11":"tag-router","12":"tag-ruckblick","13":"tag-sha-1","14":"tag-security","15":"tag-sicherheitswoche"},"hreflang":[{"hreflang":"de","url":"https:\/\/www.kaspersky.de\/blog\/security-week-42\/6284\/"},{"hreflang":"en-us","url":"https:\/\/usa.kaspersky.com\/blog\/security-week-42\/6148\/"},{"hreflang":"en-gb","url":"https:\/\/www.kaspersky.co.uk\/blog\/security-week-42\/6345\/"},{"hreflang":"es-mx","url":"https:\/\/latam.kaspersky.com\/blog\/security-week-42\/6325\/"},{"hreflang":"es","url":"https:\/\/www.kaspersky.es\/blog\/security-week-42\/7108\/"},{"hreflang":"it","url":"https:\/\/www.kaspersky.it\/blog\/security-week-42\/6836\/"},{"hreflang":"ru","url":"https:\/\/www.kaspersky.ru\/blog\/security-week-42\/9370\/"},{"hreflang":"x-default","url":"https:\/\/www.kaspersky.com\/blog\/security-week-42\/10278\/"},{"hreflang":"ja","url":"https:\/\/blog.kaspersky.co.jp\/security-week-42\/9276\/"},{"hreflang":"ru-kz","url":"https:\/\/blog.kaspersky.kz\/security-week-42\/9370\/"},{"hreflang":"en-au","url":"https:\/\/www.kaspersky.com.au\/blog\/security-week-42\/10278\/"},{"hreflang":"en-za","url":"https:\/\/www.kaspersky.co.za\/blog\/security-week-42\/10278\/"}],"acf":[],"banners":"","maintag":{"url":"https:\/\/www.kaspersky.de\/blog\/tag\/android\/","name":"android"},"_links":{"self":[{"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/posts\/6284","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/users\/53"}],"replies":[{"embeddable":true,"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/comments?post=6284"}],"version-history":[{"count":4,"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/posts\/6284\/revisions"}],"predecessor-version":[{"id":28825,"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/posts\/6284\/revisions\/28825"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/media\/6286"}],"wp:attachment":[{"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/media?parent=6284"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/categories?post=6284"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/tags?post=6284"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}