Schwere Sicherheitslücke in 2.1/2.2

In unverschlüsselten WLANs oder solchen, bei denen alle Anwender den gleichen Schlüssel benutzen, kann ein Angreifer das Token mit Wireshark mitlesen und für eigene Zwecke verwenden, wie Forscher der Uni Ulm berichten.
Panikmache wie immer.
Wer in offenen WLans sicherheitsrelevante Sachen macht, hat es nicht besser verdient.
 
  • Danke
Reaktionen: Geordi2k9
FZelle schrieb:
Panikmache wie immer.
Wer in offenen WLans sicherheitsrelevante Sachen macht, hat es nicht besser verdient.

"[...]oder solchen, bei denen alle Anwender den gleichen Schüssel benutzen[...]"

Das dürfte so ziemlich 99% aller privaten WLANs betreffen...
 
joa, nur um den Token mitlesen zu können muß man glaub ich zugriff auf das Netzwerk haben... oder?
und die frage ist ja, wieviele Leute in einem Privaten Netzwerk im durchschnitt per WLAN verbunden sind (so zwischen 1 bis 3 Personen, je nach größe des Haushaltes) und da fragt man sich wer da dann der Angreifer ist...

und wo gibt es keine Sicherheitslücken? die gibt es selbst im Market, denn es soll ja böse apps geben, die dich ausspionieren und zugriff auf dein gesamtes Phone haben, nur wer sowas installiert ist ja selbst schuld...
und genau so selbst schuld ist jemand, der sein WLAN nicht richtig absichert und dann per Handy seine Bankgeschäfte erledigt, am besten noch wenn er in dem Laden mit dem Großen Goldenem M sitz und nen BigMac ist...
 
FZelle schrieb:
Panikmache wie immer.
Wer in offenen WLans sicherheitsrelevante Sachen macht, hat es nicht besser verdient.

Ich glaube ganz so einfach ist das nicht. Der automatische Sync von Mail und Kalender läuft ja auch noch weiter, wenn man offene WLans nutzt. Wer denkt schon immer dran, die abzuschalten. Darum ging es in der Meldung.
Da surft man vielleicht nur ein wenig rum und vermeidet kritische Anwendungen und trotzdem werden die unverschlüsselten Token im Hintergrund übermittelt.
 
Einfach nicht mit unverschlüsselten WLANs verbinden. Wer dort surft, egal ob mit PC oder Handy, ist eh selber schuld wenn jemand seinen Netzwerkverkehr mitliest.
 
Müsste das gleiche Problem nicht auch im Netz des Providers auftreten (mindestens mal mit allen die in der gleichen Zelle eingebucht sind)? Ich kann mir nicht vorstellen, dass dort jeder Client per Switch, NAT und/oder Firewall von den anderen abgeschottet ist.
 
TheSpiritof69 schrieb:
Einfach nicht mit unverschlüsselten WLANs verbinden. Wer dort surft, egal ob mit PC oder Handy, ist eh selber schuld wenn jemand seinen Netzwerkverkehr mitliest.

In verschlüsselten WLAN bist du auch nicht sicherer. Bei mehreren PC's im privaten Netzwerk, die auch noch von verschiedenen Personen genutzt werden, kannst du auch nie sicher sein, das die immer Clean sind oder keiner die Token mit liest.
Nicht zu vergessen Firmennetzwerke wenn man dort sein Android nutzen darf (oder muss).
Ganz so einfach mit '"Selber Schuld" ist das nicht.
 
TheSpiritof69 schrieb:
Einfach nicht mit unverschlüsselten WLANs verbinden. Wer dort surft, egal ob mit PC oder Handy, ist eh selber schuld wenn jemand seinen Netzwerkverkehr mitliest.
Selber schuld wenn mans weiß. Es werden jeden Tag 400.000 neue Android Geräte aktiviert, wieviele von denen wissen, dass man in offenen WLans die Synchro deaktivieren sollte? Es gibt zwei Richtungen von Ignoranz und deine ist die schlimmere.

