Bueno, tras un extenso parón espero poder retomar poco a poco el ritmo del blog. Animo al resto de “editores” a que publiquen algo y así no se note tanto cuando alguno entramos en un agujero negro. Y si alguno de los que estáis por Sevilla en esto de la seguridad queréis publicar algo, pues hacedmelo llegar, ¿ok?

Hoy quiero hablaros de un detalle de inseguridad de los visores de SIG (Sistemas de Información Geográfica). El visor es una aplicación web que extrae las imágenes de un mapa de alguna base de datos con localización geográfica (el SIG propiamente dicho). Sobre estas imágenes es posible añadir ‘capas’ que no es otra cosa que más información relacionada con la posición.

Muchos de estos visores te dejan, como usuario, añadir nuevas capas de otras fuentes para crear tu propio mapa. Otros ya traen sus capas fijas y puedes añadirlas o quitarlas pero sólo esas.

Ahora bien, la implementación de la funcionalidad de añadir capas suele incluir un cuadro de diálogo donde le pones un nombre, le indicas una URL para descargarla y le pones qué tipo de capa es (hay varias opciones).

Internamente, es el servidor el que se conecta al recurso, se lo descarga y lo devuelve al navegador. Lo bueno (o lo malo, según se mire) es que de este modo es posible solicitar cualquier URL que queramos y el servidor la pillará para nosotros.

el_mapa

Analicemos un poco esta situación: básicamente esta funcionalidad es un proxy que se ejecuta en un servidor en una red interna del organismo correspondiente al que le puedes solicitar cualquier URL, incluso de equipos internos. De hecho, en algunos SIG que he visto la URL se llama proxy o MapProxy o similar.

¿Cómo identificar esta funcionalidad? Si se trata de un visor que acepta capas, nada más fácil que añadir una URL cualquier y observar con un proxy de interceptación (Burp, por ejemplo) a ver qué URL utiliza. Si tenéis algún servidor web por ahí, ponedlo y echad un ojo a los logs.

Si no acepta capas, esta funcionalidad de proxy puede estar presente aunque no se use en la aplicación web y conviene echar un ojo al código fuente de los ficheros javascript para identificar la URL en cuestión.

Por lo tanto, si hacemos un análisis de seguridad a un organismo que tiene un SIG con esta ‘vulnerabilidad’ ya tenemos una forma de acceder a sus webs internas.

Pero ojo, ese no es el único problema, que te usen como ‘proxy’ abierto para hacer fechorías te puede traer muchos problemas (consumo de ancho de banda, inclusión en listas negras, ser origen de ‘delitos’, etc.).

Algunas limitaciones de este tipo de proxies:

  • El método HTTP está fijado, en algunos es GET y en otros, POST.
  • Normalmente no es posible generar solicitudes complejas, ya que la URL que pongamos es un parámetro de otra URL, incluir variables puede no acabar de funcionar.
  • Los enlaces de la página interna no funcionan, claro, porque no tienen en cuenta que hemos accedido de una forma subrepticia.
  • A veces el Content-Type es xml y el navegador no lo acaba llevando bien.

¿Cómo solucionar esto? Pues si no se trata de un visor SIG con capacidad para añadir capas, desactivando la funcionalidad ‘proxy’.

Por el contrario, si se trata de un visor SIG para añadir capas externas, se podrían filtrar las URLs con algún criterio o comprobar que la vuelta efectivamente corresponde al formato esperado. También se puede hacer que sea el navegador el que descargue el recurso y no el servidor, evitando este problema.

Y, como siempre, registrad logs y echad un ojo de vez en cuando no vaya ser que…

ACTUALIZACIÓN:

Ups “que sea el navegador el que descargue el recurso y no el servidor“. Acabo de comerme la Same-Origin Policy (aka SOP). Luego pensando me he dado cuenta de que igual no es tan fácil esta opción así de primeras.

