Yo, Bicho.

Algunos me llaman Kido, otros Disken, aunque puede que el nombre que me haya hecho más popular sea Conficker. En realidad no importa, sólo son nombres que me dan aquellos que me buscan para destruirme. Mi auténtico nombre es algo que, como mi creador, permanece oculto.

Soy un bicho, y esta es mi historia.

Nací hace algunos meses en un garaje de algún lugar del mundo, tras bastantes horas de esfuerzo. Allí mi creador me explicó lo que sería mi misión, y me transmitió el secreto que me permitiría avanzar entre los enemigos. “Busca el 445” me dijo, ese era el camino.

Una vez en la red, me apresuré a buscar ese 445 que me iba a permitir explorar este mundo que se abría ante mi. Desgraciadamente hoy en día los 445 no se exhiben así como así, sino que se encuentran bien guardaditos, al menos de puertas hacia fuera. Tenía que haber otra manera de pasar esas malditas puertas. Tras un par de vueltas a la cabeza y un par de copas en el bar de Blaster (sí, ese que montó tras retirarse) conocí a un bicho que aseguraba conocer el secreto para que Internet Explorer le abriera las puertas. No tenía nada que perder, así que decidí colaborar con él. Nos metimos en un disfraz de JPG y me dijo que me estuviera quieto y callado, y nos apresuramos a reenviarnos a tantos buzones de correo como pudieramos, con la esperanza de que alguno de ellos no se percatara de la trampa hasta que fuera demasiado tarde.

Pasadas unas cuantas horas y visitar algunos usuarios domésticos, alguien nos descarga desde su buzón de GMail, y al abrir la imagen… mi compañero cumple su palabra, me saca del disfraz y me libera para que prosiga con mi misión.

Miro a mi alrededor y efectivamente he pasado una de las puertas, estoy en un equipo edición profesional, y me pregunto como es posible que en estas empresas permitan que los usuarios consulten el correo de GMail o cualquier otro webmail público sin ningún tipo de restricción. Mejor para mí, ya estoy dentro…

Desde aquí puedo ver un montón de 445’s de equipos que tampoco tienen activados los cortafuegos personales. Me pregunto si tiene alguna utilidad que entre equipos de usuario este puerto sea accesible, además de servirme a mi para mis planes, o si la palabra “segmentación” y “filtrado” le dice algo a esta gente. Intento avanzar de equipo a equipo, consiguiéndolo en la mayor parte de ellos; a los usuarios (y a algunos administradores) no les gusta eso de aplicar parches de seguridad, de lo contrario ni siquiera hubiera podido pasar del Internet Explorer. El caso es que tengo un montón de equipos en los que andar a mis anchas.

En muchos de ellos están también aquellos que buscan destruirme, pero no me conocen, no saben cómo soy, y somos demasiados procesos como para que se den cuenta del tipo de acciones que estoy realizando.
Me copio en disco, bien escondido, y también en tantos dispositivos USB como encuentro, así si soy destruido mientras prosigo con mi misión, otro ocupará mi lugar.

Parece que finalmente he sido descubierto. Tanto andar a mis anchas de un lado para otro hace que todo vaya más lento; quizá la próxima vez debería ser más sigiloso. Han venido unos tipos y han capturado a varios de los nuestros, me preocupa que puedan interrogarlos y conseguir averiguar todo lo que saben sobre la misión. Mis peores temores se han hecho realidad, estos tipos de antes han debido avisar a aquellos que quieren destruirnos, porque ahora de repente nos reconocen, y saben cómo y dónde nos escondemos. Intentamos huir pero el 445 ya no me muestra el camino, no tengo escapatoria. Poco a poco, todos los compañeros caen, tras varios días de intensa batalla.

Parece que mi corta vida ha llegado a su fin, pero esto no va a quedar así. Volveré… Y estaré siempre un paso por delante de ti.

Copias de Seguridad: TSM

Con este post pretendo crear una serie de entradas relacionadas con las copias de seguridad, que estoy completamente convencido que es uno de los pilares básicos en la seguridad de cualquier organización. Hablaremos de los distintos software de backups, de las diversas tecnologías hardware, de las copias Offsite, de los backups DE sistemas virtualizados y de los backups EN sistemas virtualizados (Virtual Tape Library). En fin, haremos un pequeño repaso de cómo está actualmente este mundo y espero que sirva al lector para reflexionar y analizar si su sistema de backups está funcionando como debería.

