Gratis In-App-Käufe: Apple nimmt Ermittlungen auf

Ende dieser Woche sorgte die von einem in Russland ansässigen Entwickler gefundene Möglichkeit, die so genannten In-App-Einkäufe kostenlos abwickeln zu können, für Aufsehen. Apple hat sich dazu jetzt öffentlich geäußert. mehr... Apple, Apps, App Store, Appstore Apple, Apps, App Store, Appstore Apple

Diese Nachricht vollständig anzeigen.

Jetzt einen Kommentar schreiben
 
Aus meiner Sicht ist das übertragen der Passwörter im Klartext das eigentliche große Problem und sehr fahrlässig von Apple. Das bedeutet das theoretisch jeder in einem öffentlichen Wlan das iTunes Passwort auslesen kann, wenn in einem solchen Wlan ein InApp Kauf getätigt wird
 
@paris: Siehe meinen Post weiter unten. Die Kennwörter werden NICHT "völlig unverschlüsselt" übertragen. Die gesamte Kommunikation mit dem App Store ist per TLS verschlüsselt. Man kann in einem offenen WLAN also NICHT die Kennwörter mitlesen.
 
@paris: Schon komisch das "sichere" Sandkastenprinzip. "Die Kinder hocken im Sandkasten, aber die Spielsachen sind außerhalb." Und dann ärgern sie sich noch warum sich jemand mal eins mitnimmt.
 
@***XOX***: Was hat das mit dem Thema zu tun?
 
@exocortex: Es hat etwas auf ironischer Weise mit dem Thema zu tun. Apple versucht mit allen Mitteln den Menschen zu übermitteln, dass ihr Konzept sehr sicher sei und man bedenkenlos seine Daten ihnen vertrauenswürdig mit all den persönlichen Angaben, inklusive Geld, in irgendwelchen Apps stecken kann. Wie man sieht, braucht etwas nicht von Vieren oder Trojaner befallen zu sein um unsicher zu werden.
Jetzt ist es schief gelaufen und wer immernoch nichts daraus lernt, ist einfach selber schuld.
 
@***XOX***: Genau, da passiert ein Fehler, was ein Konzern vermutlich schnell lösen kann und schon ist es ein Argument auf Apple zu verzichten...
 
@algo: Das ist nicht nur ein kleiner Fehler, wenn man Login Daten unverschlüsselt übermittelt, die auch mit Zahlungsdaten usw. verknüpft sind.
 
@charnold: Sie werden nicht unverschlüsselt übermittelt. Die Verbindung ist mit SSL/TLS gesichert.
 
@charnold: Wo habe ich was von "klein" geschrieben ? Da steht doch nur "Fehler" ?!
 
@paris: Man kann nicht einfach im WLAN die Daten mitsniffen.
Das sollte man im Artikel vielleicht auch schreiben, liest sich etwas anders. In der verschlüsselten Kommunikation werden die Daten "lediglich" unverschlüsselt übermittelt. Man hat also nur ein Problem, wenn man nicht mehr mit dem Apple Server kommuniziert. Trotzdem sollte Apple das fixen, ist allerdings nicht ganz so akut, wie es sich hier liest.
 
@paris: Login Zertifikate durch die eines russischen Hackers tauschen, welcher offenbar kein Problem mit Diebstahl hat, ist hier die größte Fahrlässigkeit.
 
@WeeZer: Er ist der erste, der damit an die Öffentlichkeit geht, aber er muss nicht der einzige sein. Es gibt viele Hacker, die ihre Hintertürchen für sich behalten und nutzen.
 
@***XOX***: Er selbst hat ja garkein Mehrwert bekommen. Für die In-App Käufe musste er selbst mehrere hundert $ ausgegeben. Hat dann die echten Signierungen an Dritte verteilt. Funktioniert weil sie nicht Geräte gebunden sind, böses Apple hat nicht genug DRM eingebaut. Eine Schande!
 
