El incidente (misconfused)

2 de abril de 2009 Por

(La entrada de hoy es la segunda colaboración de Francisco Benet, un amigo de algunos de nosotros —y familia de algún otro— que tiene gran experiencia en la gestión e integración de sistemas, protección de datos de carácter personal y evaluación de soluciones de integración de software y hardware, entre otros aspectos. Esperamos que les guste.)

Hace algo más de un lustro me enfrente a una situación un tanto extraña en el área de Sistemas de la organización para la que trabajaba, y que les describo a continuación (NOTA: parte de la situación descrita es ficción, para dar dramatismo y mayor realidad a la historia; no crean todo lo que leen).

[Read more…]

Consultores

31 de marzo de 2009 Por

Antes de nada, déjenme decirles que esta entrada no está particularmente relacionada con la seguridad; es algo que escribí hace bastante tiempo y que quedó en el olvido. Adelantaré, también, que he sido técnico, en sus diferentes variantes, durante aproximadamente seis años; he llevado móvil de guardia y me han llamado a las tres de la mañana por algo que podía esperar al día siguiente; he soportado a usuarios irritantes, he hecho intervenciones de madrugada y he sufrido incompetencias diversas, además de la mía propia. Por razones variadas e interés, hace algún tiempo cambié el mono de técnico por el de consultoría “barra” auditoría, y aquí estoy. Sirva esto como “disclaimer” previo.

Lo que vengo a responder con esta entrada es a esa sensibilidad bastante acentuada, sobre todo en entornos técnicos, que existe contra la tarea de los consultores; la típica ceja levantada “a lo Sobera” y esa cara de incredulidad que una parte del personal técnico pone cuando le presentan un proyecto de consultoría. Estoy seguro que muchos de ustedes conocen algún chiste sobre consultores. Yo me acuerdo particularmente de aquel del consultor que después de utilizar mil y una sofisticadas herramientas para decirle al pastor cuántas ovejas tiene, éste le ofrece que escoja una como recompensa y el consultor elige al perro en lugar de la oveja, demostrando no conocer en absoluto “el negocio” del cliente. El chiste es bueno, aunque la moraleja sea incorrecta. Seguramente, si ustedes son técnicos, sabrán aún más chistes. De eso precisamente quería hablar: de consultores (no de chistes).

La principal crítica que mucha gente le hace a los consultores es que éstos, tras el cobro de una hipotética cuantiosa suma, simplemente trasladan a dirección lo que el empleado “raso” ya sabe: que hay desorganización, que hay que cambiar esto o aquello o que hay que contratar más gente, entre otras propuestas. Pues ni sí, ni no, pero más “no” que “sí”. Y eso es de lo que viene a hablar este post.

Comenzaré diciendo que a nadie se le escapa que cuando se lleva a cabo una consultoría, parte de los problemas detectados son conocidos por el personal, ya que son muchas veces quienes más los sufren. En algunas ocasiones, como consultor y/o auditor, es más que evidente que las personas te “utilizan” como método de amplificación de sus problemas departamentales: recursos técnicos, personal, manera de hacer las cosas, etc.; eso no es nada malo, siempre que sepa uno discriminar entre una queja justificada y una injustificada. Esta es, sin duda, una de las tareas del consultor: informar de los problemas que parte del personal ya conoce, o al menos percibe. La cuestión que surge entonces es: ¿porqué no podría ser ese mismo personal el que realizase esa tarea de “informador”?

Por una parte, se me ocurre que existe una cuestión básica de estructura corporativa. Saltarse la jerarquía interna puede ser sencillo si se trata de una empresa pequeña, o una grande que posee buenos medios de comunicación, una gestión realmente eficiente de Recursos Humanos, y además, hay muy “buen rollo” (eso es importante). Y aún así, como trabajador y si no es una cuestión de problemas con tu responsable, desaconsejaría este tipo de actuaciones por los problemas que puede traer; el “buen rollo” dura poco si cargas contra la gestión de tu jefe; eso puede traer con facilidad malas relaciones, reticencias y “piques” internos, desconfianza, etc. Y si hablábamos de una empresa pequeña o bien gestionada, imaginen una en la que hay poca flexibilidad y la comunicación entre distintos niveles directivos es rígida y poco eficiente. Dicho de otra forma: el consultor no está restringido por esa estructura interna, y menos cuando viene directamente respaldado (como suele o debería ser) por dirección. Puede hablar con quien quiera, y puede ser franco en sus análisis y conclusiones, sin miedo a que se tomen represalias contra él. Y esto es precisamente una de las virtudes que debe tener cualquier consultor/auditor: independencia.