He perdido la cuenta de las veces que una copia de seguridad ha salvado mi puesto de trabajo. La verdad es que gran parte de mi vida laboral ha estado bastante relacionada con los backups, llevo siendo “responsable/encargado/enmarronado” de este tema desde hace unos 15 años y en varias empresas. Empiezo a pensar que yo me lo busco…..

Cierto es también que es un tema que me apasiona, pero es muy sufrido. Hay un gran trabajo de análisis, configuración y optimización de toda la infraestructura hasta que el sistema queda medianamente estable, y aun así nunca te sentirás tranquilo. Pero, como en casi todo este sector, el éxito está en minimizar lo máximo posible lo que yo llamo el “Efecto Uy“. ¿Quién no ha vivido alguna vez un… “¡Uy, pues la copia se hizo!”, “Uy, ¿cómo es que no se hace copia de este directorio?” ?

De todos los software de copias de seguridad que he tocado y créanme, son muchos, me quedo con el TSM (Tivoli Storage Manager) de IBM. Por experiencia, es el que más reduce dicho efecto y el que optimiza al máximo los recursos. Cierto es también que está pensado para un entorno de Backup medio-grande, y que las licencias no son nada baratas. Eso sí, cuando está completamente desplegado y funcionando empiezas a descansar por las noches.

Existen cinco características de este sistema que yo destacaría frente a otros productos, que son:

— Usa un “pool” de disco intermedio para las copias de los nodos, es decir, no copia directamente a cinta sino que va almacenando en disco los datos. Cuando este pool de disco llega a un límite, va volcando información a cinta mientras sigue llenándose el disco con más copias. Este es un sistema que ahorra muchísimo tiempo.

— Siempre hace copias incrementales. El sistema sólo hace una copia total la primera vez, a partir de ahí se basa en incrementales y en versiones de archivos que caducan según se parametrice. Esta característica junto con la del pool de disco logra que en unas horas se puedan hacer copias de decenas de nodos.

— Dispone de un módulo de Gestión de Recuperación de Desastres, donde la misma aplicación (si previamente le has enseñado bien) te dirá lo que tienes que hacer y cómo lo tienes que hacer en una situación de contingencia.

— La gestión de los cartuchos es automática. Olvídate de etiquetar cartuchos y saber qué tipo de copias contiene cada uno. Para el TSM no hay cartuchos sino un espacio de almacenamiento que la propia aplicación fragmenta según necesidades en bloques que copia en los cartuchos. Desde el punto de vista de seguridad esto es fundamental, puesto que no hay forma de extraer datos de un cartucho por separado, no sirve de nada si no tienes la Base de Datos de la aplicación.

— Los nodos son independientes del servidor. Aquí, es el cliente quien se pone en contacto con el servidor y le manda los archivos a copiar. Tiene dos ventajas, la primera es que reparte la carga de proceso entre todas las máquinas y la segunda es que es muy difícil que todos los servicios de planificación de todos los nodos fallen en el mismo momento. Es decir, la probabilidad que una noche fallen todas las copias es casi nula.

Por supuesto que la mayoría de aplicaciones de Backup del mercado son bastante válidas: el Symantec NetBackup y BackupExec, el Acronis, el ARC, etc. Lo principal es elegir el adecuado a la infraestructura que se disponga (número de servidores, tipo de red, tipo de servidor, SAN, NAS, cantidad de datos, ventana disponible,…) y, por supuesto, una vez se ha elegido la aplicación hay que exprimirla a fondo, puesto que hay decenas de características que no usamos en nuestras aplicaciones por desconocimiento de la misma y que nos podrían ahorrar muchos disgustos o una inmediata actualización del currículo…

* * *

(N.d.E.) La encuesta de esta semana, y a pesar de mi escasa inventiva un jueves a estas horas de la tarde, está relacionada con la privacidad en las redes sociales, y recoge algunas críticas y opiniones que éstas despiertan cuando se habla del tema de los datos de carácter personal. Espero que les resulte interesante:

[poll id=”8″]

En relación con la encuesta de la semana pasada, aunque hubo poca participación, parece que los usuarios se decantan por admitir que la basura que generan es suya únicamente dentro de su casa, aunque rebuscar en ella fuera despierte algunas reticencias de privacidad. Los resultados son los siguientes:

[poll id=”7″]

