Betrug während des App Reviews: Apple führt angeblich erneute Begutachtung kurz nach Freischaltung durch

Seit Start des iOS-App-Stores werden Apps, bevor diese im Store angeboten werden dürfen, von Apple begutachtet. Apple prüft, ob die App sich an die vorgegebenen Richtlinien hält – falls nicht, wird die App nicht im App Store zugelassen und kann nicht auf Geräten von Endbenutzern installiert werden. In den vergangenen Jahren haben diverse Entwickler aber trotzdem Apps in den Store gebracht, welche offensichtlich gegen die Begutachtungsleitlinien verstoßen.


Änderungen durch Kommando eines Steuerservers
Die Masche ist eigentlich trivial, aber trotzdem schwer von Apple aufzuspüren: Ein Entwickler reicht eine harmlos aussehende App bei Apple ein. Apple begutachtet die App und findet keine Auffälligkeiten bei der Überprüfung. Kurz nachdem die App im Store erschienen ist, ändert der Entwickler die Einstellungen auf einem Steuerserver und die App zeigt urplötzlich andere Inhalte oder Funktionen an, welche während dem App Review gar nicht sichtbar waren.

Nur manche Richtlinien können umgangen werden
Mit diesem Verfahren können aber nicht alle Begutachtungsleitlinien umgangen werden. Beispielsweise ist die Nutzung von privaten Programmierschnittstellen weiterhin nur sehr schwer möglich, da Apple zuvor automatisch die Binärdatei untersucht – in den meisten Fällen würde die Nutzung auffallen. Die Einblendung anstößiger Inhalte ist mit diesem Verfahren aber recht einfach möglich.

Apple reagiert
Einem Reddit-Nutzer nach hat Apple genau für diese Fälle nun aber einen zusätzlichen Schritt bei der Begutachtung von Apps eingeführt: 48 bis 72 Stunden nach Freigabe untersucht der App-Reviewer die App noch einmal, ob sich das Verhalten oder die Funktionalität geändert hat. Auf diese Art und Weise bekommt der Reviewer die App so zu Gesicht, wie auch Kunden das Programm sehen werden.

Natürlich ist dieses Verfahren auch nicht wasserdicht: Aktuell führt Apple den App-Review aus dem Apple-Klasse-A-Netzwerk, beginnend mit der IP-Nummer 17.*, durch – so kann ein Steuerserver recht einfach erkennen, ob es sich um einen erneuten Review handelt.

Kommentare

My2Cent08.07.19 09:44
Wenn ich eine App einstellen wollte, die gegen die Bestimmungen von Apple verstößt, dann würde ich mit denn Senden der erforderlichen Steuerbefehle sowieso ein paar Wochen warten, so dass die im Artikel genannten „48 bis 72 Stunden“ ins leere laufen.

Frei nach dem Motto:
„Den Gegner erst mal in Sicherheit wiegen“.
+1
Wiesi
Wiesi08.07.19 10:53
Ich möchte eigentlich keine Apps installieren, deren Funktion von einem "Steuerserver" abhängt. Kann mir jemand sagen, wann und warum ein solcher Server nötig ist, und warum Apple nicht warnt, daß diese App mit einem solchen Server telefoniert.
Everything should be as simple as possible, but not simpler
+1
Fabianexe
Fabianexe08.07.19 11:13
Wiesi
Ich möchte eigentlich keine Apps installieren, deren Funktion von einem "Steuerserver" abhängt. Kann mir jemand sagen, wann und warum ein solcher Server nötig ist, und warum Apple nicht warnt, daß diese App mit einem solchen Server telefoniert.

Eigentlich telefoniert jede App die mehr als feste Information Bietet mit einen Server.

Nehmen wir die MTN App. Wenn die heute anfangen Pornos statt Apple Nachrichten auf ihren Server zu packen bekommst du halt diese obwohl Apple das blöd findet.

Also wenn gehen nur Apps die feste Daten haben. Also alles was auch ohne Internet geht. Wobei es davon glaube ich wenige gibt. Sei es um die Möglichkeit zu geben Sachen nach zu laden oder Werbung ein zu blenden.
Ich glaube ich habe keine App die ohne so eine Warnung auskommen würde.

