Routeur Netgear écoutant sur le port 32764?

J'ai un Netgear DG834G exécutant le firmware V5.01.01. Du côté LAN, si je le scanne, c'est l'écoute sur le port TCP 32764. Essayer de telnet sur ce port me donne la réponse MMcS\xff\xff\xff\xff\0\0\0\0(en hexadécimal, évidemment).

J'ai UPnP désactivé, ce n'est pas un port de gestion à distance et il n'est pas ouvert du côté WAN. Je ne trouve rien dans la documentation de Netgear, et la recherche en ligne ne trouve rien non plus. Quelques personnes semblent l'avoir remarqué, mais personne n'a réellement de réponse. J'ai également créé une règle de pare-feu bloquant l'accès sortant à ce port, et il est toujours ouvert, c'est donc le routeur qui l'écoute.

Quelqu'un sait-il ce que cela pourrait être?

Hmm, bizarre.

Hex ff = Decimal 255, donc logiquement la réponse que vous recevez est équivalente à

MMcS 255.255.255.255 0.0.0.0 (points ajoutés pour la clarté du réseau) qui pour moi est fondamentalement une adresse de diffusion sur votre réseau. Cela pourrait indiquer que n'importe quelle adresse IP sur votre réseau peut utiliser le service MMCS, c'est-à-dire 255.255.255.255 net mask 0.0.0.0.

Il peut y avoir un certain nombre de choses que MMCS pourrait être, comme le MultiMedia Class Scheduler que Vista est capable d'utiliser pour obtenir la priorité pour le trafic multimédia sur le réseau. Cela expliquerait également pourquoi le port n'est ouvert que sur votre réseau local.

Aussi un peu d'informations sur le point 5 du premier post de cette page

Je doute que ce soit lié à la commutation cellulaire MIP-MANET qui semble être liée aux réseaux de téléphonie mobile. Wow, il y a des trucs bizarres qui sont retournés lorsque vous Google pour MMCS 255.255.255.255 . Comme ça .

Je dirais donc que c'est probablement un port qui permet au planificateur de classe Windows MultiMedia de parler au routeur pour hiérarchiser le trafic, mais cela pourrait être un truc bizarre de réseau de téléphonie mobile génial.

En fait, cela semble être une porte dérobée logicielle incluse par le fabricant comme décrit ici et exploitable à l'aide de ce script .

Jusqu'à présent, des personnes non liées au fournisseur ont signalé l'existence de portes dérobées dans les routeurs suivants: Linksys WAG200G, Linksys WAG320N (Firmware V1.00.12) et Netgear DM111P. Mais il semble que les appareils suivants (le vôtre inclus) peuvent également être présents, Netgear DG834, DG834G WPNT834 DG934, WG602, routeur WGR614, Linksys WAG160N et DGN2000, WAG120N wireless-WRVS4400N. Il semble probable que cette porte dérobée soit également présente dans d'autres appareils.

Il s'agit du port MIPS qui est présent dans les périphériques fabriqués par SerComm, les routeurs et les passerelles domestiques (Linksys, Netgear, Cisco) utilisés pour les mises à niveau du micrologiciel.

Ceci est géré par un scfgmgrprocessus qui écoute sur le port 32764.

Lorsqu'elles sont accessibles via telnet, les données préfixées par ScMMou MMcS(selon l'endianisme du système) semblent être renvoyées.

C'est un protocole binaire très simple avec en-tête (0xC octets) suivi d'une charge utile.

Structure d'en-tête:

typedef struct scfgmgr_header_s {
    unsigned long   magic;
    int             cmd;
    unsigned long   len;
} scfgmgr_header;

Ceci est basé sur des sources Cisco GPL (par exemple wap4410n_v2.0.1.0_gpl.tgz sur ftp-eng.cisco.com déclassé).

Pour des informations réelles, voir la description d'elvanderb et un exemple de code Python .

Actuellement, il est célèbre pour le débordement de tampon basé sur le tas qui peut vous donner un accès complet à l'appareil ( une porte dérobée ). Cela a été découvert par Eloi Vanderbeken à Noël 2013, mais il était probablement connu des pirates chinois en 2008 ( fichier cgi ).

Voici comment ça marche.

Débordement de tampon basé sur le tas:

Messages:

Donc, utiliser un simple message débordant peut donner beaucoup de détails intéressants:

Cependant, cela pourrait entraîner la réinitialisation de la configuration, alors ne le faites pas à la maison.

