Est-il théoriquement possible de déployer des portes dérobées sur des ports supérieurs à 65535?
En supposant que vous avez pu modifier le système d'exploitation/micrologiciel/périphérique pour que le serveur/client envoie et écoute sur des ports supérieurs à 65535, pourrait-il être possible de planter une porte dérobée et de la faire écouter, disons, sur le port 70000?
Je suppose que la vraie question est la suivante:
Si vous avez reconstruit la pile TCP/IP localement sur la machine, le concept global ne fonctionnerait-il pas en raison de la façon dont le RFC 793 - Transmission Control Protocol Standard fonctionne comme mentionné ci-dessous dans certaines des réponses? Rendre impossible l'accès à un service fonctionnant sur un port supérieur à 65535.
On a tellement parlé de matériel et d'appareils ayant créé des portes dérobées que seul le gouvernement a accès à la surveillance, et j'étais simplement curieux de savoir si c'était l'une des façons de le faire et d'éviter la détection et la découverte?
Non, le champ du numéro de port dans un en-tête TCP est techniquement limité à 2 octets. (Vous donnant 2^16=65536 ports possibles)
Si vous modifiez le protocole en réservant plus de bits pour des ports plus élevés, vous violez la spécification pour segments TCP et vous ne seriez pas compris par un client. En d'autres termes, vous ne parlez plus TCP et le terme "port" comme dans "port source/destination TCP" ne s'appliquerait pas. La même limitation existe pour les ports UDP.
Cela dit, une porte dérobée pourrait communiquer à la place via un protocole différent de TCP ou UDP pour masquer sa communication. Par exemple, icmpsh est un Shell inversé qui utilise uniquement ICMP. Enfin, vous pouvez également implémenter votre propre protocole de couche de transport personnalisé en utilisant sockets bruts qui peut avoir sa propre notion de ports avec une plage supérieure à 0-65535.
Non, c'est ce nombre car le champ TCP pour cela ne fait que 16 bits de long (65536, mais à partir de 0) , il est donc fondamentalement impossible de communiquer un niveau supérieur port que 65535
Si vous avez reconstruit la pile TCP/IP localement sur la machine, le concept global ne fonctionnerait-il pas en raison du fonctionnement de la RFC 793 - Transmission Control Protocol Standard comme mentionné ci-dessous dans certaines des réponses? Rendre impossible l'accès à un service fonctionnant sur un port supérieur à 65535.
Il n'y a aucun service TCP/UDP sur les ports supérieurs à 65535. S'il prend en charge les numéros de port supérieurs à 216-1, puis ce n'est plus TCP (ou UDP) .
Pouvez-vous avoir autre chose ça ...? Sûr. Et pourrait-il être très similaire à TCP? Au point d'être rétrocompatible? Oui aux deux questions.
Il y a eu tellement de discussions sur le matériel et les appareils ayant créé des portes dérobées que seul le gouvernement a également accès pour la surveillance, et j'étais simplement curieux de savoir si c'était peut-être l'une des façons de le faire et d'éviter la détection et la découverte?
Si j'avais développé un tel appareil, il s'appuierait sur un protocole suffisamment commun pour être banal. Un paquet de protocole inconnu/illégal, après quoi un trafic supplémentaire s'ensuit, serait assez suspect.
Se cacher (presque) à la vue
Ce qu'un tel périphérique pourrait faire pourrait, par exemple, inspecter certains octets dans la charge utile. Il s'agit généralement de valeurs non corrélées; Je pourrais alors envoyer des paquets à la cible, ou s'il s'agit d'un routeur, sans même une adresse IP propre, à un hôte aléatoire, peut-être même inexistant au-delà la cible, se faisant passer pour (par exemple ) une demande HTTPS ou une tentative de connexion SSH.
Si vous voyez un paquet que vous ne connaissez pas, vous pourriez devenir suspect. Mais même si vous avez vu dans les journaux quelque chose comme
SSH: failed attempt for user maintenance
SSH: failed attempt for user maintenance
SSH: failed attempt for user maintenance
vous ne vous inquiéteriez pas, surtout si vous aviez non "maintenance" utilisateur. Vous supposeriez peut-être que quelqu'un, quelque part, a découvert une attaque contre un appareil avec un utilisateur par défaut de "maintenance" (diable, si j'étais un gouvernement, je pourrais marché un tel appareil, le rendre vulnérable , et non pas le réparer, dans le seul but de justifier de telles connexions sur des appareils totalement différents. Quelle est la première chose que vous feriez en voyant de telles tentatives? Soit rien ("bruteforce inoffensive. Idiot"), google et haussement d'épaules ("Oh, quelqu'un qui pense que j'ai un CheapRouter 2000. Idiot", peut-être écrire une règle de pare-feu pour bloquer l'adresse IP - sauf que les paquets arrivent toujours à la carte réseau).
Et ce qui se passe réellement, c'est que le mauvais firmware du routeur, de la carte réseau, de la carte mère ou quoi d'autre, reconnaît le paquet et renvoie une réponse. Il pourrait le faire en forgeant des paquets de réponses écrasant les "vrais".
Le seul symptôme de quelque chose de très grave se produirait si vous compariez, disons, le trafic entrant et sortant d'un mauvais routeur:
Hôte avec serveur SSH:
--> SSH SYN --> ROUTER --> SSH SYN --> Host
<-- SSH S+A --- ROUTER <-- SSH S+A <-- Host
--> SSH ACK --> ROUTER --> SSH ACK --> Host
...
--> LOGIN ----> ROUTER --> LOGIN ----> Host
<-- FAIL2------ ROUTER <-- FAIL1 <---- Host packets are different!
Hôte sans serveur SSH:
--> SSH SYN --> ROUTER --> SSH SYN --> Host
<-- SSH S+A --- ROUTER <-- SSH RST <-- Host wait, WTF?
--> SSH ACK --> ROUTER Host
...
--> LOGIN ----> ROUTER Host
<-- FAIL2------ ROUTER Host
Si vous renifliez sur un câble, à gauche ou à droite de l'appareil compromis, vous ne remarqueriez rien de mal immédiatement.
L'autre chose suspecte serait alors que l'expéditeur utilise apparemment l'extension TCP Fast Open . Notez que vous pouvez envoyer des données supplémentaires dans le SYN même sans TCP/FO, elles seront simplement ignorées par les périphériques qui sont les deux non FO et non compromis.
Comme déjà dit, les numéros de port sont représentés avec un entier 16 bits non signé et ne peuvent pas être supérieurs à 65535.
Mais il y a une possibilité d'utiliser différents protocoles (pas TCP ou UDP). Dans l'en-tête IP, il y a un champ de 8 bits appelé "numéro de protocole", qui indique quel protocole de transport est utilisé à l'intérieur de ce paquet.
Vous pouvez consulter le tableau des protocoles de transport ici: http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml
Certains protocoles de cette liste sont largement utilisés par les utilisateurs (par exemple, TCP ou UDP), certains plus rarement (DCCP ou UDPLite). Certains numéros de protocole ne sont pas encore utilisés et certains sont déconseillés (ARGUS, EMCON).
Ainsi, la porte dérobée peut utiliser des numéros de protocole inutilisés pour envoyer des données à son serveur. Bien sûr, cette technique est difficile à implémenter (nécessite l'accès à rawsocket ou l'implémentation d'une porte dérobée en tant que module de noyau OS).
Source: https://www.frozentux.net/iptables-tutorial/iptables-tutorial.html#TCPIPREPETITION
Ce document vraiment complet indique clairement comment les bits sont attribués sur Internet via TCP. Il montre les ports source et de destination côte à côte.
Vous avez donc créé un port source 32 bits? NOPE dès qu'il touche les octets Internet 3 & 4 (ordre inférieur) de votre port source sera traité à destination.
Le port de destination avec effacer le numéro de séquence, et tout sera poussé plus loin sur la ligne.
Maintenant que le numéro de séquence a été détruit, la destination ne s'attendra pas à ce numéro de séquence et le déposera comme s'il s'agissait d'un paquet usurpé.
Même s'il a dépassé ce point, le numéro d'accusé de réception sera écrasé par le numéro de séquence et puisque ce numéro est maintenant invalide, en ce qui concerne Internet, il ne sera jamais reconnu.
J'ai réfléchi à cela pendant quelques jours, et je pense que la réponse peut être oui, mais d'une manière étrange.
Ainsi, comme beaucoup d'autres réponses l'ont souligné, TCP indique que les numéros de port sont de 16 bits. Cela fait 16 1 et 0. Cela a une limite de 65 535 ports répétables. Pour le reste de l'exemple allaient utiliser 4 bits parce que je suis paresseux.
Donc, avec 4 bits, je peux représenter 15 ports.
Votre porte dérobée théâtrale devrait s'appuyer sur la façon dont elle a traité les paquets mal formés TCP paquets. Donc (rappelez-vous 4 bits au lieu de 16). Permet d'envoyer du trafic sur le port 17.
L'en-tête serait mal formé comme 10001. Votre pile TCP pourrait indiquer que si vous obtenez un en-tête mal formé, suivez un chemin logique différent, en attachant des données au port des quatre "plus à droite" quatre Dans ce cas, le port 1 ou 0001. La vraie astuce est que TCP utilise simplement le nombre de bits. Ce n'est pas comme xml où il y a un [port] 10001 [/ port]. Donc vous besoin d'un moyen de détecter le débordement de l'en-tête de votre port. SYN est juste à côté du port pour que vous puissiez le faire, un SYN de exactement "1073741823" signifie que votre port de destination est plus grand d'un.
Ce chemin logique différent pourrait alors rester actif pendant toute la durée de la connexion sur le port 1.
De cette façon, vous pourriez avoir une porte dérobée TCP autour d'un endroit qui a accepté des paquets mal formés et a fait quelque chose de spécial avec eux. Le vrai problème est que rien d'autre que votre TCP = pile pourrait les comprendre. Routeurs, commutateurs intelligents, même en théorie, certaines cartes NIC abandonneraient le paquet, car il est mal formé. Il n'y aurait presque aucun moyen de savoir si un paquet le ferait) à sa destination avec cet en-tête mal formé.
Mais, si vous connectez deux périphériques avec la pile wonky TCP à un commutateur ou un concentrateur "stupide". En théorie, vous pourriez le faire fonctionner, mais ce ne serait pas dans le TCP spéc.
Cela serait possible mais vous ne seriez pas en mesure d'utiliser des protocoles tels que UDP et TCP puisque leur port max est 65535.
Vous devez implémenter votre propre protocole en plus du protocole IP.
Cela peut être possible en utilisant des sockets brutes.
Il y a eu tellement de discussions sur le matériel et les appareils ayant créé des portes dérobées que seul le gouvernement a également accès pour la surveillance, et j'étais simplement curieux de savoir si c'était l'une des façons de le faire et d'éviter la détection et la découverte?
Je ne pense pas que cela aiderait à rendre la connexion plus furtive car vous seriez toujours en mesure de voir les paquets traverser le réseau.
Tout le monde l'a expliqué en termes de paquet TCP/IP: le champ du port ne fait que 16 bits.
Mais qu'en est-il du code source du noyau Linux et comment il gère le port? Partout dans le noyau Linux, pour le port TCP/IP, il est toujours converti en "court" ou 16 bits. Et lorsqu'elle est compilée dans x86 Assembly, la version 16 bits des instructions est utilisée pour gérer les données 16 bits.
Et si vous vous interrogez sur IPv6, il s'agit du même système d'exploitation IPv4 - tout sur TCP et UDP.
https://stackoverflow.com/questions/186829/how-do-ports-work-with-ipv6
Mais bien sûr, vous pouvez configurer une communication étrange comme l'utilisation de DEUX serveurs pour la communication - chacun ayant des ports 16 bits individuels et donc lorsque vous les combinez, vous avez un port virtuel 32 bits. Mais seul le monde entier saura comment parler aux deux serveurs - par exemple, diviser les données en deux et les diviser entre les deux serveurs, pour être reconstruit à nouveau côté client.
Il semblait vraiment que plus de 16 bits était presque impossible.