Por otro lado, y esta es una de esas cosas que no se ven, una persona interna afectada directamente por un determinado problema posee de manera involuntaria e inconsciente un componente importante de subjetividad que con toda probabilidad va a influir en la crítica que hace, algo que una persona externa al departamento, sea una entidad independiente o personal de auditoría interno, no tendrá. Quizá tenga razón y es cierto que exista —por ejemplo— un problema de personal, pero quizá no hagan falta dos personas como él sugiere o pretende que se contraten, sino una persona y una mejora de la gestión interna del departamento. Existen multitud de situaciones en las que cada una de las personas de un departamento aporta su granito de arena al problema; quizá su forma de trabajar, planificar el tiempo o gestionar a su equipo sea parte de la cuestión, y es difícil que vaya a ver eso. En este caso, los análisis del consultor serán más o menos acertados, pero no estarán influidos por cuestiones que le afecten directamente.

Por último, pero no por ello menos importante, un consultor tiene la experiencia de su más o menos dilatada carrera, en la que ha visto muchos más casos que el que tiene delante en ese momento. Por ello es capaz no sólo de abstraerse de los problemas concretos y particulares que observa, y ver el bosque en lugar de únicamente los árboles, sino de aportar soluciones que ha podido comprobar que funcionan en otras organizaciones.

Pero aparte de estos temas, que considero que son más que suficientes, hay todavía un aspecto que es también responsabilidad del consultor: analizar aquellos problemas que el personal interno no conoce o no quiere conocer, bien por “conflicto de intereses”, por comodidad o vayan ustedes a saber qué. Y me refiero a la reticencia y resistencia de las personas y organizaciones a cambiar de forma de trabajar; es complicado que detectemos un problema, y además seamos capaces de identificar (y sobre todo admitir) nuestra parte de culpa en él, si su modificación nos repercute en una forma de hacer las cosas con la que nos sentimos cómodos; se trata de una vertiente distinta de aquello de la paja en el ojo ajeno y la viga en el propio. Los cambios introducen una molestia, una perturbación en nuestra rutina diaria, que aunque a la larga puedan ser buenos, no son bienvenidos. Y en ese punto el análisis de una persona ajena al problema es necesario, porque no tendrá que escoger entre las molestias de cambiar de forma de trabajar y las mejoras que eso le supone a la organización. En definitiva, y sin entrar en cuestiones filosóficas, a menudo vemos lo que queremos ver, tanto queriendo y sin querer; las personas estamos tan metidas en nuestra rutina diaria que nos cuesta ver qué hacemos mal y además, asumirlo y cambiar nuestra forma de trabajar.

En la línea de la crítica de que al consultor se le paga por decir algo que ya se sabe, hay que añadir que el consultor no sólo “dice”, sino que lleva detrás un trabajo bastante más elaborado, en el que se encarga de mantener unas reuniones, analizar la información recabada y generar unos informes, algo que lleva tiempo. En realidad, gran parte de las personas que son críticas con la tarea de los consultores se negarían a realizar esa tarea, porque no les gusta, les supondría enfrentamientos con personal interno, y porque eso les supondría una carga de trabajo adicional. Seguramente muchos sabemos cómo cambiar un tubo fluorescente fundido, pero cuando eso pasa en el trabajo, salvo raras excepciones (o necesidades de orden mayor), no lo hacemos; llamamos al electricista. Al fin y al cabo, ese no es nuestro trabajo, no nos gusta, no queremos problemas con el de riesgos laborales, y si al final hay algo más que un tubo fundido, no sabremos qué hacer.

Es así de simple, más o menos.

WWW. Una ventana al mundo, una ventana para los intrusos

26 de marzo de 2009 Por