Voici quelques commandes inversées exécutées par le routeur exécutées via ce port.

1. nvram - Configuration de vidage.

2. get var - Obtenez la configuration var

   débordement de tampon possible basé sur la pile (si la variable est contrôlée par l'utilisateur)

3. set var - Définir la configuration var

   débordement de tampon basé sur la pile, le tampon de sortie (taille ≈ 0x10000) est sur la pile.

4. commit nvram - Lisez nvram / dev / mtdblock / 3 depuis / tmp / nvram et vérifiez CRC

   définir nvram (/ dev / mtdblock / 3) à partir de / tmp / nvram; vérifier CRC

5. Activer le mode bridge (pas sûr, je n'ai pas eu le temps de le tester)

   nvram_set(“wan_mode”, bridgedonly)
   nvram_set(“wan_encap”, 0)
   nvram_set(“wan_vpi”, 8)
   nvram_set(“wan_vci”, 81)
   system(“/usr/bin/killall br2684ctl”)
   system(“/usr/bin/killall udhcpd”)
   system(“/usr/bin/killall -9 atm_monitor”)
   system(“/usr/sbin/rc wan stop >/dev/null 2>&1”)
   system(“/usr/sbin/atm_monitor&”)
   

6. Afficher la vitesse Internet mesurée (téléchargement / téléchargement)

7. cmd (ouais, c'est une coquille…)

   • commandes spéciales:

     • exit, bye, quit -> quit ... (vivant = 0)
     • cd: changer de répertoire (un peu WTF)

   • autres commandes:

     • débordement d'entier dans la gestion stdout (?) non exploitable mais quand même ...
     • débordement de tampon sur la sortie cmd (même tampon à nouveau)…

8. écrire un fichier

   • nom de fichier dans la charge utile
   • répertoire racine = / tmp
   • la traversée du répertoire peut être possible (non testé mais c'est un open (sprintf (“/ tmp /% s”, payload))…)

9. version de retour

10. retour modem routeur ip

    • nvram_get ("lan_ipaddr")

11. restaurer les réglages par défaut

    • nvram_set ("restore_default", 1)
    • nvram_commit

12. lire / dev / mtdblock / 0 [-4: -2]

    • ne sais pas ce que c'est, je n'ai pas eu le temps de le tester

13. vider nvram sur le disque (/ tmp / nvram) et valider

Source: (diaporama) Comment Linksys a sauvé mon Noël!

Normalement, ce type de ports devrait être officiellement confié à l' IANA .

C'est ce que unSpawn a répondu lors de LinuxQuestions en 2007 concernant ce port:

S'il s'agit d'un port officiellement attribué par l'IANA (avec un nombre compris entre 0 et environ 30000), son numéro doit correspondre à un service dans / etc / services (`` numéro de port des services getent ''), le fichier de services d'un scanner comme Nmap ou en ligne base de données comme Sans 'ISC.

Notez que l'utilisation du port éphémère peut être configurée localement à l'aide du /proc/sys/net/ipv4/ip_local_port_range sysctl. Une ancienne valeur par défaut était 1024-5000, pour les serveurs une valeur de 32768-61000 est utilisée et certaines applications veulent quelque chose comme 1025-65535.

Notez également qu'il s'agit de mappages statiques de nombre à service et que, par exemple, / etc / services dira TCP/22que SSH correspond à ce qui ne doit pas être le cas dans une situation particulière,

Sinon, si c'est un port dont vous ne savez pas quel processus lui a été lié, alors si vous avez accès à l'hôte, vous pouvez l'interroger à l'aide de netstat -anp, lsof -w -n -i protocol:portnumberou fuser -n protocol portnumber. Ceci est la méthode la plus précise,

Sinon, si vous n'avez pas accès à l'hôte, vous pouvez l'interroger, par exemple en le téléphonant. Ce n'est pas une méthode précise et dans le cas d'un hôte compromis, vous pouvez alerter l'intrus sur lequel vous êtes.

Voir également:

• (GitHub) La porte dérobée pour Linksys WAG200G (TCP / 32764).
• (GitHub) Pot de miel pour porte dérobée de routeur (TCP-32764)
• (diaporama) Comment Linksys a sauvé mon Noël!
• Mise à jour du firmware du WAG200G (FR) sur le forum Linksys
• TCP-32764 chez wikidevi
• Je voulais en savoir plus sur l'exploit "Exécution de code à distance du périphérique SerComm" sur Rapid7
• Google: "0x53634d4d" pour plus de détails.