Wobei mich jetzt grade auch der usecase interessieren würde wo man ein Smartphone hat ohne irgend so ein Programm was Internet hat.(ja ist meine bubble das ich es mir nicht selbst vorstellen kann)
+3
Mendel Kucharzeck
Mendel Kucharzeck08.07.19 11:50
Fabianexe
z.B. unser Programm MobileFamilyTree. Natürlich geht Internet-Recherche nicht, aber das Programm funktioniert auch Offline mit manueller Dateneingabe.
+1
MikeMuc08.07.19 11:53
Fabianexe
Als erstes fällt mir die berühmte Einkaufsliste ein. Wer da keine nen Sync auf mehrere Geräte will braucht, dem recht was Sie attisches. Ebenso Notizen die ja eigentlich nix anderes sind. Oder die Kameraapp. Ich glaub be, da gibt es s noch ne ganze Menge mehr...
Aber viele Apps sind eben auch nur eine Art Interface fürs Internet. Und die müssen eben alle fleißig „telefonieren“ um zu funktionieren:-)
-1
Wiesi
Wiesi08.07.19 12:12
Fabianexe
Vielen Dank für die Antwort. Wenn ich Dich richtig verstehe, dann werden in den Nutz-Datenstrom spezielle Daten für die Umsteuerung der Funktion eingestreut. (Eine Form von Steganographie.) Dafür ist natürlich kein "Steuerserver" nötig. Dies Wort hat mich verwirrt. Der Groschen ist jetzt unten.

Steganographie ist in der Tat schwer nachweisbar. Dafür wurde sie ja erfunden.

Es ist wie beim Dieselbetrug: Auf dem Prüfstand ist alles in Ordnung; später auf der Straße wird betrogen.
Everything should be as simple as possible, but not simpler
+1
Raziel108.07.19 13:28
Wiesi
Fabianexe
Vielen Dank für die Antwort. Wenn ich Dich richtig verstehe, dann werden in den Nutz-Datenstrom spezielle Daten für die Umsteuerung der Funktion eingestreut. (Eine Form von Steganographie.) Dafür ist natürlich kein "Steuerserver" nötig. Dies Wort hat mich verwirrt. Der Groschen ist jetzt unten.

Steganographie ist in der Tat schwer nachweisbar. Dafür wurde sie ja erfunden.

Es ist wie beim Dieselbetrug: Auf dem Prüfstand ist alles in Ordnung; später auf der Straße wird betrogen.


So "kompliziert" muss es nichtmal sein. Ich kann in meine App ja reinprogrammieren was ich will, da brauch ich nichts komplex zu verschleiern. Ich könnte zb nach nem Tag ne Url abfragen die Code nachlädt. Oder einfach nur nen Timer einbauen der nach ner Woche nen Flag setzt und von dem Zeitpunkt an liefert die App Inhalte von ner ganz anderen Quelle. Und so weiter. Also ich denke da muss man nicht extra versuchen das zu verstecken. Solange es nicht direkt offensichtlich ist wird es wohl nur schwer beim Test bemerkt und kommt in den Store.

Viele Apps sind ja nichtmal richtige native Apps, sondern eigentlich nur ein Browserfenster, bei dem eine Website angezeigt wird, die wie eine App aussieht. (im Normfall natürlich trotzdem offline auf dem Gerät. Systeme wie Cordova bzw Ionic nutzen das, um das einfache Entwickeln von Apps auf allen Plattformen zu ermöglichen, bei dem die "App" eigentlich nur ne Website ist die dann in einen nativen Container verpackt wird.). Aber im Grunde verhindert nichts, das ich da einfach beliebige Inhalte anzeige.

Wege gibts also viele und die sind nichtmal schwierig oder komplex. Es zahlt sich halt oft nicht aus weil man dann vermutlich direkt und für immer aus dem Store fliegt, wenn man erwischt wird. Aber schwarze Schafe, denen das egal ist haben da sicher wenig Skrupel.
0
Wiesi
Wiesi08.07.19 14:03
Raziel1
Ich könnte zb nach nem Tag ne Url abfragen die Code nachlädt...

...und (außerhalb des Browserbereichs) zur Ausführung bringt???

Ich habe Apple's Sicherheitskonzept leider nicht vollständig verinnerlicht: Aber was nützt ein "Gatekeeper", wenn ein Programm beliebigen Code nachladen und zur Ausführung bringen kann? Und was nützt Apple's Kontrolle, wenn der Code nach der Kontrolle noch ergänzt werden kann?
Everything should be as simple as possible, but not simpler
+1
Quickmix
Quickmix08.07.19 14:19
Wiesi
Fabianexe
Vielen Dank für die Antwort. Wenn ich Dich richtig verstehe, dann werden in den Nutz-Datenstrom spezielle Daten für die Umsteuerung der Funktion eingestreut. (Eine Form von Steganographie.) Dafür ist natürlich kein "Steuerserver" nötig. Dies Wort hat mich verwirrt. Der Groschen ist jetzt unten.

Steganographie ist in der Tat schwer nachweisbar. Dafür wurde sie ja erfunden.