A menudo las organizaciones securizan su dominio protegible implantando una serie de controles tecnológicos que permiten impedir o en todo caso minimizar el impacto de actividades ilícitas por parte de terceras personal, o incluso las realizadas por el propio personal corporativo. Instalación de cortafuegos perimetrales, software de detección y eliminación de malware, proxys, sistemas de detección de intrusos y un largo etcétera, serían algunas de las medidas empleadas.

En este momento el responsable de TI de la organización siente una falsa sensación de seguridad, ya que descuida, entre otras cosas, las posibles vulnerabilidades latentes en el software de los servicios de DMZ. Normalmente estos servicios perimetrales (servidores de correo, DNS…) se sustentan en software de amplia distribución y con un soporte de actualizaciones de seguridad pero, ¿qué ocurre con la pagina web corporativa? Estos sites que ofrecen la imagen y la marca de la organización al resto del mundo son desarrollados de forma personalizada, sin un soporte, muchas veces, de actualizaciones de seguridad. Si quieres que corrija estos errores, paga el esfuerzo que requiere ese desarrollo adicional. Sí, esta frase es bastante común, dado que este tipo de situaciones no se contemplaron en el alcance del proyecto, ni se requirió que el desarrollo siguiera un marco de trabajo de desarrollo seguro.

En bastantes de las auditorias y test de intrusión de aplicativos web que S2 Grupo ha realizado, no sólo se obtuvo el control del site auditado (acceso a insertar modificar o eliminar el contenido de la web), sino que se pudo obtener numerosa información confidencial (credenciales de acceso a zonas privadas, números de cuenta bancarias, cuantas de correo electrónico, documentos confidenciales de la organización…), sin comentar la posibilidad de realizar ataques de phishing y robo de sesiones. Todo ello tan sólo a través de la página web de la corporación, esa ventana al mundo accesible desde el sitio más recóndito del planeta.

Para hacerse una idea de los potenciales puntos de entrada que un intruso tendría a través de la web basta con tener en cuenta el conjunto de parámetros POST y GET de los posibles recursos dinámicos (jsp, asp, php, cgi’s…), así como cookies o cualquier otro tipo de información que sea enviada desde el cliente para que el servidor la procese. En un site de tamaño medio donde su funcionalidad sea informativa y presente una zona privada, el total de puntos de entrada del atacante es inmenso.

He aquí el papel relevante que juega la seguridad en este tipo de servicios, y que en general se tiene totalmente descuidados. Pero, ¿cómo es posible mitigar estos riesgos? Pues aplicando principalmente dos estrategias:

  • Usar un Framework de desarrollo seguro que se integre en el ciclo de vida de desarrollo del software.
  • Realizar auditorias de seguridad, preferiblemente con test de penetración, cuyo alcance abarque tanto el análisis de las vulnerabilidades de la web como los permisos de la base de datos que la sustenta (en caso de que use, claro). Este último punto es de vital importancia porque en numerosas ocasiones los permisos del usuario de la BD que la aplicación utiliza son inadecuados, permitiendo obtener información que no tendría porqué ser accesible. Recordar que siempre hay que aplicar la máxima del mínimo privilegio.

A todo esto cabe añadir que las aplicaciones en general tienden cada vez mas a desplegar su interfaz gráfico hacia la web, e incluso programas típicos de edición de texto como Microsoft Word tienen sus homólogos en la web (ver Google Docs). Dado el auge de esta tendencia y la escasa preocupación por la seguridad de estos servicios, nos lleva hacia un panorama desolador e inseguro, haciendo necesaria la aplicación de controles preventivos y reactivos, que mitiguen estas amenazas para las organizaciones y usuarios particulares.

Pero, ¿quién tiene la responsabilidad de que estos fallos permitan al intruso acceder a la información confidencial? Indudablemente para mí, el programador web, que a menudo es contratado sin experiencia, no solo en seguridad sino en cuanto a skill de programación se refiere, por empresas que lo único que quieren es obtener un producto en poco tiempo, bonito y que cumpla las especificaciones requeridas por el cliente; preocupándose por la funcionalidad y descuidado el rendimiento y la seguridad de su plataforma. ¿Sería conveniente aplicar algún tipo de castigo? Una de las medidas que el equipo de auditoria del ACE Team de Microsoft aplica sobre sus proyectos de desarrollo es penalizar a los jefes de proyecto y programadores que desarrollen de forma insegura, reduciendo el presupuesto de sus proyectos según el número y grado de vulnerabilidades encontradas. Sería una opción a considerar.