@paris: Apple spart halt an Entwicklungskosten wenn sie Sicherheit vernachlässigen :) Wurde ja schon oft genug bei Apple praktiziert
 
@lecker_schnipo: Zum Beispiel?
 
@exocortex: http://bit.ly/MwF9eJ
 
@lecker_schnipo: Den Link den du mir schickst macht nur dann Sinn, wenn ich weiß nach was ich suchen soll, aber nur zu faul bin selbst danach zu suchen. Er macht aber keinen Sinn, wenn du mir damit mitteilen willst nach was ich suchen soll. Woher soll ich wissen welche Sicherheitslücke du mit deinem Beitrag meinst?
 
@exocortex: SSL/TLS ist nur eine Übertragungsverschlüsselung und keine Datenverschlüsselung. Daher werden die Kennwörter und IDs sehr wohl im Klartext übertragen und sind somit durch "Man-in-the-Middle-Angriffe" abgreifbar.
 
@DennisMoore: Den Unterschied zwischen "Übertragungsverschlüsselung" und "Datenverschlüsselung" musst du mir jetzt aber mal erklären ...

Aber gut, bleiben wir bei deiner Argumentation. Demnach übermittelt Facebook mein Kennwort also auch im Klartext? Und wenn ich mich bei Google Mail anmelde, wird mein Kennwort ebenfalls im Klartext übermittelt? Laut deiner Argumentation verwenden überhaupt alle Webseiten Klartext-Passwörter!
 
@exocortex: Ich weiß nicht ob Google oder die anderen das Passwort verschlüsseln bevor sie es über die SSL-Verbindung schicken. Daher kann ich nicht beantworten ob sie das Kennwort im Klartext übermitteln. Wie auch immer: Der Unterschied zwischen Datenverschlüsselung und Übertragungsverschlüsselung ist, dass es einem nichts nutzt bei Datenverschlüsselung den Datenstrom mitzulesen. Bei reiner Übertragungsverschlüsselung schon. Sofern man sich technisch zwischen die beiden Kommunikationspartner eingeklinkt hat. Wenn ich mit einem Auto durch einen Tunnel fahre und du von oben draufschaust kannst du mich auch nicht sehen. Das ändert aber nichts an den Eigenschaften meines Fahrzeugs.
 
@DennisMoore: Nein, sie verschlüsseln das Passwort NICHT, bevor sie es über die SSL-Verbindung übertragen - denn genau dafür ist ja die SSL-Verschlüsselung ja da! Deine Unterteilung in "Datenstrom" und "Übertragungsstrom" ist unsinnig, da beides das gleiche ist.
 
@exocortex: Nein, ist es eben nicht. Außerdem rede ich gar nicht von Strömen. Entweder man verschlüsselt die Nutzdaten auf der einen Seite und entschlüsselt sie auf der anderen Seite, oder man verschlüsselt den Kommunikationsweg. Das ist ein Unterschied, und manchmal ein entscheidender wie man an diesem Beispiel sieht. Außerdem findet die Verschlüsselung bei der Transportlayer-Verschlüsselung auf einer ganz anderen Ebene statt, wenn man sich mal das Schichtenmodell ansieht. Auf sämtlichen Ebenen darüber sind die Nutzdaten unverschlüsselt abgreifbar. Und hier nochmal der entscheidende Abschnitt aus "Wikipedia", der das aktuelle Problem ebenfalls beschreibt -> "SSL verschlüsselt nur die Kommunikation zwischen zwei Stationen. Es sind jedoch auch Szenarien (insbesondere in serviceorientierten Architekturen) denkbar, in denen eine Nachricht über mehrere Stationen gesendet wird. Wenn jede dieser Stationen aber nur einen Teil der Nachricht lesen darf, reicht SSL nicht mehr aus, da jede Station alle Daten der Nachricht entschlüsseln kann. Somit entstehen Sicherheitslücken an jeder Station, die nicht für sie bestimmte Daten entschlüsseln kann"
 