Nada más; pasen un buen fin de semana y si deciden pasarse por Valencia, tráiganse puestas las ganas de fiesta.

¿Romper WPA? (¿Aun estamos con esas?)

No sé si es debido al par de entradas que Roberto publicó hace unos meses poniendo los puntos sobre las íes en relación con la noticia lanzada por Elcomsoft (en la que afirmaba que era posible romper WPA/WPA2 100 veces más rápido utilizando el poder de procesamiento de GPUs y su producto de recuperación de contraseñas), pero durante los cuatro últimos meses más de 1200 usuarios han llegado a este blog buscando cómo crackear/hackear/romper las claves/contraseñas/hash de wpa/wpa2.

Y no me extraña en absoluto, a la vista de lo que se publica en las revistas de divulgación informática. En concreto, el otro día fui a parar a un artículo de Noé Soriano (director de Comunicación y Marketing de ConsultorPC) en PC Actual, titulado ¿Ya no son seguras las redes WiFi?, que contiene unas afirmaciones que me gustaría comentar. En concreto, todo se resume en la siguiente frase:

Cabe preguntarse si son justas las estrictas normas de protección de datos que se les está exigiendo actualmente a las empresas y organismos, cuando el principal estándar de encriptación comercializado [WPA/WPA2] es perfectamente accesible en pocas horas con unas cuantas tarjetas gráficas en paralelo.
[…]
Este razonamiento, o sistema de medición de la seguridad de las encriptaciones, que cumplía WPA en 1995 cuando se presentó, no parece muy válido actualmente si tenemos en cuenta que en sólo trece años la tecnología de procesamiento ha avanzado tanto como para echarlo abajo con un sistema de ámbito doméstico.

En primer lugar, hay que destacar que ni la LOPD ni el RDLOPD exigen tales “estrictas” normas de protección. Se habla de registros y control de accesos, de cifrado, de copias de seguridad, de caducidad de contraseñas, de seguridad física, todas ellas medidas de seguridad más que razonables, habida cuenta del estado de la tecnología. No cabe, por tanto, relacionar un aspecto con otro, teniendo en cuenta además que la LOPD no es un capricho legislativo sino la aplicación de un derecho de las personas. Ni la ley ni su reglamento requieren la instalación de sofisticados programas, ni dispositivos extraños ultrasofisticados; en general el cumplimiento de las medidas técnicas es bastante sencillo, y son las medidas de carácter organizativo las que son más complicadas de cumplir.

En segundo lugar, la afirmación de que WPA y WPA2 son accesibles en pocas horas con unas cuantas tarjetas en paralelo o con un sistema doméstico es ciertamente gratuita y muy aventurada. En mi opinión, se trata básicamente de un error de concepto. Destaquemos varios datos:

(a) Los procesadores actuales mas potentes (utilizando el algoritmo de Aircrack) pueden a lo sumo barrer 400 palabras por segundo, si no disponemos de la tabla precomputada. Si multiplicamos por 100, tal y como plantea Elcomsoft, tenemos 40.000 palabras por segundo.

(b) Si disponemos de la tabla precomputada, la cual depende del SSID, y por lo tanto no siempre está lista para ser utilizada, podemos incrementar esa velocidad hasta 40.000 palabras por segundo. Si multiplicamos por 100, tal y como plantea Elcomsoft, tenemos 4.000.000 palabras por segundo.

(c) La longitud mínima de una PSK de WPA o WPA2 es de 8 caracteres y el alfabeto manejado es de [A-Za-z0-9Sym32], tenemos (29+29+10+32)8 = 10.000.000.000.000.000 posibles palabras del lenguaje. En el caso medio, por tanto, tenemos 5.000.000.000.000.000 de palabras.

Con estos datos, sí, si disponen ustedes de la tabla precomputada, la PSK es parte de un diccionario, y tienen suerte, efectivamente en unas cuantas horas podrán ustedes explotar la clave de la red Wifi. Y probablemente no les haga falta tirar de Elcomsoft ni de GPUs en paralelo. Francamente, eso pasa con prácticamente cualquier algoritmo de cifrado sobre el que se aplique fuerza bruta, y no dice demasiado sobre su fortaleza. Elijan ustedes ‘patata’ como contraseña de su cuenta de correo y una persona avispada con un poco de vista y algo de suerte la adivinará en cuestión de segundos. ¿Nos da eso alguna información del algoritmo utilizado para cifrar dicha clave? No. Lo único que nos dice es que la persona que eligió ‘patata’ como contraseña no estaba siguiendo buenas prácticas. Y eso es todo.