Al respecto, y en la línea de lo comentado, la encuesta de esta semana es la siguiente:

[poll id=”10″]

* * *

(N.d.E.) En relación con la encuesta anterior, cuyo resultado les muestro debajo, ha quedado claro (siempre teniendo en cuenta el ámbito en el que nos movemos y el público de este blog) que en general, la preocupación por los datos gestionados por las (empresas propietarias de las) redes sociales es legítima y compartida por gran parte de nuestros lectores.

[poll id=”8″]

Yo, Bicho.

24 de marzo de 2009 Por

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.

¿En qué piensan los desarrolladores?

9 de marzo de 2009 Por

El otro día, mirando los archivos que tengo en el ordenador de casa encontré algunos proyectos antiguos en Visual Basic que diseñé hace algunos años. En aquella época trabajaba en una empresa muy pequeña (dos desarrolladores, un administrador de sistemas y “el jefe”), para nosotros todo lo que hacíamos era la mejor opción y los clientes quedaban bastantes satisfechos con nuestro trabajo. Los desarrollos los hacíamos con Visual Basic 6.0 contra bases de datos Microsoft Access y en el mejor de los casos SQL Server 2000; todo Microsoft, por supuesto.

Con los conocimientos de seguridad que he ido adquiriendo a lo largo de mi vida laboral me doy cuenta de que los proyectos que diseñábamos de manera tan “perfecta” tenían… ¡más vulnerabilidades que código escrito!, y que si un usuario malintencionado se hubiera entretenido en explotarlas hubiera destrozado el sistema en cuestión de segundos. Pensando en todo esto me pregunto: ¿Por qué diseñabámos así? ¿No teníamos los conocimientos necesarios? La respuesta es que en ningún momento del desarrollo nos planteábamos la posibilidad de que existieran usuarios malintencionados, o en otras palabras, asumíamos que “los usuarios de nuestra aplicación son demasiado torpes como para hacer esas cosas”. Obviamente, no puedes confiar en que los usuarios de tus aplicaciones vayan a ser “buenos” y no salirse del camino que les dibujas, porque si encuentras uno curioso, puedes llevarte más de una sorpresa desagradable.

Pongamos un ejemplo más técnico. En cierta ocasión, decidimos implementar un proyecto Windows en .Net, y en el app.config establecimos la cadena de conexión a la BBDD junto con el usuario y la clave con permisos de lectura y escritura. Se decidió publicarlo para que nos fuese más cómoda la implantación y las actualizaciones (funcionalidad de .Net que va de “serie” con el Visual Studio 2005). Probamos el funcionamiento de la aplicación una vez publicada y navegamos un poco por los ficheros que nos descargaba el instalador y… ¡sorpresa! El app.config lo había metido en la máquina del cliente (quizá con alguna extensión extra) y si se abría con el Notepad podía verse la cadena de conexión a la BBDD.

Con esta estrategia de implantación y de desarrollo teníamos un sistema poco seguro. ¿Qué opciones se plantean en casos como este?

(a) Presuponer que los usuarios van a conocer la cadena de conexión, el usuario y clave de acceso a la BBDD, por lo que se pueden establecer los permisos pensando en ello.

(b) Si los usuarios no deben conocer nunca datos sobre la BBDD, es necesario realizar un entorno cliente-servidor de manera que nuestra pequeña aplicación utilizada por los usuarios se conecte a una aplicación remota que haga las tareas de BBDD que se le soliciten. De esta manera nuestra aplicación cliente tiene datos de conectividad a nuestra aplicación servidor, pero nunca de la BBDD.

Para evitar todo esto hubiese sido necesario añadir una fase de seguridad adicional en nuestra metodología de desarrollo, en la que entre otras cosas adoptasemos el rol de un posible atacante, probando exhaustivamente todas las posibles casuísticas que hacían vulnerable la aplicación y estudiando la forma de ponerles remedio.