Probablemente lo mejor sería comprobar que el fichero se ajusta al DTD específico del tipo de mapa que se quiere cargar, evitando servirlo si no es un fichero esperado y no enviando ciegamente lo que se descargue de la URL.

Recientemente he tenido la ‘suerte’ de encontrarme algunos ejemplos de auto-cifrado. Con esta expresión me refiero a lo siguiente: Software en manos de un usuario que tiene cierta información cifrada a la que él no puede acceder pero cuya clave se almacena en el código o configuración que utiliza el código.

Por eso lo llamo ‘auto-cifrado’. Es curioso porque da la impresión de que la información local cifrada es segura hasta que preguntas “¿y con qué clave se descifra esto?”. En los casos que me he encontrado, la empresa que desarrolla la solución le ha dicho al cliente “no te preocupes, que está cifrado”. Pero claro, para evitar que cualquier pueda descifrarlo, la clave no puede estar ‘en el mismo equipo’.

Por lo tanto, si tenéis que analizar un software de escritorio o applet y os encontrais un fichero cifrado, buscad entre la configuración o el código para ver si han sido tan descuidados como para guardar la clave por ahí.

Y si contratáis una solución a una empresa externa y os dicen que tal o cual está cifrado, preguntad dónde se almacena la clave.

Creo que este tweet que vi el otro día ejemplifica perfectamente lo que digo.

En fin, esto que parece algo simple me he sorprendido de verlo recientemente en varias ocasiones, así que, ¡tened cuidado con el auto-cifrado!

Siempre le he tenido ganas a los terminales públicos en general. Tal y como están pensados los sistemas operativos es complicado hacer un sistema de accceso público que impida totalmente escapar de las limitadas funciones que presenta.

En IKEA hay varios terminales con diversas funcionalidades y siempre que voy me da por echar un ojillo a alguno de ellos a ver si consigo escaparme de la interfaz. Si recordáis, hace tiempo conseguí navegar desde un terminal de consulta.

Esta vez le ha tocado el turno al terminal de encuesta de opinión.

Este terminal te muestra un navegador en modo pantalla completa en el que, supuestamente, sólo puedes marcar lo que opinas en una encuesta y escribir observaciones en un TEXTAREA. El terminal tiene un teclado completo y un ratón, cosa muy peligrosa.

Probando, todas las combinaciones de teclas que conozco de Windows estaban desactivadas excepto Alt-Tab, que nos deja ver el nombre del software empleado que parece llamarse OneBrowser. Aunque no he encontrado nada por Internet al respecto en una búsqueda rápida.

Probé a rellenar el TEXTAREA con un texto muy largo a ver si eso provocaba algún error en la aplicación pero no parece que tuviera efecto. Sin embargo, si terminas de rellenar el formulario aparece una página de agradecimiento con Ana. Ana parece ser un objeto Flash que te deja pulsar con el botón derecho y ver las típicas opciones de Flash.

Pulsando en ‘Print…’ obtenemos un cuadro de ‘Guardar como’ para un fichero .XPS ya que no parece que tengan configurada ninguna impresora. Y aquí es donde empieza la fiesta.

Desde este cuadro, que es un navegador al completo, no parece posible acceder a ficheros locales (sólo la unidad de CD) pero sí es posible ver equipos de red y carpetas compartidas.

Usando la ‘Vista previa’ o el ‘Abrir con’ es posible visualizar los documentos de estas carpetas. No llegué a probar si era posible navegar (seguramente no) ni a lanzar un interprete de comandos (que lo veo jodido) aunque teniendo la posibilidad de ejecutar aplicaciones seguro que algo se puede hacer.

Además, en este caso hay todo el tiempo del mundo porque yo todavía no he visto a nadie rellenar la hojita, no como en otros sitios donde no para de llegar gente y te da cosa.