Escojan una PSK de 12, 16 o 20 letras, números y símbolos, la apuntan en un papel y la pegan con celo debajo del router (entorno doméstico, por supuesto; en el corporativo, en el aplicativo que utilicen para la gestión de contraseñas). Después de todo, no es algo que vayan a necesitar todos los días. La SSID, cojan la que quieran, pero si además se inventan un nombre poco común, aun mejor. Pueden estar seguros de que, hoy por hoy, y con estas simples medidas, su Wifi estará a salvo de cualquier ataque de fuerza bruta o diccionario mediante GPUs… y de que esta es la última entrada sobre el tema en cuestión.

José María tiene una estupenda entrada en su blog dónde indica todo lo que hay que saber para configurar de manera segura tu router.

Lumension Device ControlTM: Administración de Dispositivos Móviles/Extraíbles

En esta entrada me gustaría comentar un software de la compañía Lumension (antes SecureWave) denominado Lumension Device ControlTM (antes Sanctuary), que forma parte de una amplia gama de productos orientados a la seguridad activa, y que resulta muy útil a la hora de administrar el uso de dispositivos móviles en cualquier empresa y controlar el tráfico de información confidencial.

Esta aplicación nos permite discriminar qué usuarios y/o equipos pueden ejecutar contenidos en dispositivos de almacenamiento como memorias USB, Pda’s, Blackberry, etc. Tiene también una peculiaridad bastante interesante que es la de llevar un registro de todo lo que se copia, mueve o se borra de cualquier dispositivo externo, aspecto importantísimo a la hora de controlar qué datos confidenciales o de uso interno se están utilizando y evitar así que dicha información se transmita sin control alguno.

Este aplicativo se implanta de forma muy positiva y sobre todo, de manera muy sencilla y casi transparente a los usuarios. A continuación, se indican una serie de características a tener en cuenta:

1. Fácil instalación y Administración del servidor.

La instalación es bastante sencilla, puesto que sólo hay que configurar el usuario encargado de arrancar el servicio de la aplicación, en nuestro caso el usuario Administrador del Dominio. En lo referente a la Administración, se utilizan dos utilidades: la consola y el distribuidor de paquetes.

a) La consola se utiliza para la administración de políticas, concesión de permisos y el registro de nuevos dispositivos en la red. Su manejo es muy simple, con un único punto, el uso de políticas, que puede resultar más controvertido pero sin llegar a influir en una administración intuitiva.

b) El distribuidor de paquetes se utiliza para enviar a los equipos clientes el agente de comunicación y las directivas aplicadas en el servidor. Sin este agente instalado en las máquinas, el servicio no funciona.

2. Posibilidad de Cifrar tanto dispositivos USB como CD’s/DVD’s.

Al instalar el agente en cualquier máquina, tenemos la posibilidad de aplicar cifrado en todo tipo de dispositivos USB, e incluso CD’s o DVD’s, simplemente utilizando una pequeña aplicación copiada en dichos dispositivos.

3. Posibilidad de registrar toda la información transmitida en los dispositivos móviles.

Esto puede resultar muy útil a la hora de controlar, especialmente, el tránsito de información confidencial o de uso interno, o también, para ver qué usuario/s han accedido a dicha información (cuestión que resulta muy interesante en el ámbito de la LOPD). Es más, no sólo podemos saber qué archivos se están ejecutando, sino incluso abrir esos ficheros y ver las modificaciones que se han hecho.

En conclusión, creo que es una herramienta muy interesante a tener en cuenta, si estamos pensando en llevar a cabo un control de nuestros dispositivos o impedir que ciertos usuarios tengan la posibilidad de guardarla en dispositivos no autorizados.

Evidentemente, sigue habiendo una vía de escape más difícil de controlar que es el correo electrónico, pero con esta aplicación, podemos minimizar la posibilidad de que datos privados o comprometidos circulen a su libre elección.

In-session Phishing

insession.jpgRecientemente ha sido publicado un nuevo vector de ataque de phishing de mayor complejidad que el clásico envío masivo de correos electrónicos, y que podría permitir el robo de credenciales en aplicaciones bancarias, juegos-online, etc. El denominado In-session Phishing se vale de una vulnerabilidad en la mayoría de los navegadores web: Internet Explorer, Firefox, Safari, o Chrome, al hacer uso de ciertas funciones javascript.

