Bloquer le tracking d'une Smart TV samsung ou comment entuber Samsung dans les règles de l'art.
J'ai fais l'acquisition récemment d'une télé connecté, cependant je ne souhaitais pas avoir un télé connecté à la base. Pas en raison de ces fonctions ULTRA PRATIQUE(disons le), mais en raison de la fuite de donnée. Du coup, je me suis mis en tête de lui museler la gueule. Elle est déjà ultra fonctionnelle déconnecté d'internet et avec une nvidia sous lineage OS, mais malheuresement les membres de ma smala, on plus d'intérêt pour les fonctionnalités qui lui sont possible, pluôt que pour la sécurité des données qui y circulent.
Pour ce faire, pour voir que dis la télé, j'ai décidé de la connecté à un réseau "sans" DNS. Pour anisi dire, j'ai déconnecté le résolveur local est mon réseau interdit toutes sortie par le port 53 non autorisé. Par conséquent, avant même de commencer, je me doute très bien du fonctionnement théorique de la télé et à quel point celle-ci va être perdu.
Bref, J'ai connecté la télé en faisant une capture wireshark et là... patatra... 
Comme vous pouvez le voir, nous avons affaire ici à un putain de geulard. La totalité de la photo se passe littérallement en l'espace de 1 seconde... il gueule comme pas permis à tous vent sur les IP multicast. Je sais qu'elle sont utilisé pour être reconnu sur le reseaux et permmettre des services tel que le partage d'écran sans-fil ect... mais quand même... Comme vous pouvez le voir elle fait également des requête DNS pour avoir essayer de communiquer avec les serveur samsung... Et justement, je vais principalement m'attarder sur les données sortantes de mon reseau. Et même si il ne faire normalement jamais confiance à personne, même sur mon réseau local, je souhaite dans un premier temps préservé des donnée qui n'ont rien à faire en dehors de chez moi.
J'ai donc fait un filtre pour dégager les données des IP multicast et voilà ce que l'on obtient: 
On voit très bien, ici, des requêtes DNS à ne plus savoir quoi en faire. Il envoie également des information sur ces services sur l'IP broadcast du réseau local (192.168.1.255)
Décortiquons les requêtes DNS: Il commence d'abords par utiliser les ressources DNS déclarer sur le réseau pour ensuite se rabattre sur le réseaux de google. c'est à dire que si le réseau local lui convient parce que par exemple il filtre traqueur et autre, il va voir chez le voisin si tout va bien...
De plus, même si google est un choix périn au niveau de la pérénité, il ne l'est que très peu vis-à-vis de la sécurité, mais bref passons cela...
On voit qu'il demande les uns après les autres, les adresses suivante: time.samsungcloudsolution.com; cdn.samsungcloudsolution.com -> uniquement en IPv4. Alors que tout de suite après il demande gld.push.samsungosp.com en IPv4 puis en IPv6...
............... AH ...........
Ha ok, les fonctions je suppose principale il refuse catégoriquement de IPv6 mais par contre pour push mes données, alors là tu as le choix du réseau... car oui c'est vrai qu'il est plus important de push mes données...
De toutes évidences, comme elle n'arrive pas à obtenir aucune de ces adresse, elle essaye go.microsoft.com pour bien vérifier qu'elle est connecté à internet... (j'imagine)
Mais... voyons monsieurs, il n'y a pas que le DNS dans la vie.... il y a aussi les ping.... ... ... De plus, 1 fois pour google, 1 fois pour microsoft, vous bouffer pas un peu à tous les ratelier... essayer au moins de vous coller sur 1 GAFAM, mais demander pas à google, l'adresse de microsoft, c'est un peu idiot!!!!
Voilà 1er démarrage, c'est presque tout... On va dire que c'est déjà pas mal... Il réclame ces 3 adresses une 50aine de fois en quelque secondes avant de se lasser, il demande ensuite que cdn et time et puis encore au bout de quelque secondes, uniquement time à un rythme de 30 fois par seconde, alternativement au DNS local déclaré et à google. Probablement pour ne pas loupé la moindre seconde de connexion à internet. Nous avons également 1 fois, UNE requête SRV pour l'adresse _hbbtv-ait._tcp.hbbtvopapps.org ... Une seul fois, en plein milieu de toutes les autres...
Et comme vous pouvez le voir sur les 2 photos qui suivent:
Samsung nous informe bien qui va envoyé des données à caractères personnels AVANT MÊME de valider valider le traitement (RGPD.... ça n'existe toujours pas en 2021.) Et ensuite il déclare que il est pas connecté à l'internet... (alors que pour l'instant je n'est bloqué uniquement les DNS) J'avais bien parié mon coup: Il ne se base uniquement sur les DNS et c'est du pain benni pour moi.
Aussi, autre GROSSE BLAGUE, la réinitialisation réseau ne sert STRICTEMENT à rien si vous êtes en ethernet, car il continue de gueuler comme si de rien n'était. Sans aucune gène... Vous devez retourner dans configuration réseau, sélectionner réseau sans-fil et lui laisser faire une recherche wifi pour qu'il oublie tout... bien joué!!!!
Pour mon deuxième démarrage, j'ai bloqué tout son traffic. J'ai oublié de réactiver les DNS et il m'a fait un truc bizarre. Comme j'avais défini samsungosp et cdn en 127.0.0.1 . La TV reste bloqué sur la configuration réseau. Fait étonnant après 2 minutes de tentative avec time, il a commencé à envoyé des requête pool.ntp.org, puis 10 minutes après, après 5 tentatives à www.worldtimeserver.com. Elle a crash.
3ème tentative avec le traffic bloquer et les DNS réactiver avec time uniquement d'autoriser. Il essaye en boucle en faisant 2 requête sur le port 443 (https) pour time, 1 requête sur le port 80 (http) pour worldtimeserver et 1 requête NTP sur le pool.ntp.org.
Je ne vois pas pourquoi la télé devrait faire des requête HTTPS ou même HTTP pour juste récupérer l'heure... par conséquent je vais lui obliger à faire des requêtes NTP en bloquant time et woraltimeserver, car il n'y a pas de raison de prendre bcp de ressources pour juste mettre à jour leur heures.
4ème tentatives :après avoir obtenue l'heure avec ntp, il fait en permanence une requête sur cdn à raison de 2 requête par secondes. Par moment il fait encore des requêtes https ET http(cette fois) pour leur serveur time. Après redémarrage, il se permet également de faire des requêtes http à go.microsoft.com.
Pour ma 5ème tentative, je débloque cdn et le port 80 uniquement. Et la télé accepte enfin de se considéré comme connecté à internet. Pour cela elle fait 5 requête GET:
Hypertext Transfer Protocol
GET /Public/network/files/check.xml HTTP/1.1\r\n
[Expert Info (Chat/Sequence): GET /Public/network/files/check.xml HTTP/1.1\r\n]
[GET /Public/network/files/check.xml HTTP/1.1\r\n]
[Severity level: Chat]
[Group: Sequence]
Request Method: GET
Request URI: /Public/network/files/check.xml
Request Version: HTTP/1.1
Host: cdn.samsungcloudsolution.com\r\n
Accept: */*\r\n
\r\n
[Full request URI: http://cdn.samsungcloudsolution.com/Public/network/files/check.xml]
[HTTP request 1/1]
[Response in frame: 12818]
Et le serveur lui repond:
Hypertext Transfer Protocol
HTTP/1.1 200 OK\r\n
[Expert Info (Chat/Sequence): HTTP/1.1 200 OK\r\n]
[HTTP/1.1 200 OK\r\n]
[Severity level: Chat]
[Group: Sequence]
Response Version: HTTP/1.1
Status Code: 200
[Status Code Description: OK]
Response Phrase: OK
x-amz-id-2: uZv+lDGJNYL767hL3XUEKD1gUp3p7G2GG2XfNZOCd1/UjEPLZos0QyxuoP43B0eR3tOshp3afY4=\r\n
x-amz-request-id: 237308E20FF111B0\r\n
Last-Modified: Tue, 06 Jan 2015 06:33:20 GMT\r\n
ETag: "bfb98aebf53246f34b26a19496961af0"\r\n
x-amz-meta-cb-modifiedtime: Tue, 06 Jan 2015 06:32:43 GMT\r\n
Accept-Ranges: bytes\r\n
Content-Type: text/xml\r\n
Content-Length: 53\r\n
[Content length: 53]
Server: AmazonS3\r\n
Date: Mon, 15 Feb 2021 22:17:02 GMT\r\n
Connection: keep-alive\r\n
\r\n
[HTTP response 1/1]
[Time since request: 0.006769000 seconds]
[Request in frame: 12812]
[Request URI: http://cdn.samsungcloudsolution.com/Public/network/files/check.xml]
File Data: 53 bytes
il fait également une requête à microsoft:
Hypertext Transfer Protocol
GET /fwlink/?LinkId=799153 HTTP/1.0\r\n
[Expert Info (Chat/Sequence): GET /fwlink/?LinkId=799153 HTTP/1.0\r\n]
[GET /fwlink/?LinkId=799153 HTTP/1.0\r\n]
[Severity level: Chat]
[Group: Sequence]
Request Method: GET
Request URI: /fwlink/?LinkId=799153
Request URI Path: /fwlink/
Request URI Query: LinkId=799153
Request URI Query Parameter: LinkId=799153
Request Version: HTTP/1.0
Host: go.microsoft.com\r\n
User-Agent: PlayReadyClient\r\n
Pragma: no-cache\r\n
\r\n
[Full request URI: http://go.microsoft.com/fwlink/?LinkId=799153]
[HTTP request 1/1]
[Response in frame: 13174]
Hypertext Transfer Protocol
HTTP/1.0 302 Moved Temporarily\r\n
[Expert Info (Chat/Sequence): HTTP/1.0 302 Moved Temporarily\r\n]
[HTTP/1.0 302 Moved Temporarily\r\n]
[Severity level: Chat]
[Group: Sequence]
Response Version: HTTP/1.0
Status Code: 302
[Status Code Description: Found]
Response Phrase: Moved Temporarily
Location: https://secureclock.playready.microsoft.com/secureclock/vista_rtm/?petition\r\n
Server: Kestrel\r\n
Request-Context: appId=cid-v1:9b037ab9-fa5a-4c09-81bd-41ffa859f01e\r\n
X-Response-Cache-Status: True\r\n
X-Powered-By: ASP.NET\r\n
Content-Length: 0\r\n
[Content length: 0]
Expires: Mon, 15 Feb 2021 22:17:03 GMT\r\n
Cache-Control: max-age=0, no-cache, no-store\r\n
Pragma: no-cache\r\n
Date: Mon, 15 Feb 2021 22:17:03 GMT\r\n
Connection: close\r\n
\r\n
[HTTP response 1/1]
[Time since request: 0.006904000 seconds]
[Request in frame: 13169]
[Request URI: http://go.microsoft.com/fwlink/?LinkId=799153]
et puis ça part en couille avec des redirection qu'il se permet de suivre:
GET /secureclock/vista_rtm/?petition HTTP/1.0\r\n
[Expert Info (Chat/Sequence): GET /secureclock/vista_rtm/?petition HTTP/1.0\r\n]
[GET /secureclock/vista_rtm/?petition HTTP/1.0\r\n]
[Severity level: Chat]
[Group: Sequence]
Request Method: GET
Request URI: /secureclock/vista_rtm/?petition
Request URI Path: /secureclock/vista_rtm/
Request URI Query: petition
Request URI Query Parameter: petition
Request Version: HTTP/1.0
HTTP/1.1 200 OK\r\n
[Expert Info (Chat/Sequence): HTTP/1.1 200 OK\r\n]
[HTTP/1.1 200 OK\r\n]
[Severity level: Chat]
[Group: Sequence]
Response Version: HTTP/1.1
Status Code: 200
[Status Code Description: OK]
Response Phrase: OK
Hypertext Transfer Protocol
POST /secureclock/vista_rtm/?Time&V20 HTTP/1.0\r\n
[Expert Info (Chat/Sequence): POST /secureclock/vista_rtm/?Time&V20 HTTP/1.0\r\n]
[POST /secureclock/vista_rtm/?Time&V20 HTTP/1.0\r\n]
[Severity level: Chat]
[Group: Sequence]
Request Method: POST
Request URI: /secureclock/vista_rtm/?Time&V20
Request URI Path: /secureclock/vista_rtm/
Request URI Query: Time&V20
Request URI Query Parameter: Time
Request URI Query Parameter: V20
Request Version: HTTP/1.0
Host: secureclock.playready.microsoft.com\r\n
User-Agent: PlayReadyClient\r\n
Content-Type: application/x-www-form-urlencoded\r\n
Pragma: no-cache\r\n
Content-Length: 380\r\n
[Content length: 380]
\r\n
[Full request URI: http://secureclock.playready.microsoft.com/secureclock/vista_rtm/?Time&V20]
[HTTP request 1/1]
[Response in frame: 13721]
File Data: 380 bytes
Cependant, après tout ça, elle se considère bien connecté à internet mais lors de l'acceptation des conditions générales, la télé exige une connection au serveur time. Du coup, je vais lui laisser accès à time pour voir...