Pese a que la configuración segura en los sistemas de IKEA es muy buena, no sé por qué razón el sistema no sólo se encuentra conectado al dominio sino que tiene acceso a sistemas y carpetas de red.

Quizá sea por tener el sistema actualizado o controlado desde el dominio. Pero esto tiene un riesgo mayor cuando se consigue escapar del modo quiosco.

En fin, mucho cuidadito con cómo diseñáis un sistema de acceso público y comprobadlo todo, aporread el teclado, pinchad en todos los sitios y aseguraos que no hay forma de escapar y, si alguien lo consigue, que no tenga mucho más que hacer.

Por cierto, al lado de uno de estos terminales me encontré un Ethernet Exposed. Por supuesto, no pude probarlo… ¿dará link?

El otro día estaba haciendo una auditoria de una aplicación web que no tenía medidas anti-CSRF me encontré que era vulnerable a XSS almacenado si se subía un fichero que incluía HTML en un campo que luego se le mostraba al usuario.

Era gracioso porque, al no permitir paréntesis, no podías ejecutar nada en javascript fácilmente. Por lo que me decidí por insertar un EMBED a un Flash que ejecutaba el javascript :).

Pero no es de eso de lo que quería hablaros. Resulta que el problema es ¿cómo haces que el usuario suba el fichero? Pues, al no tener protección contra CSRF, uno puede pensar que sería posible si se consigue que el usuario se conecte a una página que controlamos nosotros en la que le hacemos solicitar la URL de subida de ficheros y le enganchamos nuestro perverso fichero.

Por obra y gracia del CSRF, la sesión del usuario se utilizará para la operación y él ni se dará cuenta. El problema viene cuando resulta que los navegadores han restringido precisamente la posibilidad de incluir un fichero en un FORM. Debido a cuestiones de seguridad.

Si intentas asignar el VALUE a un campo INPUT TYPE=”file” lo que obtienes depende del navegador. En Chrome se envía vacío y en Firefox da un error de seguridad, por ejemplo.

Pero vamos, que es necesaria la intervención manual del usuario para que use el diálogo de seleccionar fichero.

Pero como podrás imaginar, no está todo perdido. Buscando y buscando, me encontré con este artículo donde explica como hacerlo de una forma distinta. Pero antes de entrar en detalle, un poquito de SOP.

Ya sabéis lo que es SOP, ¿verdad? Si no, a leerse el libro de la bruja ahora mismo. Bueno, en esencia y muy simplificado viene a decir que los scripts que proviene de un origen, únicamente pueden interaccionar con ese origen. Entendiendo origen como el dominio desde el que se han cargado, más o menos.

Ya que, de lo contrario, un script malicioso en una página podría hacer barbaridades en tu nombre en cualquier otra página y esto sería el fin de todo.

En particular, las peticiones AJAX (XMLHttpRequest o XHR) que se realizan desde un script únicamente pueden salir hacia el origen del que proviene el script.

Ahora bien, resulta que hay gente que ‘necesita’ hacer peticiones entre dominios. Por lo que se han inventado varias técnicas para permitirlo de forma relativamente controlada.

Uno de esos mecanismos es Cross-Origin Resource Sharing (CORS). En este mecanismo, el servidor web le dice al navegador para qué dominios permite que se viole el SOP mediante cabeceras HTTP.

Y el navegador web envía solicitudes XHR incluyendo la cabecera Origin: en la que indica el origen para que el servidor de aplicación discrimine si acepto o no la solicitud. Pero… ¿qué pasa si la aplicación no entiende de CORS?

Pues por extraño que parezca algunos navegadores te dejan hacer cualquier petición XHR a cualquier dominio, añadiendo felizmente la cabecera Origin:. Eso sí, la vuelta no la puedes leer desde tu script a menos que el servidor envíe las cabeceras CORS adecuadas (que no lo va a hacer, claro).

Esto es precisamente lo que necesitamos para subir nuestro fichero fraudulento a una web que no entienda CORS (¿y tú conoces alguna que lo haga en tu entorno cercano?).