Para explotar con éxito este fallo de seguridad es necesario que se den las dos situaciones siguientes:

1. El usuario este autenticado en la aplicación objetivo del robo de credenciales.
2. Un segundo site que alberga cierto código malicioso es visitado por el usuario, mientras en la web objetivo se esta todavía autenticado.

Al parecer el navegador procede a albergar una huella cuando una página web que utiliza ciertas funciones javascript es visitada, funciones muy habituales según sus descubridores, Trusteer. De esta manera es posible desde una segunda página interrogar al cliente con preguntas binarias sobre si se está o no autenticado en un cierto dominio. Si la respuesta es afirmativa, el código malicioso presenta un sencillo pop-up que informa al usuario sobre una falsa caducidad de la sesión y la necesidad de reautenticarse en la aplicación. En ese momento el usuario no percibe ningún comportamiento extraño puesto que hasta el momento confía en que estaba registrado en un site totalmente lícito.

[Read more…]

Ofuscación de la barra de estado en Firefox 3.0.5 / Clickjacking PoC

Pueden comprobar, si miran el código fuente de la prueba de concepto (adjunta debajo), que el enlace del “a href” efectivamente apunta a Google, y que por tanto, al pasar sobre el enlace, la barra de estado muestra la dirección de Google. Tengan cuidado con estas cosas.

https://www.securityartwork.es/PoC_clickjacking.html

Ya no te puedes fiar de nadie…

El año 2008 fue el año de la “vulnerabilidad crítica que pone en compromiso toda la seguridad de Internet”. Hemos visto varios casos de estos, primero la vulnerabilidad del DNS, luego algunas otras vulnerabilidades en los protocolos de enrutamiento, y alguna otra cosa de menor importancia.

En todos ellos, al final, la solución siempre ha sido la misma: apoyarnos en el uso de certificados digitales (clave pública y privada) para garantizar que estamos conectando donde realmente queremos conectar, y que toda la comunicación entre ambos extremos va a permanecer cifrada, no legible e inalterable por agentes externos a nuestra comunicación.

El gran problema del cifrado de comunicaciones mediante certificados es la distribución de las claves públicas, debemos encontrar alguna manera de poder obtener las claves públicas de nuestros sites web preferidos de tal manera que estos no puedan ser alterados, puesto que en ese caso no existiría ningún impedimento para que un intruso creara un certificado falso y nos lo hiciera llegar al realizar contra nosotros un ataque de Man-in-the-Middle.

Para solucionar este problema entraron en juego las CA (Certification Authority). Las autoridades de certificación son entidades a priori confiables por todo el mundo cuya misión es FIRMAR estos certificados digitales. Podriamos decir que son el equivalente a los Notarios en el “mundo real” (que me perdonen los notarios por la comparación), son entidades confiables que se encargan de “dar Fe” de que la persona que ha firmado un documento es quien dice ser. Las CA funcionan igual, disponen de su propia clave pública y su clave privada, y firman con su clave privada los certificados de las entidades que se lo solicitan.

Por poner un ejemplo para que quede la cosa más clara, pongamos que soy el administrador de www.mibanco.es y que he configurado el acceso por HTTPS con mis claves pública y privada para garantizar la seguridad de mis usuarios. Si no acudo a una CA para que firme mi certificado, los usuarios al conectar a mi web recibirán el mensaje de “este certificado no está firmado por una CA de confianza”, exactamente el mismo mensaje que les daría si un intruso realizara un ataque de Man-in-the-Middle (nos dará un certificado firmado por si mismo). Como no queremos que peligre la seguridad de nuestros usuarios, acudimos a una de las CAs reconocidas, la cual verifica nuestra identidad como administrador del host www.mibanco.es y firma con su clave privada nuestro certificado.

Al poner nuestro nuevo certificado firmado en nuestra web, a partir de ahora nuestros usuarios ya dispondrán de la diferencia entre conectar a la web auténtica (certificado firmado por la CA) y conecter a una web que intenta suplantar a la auténtica (certificado firmado por alguien que no es de confianza).

Como podeis imaginar, de esta manera, el problema de distribución de claves públicas de las webs se reduce al problema de distribución de claves públicas de las CAs, pero este es mucho menos debido a que, evidentemente, hay muchas menos CAs reconocidas que sitios webs en Internet. La solución es, sencillamente, incluir las claves públicas de las CAs más relevantes en el propio navegador web.