Como desarrollador, debo admitir que todo esto no me lo planteaba en aquella época, ya que diseñaba pequeños proyectos y nunca pensé que existirían usuarios tan “malvados” e “inteligentes” como para explotar posibles agujeros de seguridad. Pero si esos mismos proyectos los desarrollara hoy, por pequeños que fueran, nunca confiaría en que los usuarios lo vayan a utilizar de la manera esperada, sino que me pondría a la defensiva y trataría de pensar: si yo quisiera explotar esta aplicación… ¿qué haría?

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

3 de marzo de 2009 Por

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

1 de marzo de 2009 Por

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.

Economía en tiempos de guerra

26 de febrero de 2009 Por

Pasamos una época complicada en el tema económico, en la que diversos estudios aseguran que aumentan las depresiones y las visitas al psicólogo, mientras que otros destacan el aumento del dinero destinado a juegos de azar por parte de las familias. Una de las alternativas de estos juegos de azar que muchos de ustedes conocerán son las apuestas por Internet, que quizá algunos incluso hayan probado.

El procedimiento de uso suele ser sencillo: un registro, un depósito monetario mediante tarjeta de crédito o similares y a buscar rentabilidad en las apuestas (no se preocupen, que ya les hablaré de eso otro día). Supongo que convendrán conmigo en que en esta época en la que el tema de la seguridad informática es tan candente, se le debe dar mucha importancia a las compañías que demuestran rigor al menos en la seguridad de sus portales. Al fin y al cabo parte de los ahorros —o no— de los usuarios va estar un tiempo en sus cuentas bancarias, hasta que éstos puedan recuperarlo.

Como medidas de seguridad, estos portales suelen ofrecen páginas cifradas con https, algunas incluso incorporan algún tipo de mecanismo de comprobación de fortaleza de contraseña en el registro, y en general, ofrecen la apariencia de preocuparse por el tema de la seguridad. Sin embargo, lo que para un usuario puede ser la diferencia para gastar o no su dinero, para las compañías parece no tener importancia. Entre otras cosas, no es extraño que los operadores que atienden el chat de ayuda de alguna de estas casas online soliciten la contraseña del usuario, lo que me hace suponer que almacenan las contraseñas en claro. No parece muy seguro, ¿verdad?

Por ejemplo, ¿realizarían algún tipo de transacción económica con una página que muestra el siguiente mensaje cuando se accede a su portal como un simple invitado?

query: DELETE FROM shoppingcart WHERE NOT EXISTS (SELECT 1 FROM session WHERE session.UserAccount_UserAccountID = shoppingcart.UserAccount_UserAccountID) -> Deadlock found when trying to get lock; try restarting transaction

Dejando a un lado estas pequeñas muestras de lo que no se debe hacer si se quiere ganar la confianza del usuario, y relacionado con el punto anterior, si me lo permiten me gustaría plantearles la siguiente cuestión, que será la encuesta de la semana y a la que podrán contestar a lo largo de esta semana:

[poll id=”6″]

* * *

(N.d.E.) En relación con la encuesta de la semana pasada, los resultados se muestran debajo, dando como resultado que una gran parte de las personas tienen una relativa concienciación de la seguridad, pero sin llegar al modo paranoico. En cualquier caso, la muestra no puede considerarse representativa, y no sólo por el número, sino también por el público objetivo de este blog.

[poll id=”5″]

Por lo demás, buen fin de semana a todos. Nos vemos el lunes, más y mejor.

¿Uifi? ¿Uep? ¿Uvepeá? ¿Y eso qué é lo que é, señor agente?

25 de febrero de 2009 Por

Leía hoy una interesante entrada en el blog de Javier Cao acerca de la falta de concienciación de las contraseñas, y a través de ésta llegaba a la noticia de que la AEPD había absuelto a un usuario denunciado por colgar imágenes vejatorias en la web debido a que éste alegaba que tenía la web desprotegida [bandaancha.eu].

Aparte de algunas anotaciones muy acertadas por parte de bandaancha.eu, como es el hecho de que como indica el abogado David Maeztu, los datos de tráfico de una persona física o jurídica no pueden ser cedidos por una operadora de telecomunicaciones a la AEPD si no es previa solicitud judicial (solicitud judicial que a menudo no existe), me llama la atención que el hecho de tener la Wifi abierta pueda servir de atenuante e incluso ser una razón suficiente para absolver de una sanción de la AEPD.