Por lo tanto, para subir un fichero mediante CSRF, en la página maliciosa creas la solicitud XHR que simula una solicitud HTTP que incluye las cabeceras y contenido de una subida de fichero (añades .withCredentials=”true” para que envíe las cookies del sitio)  y la envías a la URL de subida de ficheros.

Echad un ojo a los ejemplos (víctima, atacante) del artículo que citaba si queréis ver cómo se hace.

La triste realidad es que todo el mundo tiene vulnerabilidades de seguridad. Algunas más fáciles de descubrir, otras más difíciles. Algunas más fáciles de arreglar y otras más difíciles.

En el conocimiento y tratamiento de vulnerabilidades ocurren procesos psicológicos interesantes. Para empezar, aunque todo el mundo te diga que está muy interesado en la seguridad y en conocer sus vulnerabilidades. Sin embargo, a nadie le gusta que se conozcan sus debilidades, por lo que no siempre muestran alegría con los resultados.

Otro interesante efecto es ver la solución de las vulnerabilidades como algo complejo cuando, la mayor parte de las veces, no lo es tanto. Incluso las de desarrollo, que parecen las más complejas, tampoco es para tanto.

Por último, ya sea por falta de tiempo, recursos, conocimientos, dinero o prioridades puede ocurrir que te dé igual qué vulnerabilidades tengas porque no las vas a arreglar, de todas formas.

En definitiva, el viejo dicho de que el conocimiento os hará libres no siempre aplica y es tristemente descorazonador ver que realmente ocurre lo contrario.

He pretendido reflejar esta situación en este nuevo lunes desmotivador que, tras un cierto periodo de ausencia, vuelve para recordarnos a todos lo vulnerable que somos, queramos saberlo o no.

¿Qué es peor, la ignorancia o la indiferencia? ¿Quién lo sabe? ¿A quién le importa?

La sensación de seguridad es algo psicológico que, en muchos casos, viene erróneamente dada por la ignorancia o la indiferencia hacia este tema.

Para aquellas personas que, además, son responsables de sistemas de información, he hecho un pequeño checklist en el que resumo algunas actividades que considero que son esenciales para no sentirse completamente inseguro.

Por lo tanto, no estas seguro si…

  • Crees que no eres un objetivo para nadie
  • Nunca has sufrido una auditoría
  • Cualquiera puede saber más que tú de tus entornos con un simple nmap
  • Crees que tu [cortafuegos|WAF|IDS/IPS] te va a servir de algo
  • Te fías de tus usuarios, administradores y desarrolladores
  • Ni tú ni nadie mira los logs de tus sistemas y aplicaciones
  • Pones en producción servicios cuya seguridad no ha analizado nadie
  • Crees que el [documento de seguridad|plan de seguridad|plan de adecuación|etc.] desde tu estantería te protege automágicamente
  • Piensas que únicamente el (poco) personal de seguridad es responsable de la seguridad de tu infraestructura
  • Te sientes seguro

Por supuesto esto no es un listado completo, ¿qué más añadirías?

Recientemente he tenido ocasión de analizar redes de clientes donde había expuestas multitud de impresoras de diversas marcas y he estado investigando un poco sobre el tema. Os comento brevemente lo que he averiguado sobre la configuración habitual de estos equipos y sus implicaciones para la seguridad de la organización.

Aunque digo impresoras, realmente, en algunos casos se trata de equipos multifunción que hacen no sólo de impresora sino también de fax, escáner, fotocopiadora, máquina de café, sandwichera y picadora.

Servicios

Antes de nada, veamos qué ofrece una impresora cualquiera.

