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.
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.
Vamos a ver si animamos un poco esto que está algo decaído. Y nada mejor que un quiosco inseguro, que siempre es muy gracioso.
Desde lo del IKEA le tengo ganas a cualquier quiosco que pillo y siempre intento meterles mano. He pillado alguno más que no puedo contar porque son de clientes (algunos pagados y otros de buen rollo).
En particular, este que os cuento hoy ha sucedido esta mañana en unas oficinas de un organismo nacional del que prefiero mantener el anonimato.
El quiosco en cuestión está en la puerta para expedir los tiques de turno para ser atendido. Nada más verlo te das cuenta de que es un Explorer con una web.
Pues la cosa es que dándole varias veces en la esquina con el dedo así rápido conseguimos sacar el menú de imágenes del Explorer. A partir de ahí, es posible acceder al navegador de ficheros pulsando el último icono (que te lleva a ‘mis imágenes’), que te muestra también la barra de Windows.
Aquí os dejo una foto del hecho. Observad que se trata de Windows XP con servicios Novell y, al menos, tiene instalado el MySQL -Front. Este software es gracioso porque, según su descripción es:
MySQL-Front es una sencilla pero útil aplicación diseñada especialmente para desarrolladores que trabajan con MySQL.
Desde el primer momento en el que empiezas a usar este administrador descubres su facilidad para obtener información sobre las bases de datos, tanto de sus tablas como de su estructura y contenido.
Todo ello desde un interfaz muy intuitivo que recuerda bastante a la estructura del Explorador de Windows.
Con MySQL-Front se pueden realizar acciones básicas como añadir, borrar o modificar tablas, campos, registros, y además:
No parece muy necesario en un quiosco… Lo que me sorprende también es que tiene un software de quiosco… pero vamos, no parece ser muy efectivo contra acceso al sistema operativo.
Por cierto que, os estaréis preguntando… ¿pero tenia conexión a Internet? ¿Se podía acceder a otros equipos del organismo? ¿Qué privilegios tenía vuestro usuario? ¿Era parte del dominio? ¿Presume un pájaro cuando vuela? ¿Ha visto usted algún marciano?
Pues la verdad es que… ni puta idea. Lo primero es que el cacharro no tiene teclado físico. Así que por aquél entonces no sabía como lanzar uno virtual (parece que Windows XP trae un ‘on screen keyboard’ que puede lanzarse mediante el comando OSK).
Y lo segundo es que no paraba de entrar gente a por su turno y así no había manera de probar nada.
Por lo tanto, si vuelvo a ir ya os contaré, siempre y cuando no esté la cosa saturada de peña, que si no…
Para terminar, un poco de moralina. Y es que no se pueden tener quioscos así desprotegidos porque afectan a la seguridad de toda la organización y, en muchos casos, es trivial saltarse la protección del ‘modo quiosco’.
Y en este caso en concreto, ¿de verdad es necesaria una página web y un windows XP para cuatro botones que escupen un turno secuencial?
.