Al respecto, y sin extenderme demasiado, creo que hay que destacar varios aspectos. El primero es que confiar en que tener la Wifi desprotegida pueda servirte como escudo es como poco jugársela a los dados; yo no confiaría en que la AEPD resuelva siempre positivamente, e incluso si fuese a través posibilidad de un recurso favorable, eso podría suponer unas molestias considerables. El segundo es que, a pesar de la resolución de la AEPD, en caso de tener que enfrentar una acusación de un delito mayor como podría ser pederastia, amenazas, o pertenencia a banda armada (asusta, ¿eh?), no estoy seguro de que este argumento fuese suficiente, sin mencionar las más que previsibles molestias que tal situación acarrearía independientemente de la culpabilidad o no. Tengan en cuenta, no obstante, que no soy abogado y estoy simplemente especulando, por lo que podría estar terriblemente equivocado (o depender del juez y las circunstancias del caso); en definitiva, lo que vengo a apoyar, como ya hice en su momento, es que nadie debería confiar en que tener la Wifi abierta pueda salvarle de un problema si a través de la línea de la que es titular se cometen delitos de cierta gravedad.

Hasta aquí, la cruz. La cara es que, al menos en el caso de Telefónica (por mi experiencia), y apuesto a que esto se cumple en la mayoría de proveedores, los routers de acceso a Internet se proporcionan configurados con el protocolo WEP, totalmente vulnerable y fácilmente explotable en cuestión de segundos por cualquier persona con un poco de interés; nadie con conocimientos técnicos puede alegar desconocimiento de este hecho, y menos el proveedor del dispositivo. Es más, en el caso de Telefónica dicho operador ni siquiera proporciona las claves de acceso al dispositivo, ya que su gestión se realiza por defecto —esto puede cambiarse— a través del portal “Alejandra”, aspecto que no averigua uno hasta que indaga un poco. Me apuesto un brazo con ustedes a que cualquier solicitud de asistencia técnica orientada a incrementar el nivel de seguridad de tu dispositivo (i.e. cambiar de WEP a WPA/WPA2) es (a) descartada directamente por el operador de turno, y/o (b) cobrada rigurosamente, dependiendo de la insistencia (quizá lo pruebe). En cualquier caso, y como es lógico, la mayoría de las personas que disponen de acceso ADSL a Internet carecen de los conocimientos técnicos para cambiar el protocolo de seguridad del router, y aunque uno disponga de los conocimientos (lo que podría representar un problema si el titular de la línea ha modificado la configuración pero no el protocolo de seguridad, aunque en ese caso, volvemos a las mismas), puede alegar que el dispositivo venía configurado con un protocolo vulnerable y que por precaución no lo modificó.

A la vista de las dos opciones, ¿ustedes qué opinan? ¿Es razonable preocuparse por la seguridad de la propia red para evitar delitos por parte de vecinos y/o afines, o no hacerlo es en realidad la mejor medida de seguridad?

(De todas formas, tampoco se fíen. Como ya les comentamos hace tiempo, no todo el mundo e güeno y las cosas no son siempre lo que parecen.)

El Diablo está en los detalles

24 de febrero de 2009 Por

La portada de uno de los periódicos que conservo por casa reza en un gran titular “Obama inagura el primer gobierno 2.0 del mundo”, y a nadie se le escapa, en efecto, que el nuevo presidente norteamericano ha hecho de Internet y la web 2.0 una de sus principales bazas para llegar al Capitolio. Pero aunque eso lo hace indudablemente más real y cercano a la realidad de los ciudadanos, desde el principio han surgido voces críticas con el uso que se le da a algunos servicios, que van en la línea de las críticas a la privacidad de las redes sociales y el gigante Google.

En este caso no vengo a hablarles de la reticencia a desprenderse de su Blackberry, aspecto que ya comentamos hace unas semanas, sino de un par de cuestiones que Steve M. Bellovin y Christopher Soghoian entre otros, han puesto de relevancia en los últimos tiempos, y es el uso que la Oficina Ejecutiva del Presidente de los Estados Unidos hace de terceras partes para la provisión de servicios web, violando directivas federales, y proporcionando una valiosa información de orientacion política e ideológica a empresas privadas “afines”.