Como podéis ver, hay un conjunto considerable de servicios ofrecidos para diferentes métodos de impresión y de acceso. Como yo no soy un experto en impresoras me centraré en los protocolos que sí conozco y son los que me interesan:

  • ftp: acceso para la subida directa de ficheros que serán imprimidos por la impresora.
  • telnet: interfaz de configuración en modo texto. Se trata de una pequeña shell con los parámetros de configuración y consulta de estado.
  • http/https: interfaz web de configuración. Son los mismos parámetros que en la interfaz telnet pero para quien prefiera el navegador.
Sobre el acceso FTP es interesante conocer que algunas impresoras permiten realizar escaneos de puertos mediante el uso de la directiva PORT de las impresoras. Con el script ftp-bounce de nmap podemos identificar si un servidor FTP lo permite.

En el caso de que el servidor lo soporte, es posible, mediante nmap, realizar un escaneo empleando el servidor FTP: nmap -b servidor_ftp servidor_destino

Acceso

Normalmente, las impresoras te dejan ver su configuración sin necesidad de disponer de credenciales de acceso. Sin embargo, para configurarlas es posible establecer una contraseña de administración, aunque la experiencia me dice que no es común cambiar la que traiga por defecto, si es que traen.

Cuando encontréis una impresora con contraseña, buscad en vuestra lista de contraseñas por defecto favorita y probad a ver si es que no han cambiado la contraseña por defecto.

Por ejemplo, algunas de las que me he encontrado recientemente:

  • Impresoras HP: no suelen tener contraseña
  • Impresoras Kónica/Minolta: la contraseña de administración por defecto es 12345678
  • Impresoras Canon: normalmente sin contraseña
  • Impresoras Ricoh: la contraseña del usuario admin está en blanco por defecto
  • Impresoras Brother: las credenciales de administración son ‘admin/access’
  • Impresoras Kyocera: normalmente sin contraseña
  • Impresoras EPSON: normalmente sin contraseña
  • Impresoras OKI: la contraseña del usuario admin son los 6 últimos dígitos de la MAC (que puedes obtener sin necesidad de autenticación)
  • Impresoras Lexmark: normalmente sin contraseña
  • Impresoras Printronix: la contraseña del usuario admin está en blanco

Esto es mi experiencia reciente en los modelos que he encontrado, para más información véase el manual del modelo correspondiente o las susodichas listas de contraseñas por defecto.

Registro

A través de la interfaz de configuración es posible acceder al registro de impresión donde, si tenemos suerte, veremos nombres de usuario, otros equipos de red y los nombres de los documentos imprimidos.

En el caso particular de las impresoras Ricoh, que disponen de un Document Server, podemos ver algunos documentos almacenados (como imágenes) en la propia impresora.

Posibilidades

Bueno, pues ahora que puedo acceder a administrar una impresora… ¿qué puedo hacer que sea relevante desde el punto de vista de seguridad? O, dicho de otro modo, ¿cómo puedo putear? Os adjunto un listado de posibles acciones sencillas con las que dar por culete al que se ha dejado la impresora sin proteger:

La primera cosa que se puede hacer es, por supuesto, imprimir. Esto puede ser una chorrada evidente. Pero considerad que hay veces que la impresora está gestionada por un servidor de impresión con software dedicado a controlar (restringir, registrar) la impresión. Si la impresora permite imprimir por jetdirect, ftp o desde la propia interfaz web… probablemente nos saltemos estas restricciones y registros.

Ahora bien, consideremos que, realmente, podemos imprimir cualquier cosa, no sólo documentos. Haciendo un volcado de nuestro disco duro a la impresora nos aseguramos una denegación de servicio y un gasto de papel considerable.

Por otro lado, dado que la mayor parte de las impresoras no tienen asignada la contraseña de administrador, podemos asignar una contraseña y forzar a que tengan que volver a ‘factory default’ para reconfigurarla. Si esto lo hacemos en un número interesante de impresoras podemos incurrir en un coste interesante en mantenimiento y pérdida de funcionalidad.