Thyrion schrieb:
Müsste das gleiche Problem nicht auch im Netz des Providers auftreten (mindestens mal mit allen die in der gleichen Zelle eingebucht sind)? Ich kann mir nicht vorstellen, dass dort jeder Client per Switch, NAT und/oder Firewall von den anderen abgeschottet ist.
Im Netz des Providers hat man nicht mal mehr eine eigene IP sondern teilt sich die mit ein paar anderen, deshalb sollte das vernünftig geswitched sein.

Und das Thema gabs schonmal: https://www.android-hilfe.de/forum/...il-kontodaten-nicht-verschluesselt.91107.html
 
wenn die lücke wirklich so gravierend ist, ist dann der handyhersteller nicht verpflichtet diese zu schließen? also sozusagen z.b. eine neue android version anzubieten die die lücke schliesst? oder kann man auch kleinere patches bringen?
 
crobe schrieb:
Im Netz des Providers hat man nicht mal mehr eine eigene IP sondern teilt sich die mit ein paar anderen, deshalb sollte das vernünftig geswitched sein.
Aber doch nur nach außen hin. Innerhalb des Netzes teile ich mir doch keine IPs mit anderen, oder?
Und ich glaube nicht, dass dort für jedes Gerät ein eigenes Netz aufgemacht wird.

Ich glaube, ich muss mal ein wenig mit Shark rumspielen ;)
 
meierzwo schrieb:
In verschlüsselten WLAN bist du auch nicht sicherer. Bei mehreren PC's im privaten Netzwerk, die auch noch von verschiedenen Personen genutzt werden, kannst du auch nie sicher sein, das die immer Clean sind oder keiner die Token mit liest.
Nicht zu vergessen Firmennetzwerke wenn man dort sein Android nutzen darf (oder muss).
Ganz so einfach mit '"Selber Schuld" ist das nicht.

In privaten Netzen gehe ich davon aus, dass ich den Leuten, mit denen ich das Netz teile vertrauen kann.
Firmennetze sind natürlich eine andere Geschichte, aber die meide ich so gut es geht.


crobe schrieb:
Selber schuld wenn mans weiß. Es werden jeden Tag 400.000 neue Android Geräte aktiviert, wieviele von denen wissen, dass man in offenen WLans die Synchro deaktivieren sollte? Es gibt zwei Richtungen von Ignoranz und deine ist die schlimmere.

Im Netz des Providers hat man nicht mal mehr eine eigene IP sondern teilt sich die mit ein paar anderen, deshalb sollte das vernünftig geswitched sein.

Und das Thema gabs schonmal: https://www.android-hilfe.de/forum/...il-kontodaten-nicht-verschluesselt.91107.html

Wie gesagt, wenn man offene WLAN-Netze grundsätzlich vermeidet, verringert man wegen obigem Punkt das Risiko jedweden Datenklaus, egal ob vom Handy oder vom Notebook aus ungemein.

Das hat auch nichts mit Ignoranz zu tun. Wenn ich eine offenes, unverschlüsseltes, selbst ein nur WEP-verschlüsseltes WLAN sehe verbinde ich nicht, weil ich immer davon ausgehe, dass Anwendungen bzw. Apps kein SSL verwenden. Ende.

tavoc schrieb:
Android vulnerability exposes users to data theft | Mobile security - InfoWorld

da nochmal.

Und es beschränkt sich nicht nur auf offene WLANs. Ich kann ja einen eigenen AP spoofen mit gleicher SSID und stärkerer Abstrahlleistung. Jedes Handy wird sich dann dahin verbinden, welches die SSID kennt.

AP-Spoofing lässt sich vermeiden, wenn man den Access-Point richtig einrichtet, zB mit Zertifikaten und Verifikation selbiger auf dem Client.
 
AP Spoofing lässt sich vermeiden wenn du den AP richtig einstellst, ja. Aber wenn ich als Angreifer einen eigenen AP anbiete, der die gleiche SSID anbietet, dann wird der Kunde davon nichts merken.