Empecemos por el principio. Hace algo más de un mes se puso en marcha una iniciativa por la que cualquier miembro del Congreso y del Senado norteamericano dispondría de un espacio en YouTube para colgar sus videos y exponer sus ideas a los ciudadanos, algo totalmente elogiable. Si no recuerdo mal, en la campaña electoral española se hizo algo similar, aunque ignoro con qué porcentaje de éxito. Como apunta Bellovin, el problema de esta iniciativa es que aunque aprovecha la tecnología para acercar los representantes a los ciudadanos, lo hace pagando un precio nada despreciable, como es la cesión de una información muy valiosa a una compañía privada como es Google. Francamente, a estas alturas de la historia, y una vez abandonado hace tiempo el lema Don’t be evil, proporcionarle al buscador información de carácter ideológico y político de los ciudadanos para que la utilice en su propio provecho, con el beneplácito y la connivencia del gobierno estadounidense, me parece una falta de concienciación y de la importancia de la privacidad en el mundo 2.0.

En segundo lugar, y para entender lo que sigue, cabe distinguir entre lo que son cookies de sesión y cookies persistentes. Mientras que las primeras son utilizadas mientras el navegador permanece abierto, y son eliminadas al cerrarlo, las segundas no se borran, sino que permanecen en el navegador, permitiendo al “propietario” de la cookie conocer información sobre la última visita o la información que hemos visitado en el pasado. En este último caso, páginas como YouTube han llegado a un nivel de sofisticación que permiten a Google conocer, bajo ciertas condiciones, las páginas y blogs que un usuario está visitando con la sola presencia de un video de YouTube en la página, aun cuando el usuario no “clickee” sobre el video.

Tras esto, déjenme introducirles con un fragmento del Memorando M-00-13, Privacy Policies and Data Collection on Federal Web Sites, de la Office of Management and Budget of the Executive Office of the President of the United States, que se abrevia como OMB. Disculpen si las traducciones no son demasiado apropiadas; lo que sigue es el cuarto y quinto párrafo del dicho memorando, que data del 22 de junio de 2000:

Las inquietudes particulares sobre privacidad deben ser tenidas en cuenta cuando el uso de tecnologías web pueda permitir seguir las actividades de usuarios a través del tiempo y entre páginas web diferentes. Estas preocupaciones son especialmente importantes cuando los individuos que han llegado a las páginas gubernamentales no tienen un aviso claro y visible de cualesquiera actividades de seguimiento. […]

[…] la presunción debe ser que las “cookies” no serán utilizadas en las páginas web federales. Bajo esta nueva política federal, las “cookies” no deben ser utilizadas en las páginas web federales, o por los contratistas que gestionen páginas web en nombre de las agencias, a menos que, además de existir un aviso claro y visible, se cumplan las condiciones siguientes: una necesidad imperante que obligue a recopilar los datos sobre el sitio; protecciones de la privacidad apropiadas y públicas para el manejo de la información derivada de las “cookies”; y aprobación personal por el jefe de la agencia. […]

Dicho memorando fue modificado posteriormente, el 26 de Septiembre de 2003, por el memorando M-03-22, OMB Guidance for Implementing the Privacy Provisions of the E-Government Act of 2002 introduciendo las siguientes modificaciones (Anexo D):

1. Tracking technology prohibitions:

a. Agencies are prohibited from using persistent cookies or any other means (e.g., web beacons) to track visitors’ activity on the Internet except as provided in subsection (b) below;

b. Agency heads may approve, or may authorize the heads of sub-agencies or senior official(s) reporting directly to the agency head to approve, the use of persistent tracking technology for a compelling need. When used, agency’s must post clear notice in the agency’s privacy policy of:

      * the nature of the information collected;
      * the purpose and use for the information;
      * whether and to whom the information will be disclosed; and
      * the privacy safeguards applied to the information collected.