Después de todas esta no-breve introducción a las CAs, volvemos al problema que nos ocupa: ¿Nos fiamos de nuestras CAs?

El pasado 30 de Diciembre, en el 25th Chaos Communication Congress (25C3) en Berlín, un grupo internacional de investigadores (principalmente Estadounidenses, Holandeses y Suizos) anunciaron que habían conseguido explotar la conocida debilidad ante colisiones del algoritmo de Hash MD5 para realizar un ataque real contra la infraestructura de PKIs.

Como ya es sabido desde hace algún tiempo, el algoritmo MD5 es susceptible de presentar colisiones, es decir, es posible encontrar dos textos de entrada diferentes que sin embargo produzcan el mismo Hash resultado. Esto supone un verdadero problema para los algurirmos o sistemas que se apoyen en Hash MD5, puesto que para toda operación que se realice con este Hash, las dos entradas serán completamente indistinguibles.

Es el caso de las CAs, existen algunas CAs que a día de hoy siguen utilizando MD5 como Hash cuando firman certificados, ya que no firman el certificado entero por una cuestión de eficiencia, sino que calculan el MD5 de los parámetros más significativos del certificado y luego firman dicho Hash.

Como podeis imaginar, ahí es donde está el problema, ya que debido a la vulnerabilidad del algoritmo MD5, es posible encontrar 2 certificados diferentes cuyo Hash sea idéntico, y por lo tanto, el Hash firmado por la CA será igualmente idéntico. Este problema puede ser usado para usurpar la identidad de un host y realizar ataques Man-in-the-Middle, puesto que nuestro navegador reconocerá el certificado malicioso como firmado por una CA de confianza.

Volviendo al ejemplo de www.mibanco.es ,supongamos que un intruso quiere usurpar la identidad del sitio web, solo tiene que descargar el certificado con la clave pública del host (que se puede descargar desde el propio host) y calcular un certificado (con su clave pública y privada) cuyo contenido tenga como resultado el mismo Hash MD5 que el certificado original. Una vez conseguido esto (algo nada sencillo, los investigadores han tenido que usar un cluster compuesto por 200 Playstation 3 durante 3 días) lo único que hay que hacer es aplicar el Hash firmado original al certificado malicioso, que efectivamente será perfectamente válido, por lo que cuando el usuario acceda al sitio malicioso este aceptará el certificado ya que lo reconocerá como firmado por una CA reconocida.

En realidad, el ataque mostrado por los investigadores es un poco más complicado, ellos lo que hacen es conseguir que una CA reconocida firme el certificado de otra CA propia, una rogueCA, a partir de lo cual cualquier cosa que firmen con esa CA (que es de la propiedad de los atacantes) será automáticamente aceptado por todos los navegadores, lo cual es aún más terrorifico si cabe. Podeis acudir a la web original de los investigadores para más detalles.

Las CAs afectadas por esta vulnerabilidad ya han anunciado que están corrigiendo este problema, pero por el momento, la única medida efectiva con la que nos podemos quedar tranquilos es eliminar los certificados públicos de las CAs que aún utilizan MD5 de nuestro navegador/sistema operativo, ya que si no confiamos en la CA, no vamos a “tragarnos” la suplantación basada en la firma de esa CA.

Para no tener que comprobar uno a uno los certificados, podemos usar esta herramienta aunque sólo funciona en entornos Windows, según se lee en la propia web.

Si es que al final no podremos confiar en nadie…

SQL Injection

—Buenos días, Maestro, hoy vengo a traerte una ofrenda.
—Vaya, una tira cómica de xkcd… son un tanto curiosas.

exploits of a mom

—Sí, ésta la he encontrado en esta noticia de abril sobre un ataque de inyección de SQL. Me ha hecho gracia y se me ha ocurrido traerla como excusa para ver si eres capaz de decirme algo nuevo sobre un tema tan conocido ([1] [2] [3]) y que, sin embargo, sigue dándonos sustos tan a menudo.
—Pues precisamente acabo de leer hace nada otra noticia sobre un ataque a los servidores de MS SQL Server a través del IE7, que parece tener relación. Mira, aquí está. Aunque sé que no hace falta, te traduzco libremente algunas frases:

“[…] otra vulnerabilidad zero-day en un producto de MS. Esta vez es el SQL Server […] el bug de SQL permitiría la ejecución de código malicioso a un usuario autenticado mediante una conexión directa a la BD o también a través de una inyección SQL en una aplicación Web vulnerable […]”

—En la noticia de abril también se habla de inyección de SQL, aprovechando una funcionalidad del Microsoft Internet Information Server (IIS) que llama comandos genéricos, que sólo tiene SQL Server.
—Sí, recuerdo el caso. La vulnerabilidad es una funcionalidad de SQL Server, y eso es lo que permitió que el ataque fuera genérico y por tanto, masivo. Pero la puerta de entrada son las vulnerabilidades en las aplicaciones Web que había en los servidores. El revuelo en ambos casos viene porque la funcionalidad genérica en un caso y el bug en el otro son en productos de Microsoft y permiten ataques genéricos.
—Esto es un sinvivir.
—Claro, el problema es que el software sobre el que descansan nuestras aplicaciones es muy complejo y una vulnerabilidad se cuela con cierta facilidad. Es más, te diría que pasa poco para lo que podría pasar.
—Y, maestro, ¿qué hacemos? Si cambiamos de SGBD (Sistema de Gestión de Base de Datos), tendremos otras vulnerabilidades. No creo que Microsoft sea especialmente peor que los demás.
—Pues no. Lo que pasa es que, muchas veces, no se presta la atención debida a las aplicaciones que se construyen sobre el software de base y no podemos esperar que éste sea invulnerable a cualquier ataque. Además, la entrada se produce porque las aplicaciones Web no están bien diseñadas y programadas. Es decir, que nos dejamos las puertas abiertas. Por ejemplo, todavía no se siguen las reglas básicas para evitar los ataques de inyección de SQL, que, como bien sabes, son…
—Si, claro: “No utilizarás accesos a la BD en tus aplicaciones con privilegios mayores que lo mínimo imprescindible“, “No usarás sentencias SQL dinámicas con variables, sino queries parametrizadas“, “Usarás procedimientos almacenados con cuidado“, “No usaras nombres dinámicos de tablas, salvo en caso de extrema necesidad“…
—Cuando estas cosas hacen falta, vale la pena replantearse el diseño de la funcionalidad que quieres conseguir.
—Y con eso, ¿nos evitamos el riesgo?
—Lo reducimos, lo reducimos. Ya sabes que la seguridad absoluta no existe. Como decía Einstein, sólo hay dos cosas infinitas: el Universo y la estupidez humana… y, de lo primero, no estaba seguro.

XSS Cross-site Scripting (II)

()

—Perdona por la interrupción. Como te decía, desde el punto de vista de Alicia, hay poco que pueda hacer. Puede desactivar la ejecución de script en su navegador, lo que la dejará sin poder visitar muchas de las páginas que le interesan. Puede activarlo sólo para los sitios de confianza, asumiendo que éstos no son vulnerables a este tipo de ataques (lo que es mucho asumir) y, por supuesto, ser sanamente desconfiada para evitar la parte de ingeniería social del ataque. Y poco más. La responsabilidad está en quienes han desarrollado el sitio web vulnerable, que deben corregir la aplicación Web para que no lo sea.
—¿Se puede conseguir eso?
—Claro. El éxito del ataque se basa en que el sitio Web devuelve el código script que se le inyecta y que se ejecuta en el navegador de Alicia. Basta con no hacerlo.
—¿No devolver el script que luego se ejecuta?
—Ese es el enfoque que siguen muchos desarrolladores. Aplicar “html encoding“. ¿Sabes lo que significa?
—Sí, claro, se trata de “escapar” un carácter especial de un código html para que se muestre como tal, en lugar de ser interpretado por el navegador. Se utiliza siempre que se muestran ejemplos de html en un sitio Web.
—Exacto. Si quiero que en una página salga “<br />” en lugar de un salto de línea en el navegador, debo escribir “&lt;br /&gt;”, ya que esa secuencia tiene un significado especial. He de indicarle al navegador que no debe interpretarla, sino mostrarla, utilizando &lt; para “<" y lo mismo con el resto de caracteres. —Entonces, basta con “escapar" todos los caracteres especiales. —En principio. Claro que eso tiene el inconveniente de no permitir al usuario que introduzca negritas, cursivas o enlaces dentro de su texto. Quizás un inconveniente aceptable. —Bueno, se pueden permitir algunos de los caracteres especiales o, mejor dicho, determinadas combinaciones, como “<a href=", pero no otras, como “<script>". —Sí, claro. Es la táctica de detectar las entradas no deseables y eliminarlas o neutralizarlas. El problema es que hay más formas de introducir un script en un texto de manera que no se detecte con facilidad. Por ejemplo, se puede introducir “%3D%3C%73%63%72%69%70%74%3E", que es lo mismo que “<script>", como parte de una URL. Pero lo peor es que puedes estar protegiendo la aplicación frente a determinadas formas de introducir un script, pero luego aparecer en el futuro otras que no tenías previstas y no ser capaz de detectarlas. —Pero seguro que sabes una solución y me la vas a contar… —Pues la solución es obvia, si aplicamos una de las buenas prácticas de programación que cualquier buen desarrollador conoce: validar cualquier entrada del usuario contra una especificación de las entradas correctas. O sea, admitir lo que es correcto según las especificaciones del programa y rechazar cualquier otra cosa. —Usando expresiones regulares. —Es uno de los métodos más útiles, sí. —En resumen, que el XSS se evita controlando bien todas las entradas a la aplicación, validándolas según la especificación de lo que se considere una entrada correcta. —Ni más, ni menos.