Ein HTC Desire verbindet sich z.B. ohne zu meckern damit. Nur weil es den Namen kennt. Gut ist in dem Fall sowas wie Karmasploit, sodass der AP auf jeden Namen in deiner SSID Liste mit ja antwortet.
Und selbst wenn man keinen eigenen AP hat, das UNI Wlan ist immer wieder toll. VOrallem zu Semesterbeginn, neben den ganzen Freigaben der Windows Kisten kommen nun noch die Smartphones.

Und weiter gilt es noch die Sicherheit der anderen mobilen Netze zu beurteilen, es ist ein interessantes Thema, nur leider "darf" man dort nicht so frei testen. Ich denke nicht das UMTS und co wirklich sicher sind und eine saubere Trennung erlauben. Letzendlich bleibt der Faktor Mensch übrig, über diesen wird es immer eine Möglichkeit geben eine Schwachstelle auszunutzen.
 
Das ein Man-in-ihe-middle-Angriff unabhängig vom OS immer möglich ist brauchen wir doch eh nicht zu diskutieren, oder?
Der Fehler in Android oder eher den Apps liegt ja darin, dass die Authentifizierungs-Token unverschlüsselt versendet werden! Warum ein Konzern wie Google solche doofen Fehler macht verstehe ich nicht :thumbdn: Ich hoffe ganz stark, dass Google hier sehr schnell reagiert und vielleicht sogar per "Push" die betroffenden Apps auf allen betroffenen Android Geräten fixt.
 
  • Danke
Reaktionen: Haggy
Ein Update wäre wünschenswert. Es müsste einfach nur die API der Programme geändert werden, z.b. alles über SSL senden. Das wärs schon.

Bin gespannt wann das gelöst wird, und ob die meisten neuen Geräte ein zeitnahes Update erhalten.
 
Was ich an der Sache interessant finde, das Thema wird schon im Radio rauf und runter gespielt, und hier in den News ist es noch nicht aufgetaucht?
 
TheSpiritof69 schrieb:
Das hat auch nichts mit Ignoranz zu tun. Wenn ich eine offenes, unverschlüsseltes, selbst ein nur WEP-verschlüsseltes WLAN sehe verbinde ich nicht, weil ich immer davon ausgehe, dass Anwendungen bzw. Apps kein SSL verwenden. Ende.
Doch, hat es :)
 
Wow, Sebastian war bisher der Einzige der das Problem vollständig erkannt hat. Das hat nicht im Geringsten mit WLAN und dessen Verschlüsselung zu tun. Solange das Auth-Token nicht auf der kompletten Strecke zwischen Telefon und Googleserver verschlüsselt übertragen wird, ist es ohne großen Aufwand auf der komplette Strecke auslesbar. Das gilt für sämtliche unverschlüsselte Kommunikation.
 
quatschkopf schrieb:
wenn die lücke wirklich so gravierend ist, ist dann der handyhersteller nicht verpflichtet diese zu schließen? also sozusagen z.b. eine neue android version anzubieten die die lücke schliesst? oder kann man auch kleinere patches bringen?

Es stellt sich die Frage ob die Fehler der offenen Tokens App-Fehler sind. Dann ist Google in der Pflicht.

Sind es OS-Fehler ( weil dafür vielleicht eine API genutzt wird), dann ist zunächst auch Google dran, aber das ganze zieht Fäden zu den Providern und Herstellern.

Immerhin liegt meinem Desire Z ein Mangel zu Grunde. Den kann ich nicht selbst beheben ( signierter Bootloader, also kein eigenständiges aufspielen von Android 2.3.4) und somit ist HTC doch in der Pflicht den Mangel abzustellen! Hätte ich Zeit, würde es mich förmlich jucken das auszutesten. Bisher hat mich der signierte Bootloader nicht gestört, jetzt denke ich darüber nach beim nächsten mal eben doch ein Telefon mit offenem Bootloader zu nehmen ( also kein HTC mehr).
 

Ähnliche Themen

M
Antworten
2
Aufrufe
493
marexel
M
DerAndroidUser
Antworten
1
Aufrufe
262
mblaster4711
mblaster4711
A
Antworten
6
Aufrufe
648
allsquare
A
Zurück
Oben Unten