@DennisMoore: Ja, das stimmt schon, trifft aber auf das Beispiel hier nicht zu. Es findet eine Kommunikation zwischen einem Client und einem Server statt - im Prinzip so wie bei jeder Website. Und genau für diese Szenarien ist SSL ja gedacht: Um eine sichere Kommunikation zwischen dem Client und dem Server zu ermöglichen. Der Angreifer kann die Daten ja nicht auslesen weil die Kommunikation über SSL unsicher wäre, sondern weil er sich als Empfänger ausgibt. Würde die Verschlüsselung auf einer anderen Ebene stattfinden, z.B. auf Ebene der Anwendung, müsste sich der Angreifer eben als die empfangende Anwendung ausgeben und könnte dann ebenfalls die Passwörter im Klartext lesen. Das ist immer so: Gebe ich mich als rechtmäßiger Empfänger aus und der Sender verschlüsselt die Daten an mich, dann kann ich sie natürlich auch entschlüsseln. Das Problem ist hier nicht dass die Passwörter nicht ordentlich verschlüsselt werden würden, das Problem ist, dass der iPhone-Besitzer sein iPhone so manipuliert, dass es mit einem gefälschten Empfänger kommuniziert.
 
@exocortex: Wären die Daten ordentlich verschlüsselt und nicht "roh" über SSL übertragen worden hättest du keinen Klartext mitlesen können, selbst wenn du dich als Empfänger ausgegeben hättest. Denn du kennst ja nicht automatisch den Schlüssel mit dem die Nutzdaten verschlüsselt wurden. Entschlüsseln wäre daher auch nur durch ausprobieren aller möglichen Schlüssel möglich. Und das kann je nach Verschlüsselung und Schlüssellänge sehr lange dauern.
 
@DennisMoore: Der Hack basiert ja da darauf, dass ich dem Sender einen falschen Empfänger vorgaukele. In diesem Fall wird ein falscher Empfänger für die SSL-Verschlüsselung vorgegaukelt. Wenn der Sender seine Daten noch vor dem Senden extra verschlüsselt, dann muss ich ihm eben für diese Verschlüsselung einen falschen Empfänger vorgaukeln, indem ich ihm einen falschen Schlüssel unterschiebe. Das ändert also an der Problematik nichts.
 
Dass die Kennwörter "völlig unverschlüsselt" übertragen werden klingt aber etwas fehlleitend. Die Kommunikation mit dem App Store-Servern erfolgt nämlich komplett verschlüsselt per TLS. Die Kennwörter werden also sehr wohl verschlüsselt. Nur wenn es natürlich jemand schafft eine CA und ein Zertifikat zu fälschen und somit selbst eine derartig verschlüsselte Kommunikation abzufangen, dann kann er die innerhalb der verschlüsselten Verbindung gesendeten Kennwörter natürlich sehen. Trotzdem wäre es natürlich besser z.B. Kennworthashes zu übertragen, nicht die Kennwörter selber.
 
@exocortex: die unverschlüselte Übertragung gilt nicht für Passworte (bitte auch richtig lesen)
 
@222222: Dein Satz ergibt so keinen Sinn. Meintest du "Die verschlüsselte Übertragung gilt nicht für Passworte"?
 
Uhhh Ermittlungen! Geben sich dann mal wieder Apple Mitarbeiter als Polizisten aus?
 
@esbinich: Dürfen die jetzt nicht mal ein Problem analysieren und eine Lösung dafür finden ?! Soweit ich weiß nennt man das ermitteln ;)
 
@algo: Dann weißt du nicht auf was esbinich hinaus wollte ;-) allerdings suche ich jetzt nicht die News dazu, ich glaub die gab es nämlich auch auf winfuture.
 
"Apple nimmt Ermittlungen auf"