Herramientas de acceso remoto por conexión inversa

Dentro de las herramientas ciertamente peligrosas (aunque muy útiles en algunas ocasiones), durante estos últimos años se están popularizando las de acceso remoto a los PCs de escritorio, a pesar de que en realidad son muy antiguas y desde siempre han traido importantes problemas de seguridad, como por ejemplo, el Back Orifice (cuyo nombre estarán de acuerdo conmigo que es bastante descriptivo).

Las últimas versiones de estas herramientas que les comento están diseñadas para saltarse todas las políticas de seguridad perimetral implantadas en las organizaciones; por supuesto, el uso de dichas herramientas puede ser perfectamente lícito, pero puede también no serlo (y en ese caso, convertirse en un riesgo de seguridad) si no son controladas y validadas por la normativa de la organización.

La manera de funcionar de estas herramientas es mediante conexiones inversas, de modo que es el equipo interno a la organización el que inicia la conexión hacia el exterior, para luego pasar el control al sistema externo. La manera que tienen de realizar esto es iniciando la conexión, algo que suele estar más abierto o si quieren “permitido” en los cortafuegos. No obstante, en aquellos casos (debería ser en la mayoría) en que las conexiones estén cerradas y sólo se permita la conexión a navegación a través de un proxy, estos programas son capaces de utilizar una tunelización http, saltándose virtualmente cualquier protección perimetral.

Algunas de estas herramientas, que en algunos casos hemos tenido la ocasión de ver en pleno “uso y abuso”, son las siguientes:

Webex: Esta herramienta es utilizada por muchos grandes proveedores de cabinas de disco, de BBDD, etc. Se utiliza mucho en grandes catástrofes en sistemas críticos, ya que permite al especialista que se conecte directamente para resolver la incidencia sin que medie una persona intermedia. En muchas organizaciones grandes con este tipo de equipamiento, y ante la aparición de problemas no siempre críticos, los administradores de estos equipos tienden a habilitan el acceso remoto al proveedor para que le arregle el problema, sin que este acceso se encuentre auditado, controlado y registrado en ningún sitio.

Logmein: Esta herramienta, que recientemente se ha popularizado, hemos tenido la ocasión de verla instalada por algun usuario “espabilado” en su propio PC de oficina para conectarse en remoto (según él, para adelantar trabajo). Este servicio/herramienta tiene grandes funcionalidades, es sencilla de instalar, se pueden realizar conexiones bajo demanda (con lo que se puede uno conectar cuando quiera), pero tiene como riesgo adicional que la empresa que da el servicio también tendria la posibilidad teórica de conectarse.

Zebedee server: Este aplicativo es un tunelizador de IP opensource, con capacidad de tunelizar por http, que permite el redireccionamiento de cualquier puerto, para que sea accesible desde el otro extremo, lo que lo hace prácticamente “a prueba” de cortafuegos.

Por supuesto, existen configuraciones de los proxys, y restricción en los permisos de instalación de software que pueden evitar este tipo de software malicioso, pero no siempre están presentes o se controlan correctamente, y este tipo de aplicaciones de acceso remoto es algo que hay que tener muy en cuenta. ¿Está usted seguro de quien tiene acceso remoto a su organización?