Es ist wie beim Dieselbetrug: Auf dem Prüfstand ist alles in Ordnung; später auf der Straße wird betrogen.

Aufgedeckt wurde er trotzdem.
+1
Raziel109.07.19 14:06
Wiesi
Raziel1
Ich könnte zb nach nem Tag ne Url abfragen die Code nachlädt...

...und (außerhalb des Browserbereichs) zur Ausführung bringt???

Ich habe Apple's Sicherheitskonzept leider nicht vollständig verinnerlicht: Aber was nützt ein "Gatekeeper", wenn ein Programm beliebigen Code nachladen und zur Ausführung bringen kann? Und was nützt Apple's Kontrolle, wenn der Code nach der Kontrolle noch ergänzt werden kann?


Gute Frage. Es kann nun mal schwer alles kontrolliert werden. Wenn ich zb Cordova verwende und meine App quasi nur ein Container ist, mit allen Klassen und Methoden die ich als Schnittstelle für native Funktionen brauche (welche direkt von Cordova zur Verfügung gestellt werden) und der Appinhalt selbst eigentlich nur ein Browser ist Dann verhindert doch eigentlich nichts, das ich irgendwelche Inhalte dynamisch lade und die Schnittstellen dann für böse Zwecke missbrauche.

Vielleicht kann ich keinen Swift Code nachladen, aber brauch ich ja garnicht. Im Browser kann ich ja fast machen was ich will. Viele Apps verwenden solche Framworks und es hatten auch viele solche Funktionen impementiert, wodruch man App Updates selbst auf Geräte Pushen konnte, ohne die App selbst updaten zu müssen. Es wurden einfach die ganzen Webinhalte aktualisiert. Das wurde dann später wegen genau dieser Problematik von Apple verboten. Aber das heist nicht, das es nicht trotzdem manche versuchen.
0
Wiesi
Wiesi09.07.19 17:56
Raziel1

Durch die Parenthese hatte hat ich meine Bedenken auf den Bereich außerhalb des Browsers eingeschränkt. Hier sollte Apple das Nachladen von Code und dessen Ausführung unbedingt verhindern, wenn das Sicherheitskonzept ernst genommen werden soll.

Im Browser ist so gut wie alles möglich, da man sonst die Normen von html & Co nicht erfüllen kann. Hier sollte Apple allerdings sicherstellen, daß die Umgebung des Browsers nicht verlassen werden kann. Insbesondere sollte verhindert werden, auf Daten außerhalb dieser Umgebung zuzugreifen. Dazu braucht man allerdings mehr als einen einfachen Sandkasten. Das ist schon eher eine Quarantäne.

Allerdings ist zu bedenken, daß die Browser-Umgebung die Nutzerschnittstelle mit einschließt. Hier ist der Nutzer in der Verantwortung. Apple wiederum sollte dem Nutzer die Möglichkeit geben, Mikrofon, Kamera und Standortdaten von der Umgebung zu separieren.
Everything should be as simple as possible, but not simpler
0
Raziel110.07.19 10:44
Wiesi
Raziel1

Durch die Parenthese hatte hat ich meine Bedenken auf den Bereich außerhalb des Browsers eingeschränkt. Hier sollte Apple das Nachladen von Code und dessen Ausführung unbedingt verhindern, wenn das Sicherheitskonzept ernst genommen werden soll.

Im Browser ist so gut wie alles möglich, da man sonst die Normen von html & Co nicht erfüllen kann. Hier sollte Apple allerdings sicherstellen, daß die Umgebung des Browsers nicht verlassen werden kann. Insbesondere sollte verhindert werden, auf Daten außerhalb dieser Umgebung zuzugreifen. Dazu braucht man allerdings mehr als einen einfachen Sandkasten. Das ist schon eher eine Quarantäne.

Allerdings ist zu bedenken, daß die Browser-Umgebung die Nutzerschnittstelle mit einschließt. Hier ist der Nutzer in der Verantwortung. Apple wiederum sollte dem Nutzer die Möglichkeit geben, Mikrofon, Kamera und Standortdaten von der Umgebung zu separieren.


Da hast du nicht unrecht. Würde Apple die WebView allerdings so einschränken, das diese nicht mehr mit nativen Code kommunizieren kann, hätte vermutlich ein überraschend großer Teil an Apps ein Problem. Man glaubt garnicht wieviele der Apps im Store mit Cordova/Ionic oder anderen Dingen gebaut wurden und eigentlich nur eine (lokale) Website sind, die aussieht wie eine vollwertige native App. Diese Apps müssten dann wohl alle aus dem Store fliegen und Entwickler wären gezwungen, wieder nur vollkommen native Apps zu schreiben.