Wow, sind sie jetzt selbsternannte Polizisten?

Sollten sie nicht einmal in ihren asiatischen Fabriken und bei unserer schamlos abgezockten Jugend ermitteln?
 
@Harmoni: Schon lustig wie sich Leute an einem Unternehmen aufhängen alleine wegen einer Überschrift auf einer Homepage. Dir ist schon klar dass "Apple nimmt Ermittlungen auf" einfach nur eine Formulierung von Winfuture ist?
 
@exocortex: Mache Leute haben halt einen groben Dachschaden
 
Damit ich das richtig verstehe....man installiere sich 2 gefälschte Zertifikate und ändere einen dns Eintrag und jammert hinterher rum, dass die ansonsten mit dem Apple Server verschlüsselte Kommunikation nicht mehr stattfindet und dabei logindaten unverschlüsselt woanders hingehen ? Klingt für mich eigentlich eher danach, als wenn das Sicherheitsproblem vor dem idevice sitzt. Wenn ich irre, bitte berichtigen .
 
In-App-Käufe sind abzocke. Apple hat fesrgelegt was Apps im AppStore kosten sollen und einige Schlaumeier bauen noch ein extra bezahl model in die App ein so das ohne ein In-App-Käufe man mit der App nix machen kann, ist leider nicht wie bei Free to Play
 
@Helldown:
Wo legt denn Apple Preise fest? Was die Hersteller machen ist ihr Ding. Es gibt auch gute free-to-play Modelle und in App Käufe.
 
@GlennTemp: "Was die Hersteller machen ist ihr Ding" darum gibs aucg VLC oder Groovshark nur noch in Cydia, kannst alles bei wiki lesen.
 
@Helldown: VLC gibt es nicht im App Store weil sich die Entwickler von VLC selbst bei dem Entwickler der VLC-App beschwert haben, was kann da Apple dafür?
 
@Helldown: Apple legt die Preise der Apps fest? Seit wann das?
 
haha bei apple dreht sich alles nur anwälte und um kohle armes america ohhhhhhh :))
 
Ich erinnere mich, dass es schon seit einiger Zeit Videos auf YouTube gibt, die "gratis" In-App Käufe (ohne Download-Content) mit einem Jailbreak Tweak ermöglichen... Was ist damit?
 
@Timecop069: Was soll damit sein?
 
den "iAp Cracker" gibt es doch seit langem... was an DIESEM Hack anders sein soll, sei mal in den Raum gestellt...
 
@JoleTG: Beide funktionieren technisch völlig anders und das wichtigste: Dieser hier erfordert keinen Jailbreak, der iAp Cracker schon.
 
@exocortex: Da stimme ich dir evtl. zu, worauf ich hinaus wollte ist das Prinzip, dass man sich über beide Wege - illegal (je nach Betrachtungswinkel :)) - an kostenpflichtige Inhalte Zugriff verschafft.
 
@JoleTG: Wieso stimmst du mir nur "eventuell" zu? Dass beide Hacks technisch völlig anders arbeiten und dieser hier keinen Jailbreak erfordert ist eine Tatsache, da gibt es nichts zu überlegen. Wenn es dir nur ims Prinzip geht - frei In-App-Käufe - und du schon weißt, dass beide ja im Prinzip das gleiche machen, warum fragst du dann, was an diesem Hack nun anders sein soll?
 
Als erste Sofortmaßnahme in der Analyse des Problems hat Apple direkt das Demo-Video auf Youtube gesperrt ^^
Kommentar abgeben Netiquette beachten!

iPhone 5 im Preisvergleich

WinFuture Mobil

WinFuture.mbo QR-Code Auch Unterwegs bestens informiert!
Nachrichten und Kommentare auf
dem Smartphone lesen.

Folgt uns auf Twitter

WinFuture bei Twitter

Interessante Artikel & Testberichte

WinFuture wird gehostet von Artfiles