Modificando la configuración de los parámetros de impresión podemos volver loco a más de uno, que pensará que se trata de una mala configuración del Word.

Una cosa que no he probado nunca es a pedir suministros a través de la propia impresora. En algunos modelos, existe la opción de enviar un informe de estado de la impresora y solicitar suministros… De hacerlo, no sé qué pasaría.

Si queremos que no se pueda imprimir, siempre podemos cambiar la configuración de red de la impresora o suprimir  servicios de impresión.

Pero lo que me parece más divertido es la posibilidad de modificar la configuración de red de la impresora para interferir con otros sistemas. Por ejemplo, podemos ponerle a la impresora la dirección IP del router por defecto, provocando un conflicto de direcciones IP que afectará a los que se encuentren cerca. O ponerle la dirección IP de cualquier otro servicio al que queramos afectar. Me imagino cuándo y cómo se darán cuenta de que se trata de la impresora.

Conclusiones

La verdad es que todo esto viene porque un cliente en particular tiene un conjunto considerable de impresoras expuestas a Internet, por lo que el riesgo es mucho mayor que en otros casos. Por lo tanto, la primera conclusión, visto lo visto, es no exponer las impresoras a Internet (no puedo pensar en ninguna razón para hacerlo).

La segunda conclusión es que es bastante recomendable ponerle una contraseña a la impresora para administración o sustituir las que vengan por defecto. Las contraseñas asignadas pueden ser almacenadas en algún repositorio cifrado para que la comparta el personal de microinformática, por ejemplo.

Por aquello de reducir la superficie de exposición y evitar que exploten vulnerabilidades en servicios que no usas, merece la pena perder el tiempo en analizar la funcionalidad de la impresora y reducir los servicios expuestos que no sean necesarios.

Respecto a la situación de las impresoras, es práctica habitual que se encuentren en el mismo segmento de red de los usuarios, aunque no hay nada que impida ubicarlas en su propio segmento de red con reglas del cortafuegos para evitar que usuarios no autorizados accedan a servicios expuestos que no sean necesarios (en el caso de que no se puedan desactivar o para curarse en salud).

Por otro lado, no está de más monitorizar la impresora. La mayor parte tienen la posibilidad de monitorización mediante SNMP, así que no cuesta nada añadirlas a nuestro Nagios o software similar y monitorizar su estado. Algunas incluso soportan syslog.

También conviene hacer una copia de la configuración por si se desconfigura de forma misteriosa, reducimos el tiempo de volver a ponerla operativa.

En fin, quizá estoy siendo un poco paranoico en este sentido. Aunque desde luego exponer tus impresoras a Internet está totalmente fuera de lugar, normalmente nadie en la red interna suele andar puteando… pero… yo me quedo más tranquilo si tengo todos los cacharros controlados, ¿y tú?

Referencias

Además de lo citado anteriormente, hay otros problemas que podrían provocar denegación de servicio e incluso ejecución de código. Para más información podéis leer este artículo de IronGeek o esta presentación de Andrei Costin.

Por último, si todo esto no te convence, siempre puedes hacer lo que hicieron los protagonistas de ‘Trabajo basura’ y desahogarte de todas las veces que la puta impresora te hizo la vida imposible.

El otro día por azar encontré una Wi-Fi abierta cuyo ESSID era ‘AirProjector’ o algo similar. Tuve curiosidad y me conecté para ver de qué se trataba.

Resulta que era un sistema de proyección a través de wireless de la empresa Optoma. Mediante un software que te puedes descargar del propio proyector todos los participantes en una reunión pueden proyectar en la pantalla.

Una vez tienes IP, si intentas navegar hacia cualquier sitio te redirige a la dirección IP 192.168.100.10 donde te presenta una página con diversas opciones:

  • Descarga del software para usar el proyector
  • Control de la conferencia, donde se indican los parámetros de cada sesión
  • Administración