Ich selbst hab auch schon ein paar Apps mit Cordova erstellt. Aktuell hab ich eine, die rein nativ umgesetzt wurde, allerdings gibt es auch hier eine Webview, über die man sich auf ein Webinterface einloggen kann und diese Webview muss natürlich irgendwie mit dem nativen Teil kommunizieren. Und sei es nur für einfache Dinge wie einen Logout, oder um einen QR Code Scan zu aktivieren etc.

Aber das könnte natürlich wie oben schon beschrieben missbraucht werden. Ausser Apple verbietet entweder jegliche Kommunikation mit Inhalten der Webview oder erlaubt nur noch lokale Webinhalte zu öffnen, die mit der App geliefert wurden.
0
Wiesi
Wiesi10.07.19 11:53
Raziel1

Traurig, traurig, traurig. Wir hatten am Institut einen Angestellten, der in seiner Bundeswehrzeit, am Eingang der Kaserne nachts Wache schieben mußte. Nun wußte jedermann, daß an der Rückseite des Geländes schon seit Olims Zeiten ein Stück Zaum fehlte. So schrieb er denn eines Nachts ins Wachbuch, daß dieses Stück Zaum geklaut wurde. Da war dann tüchtig was los. Und im Unterschied zu Apple wurde das Loch schleunigst geschlossen.

Zur Lösung unseres Problems: Jede App, die WebView benutzen will, sollte für die Kommunikation ein angepasstes und von Apple geprüftes Plugin benutzen. Ist das zumutbar und kann das unser Problem lösen? (Vermutlich muß Apple für Plugins dieser Art eine eigene Schnittelle zum Browser schaffen)
Everything should be as simple as possible, but not simpler
0
Raziel110.07.19 13:48
Wiesi

Schwierig denke ich. Es sind ja jetzt auch von Apple bereitgestellte Schnittstellen. Nur wie in meinem Fall: Ich nutze die Schnittstelle die Apple bereit stellt und kommuniziere eigentlich, in meinem Fall, nur welche Methode ich gerne im nativen Teil aufgerufen haben will. Diese implementiere ich natürlich vorher auch mit Swift.

Aber theoretisch kann ich ja alle möglich Methoden implementieren, die auch völlig legitim sind und diese dann nur plötzlich anders verwenden. Ich sehe da eigentlich nur den Wegzwei Arten von Webviews zur Verfügung zu stellen (was Apple schon tut) Eine Safari artige Variante, mit den bekannten Interface Elementen, die alles öffnen darf, aber keine Schnittstellen bietet (die gibt es so in der Form schon). Und eine anpassbare Version, die Schnittstellen bietet, aber nur öffnen darf, was bereits lokal bei der App dabei war.

Zweites gibt es auch, nur eben ohne die Einschränkung. Aber wenn man diese einführen würde, währen zb auch direkt alle anderen Browser, wie Chrome, Firefox und so weiter nicht mehr umsetzbar auf iOS.
0
Wiesi
Wiesi10.07.19 17:26
Raziel1

Vielen Dank, daß Du so geduldig auf meine Erwiderungen eingehst. Wenn ich Dich richtig verstehe, wäre das Abdichten der Kommunikationsschnittstelle beim MacOS möglich, da die anderen Browser Apple's Webkit dort nicht benutzen müssen.
Everything should be as simple as possible, but not simpler
0
Raziel111.07.19 08:03
Beim Mac kann ich dir garnicht sagen, wir die Situation dort aussieht und welche Schnittstellen es gibt, bzw welche Konsequenzen es hätte wenn man hier alles sperren würde. Ich entwickle momentan nur für iOS und konnte mich mit macOS noch nicht auseinandersetzen.

Auf iOS verwenden halt viele Apps die die Webview, sei es für spezifische Inhalte oder weil die ganze App eigentlich nur daraus besteht. Aber wenn wir uns mal umsehen, geht ja vieles in Richtung PWAs, also Web Apps. Da kann ich dann direkt von ner Website ne App installieren und wer weiß was die dann macht. Da stellen sich noch mehr Sicherheitsfragen. Ich glaube ja nicht das Apple da zu viel Zugriffe ermöglichen wird, denn sonst wären da jede Menge "potentielle" Probleme die Folge.
0

Kommentieren

Sie müssen sich einloggen, um die News kommentieren zu können.

OK MacTechNews.de verwendet Cookies unter anderem für personalisierte Inhalte, Seitenanalyse und bei der Auslieferung von Google-Anzeigen. Dies war zwar schon immer so, auf Wunsch der EU muss nun jedoch explizit darauf hingewiesen werden. Durch Nutzung der Website erklären Sie sich damit einverstanden. Weitere Informationen