N24 – kommt NICHT zur Sache

Es ist nun schon eine Weile her, dass ich auf AndroidPIT einen Artikel veröffentlichte, in welchem ich über das, sagen wir mal “etwas merkwürdige Verhalten” der N24-App zum damaligen Zeitpunkt ( Mitte August 2012) berichtete. Seit der Veröffentlichung dieses Artikels gab es dann sowohl in besagtem Blog, als auch auf Google Plus in einem von N24 gestartetem Beitrag, rege Diskussionen hinsichtlich der von mir aufgezeigten Übertragung von schützenswürdigen Daten der Nutzer ins Europäische Ausland.


Heute bekam ich die Benachrichtigung vom Google Play-Store, dass es ein Update der N24-App gäbe. Grund genug also das Update einmal auszuführen und zu verfizieren, ob man sich, wie von N24 am 16.08.2012 zugesagt, mit der Lösung des Problems beschäftigt hat und meinen damals gemachten Vorschlägen gerecht geworden ist.

( Link: https://plus.google.com/u/0/+N24Online/posts/Hw5ckj1CPUd )

Meine Vorgehensweise:

  • Installation des N24 -Updates aus dem Google Play Store
  • Starten eines Netzwerk Proxys
  • Einbuchen des Devices ins eigene  Wlan
  • Umleiten des Netzwerkverkehrs meines Smartphones über den Proxy
  • Aufruf der App,
  • Aufruf eines Artikels
  • Beenden der App
  • Auswerten des Netzwerkverkehrs
  • Auswerten des Logcat am Device (mittels USB Verbindung zum PC und ADB)


Die Ergebnisse:
Zunächst wurde der Netzwerkverkehr welcher durch die N24-App verursacht wurde untersucht. Wie schon damals zeigte sich hier, dass die ersten beiden Internet-Zugriffe der App zu einem Server in Paris gehen:
“POST http://mobile.smartadserver.com/call2/pubmj/38682/262515/12627/M/1354123086138//
dafaadf7199b3f3cf/Mozilla%2F5.0%20%28Linux%3B%20U%3B%20
Android%204.1.1%3B%20de-at%3B%20GT-N7100%20Build%2FJRO03C%29%20
AppleWebKit%2F534.30%20%28KHTML%2C%20like%20Gecko%29%20Version%2F4.0%20
Mobile%20Safari%2F534.30”

Content-Length: 241
Content-Type: application/x-www-form-urlencoded
Host: mobile.smartadserver.com
Connection: Keep-Alive

Um nun sicherzustellen,  dass es auch wirklich die App von N24 ist, das obige Ergebnis erzeugte, stellte ich zunächst mit Hilfe eines einfachen Shell-Befehls fest, welche PID (Process ID) die N24 App hat.

C:\users\anonym\adb shell
shell@android:/ $ ps
ps
USER           PID        PPID  VSIZE   RSS       WCHAN    PC              NAME
u0_a170   16542 1935  583348 86588 ffffffff 00000000 S de.cellular.n24hybrid

Korrespondierende Informationen dazu aus dem Logcat (Systemlog des Smartphones):

Obige Informationen verwendete ich nun weiter, um folgendes im Logcat des Smartphones zu finden:

11-28 20:06:21.090: I/SmartAdServer(16542):Messages posted to the server :
{„connexion“:“wifi“,
„uid“:“dafaadf7199b3f3cf“,
„platform“:“Android“,
„lang“:“de“,
„sdkversion“:“2.0″,
„sdkname“:“SDKAndroid“,
„appname“:“NFC-Dienst“}

11-28 20:06:21.090: I/SmartAdServer(16542): Will load ad at URL:
http://mobile.smartadserver.com/call2/pubmj/38682/262515/12627/M/1354129581094//dafaadf7199b3f3cf/
Mozilla%2F5.0%20%28Linux%3B%20U%3B%20Android%204.1.1%3B%20de-at%3B%20GT-N7100%20
Build%2FJRO03C%29%20AppleWebKit%2F534.30%20%28KHTML%2C%20
like%20Gecko%29%20Version%2F4.0%20Mobile%20Safari%2F534.30
11-28 20:06:21.110:
I/GATE(16542): <GATE-M>DEV_ACTION_COMPLETED</GATE-M>

Das passt haargenau zu dem weiter oben entdeckten Netzwerkverkehr, der durch die N24-App verursacht wird. Eine weitere Überprüfung zum Server mobile.smartadserver.com erbrachte, dass dieser (wie schon damals auch) in Frankreich/Paris angesiedelt ist.

Hier der Traceroute zu mobile.smartadserver.com:
C:\Users\anonym>tracert mobile.smartadserver.com
Routenverfolgung zu itx5.smartadserver.com [91.103.142.129] über maximal 30 Abschnitte:

1    <1 ms    <1 ms    <1 ms  192.168.1.1
2     1 ms     1 ms     1 ms  192.168.0.1
3     *       18 ms    15 ms  vie-91-186-158-000.dsl.sil.at [91.186.158.0]
4    15 ms    15 ms    15 ms  Te3-4-c2.oe3.sil.at [86.59.127.65]
5    18 ms    15 ms    15 ms  81.189.132.89
6    15 ms    15 ms    16 ms  212.152.193.90
7    25 ms    16 ms    15 ms  wen3-core-1.tengigabiteth11-0.tele2.net [130.244.49.117]
8    15 ms    15 ms    16 ms  wen1-core-1.pos10-0.tele2.net [130.244.39.253]
9    53 ms    45 ms    49 ms  fra50-core-1.pos0-12-0-0.tele2.net [130.244.205.41]
10    29 ms    29 ms    31 ms  fra36-core-1.bundle-ether5.tele2.net [130.244.64.184]
11    30 ms    30 ms    28 ms  fra36-peer-1.ae3-unit0.tele2.net [130.244.64.187]
12    29 ms    29 ms    28 ms  peer-as3356.fra36.tele2.net [130.244.200.86]
13    40 ms    29 ms    29 ms  vlan80.csw3.Frankfurt1.Level3.net [4.69.154.190]
14    29 ms    28 ms    38 ms  ae-81-81.ebr1.Frankfurt1.Level3.net [4.69.140.9]
15    38 ms    41 ms    37 ms  ae-46-46.ebr2.Paris1.Level3.net [4.69.143.138]
16    37 ms    48 ms    49 ms  ae-58-223.csw2.Paris1.Level3.net [4.69.161.62]
17    58 ms    37 ms    37 ms  ae-22-52.car2.Paris1.Level3.net [4.69.139.227]
18    38 ms    38 ms    38 ms  SIPARTECH.car2.Paris1.Level3.net [212.73.207.246]
19    38 ms    38 ms    68 ms  91.103.138.172
20    37 ms    38 ms    39 ms  91.103.142.129
Eine nachfolgende Überprüfung durch eine Whois Abfrage bestätigte dies dann noch explizit.


Fassen wir also mal zusammen:

Folgende Dinge werden unverschlüsselt an einen, auf einem Französischen Server liegenden Dienst  gesendet: (mobile.smartadserver.com) Dieser Dienst ist im übrigen Hauptanteilig in fester Hand des Axel Springer Verlages.
( http://www.kek-online.de/db/index.php?c=3591&mt=2&s=&f=1 )

Verbindungstyp: wifi (wlan Verbindung)  <- “connexion“:“wifi“
eine Erkennungs ID : <- „uid“:“dafaadf7199b3f3cf“
Die Geräte OS Plattform: <- „platform“:“Android“
Die eingestellte Systemsprache: <- „lang“:“de“
Die verwendete SDK Version: <- „sdkversion“:“2.0″
Der SDK Name: <- „sdkname“:“SDKAndroid“
Der App Name: <- „appname“:“NFC-Dienst“
sowie im tatsächlichen Request noch zusätzlich:

Die OS Version : Android 4.1.1
Der Geräte Typ: GT-N7100
Der Build: JRO03C
Der Browser Typ: Mozilla 5.0
Die Sprachvariant: de-at
Die Webkit Verision: AppleWebKit/534.30 (KHTML, like Gecko) Version/4.0 Mobile Safari/534.30

Soweit so schlecht, aber was ist nun das Schlimme an diesen Dingen?
Nun, zum einen wird von der N24 App hier ein Merkmal des Android Devices verwendet, welches eine einwandfrei Identifizierung dieses Devices in Netzwerken ermöglicht, und zwar der sogenannte “net.hostname” welcher die “Android Device ID” darstellt und für die gesamte Lifetime des Gerätes gültig ist.
(Siehe: http://developer.android.com/reference/android/provider/Settings.Secure.html#ANDROID_ID)
Aussage: A 64-bit number (as a hex string) that is randomly generated on the device’s first boot and should remain constant for the lifetime of the device. (The value may change if a factory reset is performed on the device.)

Darüber hinaus, werden diese Informationen über eine nicht verschlüsselte Internetverbindung, in sich UNVERSCHLÜSSELT übertragen und sind so nahezu von jedermann mit zu lesen.

Wie ich schon damals, vor 3 Monaten, darauf hingewiesen habe, wäre es so einfach, den Benutzer hier mehr Sicherheit hinsichtlich seiner Privatsphäre zu bieten. Mit einfachen Mitteln, wie beispielsweise der Verwendung einer gesicherten HTTPS Verbindung wäre schon viel getan. Zumindest könnte dann nicht mehr von jedermann diese Verbindung mitgeschnitten werden wenn sich der Benutzer der N24-App in einem offenen Netz wie beispielsweise einem WLAN-Hotspot befindet.
Weiters gibt es hinlänglich verlässliche Methoden der generierung von ID’s, um nicht auf eindeutige Device-ID’s zurückgreifen zu müssen, die ein Smartphone weltweit identifizierbar machen und die für jede App welche diese ID am Smartphone abfragt, ident sind. Auch das wurde Euch vor drei Monaten bereits erklärt liebes N24-Team.

Die wichtigen Fragen an das N24-Team lauten also erneut:

Warum verschweigt Ihr Euren Nutzern dieses App Verhalten weiterhin?
Warum geht Ihr in keinster Weise auf die Wünsche Euer Benutzer ein, die ja damals einwandfrei an Euch herangetragen wurden ?
Warum sagt ihr Euren Benutzern, Ihr wollt das Problem lösen und dann irgnoriert Ihr es?

Niemand sagt, dass es nicht notwendig ist für Euch das Device zu identifizieren, oder es falsch ist das zu tun. Nur sollte man es dann auf eine Art und Weise tun, welche die  Benutzer Eurer N24-App nicht unnötigen Risiken aussetzt.

Also, liebes N24-Team, kommen wir zur Sache, Wie wollt Ihr das Vertrauen Eurer Benutzer zurück gewinnen und diese Misstände abstellen?

Nachsatz:
Wie immer möchte ich meinem Freund Andreas von http://www.voetz.net für die nette Unterstützung danken, ebenso wie Peter W. und Immo G.

Tagged , , , , , , , .Speichere in deinen Favoriten diesen permalink.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert