Apple hat bestätigt, dass es Hackern gelungen ist, mithilfe einer modifizierten Version seiner Entwicklungsumgebung Xcode iOS-Apps mit der Malware XcodeGhost zu infizieren und in den App Store einzuschleusen. Wie Reuters berichtet, hat das Unternehmen bereits damit begonnen, betroffene Apps aus dem Online-Marktplatz zu entfernen. Zur Anzahl der verseuchten Apps machte der iPhone-Hersteller jedoch keine Angaben.
„Wir haben die Apps aus dem App Store entfernt, von denen wir wissen, dass sie mit dieser gefälschten Software erstellt wurden“, zitiert Reuters die Apple-Sprecherin Christine Monaghan. „Wir arbeiten mit den Entwicklern zusammen, um sicherzustellen, dass sie eine korrekte Version von Xcode verwenden, um ihre Apps neu aufzubauen.“
Zuvor hatten mehrere Sicherheitsanbieter, darunter Palo Alto Networks, von der Schadsoftware berichtet. Auf den ersten Blick erschien sie relativ harmlos und schien lediglich Informationen über Geräte zu sammeln und sie zu Kommando- und Kontrollservern hochzuladen. Wie Sicherheitsforscher Claud Xiao gegenüber Forbes sagte, kann die Malware jedoch „vom Angreifer aus der Ferne kontrolliert werden, um sie für Phishing-Angriffe zu nutzen oder lokale Schwachstellen in Betriebssystem oder Apps zu nutzen“. XcodeGhost könne so als Einstiegspunkt für weitere Ausnutzung dienen, was es potenziell gefährlicher mache.
Ryan Olson, Director of Threat Intelligence bei Palo Alto Networks, sagte der Agentur Reuters wiederum, sein Unternehmen habe bisher keine Hinweise auf einen Datendiebstahl oder andere negative Folgen des Angriffs entdeckt. Es sei aber trotzdem eine „große Sache“. Die Angreifer hätten gezeigt, dass es möglich sei, den App Store zu kompromittieren, wenn man zuvor die Rechner von Entwicklern legitimer Software infiziere. Andere Angreifer könnten nun diesem Beispiel folgen. „Entwickler sind ab sofort ein großes Ziel“, ergänzte Olson.
Palo Alto Networks hat nach eigenen Angaben 39 verseuchte iOS-Apps entdeckt. Es räumte allerdings es, die Zahl könne deutlich höher sein. Der chinesische Sicherheitsanbieter Qihoo360 Technology will indes sogar 344 Apps gefunden haben, die XcodeGhost enthielten.
Von der Malware betroffen waren auch namhafte Apps wie der von Tencent entwickelte Messenger WeChat, der in vielen Ländern beliebte Visitenkarten-Scanner CamCard und die App des chinesischen Uber-Rivalen Didi Kuadi. Zumindest diese Anbieter haben laut Reuters inzwischen ihre Apps bereinigt und aktualisiert.
Tipp: Wie gut kennen Sie Apple? Überprüfen Sie Ihr Wissen – mit 15 Fragen auf silicon.de.
Neueste Kommentare
28 Kommentare zu XcodeGhost: Apple bestätigt Angriff auf App Store
Kommentar hinzufügenVielen Dank für Ihren Kommentar.
Ihr Kommentar wurde gespeichert und wartet auf Moderation.
Hat nicht lang gedauert – und offensichtlich nicht das erste Mal:
http://m.heise.de/newsticker/meldung/Google-Play-Malware-rootet-Android-Geraete-2823455.html
„Eine Malware schmuggelte sich zum wiederholten Male in Google Play. Auf Android-Geräten lädt sie beliebigen Schadcode nach und soll sich nicht de-installieren lassen.“
Auch das Update beachten – es wird eine unter v4.4 geschlossene Lücke ausgenutzt. Nur, dass sie bei sehr vielen Androiden noch offen sein dürfte – mindestens auf allen Geräten <4.4, offensichtlich bei vielen 4.4 und auch 5er Androiden.
Undwie gesagt: passieren kann so etwas immer – wichtig ist, wie damit umgegangen wird: und das scheint mir eine angemessene Reaktion zu sein.
http://www.mactechnews.de/news/article/XcodeGhost-Apple-wird-betroffene-Nutzer-kontaktieren-162390.html
@PeerH,
da hast Du etwas zu lesen, was nicht von Apple oder Heise stammt. ;)
Wenn die Prüfungen bei Apple immer noch so
stattfinden, dann ist es kein Wunder, dass solche Apps es in den Apple Store schaffen.
Außerdem sollte man nicht so großkotzig damit werben, dass bei Apple so sagenhaft gut kontrolliert wird, was schon auf Grund der Anzahl von Apps gar nicht möglich ist!
Da reichen dann auch keine 7-10 Tage. ;)
Aber wie gewohnt, Du redest auch das wieder schön und versuchst mal wieder die Anderen mit in’s Spiel zu bringen.
Dass sich solche Schläfer in JEDEM System platzieren können, steht ja wohl außer Frage.
http://www.areamobile.de/news/25025-jekyll-trojaner-trickst-apples-sicherheitspruefung-fuer-ios-apps-aus
In jedem System, richtig, UND aus o.g. Gründen dürfte es unter Win Phone am einfachsten, und unter Android ebenfalls leichter möglich sein – weil das Betriebssystem keine effektive und für den Anwender leicht nutzbare und verständliche Rechtevergabe enthält.
Dir geht es aber, wie immer, nur um Apple – obwohl Du, oh, KEIN Apple System nutzt. Also: fast meine gesamte IT ist von Apple. Daher ist es zumindest verständlich, warum ich hier kommentiere.
Was war doch gleich Deine Motivation? ;-)
@PeerH,
in dem Wahn, dass hier so viele was gegen Apple haben, ist Dir wohl ganz entfallen, dass Du doch z.B. auch kein Samsung oder sonst einen Androiden besitzt. ;)
Trotzdem gibst Du doch bei fast allen Artikeln Deine Kommentare ab, um dann auf den „Schrott“ hinzuweisen!
Was ist denn Deine Motivation?
Zumal ich noch nie eines der Produkte von Apple als Schrott bezeichnet habe, Du aber dieses Wort sehr häufig benutzt!
Und ich finde es schon sehr merkwürdig, dass Apple immer wieder betont wie sorgfältig dort kontrolliert wird, es aber trotzdem solch gefährlichen Produkte in den Store schaffen.
Nö, Android kenne ich nicht als ‚Besitzer‘ – nichts, was ich kaufen würde. Ich kenne es aber sehr gut aus der Familie, und da sehe ich sehr genau was da alles los war. Teils vernünftige Geräte, die mangels Support eben nicht lange Freude bereiteten. Bis auf ein Moto G ist das aber bald überstanden, denn mittlerweile wurden die Vorzüge des iOS/Apple Systems von allen erkannt.
Wahrscheinlich weiß ich mehr über Android, als Du, der Du das System seit Jahren nutzt. Du weißt eben nicht, was noch so alles geht, weil Du Dich an Deinem alten Gerät festhälst, und dessen Probleme seit Jahren ignorierst. Was Deine Entscheidung ist, aber dadurch sind die Probleme dann eben doch real.
Und bevor das kommen sollte: Win Phone Lumia 520 und 535, nur würde ich da eben definitiv nicht meine wichtigen Dinge mit erledigen wollen – erst recht nicht persönliche Daten eingeben. Wie oben beschrieben, bleibt immer eine Restunsicherheit darüber, was die App mit den Daten machen darf und was nicht – man kann die zugewiesenen Rechte der App nicht prüfen. Da ist Android besser.
Aber auch das muss jeder selber wissen. :-)
Na klar weißt Du das, Du hast ja auch schon mehrere Doktorarbeiten geschrieben. ;)
Und mein Wiko Rainbow 4G ist ja schon soooo alt, da weiß ich wirklich nicht, was sonst noch alles geht. ;)
Vielleicht möchte und muss ich das auch nicht.
Und wenn nur noch ein Moto G in der Familie ist, bist Du ja auch nicht mehr auf dem Laufenden. Oder wurden die Androiden erst letzte Woche entsorgt? ;)
Hast Du Belege, dass man NICHT einen „Schläfer“ in die „nachgeladene Funktionsbibliothek“ platzieren kann, der sich erst nach längerer Zeit verbindet und dann richtig bösartig werden kann? Denn sie kann das ja nutzen, was durch bekannte Wege in den Raum kommt.
Oder dass der „Schläfer“ nicht das Rechtesystem aushebelt?
Dann könnte die App doch an an Daten außerhalb des Raumes kommen.
Ich denke da z.B. an die Geschichte mit den Apps, die deaktiviert sind und sich trotzdem immer wieder einschalten und auch in’s Internet gehen, und der Nutzer bekommt überhaupt nichts mit.
Ausdenken kann ich mir natürlich viel – eine ‚Schläfer‘ App, die von sich aus 1 Milliarde Geräte befällt, und dann deren Überweisungen auf mein Konto umlenkt. ;-)
Aber mit der Realität hat das Stand heute nix zu tun. Und auch nicht mit dem im Artikel beschriebenen Problem.
Wenn dem so wäre, solltest Du Dein Wiko besser entsorgen, weil Du dafür nie ein Update kriegen wirst, und bei Android so ein ‚Wunschmechanismus‘ ja ebenfalls möglich ist. ;-)
http://www.heise.de/newsticker/meldung/Google-Play-Malware-rootet-Android-Geraete-2823455.html
Viel Glück! ;-)
Zu der Nachricht: das hab ich oben beschrieben – ob der Code bösartig ist oder nicht – wer soll das entscheiden, wenn nicht der Entwickler?
Wichtig ist doch, dass auf dem Gerät nicht gegen den Willen des Anwenders Daten gestohlen werden, oder dass die App auf dem Gerät mehr machen darf als erkaubt – letzteres nennt man Hack, der oft für Jailbreakes ausgenutzt wird, und für iOS 9 gibt es m.E. zurzeit keinen funktionierenden Hack, oder gibt es ein Jailbreak? Glaube auch China gab es da einen, der bei iOS 9 Beta ging.
Noch mal das Beispiel: wenn eine App Deine Passworte verwalten soll, dann musst Du dem Entwickler vertrauen, dass er diese nicht selber sehen kann, verkauft, selber nutzt, analysiert (wozu auch immer) schludrig verwaltet, seine eingesetzte Software/Systeme sicher sind, das Übertragungsverfahren sicher ist. UND dass er in seiner App nicht versucht mehr Daten zu ziehen, als Du ihm zu geben bereit bist – durch z.B. durch ‚Schadcode‘ – auch z.B. eine Drittanbieter Webseite kann fatalsein, wäre aber kein ‚Schadcode‘ … wenn der Entwickler neue Systeme/Domänen in Betrieb nimmt, wird das wahrscheinlich niemand beanstanden.
Apple (Google, Microsoft) müssen ihrerseits das Betriebssystem so bauen, dass eine App nur das darf, was man ihr erlaubt.
Und im Vergleich zwischen iOS und Android / Win Phone haben die Anwender bei Apple die beste Übersicht.
Google versucht gerade das Apple Zugriffssystem in Android zu etablieren, aber durch die Defragmentierung haben noch nicht viele Anwender etwas davon.
(PS: was denn nun – ist es gut (Prüfung einige Sekunden) oder schlecht (Prüfung sieben Tage) wie Apple prüft? Das wird von diversen Parametern abhängen – was tut die App, welche Daten verlangt sie, wie komplex ist sie … wenn die eingereichte App ‚einfach‘ war, können sieben Sekunden sein, andere brauchen sieben Tage. Dass auch Ungewünschtes durchrutscht, siehe oben, wird nie komplett zu verhindern sein.
Da ist es dann wichtig, wie sicher das Betriebssystem ist, und wie Apple damit umgeht, sobald die App als bösartig erkannt wurde.
Und im vorliegenden Fall wurden die Apps gesperrt, und man arbeitet mit den Entwicklern an der Beseitigung des Problems.
Wie gesagt: ärgerlich, aber kein Drama.)
Nur komisch, dass die 7-10 Tage auch nix genügt haben, um das Zeug zu entdecken. ;)
Und genau das finde ich so bedenklich, wenn es solch ein Zeug, trotz der angeblich hervorragenden Kontrollen, in den Apple Store schafft, auch noch in dieser hohen Anzahl, was ist denn dann erst bei den Systemen wo die Kontrollen nicht so streng sein sollen?
Mir sagt das nur, dass Du nicht verstanden hast, was ich geschrieben habe. Vielleicht versuchst Du es noch mal in den nächsten 7-10 Tagen, vielleicht wird Dir das dann klarer. ;-)
„… und für iOS 9 gibt es m.E. zurzeit keinen funktionierenden Hack, oder gibt es ein Jailbreak? Glaube auch China gab es da einen, der bei iOS 9 Beta ging.“
Stand sogar hier bei zdnet. ;)
http://www.zdnet.de/88246341/erster-untethered-jailbreak-von-ios-9-gelungen
Ja, war die Beta, aber nachdem es 2 Tage vor Release war und er die Methode nicht veröffentlicht hat, wird es kaum gefixt worden sein.
Tja, da scheint sich aber eine ganz schöne Lawine in Gang gesetzt zu haben.
Bin mal gespannt wann es bei Google oder Microsoft die ersten verseuchten Apps gibt?
Oder sollten die „faulen“ Entwickler tatsächlich alle nur für Apple arbeiten?
Bin nicht sicher, was Android betrifft, aber bei Windows gibt es beim Rechtesystem nur Vollzugriff (= kann installiert werden) oder kein Zugriff (= man akzeptiert die Freigaben nicht) und die App lässt sich nicht installieren.
Wenn eine App installiert ist, hat man keine Ahnung was sie darf – und merkt auch nicht, wenn sie plötzlich unerwartete Rechte verlangt. Sie hat sie einfach.
Dsas entdecken dürfte also für Anwender noch schwerer sein. Will der App Entwickler etwas Böses machen, hat er kaum Hindernisse.
Er entwickelt eine App, die wird geprüft. Eines der späteren Updates hat neue Funktionen, die mehr/andere Rechte nutzen – aber das dürfte kaum zu merken sein – auch Microsoft prüft den Quellcode sehr wahrscheinlich nicht.
Sprich: wenn es bösartige Win Phone Apps geben sollte, dürften diese schwerer zu entdecken sein.
Bei Android kann man sich zumindest spezielle Tools installieren, die den Traffic, Zieladressen etc prüfen – erfahrene Anwender hätten gute Chancen misstrauisch zu werden. Inwieweit das Rechtesystem kein Friss oder Stirb ist, oder wie bei Apple sehr speziell je Funktion freigeschaltet werden kann, weiß ich so pauschal nicht. Das hängt von der Android Version ab – und die sind wenig konsistent.
Lieber PerH. Wie schreibst du immer so treffen ( Natürlich nur in einer anderen Variante). In diesem Artikel geht es eindeutig um Apple und nicht um Windows oder Android.. Nicht gleich wieder den Ablenkspezialisten spielen.
Ich hab doch weiter oben genau beschrieben, was ich meine? Und in meinem Kommentar ging ich explizit auf die Frage von JI ein, wann wohl die erste ‚verseuchte‘ Google/Microsoft App auftauchen würde.
Mit dem Ergebnis: es kann passieren, aber bei beiden würde man es schwerer merken.
Warum ist das eine Ablenkung? Du tust mir Unrecht.
@Hi, Hi …: auf diese Frage / Aussage bin ich eingegangen:
„Bin mal gespannt wann es bei Google oder Microsoft die ersten verseuchten Apps gibt?“
Bist Du noch immer der Meinung, ich sei ein ‚Ablenkspezialist‘?
…bist Du sicher, dass Du mich meinst?
Oh, nö: ich meinte „So, so…“ – das passiert, wenn sogar ‚Kunstnamen‘ nachempfunden werden. Sorry. :-]
Ich höre immer nur „die nachlässigen Entwickler“ die Xcode von BaiDu & Co. geladen haben seien das Problem.
Entweder hab ich hier einen grundlegenden Denkfehler oder das ist Ablenkung. Die Entwickler die unwissentlich verseuchte Apps eingestellt haben – Gut, die werden ihre Apps aktualisieren… Was aber ist mit denen die das absichtlich machen, was wenn die „bösen“ schon länger den XCode Compiler umdoctern und so Schadsoftware in den regulären Store bringen? Das Problem für, die User, dahinter ist doch wohl, dass sich XCode misbrauchen lässt und dass es den Sicherheitsmechanismen von Apple nicht gelungen ist, die Apps im Vorfeld zu identifizieren. Was immer „bisher“ nur aufgefallen ist, was so eine App macht oder auch nicht, kann doch nur die Spitze des Eisbergs der Möglichkeiten sein? Und wenn das mit XCode funktioniert, geht das auch mit dem WebKit, mit einer Android SDK, mit Microsofts SDK? Was ist da alles denkbar? Schlafender Code? Teile eines extrem bösen Schadprogramm in unterschiedlichen Apps ausliefern? Ich find das richtig richtig heftig.
Dein Denkfehler ist, dass Du davon ausgehst, dass Xcode anders als C++ ist – was nicht stimmt. Man kann eben Apps/Programme entwickeln, und was die tun, entscheidet der Entwickler.
Im vorliegenden Fall haben die Apps ja nicht iOS ‚kompromittiert‘, sondern die Apps konnten exakt das tun, was der App Entwiickler auch nur maximal tun kann.
Wenn die App z.B. nach dem Zugriff auf das Adressbuch fragt, kann man das gewähren oder auch nicht. Was der App Entwickler damit tut, das prüft Apple natürlich nicht – auch Google/Microsoft tun das nicht.
Auch eine mit dem kompromittierten Xcode entwickelte ‚bösartige‘ App kann aber nicht die normalen Regeln umgehen und ohne Erlaubnis des Anwenders – um mal beim Beispiel zu bleiben – auf das Adressbuch zugreifen. Aus Sicht von Apple verhält sich die App aber ’normal‘, solange sie nur die normalen Rechte und Genehmigungsprozesse nutzt.
Wie gesagt: das Schlimmste, das m.E. passieren kann, ist das Ausschnüffeln des Zwischenspeichers bei Copy&Paste – wenn man dadurch Passworte überträgt.
Der Punkt ist, dass eben den App Entwicklern (!) in ihre (!) App eine Funktion untergeschoben wurde, die von ihnen nicht (!) gewollt war.
Und das ist der Punkt, wo man eben Apple nicht vorwerfen kann, dass sie die Apps für die Entwickler prüfen/debuggen/anpassen, das müssen die schon selber tun. Apple prüft nicht den Programmcode, sondern ob sich die Apps regelkonform verhalten – und das haben sie formell. Dass man nicht den Quellcode von >1 Mio Apps prüfen kann, sollte jedem klar sein.
Die Apps wohl dürfen nix, was ’normale‘ Apps nicht auch dürfen. Nur, dass die Daten eben nicht zum App Entwickler gehen, und seine App missbraucht wird.
iOS wurde eben nicht komprimittiert, alles ‚böse‘ spielte sich direkt und nur auf Seiten der Entwickler ab: Download aus unbekannter Quelle, Checksumme nicht geprüft, Signatur Warnungen ignoriert, Konsistenz der App nicht geprüft.
Letztendlich sind die Entwickler auch die Hauptleidtragenden – ihr Ruf hat Kratzer bekommen.
(M.E. wäre so etwas auch bei Google/Microsoft möglich, und bei letzterem gibt es keine detaillierte Zugriffsrechte Steuerung: die App verlangt Zugriff – ohne dass man weiß worauf – und wenn man den gewährt, hat sie kompletten Zugriff auf alles, was sie haben will. Will man keinen Zugriff gewähren, geht keine Installation. Also Friss oder Stirb. In so einem Fall wäre das Fatal, weil eine komprimittierte App ohne Rückfrage alle Rechte hätte – keine Rückfrage beim Zugriff auf Adressbuch/Fotos/Notizen etc.)
Sorry, aber das ist alles überhaupt nicht der Punkt um den es mir geht. Apps – die mit einer veränderten Version von Xcode compiliert wurden, können Bibliotheken nachladen die nicht im Funktionsumfang angegeben sind. Genau hier versagt der Schutzmechanismus von Apple. Die Frage ob das zu lasten von Apple geht stellt sich mir doch gar nicht. Im Gegenteil, würde ich Deiner Ausführung folgen, wäre es ja noch schlimmer… dann hätten alle Bösen ein Einfallstor, welchem Apple völlig machtlos gegenüber stünde. Löse Dich einfach mal vom Gedanken des braven, ehrlichen Entwicklers. Mich interessieren die, die arges im Sinn haben und die freuen sich doch wie bolle, wenn sie über Warnungn, Checksummen etc. einfach hinwegsehen können und die App trotzdem in den Store gelangt. Die Sache ist nämlich die, zumindest soweit es aus den Sicherheitskreisen nachzuverfolgen ist, dass damit eine „Remote“ Funktion ausführbar ist. Es ist auch völlig egal was die betroffenen Apps bisher „nur“ gemacht haben, die Frage ist was sie tun könnten! Die Rechteverwaltung bei iOS spielt dabei doch gar keine Rolle mehr. Ein Schieber auf dem Display – nutzlos bei veränderten Libs. Denn Apple kann eben nicht auf den Quellcode zugreifen, da sie den überhaupt nicht haben, sondern nur compilierten Code. Es ist denkbar (und nicht auf mich losgehen, kommt nicht von mir sondern eben von den Sicherheitsfirmen), dass bspw. mehrer Apps „zusammmenarbeiten“ 3 unterschiedliche Apps laden einen völlig unauffälligen Teil nach, zusammen haben sie aber die Möglichkeit echt übles anzustellen. Oder eine entsprechende Funktion wird erst Wochen oder Monate später aktiviert. Was wenn ich damit Bezahlvorgänge auslösen kann?
Nichts mit unbekannter Quelle – Absicht. Das ist doch das Szenario um das man sich einen Kopf machen sollte.
@Chris v.D.
Na endlich mal Einer, dem genau dieselben Gedanken durch den Kopf gehen wie mir… ;) Apple’s Problem ist, dass Apps durchgewunken wurden, die mit einem modifizierten Xcode kompiliert wurden – ohne dass das offensichtlich bemerkt wurde. Sowas darf einfach nicht passieren.
…man fragt sich ganz unwillkürlich, was machen die Prüfer bei Apple in den 7 bis 10 Tagen Prüfungszeit, die (zumindest im deutschen Store) vom Einreichen bis zur Freigabe der Apps verstreichen?!
Du hast meine Kernaussage ignoriert: egal was die App macht, oder wie sie erstellt wurde – sie kann nur das tun, was die iOS Rechteverwaltung ihr erlaubt:
Beispiel: Wenn ich der App den Zugriff auf die Kamera verweigere, dann ist es egal, was in Xcode manipuliert wurde – die App kann nicht auf die Kamera zugreifen.
Nicht iOS sondern die App wurde verbogen – weil der Entwicklergeschludert hat.
Was Du ansprichst, ist ein generelles Problem, die grundsätzliche Glaubwürdigkeit von App Entwicklern – aber das ist eben ein Problem, an dem Apple wenig ändern kann. Auch bei Android oder Windows/Win Phone ‚Tools‘ verlässt man sich darauf, dass die App das tut was sie soll.
Extrembeispiel: Wenn ich eine App kaufe, die Passworte verwaltet, dann vertraue ich dem App Hersteller, dass seine App sicher ist und wenner sie in einer Datenbank verwaltet, dass diese sicher ist etc.
Apple liefert nur die Entwicklungsumgebung, den App Store als Marktplatz, und prüft, ob die Sicherheitsregelnneingehalten wurden, damit iOS/die Geräte/Zugriffsrechte eingehalten werden – sie können nicht den Quellcode prüfen, ob der Programmierer sauber arbeitet.
Wenn die App per se die Passworte auf eine unsichere Webseite/in eine unsichere Datenbank schickt, ist der Entwickler leichtsinnig – und man hat die falsche App gewählt.
Exakt deswegen bin ich eben skeptisch, dass bei Android aus unsicheren Quellen ‚Tools‘ installiert werden UND diese dann im System weitreichende Adminrechte kriegen können – man kennt den Entwickler nicht und was die App noch so macht. Oder wenn unter Win Phone ‚Friss oder Stirb‘ alle Rechte eingefordert werden – und man nicht weiß, ob die Kanera nun genutzt werden kann oder nicht.
Man bietet dem App Entwickler einen großen Vertrauensvorschuss.
Unter iOS gibt (!) es ein fein abgestimmtes Rechte System, und – ich wiederhole mich – die in diesem Fall komprimittierten Apps konnten nur das tun, was ihnen erlaubt war – und eben auf die Zwischenablage zugreifen.
Egal, was der Hacker in die App eingeschleust hätte – sie hätte immer erst fragen müssen, ob die App auf die Kamera, Adressen, Fotos etc. zugreifen darf – und spätestens dann hat der Anwender die Möglichkeit misstrauisch zu werden.
(Anm.: Bei Win Phone hat er diese Chance eher nicht, weil er nicht weiß welche Rechte die App zu Beginn erhalten hat. Und bei Android ist man tendenziell eh überfordert, weil die Apps einmalig im Paket etliche Rechte abfragen – also auch schwer zu überprüfen.)
Anders gesagt: wenn ich im App Store eine App kaufe, die meine Passworte verwaltet, dann vertraue ich damit dem App Entwickler – und nicht Apple.
Wenn er im Update eine neue Routine einbaut, die unbemerkt Fotos sammelt, dann wird unter …
… iOS der Anwender gefragt (darf XYZ Zugriff auf Fotos erhalten?),
… unter Windows der Anwender nichts davon merken
… unter Android der Nutzer gefragt, ob die App das darf, und das und das und das – und auf die Fotos zugreifen, und das und das – und möglicherweise genehmigt man das, weil man überfordert ist.
Sofern die App sonst nicht auffällig ist, ist das immer möglich. Deswegen ist ein dediziertes Rechtesystem für den Zugriff auch so wichtig. Und deswegen haben Anwender von Win Phone und Android es schwerer den Überblick zu haben oder zu behalten.
Das Thema Vertrauen in Apps ist völlig unabhängig von iOS/Apple, weil dieses Vertrauensverhältnis immer zwischen Software Anbieter und Kunde besteht.
„Du hast meine Kernaussage ignoriert: egal was die App macht, oder wie sie erstellt wurde – sie kann nur das tun, was die iOS Rechteverwaltung ihr erlaubt:“
–
Ich fürchte eher, Du verstehst nicht worum es mir geht. Die Rechteverwaltung in iOS richtet sich nach einem vorgegebenen Funktionsumfang der App, der beim compilieren angegeben werden muss. Was aber durch das kompromittieren von Xcode möglich sein soll ist, dass eine Funktionsbibliothek „unentdeckt“ nachgeladen werden kann. Ergo gibt es auch keine Abfrage der Rechteverwaltung nach dieser Funktion. Sie ist damit faktisch nutzlos. (Nochmal nich hauen wenn ich das nicht zu 100% richtig wiedergebe was die Sicherheitsfirmen beschreiben, das Prinzip sollte aber klar sein)
Alles was Du beschreibst, ist das was man bei dem Stück Code gefunden hat, der da veröffentlicht wurde. Das Szenario ist aber dem geschuldet was damit möglich sein soll, nicht was bisher damit gemacht wurde. Natürlich ist man „selbst Schuld“ wenn man einer Taschenlampenapp die Rechte zum telefonieren einräumt. Aber genau das soll ja eben nicht nötig sein, wenn man entsprechende Funktionen unbemerkt nachladen kann, oder eben Zugriff auf eine App erhält die die gewünschte Funktion darf. Nachgewiesen ist doch bereits, das nicht nur Daten an den Hackerserver gesendet wurden, sondern dieser Server auch Befehle zurücksenden konnte. Dieser Umstand macht mir die Sorgen.
@So, so… diesmal kann man PeerH keinen Vorwurf machen, ich habe die Frage aufgeworfen ob das auch beim Android SDK, und Windows SDK möglich ist.
Ich haue nicht, wir diskutieren. :-)
Eben das geht nicht, und das versuchte ich zu beschreiben: egal, was für eine Funktionsbibliothek nachgeladen wird – sie würde ‚innerhalb‘ des von iOS vorgegebenen Rechtesystems ablaufen.
Bsp.: Wenn die Funktionsbibliothek das Apple Store Password abzufragen versuchen würde, geht das nicht, weil das die ’normale‘ App nicht darf. Auch nicht ein anderes Password einer anderen App. Sie kann nur Funktionen durchführen, die der App insgesamt nereits erlaubt sind.
Um beim Bild mit dem Raum zu bleiben: die Funktionsbibliothek kriegt keinen Zugriff auf den Nachbarraum. Sie kann nur das nutzen, was durch bekannte Wege in den Raum hinein kommt. Und das regelt iOS im Allgemeinen, und das Rechtesystem im Speziellen:
Zugriff auf Fotos, auf andere Daten, auf Kamera/Mikrofon/Kennworte, etc..
Deswegen betone ich ja das Rechtesystem: das definiert nicht nur, was die ’normale‘ App darf, sondern insgesamt was eine App je können darf. Und eine ‚Funktionsbibliothek‘ kann nicht mehr machen als die ursprüngliche App machen darf.
Nicht ohne Interaktion mit dem User –> „Zugriff auf Fotos erlauben?“ Ja/Nein.
Das zu umgehen geht nur über einen ‚Hack‘ von iOS, in dem man das Rechtesystem ‚hackt‘ – durch Bugs oder durch irgendwelche Fehler, die z.B. von Jailbreakern ausgenutzt werden.
Solange die ’nachgeladene Funktionsbibliothek‘ nicht das Rechtesystem aushebelt, spielt es aus iOS Sicht keine Rolle, was nachgeladen wird, weil das ’nur‘ die Daten betrifft, auf die die App (der Entwickler) eh Zugriff hat – und das ist ja gewollt, weil sonst hätte man beim Entwickler nicht die App gekauft, und sie installiert.
Andernfalls wäre es ein ‚Hack‘, und dann würde zweifellos Apple in der Pflicht stehen, um das zu fixen.
„Die Rechteverwaltung in iOS richtet sich nach einem vorgegebenen Funktionsumfang der App, der beim compilieren angegeben werden muss. Was aber durch das kompromittieren von Xcode möglich sein soll ist, dass eine Funktionsbibliothek „unentdeckt“ nachgeladen werden kann. Ergo gibt es auch keine Abfrage der Rechteverwaltung nach dieser Funktion. Sie ist damit faktisch nutzlos.“
Ich beantworte Deine Frage noch mal in Kurzform: der Entwickler kann x verseuchte Libraries austauschen – seine App wird deswegen nie mehr dürfen, als das iOS Rechtesystem ihr erlaubt.
All diese betroffenen Apps haben keinen Zugriff auf nicht durch irgendeine ‚Hintertür‘ erlaubte Ressourcen erhalten – iOS wurde dadurch nicht komprimittiert.
Selbst wenn die Lib versuchen würde auf ‚Apple Pay‘ zuzugreifen – es ginge WEGEN des Rechtesystems nicht.
Und das habe ich versucht zu erklären – auch die komprimittierte die App läuft in einem abgeschlossenen Raum. Sie kann, wie es passiert ist, die in die App eingegebenen Daten woanders hinschicken, aber sie kann von sich aus nicht an Daten außerhalb des Raumes kommen. Der Nutzer wird immer gefragt.
Typischer Fall: die Taschenlampen App, die den Zugriff auf Fotos haben möchte.
Unter iOS: User wird gefragt
Unter Win Phone: wenn sie bei der Installation / beim Update die Rechte hat, greift sie darauf zu
Unter Android: wenn sie nach x Rechten fragt, kann sie einem das vielleicht unterjubeln
Wenn die App aber geschrieben ist, um z.B. Daten in die Drop Box hochzuladen, dann prüft Apple wahrscheinlich nicht, was Dropbox mit den Daten macht (sichere DB, unsichere DB, Verschlüsselte Übertragung, Passwort sicher oder nicht, oder (!) beim Update neue Serverfarm in Kasachstan.
Das muss der Dropbox Entwickler selber machen, und das verantwortet er dem Anwender/Kunden gegenüber.
Hoffe, ich hab das nun verständlich erklären können.