Dicho de otra forma (y en castellano), el uso de cookies persistentes está terminentemente prohibido, salvo que haya una necesidad de peso para ello. En tales casos, debe informarse de la información recogida, finalidad, destinatarios y medidas de seguridad aplicables, y esto aplica tanto a las agencias como a cualquier contratista que gestione contenidos en nombre de las agencias. No obstante, y aquí vuelven de nuevo los “pero’s”, si acceden a algunas de las entradas del blog de La Casa Blanca, verán que algunas de ellas contienen videos incrustados que apuntan a YouTube, y que los videos también se encuentran alojados en Vimeo, para lo cual la política de privacidad ha sido modificada convenientemente, incluyendo los siguientes párrafos:

For videos that are visible on WhiteHouse.gov, a ‘persistent cookie’ is set by third party providers when you click to play a video. […]

This persistent cookie is used by some third party providers to help maintain the integrity of video statistics. A waiver has been issued by the White House Counsel’s office to allow for the use of this persistent cookie.

Esta excepción (waiver) al uso de cookies persistentes ha sido duramente criticada, ya que no parece existir ninguna base fundamentada ni razón de peso para su existencia, y la utilización de proveedores de video externos no sólo les envía un nada despreciable flujo de visitantes, algunos de los cuales continuarán en el website externo, sino que sobre todo les proporciona, igual que comentábamos antes, información sobre los visitantes de varias páginas gubernamentales.

Como apunta Soghoian, no es comprensible que a estas alturas, y dado el presupuesto que La Casa Blanca maneja, se siga utilizando un website externo para el alojamiento de videos gubernamentales, cuando existen múltiples opciones comerciales de video streaming que podrían gestionarse internamente de manera autónoma, tal y como hace America.gov. Como aspecto positivo, el uso de una técnica similar al script MyTube de la Electronic Frontier Foundation para evitar algunas cookies persistentes, o las recientes modificaciones de la política de privacidad parece que apuntan a un creciente concienciamiento sobre la importancia de la privacidad, aunque es todavía claramente insuficiente. Si tenemos que escoger entre la privacidad y la web 2.0, creo que la elección no deja lugar a dudas; no podemos supeditar la primera a la segunda, por mucho que la web 2.0 traiga innumerables e inmensas ventajas. Nunca sabe uno dónde puede estar el punto de no retorno, y eso es algo que todos deberíamos tener presente, ya que jugamos en contra de los intereses de las grandes multinacionales de Internet. Por fortuna, la tecnología y las leyes permiten que no tengamos que escoger… siempre que nos dejen escoger.

En la línea de lo dicho en el anterior párrafo, seguramente a algunos lectores les parezca que puedo estar rozando la paranoia, entrando en este nivel de detalle, y más cuando no soy un ciudadano estadounidense. Sin embargo, aunque no descarto la existencia de una manía persecutoria, a estas alturas creo francamente en ese dicho que titula esta entrada y que dice que el Diablo está en los detalles. No sólo está en esa política de privacidad que deja la puerta abierta a una retención de datos para “usos legítimos de negocio”, en esa frase sutilmente introducida que exime (principalmente) a YouTube de la prohibición expresa de hacer uso de cookies persistentes en una página gubernamental, o en la aparente insignificancia que tienen los registros de visitantes al “canal de Internet” de un representante político. Está también en esa regla del cortafuegos “ANY:ANY” que alguien puso para una “demo” un día antes de irse a casa, en esa petición de acceso que por prisas y favores no sigue los cauces procedimentados, o en esa hoja Excel que mantiene Recursos Humanos, que contiene el personal con minusvalía y de la que el Responsable de Seguridad no sabe nada. Casi siempre, desde la superficie se ve todo impoluto. Rasquen un poco con la uña, y verán quién hay detrás.

* * *

Referencias:

Steve M. Bellovin: YouTube, the Government, and Privacy; More on YouTube, the Government, and Privacy.
Christopher Soghoian: Why Obama should ditch YouTube; White House exempts YouTube from privacy rules; White House acts to limit YouTube cookie tracking.
About.com: Federal Web Sites Violate Privacy Rules.
Electronic Frontier Foundation: Embedded Video and Your Privacy.
Whitehouse.org: Online Privacy Policy (24/02/2009).
OMB: OMB Guidance for Implementing the Privacy Provisions of the E-Government Act of 2002 (M-03-22); Privacy Policies and Data Collection on Federal Web Sites (M-00-13).