Pinchando en administración me encontré con una pantalla de login:

  • Usuario: admin (ya relleno)
  • Contraseña… contraseña… una palabra de 5 letras que rima por admin… ¡ya lo tengo! admin.

Pues sí. Me pregunto cuando dejará de funcionar esto del admin/admin.

En definitiva, en la interfaz de administración puedes cambiar los típicos parámetros de red, las contraseñas, actualizar el firmware y alguna cosa más.

Aunque la contraseña no fuese esa el peligro que tiene un sistema de este tipo abierto es patente. Simplemente suplantando al equipo para la descarga de software o atacando al resto de clientes conectados o un largo etc.

Respecto a la Wi-Fi, sólo soporta WEP por lo que parece fácilmente explotable.

En fin, tened mucho cuidadito con estas moderneces que luego pasa lo que pasa.

Siempre que empiezo alguna auditoría de seguridad resuena en mi mente el Private Investigations de Dire Straits. Esta canción retrata la investigación de un detective privado y cómo lo que descubre le va afectando emocionalmente.

Como supongo que muchos de los que trabajamos en seguridad nos sentimos identificados con esto, he hecho algunas leves modificaciones en la letra de la canción para incluir elementos de seguridad. Os la dejo aquí:

It’s a mystery to me – the game commences
For the usual fee – plus expenses
Confidential information – it’s in a database
This is my investigation – It will last a few days
I go checking out the reports – digging DNS
You get to know all tools in this line of work
Unhardened services – there’s always an excuse for it
And when I find the reason I still can’t get used to it
And what have you got at the end of the day?
What have you got to take away?
A couple of XSS and a new set of lies
Blind SQL injection and a pain behind the eyes
Scarred for life – no compensation
Security investigations

Os dejo un vídeo de la canción para que podáis escucharla…

Esta semana he vuelto a ver una práctica habitual en determinadas organizaciones respecto al acceso inalámbrico. Tarde o temprano, siempre hay alguna necesidad para tener una red inalámbrica, principalmente para movilidad del personal o para conexión de externos y visitantes (salas de reunión, salones de actos, recepciones, etc.).

En estos casos, la única necesidad es la navegación por Internet de los que se conectan. Pero nos encontramos con dos condiciones de contorno interesantes y opuestas

  • Los ‘visitantes’ tienen que poder acceder fácilmente, sin demasiadas trabas
  • Debe reducirse el riesgo de intrusión en las redes de la organización a través del acceso inalámbrico

En estos casos, ‘la mejor solución‘ es contratar un ADSL adicional y mantenerlo separado del resto de redes de la organización. Entonces, la red inalámbrica se deja abierta (sin autenticación ni trazabilidad) porque, al no estar conectada a la red de la organizacion, ya no hay peligro, ¿verdad?

Bueno, obviamente, sigue existiendo riesgo. Tal y como funciona TCP/IP, si consigues estar en la misma subred que ‘una víctima’, es posible tener éxito en ataques sencillos y con gran impacto (desde simplemente análisis de tráfico a suplantación de equipos, del DNS e, incluso, intrusión aprovechando vulnerabilidades del equipo).

Además, es mucho más fácil suplantar al propio AP si no se utiliza ningún tipo de cifrado.

Si consideramos que las ‘víctimas’ pueden ser miembros de la organización que están en salas de reunión, salones de actos, bibliotecas, etc. pues el riesgo tiene peor pinta.

Por no hablar de la posibilidad de que se realicen ‘malas acciones’ desde el ADSL que está a tu nombre.

En fin, no quiero tampoco extenderme mucho con este tema, es sólo para hacer notar que el hecho de que una red no se encuentre conectada a la organización no implica mágicamente que ya no haga falta mantener unos niveles mínimos de seguridad.

Y aunque sea engorroso, es siempre mejor que, quién se quiera conectar, tenga que pedirlo. Dejar una red (inalámbrica o no) abierta suele ser una mala idea.