30 junio 2011

Seguridad informática en la industria del pr0n

No, tranquilos, de momento no hemos comprado acciones para invertir en pornografía, ni hemos hecho ningún acuerdo para cambiar Security por Sex (by default). Aunque es posible que debiéramos plantearnos hacerlo, ya que la industria del porno ocupa una gran parte de Internet, y de esa tarta llamada dinero, se lleva un buen pedazo.

Y todo ese dinero hay que protegerlo, y a los clientes tenerlos contentos. Es por ello que curiosamente las páginas web de esta querida industria tienen medidas de seguridad bastante bien montadas.

A primera vista y generalizando podríamos diferenciar entre dos tipos de contenidos, los gratuitos y los de pago. Ya que estamos hablando de webs serias, los gratuitos serían el típico tour con trailers incluidos, y los de pago el contenido completo.

Evidentemente el objetivo es que, después de ser picado por el gusanillo del contenido gratuito, el usuario pase por caja para ver contenidos de verdad. ¿Y qué es lo que se quiere evitar? Que el usuario se salte el paso de pasar por caja para ver ese contenido.

Para evitar ésto, en la industria se ha extendido bastante el uso del producto Strongbox security system. Se trata de un software que protege y gestiona el login de acceso a miembros, además de añadir protección contra, por ejemplo, ataques de fuerza bruta, uso de la misma cuenta entre varios usuarios o descarga recursiva de la web.

Todo ésto con un completo sistema de reportes (screenshots incluidas) que almacena horas, IPs, países, usuarios, tiempos de actividad, logins, logins fallidos, ...

Además, para evitar ese gran enemigo de este tipo de sitios, que son los pares de usuario / contraseña comprometidos y publicados en foros, ofrecen un servicio de búsqueda automática y baneo de estas cuentas, por el módico precio de 5$ al mes.


Lo paradójico de todo esto, es que aún con tanta protección para el sitio web, el usuario inicia sesión y sus datos viajan en claro. Vale que puede no estar en manos de esta empresa implementar su sistema en el sitio con HTTPS, ¿pero ni siquiera hacer, por ejemplo, MD5 de la contraseña mediante Javascript? Pues no, ni siquiera eso.

La otra estrella del login en el área de miembros de la industria es la autenticación HTTP básica. Es increíble la cantidad de sitios que la implementan. ¿Será por la facilidad de gestión de .htaccess y .htpasswd? El hecho es que los credenciales del usuario vuelven a viajar en claro, al menos en aquellas que usen HTTP, que son la mayoría.


En cuanto a buscar en estas webs contenidos de pago a mano en el servidor mediante urls predecibles, listing de directorios o google hacking es complicado, ya que suelen tener la separación de privilegios bien montada. Tienen perfectamente definido lo que cada usuario puede y no puede ver.

La conclusión es que de forma general, las webs de esta industria suelen tener muy bien protegidos y controlados sus contenidos. No podemos decir que se aplique el mismo nivel de seguridad a los usuarios, que no sólo se les controla con tiempos de acceso, IPs, países y más datos personales de manera excesiva, sino que sus credenciales, que su dinero les han costado, viajan en claro.

Eso sí, siempre hay algún despistado que ni una cosa ni la otra. Hasta el día que a algún usuario con las manos ocupadas se le va el dedo a la tecla de la comilla y ...

Sitio web no apto para menores

... ups.
Leer más...

29 junio 2011

Ágora Ciudadana, el parlamento virtual

El proyecto Ágora Ciudadana trata de desarrollar un sistema criptográfico de votaciones que permita el voto seguro a través de Internet, soporte delegación de voto y escale masivamente. Ágora es software libre. Con esos ambiciosos requisitos cualquiera diría que este proyecto es una quimera. Y sin embargo eso es lo que perseguimos su equipo de desarrollo, del cual un servidor (Eduardo Robles, Ingeniero Informático) forma parte, y estamos razonablemente seguros de que es posible.

Los requisitos del proyecto son los mencionados anteriormente, son claros y vienen dados de la idea detrás del Partido de Internet (PDI), partido del cual nació el desarrollo de Ágora. El PDI es un partido político no partidista que no tienen ni jamás tendrá ideología política puesto que su único y radical propuesta es que sus parlamentarios electos votarán en las cámaras de representantes proporcionalmente a lo que la gente vote previamente por Internet mediante Ágora.

Esquema de Seguridad


El esquema de seguridad del sistema de votaciones de Ágora se basa en la autenticación y firmado de los votos mediante DNIe y un sistema criptográfico de votaciones basado en Mixnets, cifrando el voto mediante claves ElGamal y con la novedad del soporte de delegación del voto. En cuanto a criptografía, no se inventa nada nuevo sino que por lo contrario se utiliza estándares conocidos y aceptados por la comunidad criptográfica.

Poca gente conoce los esquemas de votaciones criptográficos, pero estos proveen varias características que un sistema de votaciones físicos no tienen, tal como que cualquiera pueda verificar matemáticamente las votaciones de forma universal. Además el secreto del voto reside en un conjunto de autoridades, de manera que mientras al menos una autoridad se mantenga honesta (o no haya sido comprometida), el voto seguirá siendo secreto.

Cómo funciona una votación

1. Generación de claves
En un sistema de votaciones basado en mixnets, lo primero que ocurre para crear una votación es que se establecen una serie de autoridades de las cuales dependerá el secreto del voto. Cada autoridad genera un par ElGamal de claves pública/privada y comparte la clave pública. Se reúnen todas las claves públicas y se combinan mediante un simple proceso matemático formando una clave pública conjunta de la votación. Con esta clave pública cifrarán los votantes los votos. Dicha clave pública aparecerá en el tablón público de la votación, lugar donde se publican todos los datos públicos que va generando dicha votación.

Además las autoridades deberán por su cuenta de forma independiente proveer su clave pública para que cualquier votante pueda cerciorarse de que la clave pública compartida es la correcta.

Cuanto más autoridades haya mejor, dará más seguridad al sistema, aunque por otra parte hará que la votación sea más costosa de procesar computacionalmente.

2. Recogida de los votos
En una votación, una vez se establece la clave pública de la votación, se establece el texto a votar y el periodo de votación. Cuando abre el periodo de votación, los votantes pueden empezar a emitir su voto mediante la web o la API pública del sistema de votaciones.

En un principio Ágora está concebido para que cualquier español mayor de 18 años pueda votar. Para evitar que personas no autorizadas voten y para evitar votos duplicados, se utiliza la autenticación del voto mediante DNIe. El votante mediante bien un programa que descarga para su ordenador o mediante un applet Java emite su voto, lo cifra, y una vez cifrado lo firma con el DNIe. Mediante la firma se puede autenticar los datos del votante (a modo de censo y como prueba de no repudio) y que el voto no es duplicado.

Los votos cifrados (y por tanto secretos) y firmados se publicarán en el tablón para cualquier pueda ver y certificar, incluido el propio votante, quien ha votado y quien no y comprobar que su voto cifrado se corresponde al que él emitió.


3. Recuento de votos
Una vez finaliza el periodo de votación, comienza el recuento de los votos. En sistema de votaciones con Mixnets, se hace en dos pasos: primero se anonimizan los votos de tal manera que no se pueda saber qué voto es de qué persona, y luego una vez anonimizados, se descifran y finalmente se recuentan los votos en claro. Todo este procesado lo llevan acabo las autoridades de la votación.

Se llama a este sistema "basado en mixnets" precisamente porque se utiliza una mixnet para anonimizar los votos: cada autoridad recifra y rebaraja los votos. Cada autoridad recifra los votos de tal manera que si por ejemplo un votante eligió "opción 1" y lo cifró como cifrado("opción 1", claveVotación) = A (siendo A un texto cifrado), el recifrado parcial que realiza la autoridad 1 sería cifradoParcial(A, claveAutoridad1) = A' = cifradoParcial(cifrado("opción 1", claveVotación), claveAutoridad1), de manera que A y A' son dos textos cifrados que no parecen en nada asociados pero contienen el mismo texto en claro. Este proceso lo hacen todas las autoridades, de tal manera que al final tenemos algo equivalente a cifrado(cifrado("opción 1", claveVotación), claveVotación) = A''.

Aunque parezca mentira, este proceso anonimiza el voto, puesto que una propiedad de ElGamal es que por muchas veces que cifres y recifres, el descifrado se hace en un sólo paso, es decir que descifrado(cifrado("opción 1")) = descifrado(cifrado(cifrado("opción 1")), y por tanto no se puede obtener mediante el descifrado que A = A' = A'', puesto que al descifrar no se obtienen los recifrados parciales sino el texto en claro inicial. Por supuesto para que no se pueda averiguar la equivalencia entre votos cifrados y recifrados y así conseguir la anonimización de los votos, también hay que rebarajar los votos recifrados.


Esquema de una mixnet (Wikipedia)Esquema de una mixnet (Wikipedia)


Una vez se han anonimizado los votos cifrados, las autoridades se ponen de acuerdo para descifrarlos, y una vez descifrados el recuento es trivial, y se publican los resultados en el tablón público de la votación. Como véis, los votos que emitieron los votantes realmente nunca son descifrados, por lo que son realmente secretos, ni siquiera las autoridades saben qué voto quién. Sólo si todas las autoridades se compinchasen podrían descifrar un voto de un votante concreto (o varios), de ahí que cuanto más autoridades y más heterogéneas mejor.

Como dije antes, las votaciones son universalmente verificables. Esto significa que incluso si todas las autoridades fuesen corruptas, se podría verificar si han amañado la votación. Esto es así porque para cada uno de los pasos que he mencionado del recuento (recifrado, barajado y descifrado), las autoridades deben aportar y subir al tablón público de la votación una prueba matemáticamente incontestable de que lo hicieron correctamente. Esto se hace mediante pruebas de cero conocimiento, que básicamente permiten verificar que algo es cierto sin revelar ninguna información adicional. Para saber más sobre cómo funcionan las pruebas de cero conocimiento recomiendo encarecidamente que leáis el ejemplo abstracto que se proporciona en la wikipedia, que a su vez sacaron del Paper "Cómo explicar las pruebas de cero conocimiento a tus hijos", pues es muy instructivo.

Esquema de voto delegado

Según los calculos que estuve haciendo, hay unas 6600 votaciones al año tan sólo en el congreso de los diputados, lo cual se acerca a una votación por hora de media. My poca gente podrá ejercer su derecho a voto en Ágora de forma informada votando con un torrente tan inmenso de votaciones, y ni que decir tiene que la mayoría de la votaciones son sobre temas de menor relevancia. De ahí que soportar el voto delegado sea un requisito indispensable para Ágora, de manera que los votantes puedan delegar su voto en alguien en quien confíen y que le pueda dedicar maś tiempo a esto, sin perjuicio de que pueda cambiar su delegación de voto en cualquier momento o pueda emitir un voto directo en votaciones concretas.

Cualquiera puede crear un delegado en Ágora, sólo tiene que registrarse como tal. Ejemplos de posibles delegados: "David Bravo", "Greenpeace", "Izquierda Unida", "Plataforma de pensionistas". El voto de los delegados es público, y siempre antes de que comience una votación se cierra el periodo que tienen los delegados para emitir su intención de voto para esa votación concreta: de esa manera se asegura que los delegados no puedan engañar a aquellos que vayan a delegar en ellos.

No obstante que el voto de los delegados sea público no impide que el voto de los votantes siga siendo secreto: si delegas tu voto en un delegado, nadie sabrá en quien hiciste tal delegación. De hecho si por ejemplo "David Bravo" el votante crea un delegado llamado "David Bravo" con el cual emite intenciones de voto, él como votante puede delegar su voto en su propio delegado, o delegar en otra persona, o incluso emitir un voto directo. Si delega su voto, nadie sabrá realmente si delegó o no en su propio delegado, puesto que el voto delegado es secreto.

Y ya me estoy adelantando un poco al hablar del voto delegado; El sistema para delegar el voto que hemos ideado (el mérito aquí sin duda es de David Ruescas, un Físico que ha estado desde el principio estudiando toda la morralla matemática y desarrollando el esquema de seguridad de Ágora) es utilizar una votación paralela y contínua para los votos delegados.

Como en cualquier otra votación hace falta tener una serie de autoridades, que crearán la clave pública de la votación y también procesarán los votos cuando sea necesario. Normalmente en las votaciones del congreso las opciones a responder son "SÍ", "NO", "ABSTENCIÓN". No obstante la votación de los delegados hay una opción por delegado.

En esta peculiar votación, denominada votación de delegados, se hacen múltiples recuentos, no se cierra nunca la votación y además las opciones de la votación (que equivalen a los delegados) cambian a lo largo del tiempo.

Por ejemplo pongamos que a día de hoy yo, Eduardo Robles delego mi voto en David Bravo. Lo que hago realmente es cifrar mi voto que pone como opción elegida "delego en David Bravo" con la clave de la votación de delegados, firmarlo con mi DNIe y enviarlo a Ágora que autenticará y recogerá mi voto.

En la siguiente votación que haya en el congreso, por ejemplo una reforma de la Ley de Propiedad Intelectual (LPI), el delegado David Bravo emitiría una intención de voto, por ejemplo "SÍ". Esto sería público, y cuando comience la votación en Ágora de los votos directos, David Bravo ya habrá tenido que fijar su intención de voto, de manera que si no estoy de acuerdo yo podría cambiar de delegado o votar directamente.

Una vez termina el periodo de votación, se hace un recuento de ambas votaciones: de la votación concreta sobre la reforma de la LPI, y de la votación de delegados. A lo mejor en la primera salen 100.000 SÍs, 30.000 NOs y 1.000 ABSTENCIÓN. Por otra parte, en la votación de delegados, podría resultar que la opción "David Bravo" obtiene 1.000.000 de votos delegados. Pues como David Bravo publicó que su intención de voto era "SÍ", ese millón de votos se sumaría a la opción "Sí", resultado en 1.100.000 votos a favor. si hubiese más delegados el proceso a seguir sería el mismo que con David Bravo: se contarían cuantos votos delegados tiene cada delegado y en el recuento final se sumarían dichos votos a la opción correspondiente a la intención de voto de dicho delegado.

Nótese que Ágora es el primer sistema criptográfico de votación que permite la delegación de voto, ahí sí que hemos innovado, y tenemos un paper pendiente de publicación donde describiremos en detalle sobre esta novedad.

Tecnología

El proyecto Ágora consta de dos partes a nivel de código: el backend y el frontend. El backend es Verificatum, una librería cuyo principal autor es el criptógrafo sueco Douglas Wikström y en la que estamos trabajando para que sea más rápida y escale masivamente, como hablaremos más adelante. Para la parte gráfica utilizaremos Ágora On Rails, desarrollado por miembros del PDI y que necesita ser reprogramado para introducirle todo el esquema de seguridad.

Voto Masivo

Como ya hemos dicho antes, , hay unas 6600 votaciones al año tan sólo en el congreso de los diputados, lo cual se acerca a una votación por hora de media. En las últimas elecciones generales había 35 millones de electores, por lo cual se sigue que de media debemos de poder llegar a procesar una tasa de hasta 35 millones de votos por hora para poder dar cabida a todos los posibles electores en Ágora; de lo contrario podríamos morir de éxito.

Un sistema criptográfico de votaciones donde hay que presentar pruebas de que el recuento de las votaciones se realizaron como es debido, donde hay que comprobar esas pruebas, y donde hay que comprobar que los votos son válidos tiene un coste computacional por voto relativamente alto. Por eso usamos verificatum que es una librería para administrar votaciones basadas en mixnets más rápida que tenemos conocimiento, y aun así estamos trabajando en adaptar verificatum para que pueda repartir la carga del procesado de los votos en múltiples máquinas mediante hadoop.

Las pruebas que hemos realizado con verificatum muestran que con 3 autoridades, claves de 2048 bits y cada autoridad utilizando una máquina potente pueden procesarse unos 300.000 votos por hora. No obstante estamos trabajando con los desarrolladores de verificatum en una versión más optimizada que permitirá un mayor rendimiento, además de la distribución del trabajo en varias máquinas, y tampoco descartamos en un futuro próximo procesar los votos con tarjetas gráficas OpenCL.

¿Votar por internet? ¡estás loco!

El voto por internet tiene peligros, eso no hay duda. Si el ordenador del votante está infectado, podría votar a la opción incorrecta sin saberlo, o no votar, o revelar el sentido de su voto. Si tiene un keylogger o un troyano, el secreto de su voto será más difícil de preservar. Con el fin de salvar en lo posible este problema, crearemos una distribución Linux LiveCD/LiveUSB para que los votantes pueda generar el voto en un entorno seguro y sin Internet, y luego emitir el voto una vez haya sido cifrado y firmado, desde dicho entorno seguro. Además se intentará hacer una campaña de información acerca del sistema, donde se explique como funciona el sistema, los posibles peligros, cómo funciona el DNIe y cómo ir a las oficinas de la policía para obtener el PIN, etc.

También por supuesto está el problema de la coacción: nada impide que tengas detrás a tu jefe mientras votas coaccionándote para que votes lo que él quiere. Aunque eso mismo ya ocurre con el voto por correo y no parece preocupar a la población.

A mí personalmente el voto por Internet no me entusiasma por los problemas de seguridad que pueden surgir, me gustaría poder tener una cabina de voto custodiada por un par de agentes con una máquina de voto certificada y revisada periódicamente por terceros en cada pueblo y cada ciudad, y no depender del policía como única autoridad certificadora de la validez de la firma y certificados del DNIe. No obstante creo que pese a las desventajas que pueda tener este sistema, el hecho de poder brindar a la ciudadanía la posibilidad de tener una democracia líquida mediante el Partido de Internet superan con creces las desventajas que pudieran surgir, y por tanto como mínimo vale la pena intentarlo.

Si realmente conseguimos tener tirón, podremos dedicarle muchos más recursos para fortalecer el sistema de votaciones con las medidas que he propuesto anteriormente, pero es algo costoso que no podemos permitirnos incialmente.

Ágora para todos y todos para Ágora

El proyecto nació como una necesidad del PDI, pero nos dimos cuenta que era una herramienta que podría ser útil a mucha más gente y por eso recientemente desligamos el proyecto del PDI, de manera que si bien es un proyecto que cumple nuestros objetivos, otros con intereses comunes son totalmente bienvenidos a colaborar en el desarrollo, que desde el principio ha sido software libre.

Actualmente estamos trabajando sin ánimo de lucro en nuestro tiempo libre unos pocos entusiastas. Tras las elecciones municipales y el 15M ha venido sangre nueva al proyecto y hay mucho más movimiento. Tenemos como colabores a gente del 15M, gente del Referéndum del 15 de Octubre que quieren AgoraOnRails+Verificatum para dicho referéndum, desarrolladores de PIRATA.CAT, puesto que es un partido que también busca la democracia líquida para los temas que queden fuera de su ideario y ya han conseguido dos regidores en Cataluña.

Ágora es un proyecto de software desarrollado con un fin eminentemente social, bastante ambicioso en lo que a seguridad se refiere y que no está terminado, así que todos los entusiastas de la seguridad estáis invitados a colaborar en el desarrollo de un software que a poco que dé sus frutos será muy gratificante verlo ser usado por miles de personas para hacer más democrático el sistema político en el que vivimos.


Artículo escrito por Eduardo Robles

Leer más...

28 junio 2011

Wargame II, recordatorio importante - Campus Party Valencia 2011

Quedan menos de dos semanas para que se celebre Campus Party Valencia en su edición número 15.

La agenda de este año se presenta realmente prometedora. En el área de seguridad y redes desde SbD participaremos una vez más, por un lado en la conferencia sobre "Hackeos Memorables", y por el otro en el reto de seguridad y hacking de Campus Party.

Es importante tener en cuenta que este año el wargame también será accesible desde fuera de Campus Party.

Esta vez hemos decidido llegar a mucha más gente, por lo que el wargame contará con bastantes pruebas de todas las categorías y con un nivel accesible, incluso para participantes que hayan tenido poco contacto con el mundo de la seguridad informática.

Para poder acceder y optar a premios, los participantes deberán estar registrados en la base de datos de Campuseros, y enviar un email a nuestra dirección de correo contacto@securitybydefault.com con su nombre, apellidos y DNI, o, si ya está registrado en la base de datos de Campuseros, con su nick y dirección de email del registro.

Se podrá participar en grupo, aunque para ello deberán registrarse todos los participantes de forma individual.

Y por supuesto, habrá premios para los que consigan ganar más puntos superando pruebas:

-1er premio: 1.000 euros + hardware valorado en 2.000 euros.
-2o premio: 600 euros.
-3er premio: 400 euros.

El concurso se realizará dentro de las fechas de Campus Party Valencia 2011, es decir, entre el 11 y 17 de Julio.

Agradecer una vez más a Campus Party por confiar en nosotros para esta tarea, y, por supuesto, a ESET que  patrocina el área de seguridad.

Durante el concurso podréis dirigiros directamente a nosotros a través de nuestra dirección de correo contacto@securitybydefault.com o de twitter @secbydefault. El hashtag oficial en twitter será #wgsbd2.

- Página del wargame en Campus Party.
- Bases del concurso.
Leer más...

27 junio 2011

DDoS contra Movistar.es ¿Causada o preparada?

Desde la semana pasada Anonymous había convocado y anunciado un ataque de Denegación de Servicio para el domingo 26 de Junio a las 16:30 hora peninsular española. La causa, el despido salvaje que la multinacional española tiene previsto llevar a cabo, dejando en la cola del INEM a nada menos que 8.500 empleados a lo largo de los próximos cinco años.


Para ello, todos aquellos simpatizantes de Anonymous que estén de acuerdo con que es un hecho ante el que hay que manifestarse en contra (quién puede no estar en contra de una barbaridad así), apuntarían sus armas LOIC contra la web de movistar.es como señal de protesta en la fecha/hora señalada.

Evidentemente, los departamentos correspondientes de Movistar, también están enterados y deberían prepararse para el ataque.

Hace unos días, en lainformacion.com, publicaron un artículo en el que nos preguntaban a Chema Alonso y a mí sobre los ataques de Denegación de Servicio, su funcionamiento, y si existían contramedidas.
Aprovechando el hilo del correo que nos enviaban desde lainformacion.com, me estuvo contando Chema Alonso los mecanismos y dispositivos de los que dispone Telefónica/Movistar para mitigar o detener con efectividad este tipo de ataques de Denegación de Servicio.
Ambos coincidimos en que, ya sea usando Akamai como cache o Amazon EC2 como mecanismos de clústering, es posible lograr una protección efectiva (aunque bastante cara) para este tipo de ataques. La conversación con Chema quedó en un: "Bueno pues a ver si resiste Movistar ante la oleada de peticiones de este domingo".

Ayer por la tarde, a eso de las 18:00, la web de Movistar.es ofrecía en su momento de carga una página como el que veis bajo estas líneas:


Sin embargo, era la propia web de Movistar quien servía esta imagen, lo que quiere decir que NO estaba bajo una Denegación de Servicio en ese momento

A eso de las 18:00, contactaba con nosotros José Manuel Rodríguez, coordinador de Medios Sociales de lainformacion.com para conocer nuestra opinión para incorporarla al seguimiento del ataque.

Me gustaría ampliar lo que se publicó en el enlace anterior, ahora con más tranquilidad y detalle:

  • La resolución DNS de www.movistar.es devuelve una única IP: 81.47.192.13. Lo que indica un único punto de entrada a la web.
  • Está claro que Movistar no tiene un único servidor para atender las peticiones de www.movistar.es (y que mucho menos es una sola máquina), por lo que suponemos que será una IP de clúster de servidores, posiblemente nateados por un potente clúster de firewalls o más probablemente de balanceadores.
  • Si efectuamos una consulta a www.movistar.es desde el navegador utilizando Tamper Data para ver las cabeceras, se observa que una de las mismas que devuelve movistar.es, es "Via 1.1 proxy-srnav2np10" y "Proxy Agent Sun-Java-System-Web-Proxy-Server/4.0.2". Esto quiere decir que hay algún elemento intermedio que hace la petición por nosotros hasta el servidor web que corresponda. Esto puede ser un WAF, un balanceador, una caché o simplemente un proxy inverso.
  • Puede que hayan tenido alguna incidencia en alguno de los servidores web (por un excesivo número de peticiones o por cualquier otro motivo) y que mostrara un "sencillo error de página no encontrada" y que ciertas peticiones entraran y se sirvieran correctamente por un servidor que no mostrase problemas.
  • Otra forma de verlo es que la propia gente de Movistar modificó la web, de manera que en vez de tener que servir todos los contenidos de la web, ante una "legión" de peticiones de Anonymous, prefiriesen servir una única página con sólo un corto texto referido a un sencillo mensaje de error.
  • De esta manera podrían luego decir que el DDoS de Anonymous no tuvo efecto alguno en la infraestructura. Desde un punto de vista de pérdida de recursos, es cierto, las peticiones no fueron suficientes para colapsar el servicio web puesto que eran los servidores de Movistar los que servían la "página de error", teniendo recursos y ancho de banda suficiente para hacerlo. Si fuese un DDoS por agotamiento de ancho de banda, no habría respuesta. Sin embargo, puede haber sucedido que lo que haya muerto, sean las máquinas que haya detrás de los servidores web y que siempre devolvieran la página de error mencionada.
  • De todas formas, el efecto es el deseado igualmente, la web de Movistar no da el servicio informativo a sus clientes. Disclaimer: Al menos cuando yo probé, la web de Movistar contestaba a las peticiones, no se notaba ralentización en las conexiones ni que hubiera conexiones que no se llevaran a cabo. Quizá previamente sí que existiera este tipo de comportamiento.
  • Al rato de ponerme a mirar, la página principal se servía correctamente, sin embargo, si pulsabas en cualquiera de los enlaces, ibas a parar a la citada página de error.
En algunos medios de comunicación, se decía que la web de movistar.es había sido tumbada y había quedado inaccesible. La verdad es que yo no llegué a ver esa parte, sino que realmente los servidores de Movistar, contestaban correctamente, incluso bastante rápido. No pude comprobar si cacheaban contenidos en Akamai, como también se pudo leer por twitter, aunque no lo parecía. 
En otros medios se indicaba que no había tenido tanta incidencia como se pretendía y que los mecanismos de defensa utilizados por Telefonica, habían sido efectivos.

La verdad, como en muchos otros casos, nunca la sabremos! Lo que está claro es que en Movistar estaban preparados para hacer frente a la cantidad de peticiones que se venían encima, aunque fuera suicidando el servicio ellos mismos (siempre y cuando mi razonamiento haya sido correcto) para evitar males mayores, como sucedió en el caso del DDoS a la SGAE el año pasado, deshabilitando la ruta. Para la siguiente las mejores opciones: Akamai, Amazon EC2 o CloudFlare como hizo Lulzsec.
Leer más...

26 junio 2011

Enlaces de la SECmana - 77

Leer más...

25 junio 2011

Vuestros "ETHERNET EXPOSED" - II

Volvemos a la carga, estamos recibiendo multitud de contribuciones por vuestra parte, con exactamente lo que queríamos ver: puntos de red ethernet en lugares más que curiosos, y que seguramente en la mayoría de los casos nos deparan una maraña de sistemas y servidores al otro lado.

Vamos a ir publicando asiduamente vuestros ETHERNET EXPOSED, por lo que no dejéis de contactar con nosotros con vuestras instantáneas y una pequeña descripción del lugar.

Al igual que en nuestra primera publicación, en esta ocasión volvemos al médico. Antonio López nos manda una imagen que según él, fue tomada en la sala de espera de un hospital de Madrid.


Como bonus informativo, Antonio nos confirma que este punto daba dirección IP por DHCP...En esta situación, esperar siempre resulta más cómodo ¿verdad? 

Después del hospital, nos vamos de compras. Borja Berastegui nos envía la siguiente foto de un centro comercial de Bilbao:



A continuación citamos directamente lo que él mismo nos comenta acerca de la situación de este ETHERNET EXPOSED, ya que no tiene desperdicio:

"Por el dia suele haber alguien con un portátil atendiendo (es un puesto de información) y por la tarde/noche cuando esta el centro abierto para los cines y así, te dejan el cable puesto, por si necesitas algo..."

No hace falta decir nada más; siempre es un placer que te dejen el cable a mano, ¡por si se nos olvida!

Queremos dar las gracias a Antonio y Borja por enviarnos estas fotos, y al resto de personas que nos han enviado sus imágenes y que tenemos en nuestro buzón de correo listas para ser publicadas tan pronto nos sea posible. Os aseguramos que irán saliendo.
---------------
[+] ETHERNET EXPOSED: Encuentra tomas de red al descubierto
[+] Vuestros "ETHERNET EXPOSED" - I
[+] Vuestros "ETHERNET EXPOSED" - II
[+] Vuestros "ETHERNET EXPOSED" - III
[+] Vuestros "ETHERNET EXPOSED" - IV
[+] Vuestros "ETHERNET EXPOSED" - V
Leer más...

24 junio 2011

Qué no hacer al gestionar incidentes de seguridad

En los últimos tiempos se han presentado distintos incidentes de seguridad que han puesto al mundo en alerta, a las compañías involucradas en la mira y a los datos personales y la privacidad en jaque. Gigantes de la Tecnología y el Entretenimiento se han visto afectados, datos personales robados, tus gustos, intereses y hábitos al descubierto.

El objetivo de presente artículo es analizar distintas acciones que se han llevado a cabo en alguno de los incidentes de las empresas descritas, para identificar en base a estas experiencias, ¿qué cosas no debemos hacer si tenemos que gestionar un incidente de seguridad en nuestra Organización?

1) Ocultar el incidente a los clientes

La primera medida que generalmente se encuentra asociada a un incidente de seguridad es el ocultamiento. Nada peor que esta acción si queremos demostrar que hemos sido diligentes con nuestros datos y con los datos de nuestros clientes. Debemos tener presente que los datos personales son de las personas, no son nuestros y que están a nuestro resguardo.

En algunos casos la situación podría tomar una gravedad extrema en la cual el nivel de exposición deje muy claro que no se estaban cumpliendo regulaciones o cuestiones legales, por ejemplo PCIDSS si dentro de la brecha están incluidos datos de medios de pago que se encontraban en plano.



2) Aumentar las cualidades del atacante


Otra situación que se está presentando frecuentemente es buscar de todas maneras omitir los errores que se hayan cometido por falta de diligencia, conocimiento o cualquier otro motivo. Cuando esto sucede lo primero que se busca es centrar la atención en las hipotéticas características que poseía el atacante, siempre haciéndolo mucho más sofisticado de lo que realmente ha sido. Es decir, aumentar el skill del atacante para minimizar nuestros errores. “Hemos sido víctimas de un ataque jamás visto”, “El atacante poseía conocimientos muy sofisticados”, “Fue Anonymous” etc, etc.


3) Describir medidas de seguridad básicas como "sofisticados" planes de mejora a raíz del incidente


Se presenta frecuentemente el hecho de nombrar como planes de acción asociados al incidente la implementación de medidas de seguridad que ya deberían haber implementado con anterioridad, y que son realmente básicas, por ejemplo: “Implementaremos un sistema de gestión de la seguridad basado en ISO/IEC 27001”, “Utilizaremos técnicas de encripción para los datos de carácter personal”, “Entrenaremos a todo nuestro personal para brindar respuesta a incidentes”. Respuestas de este estilo se pueden encontrar en los comunicados que publican las empresas afectadas, lo que no hace más que evidenciar las debilidades de seguridad y negligencia de quienes debían tomar otras acciones y en otros momentos. Está claro que cualquier Organización que deba cumplir leyes o regulaciones como PCIDSS, SOX, u otra similar, ya debía contar con este tipo de medidas de seguridad.


4) No aceptar las equivocaciones


Algo que parece tan simple no se da frecuentemente, lo que el cliente espera más allá de excusas, ocultamiento, mentiras e hipótesis falsas, es que la organización que tuvo el incidente, lo comunique a tiempo, en forma sincera y aceptando los errores que pudiera haber cometido. Es así, “No supimos cuidar sus datos, hemos cometido errores, les pedimos perdón y tenemos todos nuestros recursos a su disposición para cubrir el error y mantenerlo como cliente”. ¿Cuántas empresas están dispuestas a comunicar esto a sus clientes?


5) Ofrecer compensaciones que no están a la altura del incidente


A todo lo que venimos comentando habría que agregar que en varios casos se han presentado planes de compensación para los clientes que realmente parecen una burla, “Welcome Again” “Free Content for Ever”, “Membership Gold”, etc. Al momento de establecer dichos planes se debe priorizar al cliente, no se debe seguir especulando sabiendo que no hicimos lo que debíamos y sumado a esto ofrecer lo que más cómodo nos queda para “mostrar” que estamos preocupados. Debemos estar preocupados y debemos ofrecer un plan de compensación que realmente esté a la altura del impacto provocado.


6) Seguir pensando que la Gestión de Incidentes es un tema menor o que corresponde sólo a IT


Las Organizaciones que mantienen esta postura son aquellas en las cuáles los Directivos aún no han interpretado que la Seguridad de la Información es una prioridad y les compete a ellos por la función que ocupan, gestionar el riesgo y conocer en todo momento la postura de seguridad de su Organización, en definitiva de su negocio.
De este tipo de Organizaciones podríamos recibir “acciones de mejora” tales como “Hemos nombrado un nuevo CSO (Chief Security Officer) que reportará al CIO (Chief Information Officer)”. Lo que demuestra errores conceptuales profundos y que afectan los principios básicos de la seguridad y el control interno.

¿Alguien puede seguir pensando luego de la brecha de la PlayStation Network que la gestión de incidentes es un tema netamente técnico y de IT?


¿Y las tarjetas de pago?


Otra cuestión que también llama la atención es que las Compañías involucradas en forma indirecta, como por ejemplo V1S4, M4st3rC4rd, 4m3r1c4n 3xpr3ss, etc. no emitan ninguna comunicación al respecto.

¿Acaso PCIDSS no surgió debido a las distintas brechas de seguridad que han involucrado datos de tarjetas de pago?

¿Acaso cumplir PCIDSS no hubiera minimizado el impacto de la brecha en el caso de 50NY?


¿Cómo se deberían tomar los incidentes?


A día de hoy, los incidentes se deberían tomar como algo que en algún momento va a suceder, no sigue siendo válido pensar que lo que hacemos o lo que haremos es para no tener incidentes, eso es imposible. Se presentarán incidentes y lo que debemos hacer es establecer los mecanismos, procesos y medidas de seguridad para dar respuesta en forma oportuna y diligente. Esa respuesta a incidentes no la dará únicamente ITOrganización. Así como se aprende de un error o equivocación en la vida cotidiana (o al menos deberíamos), en el caso de los incidentes es fundamental aprender y mejorar.


"Un incidente no se puede presentar 2 veces, sin haber hecho algo al respecto”.


La implementación de un sistema de gestión de la seguridad basado en los riesgos a los que está expuesta la Organización, contemplando en todo momento los requerimientos legales y regulatorios, podría ser el camino a seguir para iniciar la gestión continua y diligente que como Organización debemos brindar a la información propia al igual que la de los clientes.


"La Gestión de la Seguridad no es de única vez o porque debo cumplir, es un proceso contínuo”.



Referencias (no es necesario reinventar la rueda):



--------------------------
Contribución gracias a Mariano del Río
Leer más...

23 junio 2011

No te fíes de NADA

1. f. Cualidad de fiable.
2. f. Probabilidad de buen funcionamiento de algo

Es francamente sorprendente como en el mundo digital la gente tiende a asignar unos niveles de fiabilidad altísimos a cosas que en realidad no los merecen.

Si pensamos en el mundo físico, casi cualquier persona sabe que un remitente en un sobre solo significa que alguien ha declarado que esa carta proviene de esa persona, pero no tiene porque ser real.

En el mundo digital las cosas no son diferentes: El remitente de un correo electrónico se puede falsificar, el número origen de un SMS es igualmente falsificable. Incluso el número que aparece en el display de tu teléfono durante una llamada puede no ser el autentico, de hecho hasta la voz puede no ser real.


Fake Mailer es una web desde la que se puede enviar un correo electrónico empleando como origen cualquier dirección. Incluso se puede especificar cual cliente de correo queremos que aparezca como origen (Outlook, thunderbird, etc)



Fake MSG (de pago) es una web que permite el envío de SMS cuyo origen lo podemos editar a nuestro gusto, pudiendo poner desde el 091 de la policía hasta cualquier otro número de móvil que queramos.


Y aquí la joya de la corona: SpoofCard. Esta web permite elegir el Caller-ID (número que aparece en el display) de una llamada a nuestro gusto pudiendo hacer que la llamada tenga el origen que queramos, tanto números de móvil como de telefonía convencional. Adicionalmente incluso permite grabar la conversación y cambiar el tono de la voz pudiendo hacer que un hombre suene como una mujer y viceversa.

Sin duda, estas herramientas pueden ser extremadamente útiles para hacer un ataque de ingeniería social. No te fíes de nada
Leer más...

22 junio 2011

Vigilando tu casa con Rovio

Tiempo llevaba dándole vueltas a la posibilidad de comprar otra Roomba, lo más barata posible, vieja, de segunda mano, o como fuera,.. únicamente para trastear, puesto que la otra tiene la importante misión de dejar la casa limpia diariamente.

La idea era ponerle una webcam y poderla guiar por casa en remoto y que me muestre cómo está todo. Comentando esto con mi amigo Alex me comentó que había ya un robot llamado Rovio con webcam integrada, que a lo mejor me interesaba más para añadir a la colección de bichos que conforman el Skynet de mi casa, en vez de repetir con otra Roomba.

Buscando diversas opciones en Amazon, Ebay, etc,… el precio no bajaba de los 160 euros, hasta que en segundamano dí con un chico de Madrid que tenía uno sin usar, por bastante menos dinero. Así que quedé con él y nos pegamos un domingo por la tarde probándolo en su casa. La unidad tenía bastante buena pinta así que dije: para mí!

La configuración del cacharro se hace bastante rápido vía wireless, permitiendo cifrados WEP, WPA y WPA2.

Los únicos puertos abiertos son:

[root@Carmen ~]# nmap -sT 192.168.1.13

Starting Nmap 4.20 ( http://insecure.org ) at 2011-06-17 08:20 CEST
Interesting ports on 192.168.1.13:
Not shown: 1695 closed ports
PORT    STATE SERVICE
80/tcp  open  http
554/tcp open  rtsp
MAC Address: 00:12:34:56:78:90 (CyberTAN Technology)
Para manejarlo se utiliza una interfaz web que proporciona mediante el servidor web embebido en el propio robot.




Trasteando con Tamper Data por ejemplo, se puede ver que el mecanismo de comunicación para dar órdenes al robot es muy sencillo.

Han implementado Basic Authentication en HTTP para poder acceder al panel, y son todo el rato llamadas a un CGI modificando dos parámetros: action y drive (opcionalmente está el parámetro "speed" que por las pruebas que he hecho no da para mucho más).

Así pues hice un programilla "supercomplicado" en perl que permite hacer que el bot se mueva para donde queramos según le pases por comando

[root@Carmen ~]# more rov.pl 
#!/usr/bin/perl
use LWP::UserAgent;

$IP_Rovio="192.168.1.13";
$Auth="Elhashquetoque";

my $url="http://".$IP_Rovio."/rev.cgi";
my $browser = LWP::UserAgent->new;
my $response = $browser->post(
    $url,
    "Pragma" => "no-cache",
    "Cache-control" => "no-cache",
    "Authorization" => "Basic $Auth",
    "Content" => [Cmd=>'nav', action=>'18', drive=>$ARGV[0]] 
);
Para hacer que se mueva, el parámetro action tiene que ser = 18.

En el parámetro drive decimos la dirección hacia donde tiene que ir. Fuzzeando dicho parámetro vemos lo siguiente:

1 adelante
2 atrás
3 izquierda
4 derecha
5 rota a la derecha (muy poquito. 1 grado?)
6 rota a la izquierda (muy poquito. 1 grado?)
7, 8, 9 y 10 hace moverse el robot a izquierda y derecha empujando con dos de las ruedas en vez de con una sola. Es parecido a 1, 2, 3 y 4
17 Rota a la derecha unos 15 grados (Necesario después de un action=33 para cancelar un Go_Home)
18 Rota a la izquierda unos 15 grados

La webcam que trae incorporada dispone de tres posiciones: abajo, media o levantada. Para seleccionar la posición, con el parámetro action=18, pasamos los valores 11, 13 y 12 al parámetro drive para hacer que esté arriba, a media altura o abajo del todo, respectivamente.

Si queremos encender o apagar un "led" que trae para poder ver algo mejor lo que la cámara envía, haremos la llamada con action=19 y un parámetro LIGHT con valores 0 ó 1.

Si simplemente queremos monitorizar el estado del robot, pasamos el valor 1 al parámetro action y nos devuelve algo como lo siguiente:

[root@Carmen ~]# perl rov.pl   
Cmd = nav
responses = 0|x=-385|y=413|theta=-0.347|room=0|ss=43
|beacon=22|beacon_x=5183|next_room=-1|next_room_ss=0
|state=0|ui_status=0|resistance=0|sm=15|pp=0|flags=0007
|brightness=6|resolution=0|video_compression=0|frame_rate=5
|privilege=0|user_check=1|speaker_volume=21|mic_volume=20
|wifi_ss=199|show_time=0|ddns_state=0|email_state=0
|battery=116|charging=0|head_position=203|ac_freq=1
Entre otras cosas, la batería que le queda, si se está cargando o no, datos de la potencia de señal wireless, el volumen del altavoz y del micrófono (se supone que puedes hablar con la gente a través del robot estando conectado al interfaz web desde donde sea), etc,…

Rovio permite además hacer un snapshot de lo que la cámara está viendo en ese preciso momento y enviarlo a una dirección de correo electrónico predefinida. Para eso el valor del parámetro action debe ser 26.

Para hacer que el robot vaya a su dock a cargarse, hay que enviar en action el valor 13.

El streaming de lo que va mostrando la webcam incorporada en el robot, se puede ver mediante http://IP_Del_rovio/GetData.cgi?width=640px&height=480px afinando la resolución deseada.

Ya hay aplicaciones para controlar Rovio desde iPhone y desde Android, aunque con todos estos datos que hemos comentado, deberíamos ser más que capaces de hacer cualquier otro tipo de interfaz de comunicación con el robot: como un programa en modo texto mediante teclas por ejemplo; o que cuando estemos de vacaciones haga un recorrido diario predefinido, que vaya haciendo snapshots y nos los vaya enviando por email,… O incluso se puede tener otro programa que coja todas esas imagenes y genere un video, que sea lo que recibamos finalmente en nuestro correo. De esa manera podríamos ir recorriendo el recinto y ver el estado en fotos de las habitaciones deseadas, que como podéis imaginar, es algo que el cacharro no es capaz de hacer por si solo.

La gracia de este tipo de robot es poder utilizarlo cuando no estás en casa y moverte con él. Sin embargo, al ser el interfaz de configuración y monitorización a través de HTTP y la autenticación básica, quizá no sea una buena idea el mapear un puerto del router directamente al servidor web del Rovio y dejar en manos de la bondad del mundo que un ataque de fuerza bruta/diccionario permita sacar la contraseña y el robot se mueva por casa a voluntad de otros.

En mi caso, que desde mi Mac puedo realizar una conexión VPN hasta mi casa, no hay problema, porque no tengo que exponer ningún servicio nuevo hacia fuera. Sin embargo, desde el iphone me gustaría acceder de forma directa.

Para ello he establecido alguna medida de seguridad extra para asegurar que desde fuera soy yo y solo yo quien accede.

Dispongo de un PC entre las redes confiables de casa y el router que me conecta a Internet. En él, tengo un Apache al que he realizado las siguientes modificaciones en el fichero httpd.conf:

<virtualhost ip_externa:puerto>
ServerName lorenzomartinez.es
ProxyRequests Off
SSLEngine on
SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP
SSLCertificateFile /unaruta/serverpem.pem
SSLCertificateKeyFile /otraruta/serverkey.key
SSLCACertificatePath /otrasrutamas/_ssl_.crt
SSLCACertificateFile /laultimadelasrutas/ca.crt
SSLVerifyClient require
SSLVerifyDepth  10
SSLOptions +OptRenegotiate
ProxyPass / http://192.168.1.13/
ProxyPassReverse / http://192.168.1.13/
CustomLog logs/rovio_log combined
</virtualhost>

Lo que hemos hecho es crear un Virtualhost que requiere un certificado SSL X.509  de cliente, firmado por una CA interna que, si todo es correcto, y gracias a mod_proxy, Apache hará las peticiones al servidor del robot Rovio. La comunicación hasta mi casa va cifrada y autenticada con el certificado SSL y entre mi máquina y Rovio, va por HTTP con cifrado WPA2 establecido por la propia red wireless.
Ya comentamos hace tiempo en SbD qué herramienta se puede utilizar para introducir el certificado digital en el iPhone. Otra opción sería dejar el certificado accesible en un servidor web  privado y añadirlo al keystore del iPhone.

Conclusiones:
  • La idea de tener un robot en casa que puedas manejar desde donde estés, suena muy friki y permite pensar en cuánto juego te va a dar.
  • El precio del robot es bastante elevado, a no ser que encuentres uno de segunda mano (aunque en perfecto estado) a muy buen precio como el que compré yo, ni se me pasaría por la cabeza comprarlo
  • Como webcam wireless que es, podría integrarlo y dejarlo activo como una webcam más controlada por Motion, y si detecta un movimiento, que avise. El problema es que cuando diéramos una vuelta con el robot, manualmente, daría un montón de falsos positivos
  • Se supone que las baterías las cargas durante 4 horas y media, el robot dura una hora y media moviéndose. En mi caso, el robot no termina nunca de cargar las baterías, permaneciendo un montón de luces encendidas del mismo (de noche parece una nave espacial como podéis ver en la foto de arriba). Por supuesto la batería dura menos de lo deseado y de lo especificado.
  • Leyendo (a posteriori… damned!) las experiencias de otros compradores de Rovio en Amazon, dan ganas de no comprarse un bicho de estos: Efectivamente la batería dura 15 minutos, el soporte de WowWee es lamentable, tardan semanas en contestar y finalmente te dicen que no es su problema, la calidad de la webcam es bastante mala cuando aun a ojos humanos hay suficiente luz.
  • Existe un accesorio que permite añadirle más luz al robot (incluso le da un aire a Johnny Número 5), y así poder monitorizar el recinto de noche. Sin embargo, el artículo está descontinuado y no hay manera de comprarlo, al igual que cualquier otro Rovio, lo cual tampoco aporta mucha fe en este tipo de producto. En Hackaday publicaron un DIY para añadirle más leds que permitan ver algo cuando las condiciones de luz empiezan a flaquear.
  • La calidad del producto no es ni de lejos la de la Roomba. Rovio cuando está en modo: "vete al dock", se nota que cuando choca con un obstáculo, tarda en detectar que eso ha pasado y que tiene que intentar moverse hacia otro lugar. Roomba en cambio, detecta cuándo va a chocar, ralentiza su movimiento para impactar despacito y gira sobre sí misma para buscar otra forma de llegar a la base. Además para poder ir al dock de forma directa, Rovio necesita tener diferentes captadores que le guíen en diversas habitaciones, en cambio Roomba va buscando con calma donde está la base cuando pueda.
  • Como ventaja ante Roomba es que Rovio trae un interfaz wireless ya incorporado, y no hay que hacer malabarismos para lograr algo vía bluetooth como en el caso del "robot redondo"
  • En definitiva, Rovio es un producto con más ambición invertida en el márketing que en la calidad del producto en sí (parece demasiado de juguete), la parte del audio sólo funciona con Internet Explorer, no tiene un modo standby,…
  • Una pena que en mi búsqueda de un novio para mi Roomba, me haya equivocado con un robot mediocre que sólo puede funcionar de día, poco rato, y con todas las luces puestas. 
  • Afortunadamente, el chico que me vendió el Robot me ofreció la oportunidad de devolvérselo si el equipo no cumplía con mis espectativas. Después de hablar con él, y a la vista de los problemas del robot, y de manifestarle que efectivamente, no me va a valer para mucho en estas condiciones, no sólo me ha dicho que me devuelve el dinero, sino que si el producto no da buen resultado, y dado que para él también fue un regalo y que ve que a mí me encantan estas cosas y que "lo vivo", me quede además con el robot. Es increíble y loable que queden personas así de honradas en este mundo! La verdad es que pasamos una tarde de domingo bastante divertida inicializando el cacharro (casi me tengo que quedar a ver la Fórmula 1 en su casa!). Me contó que tenía un grupo de música llamado "Ojos de Gamba" e incluso me regaló un disco! Muchísimas gracias Israel!
Leer más...

21 junio 2011

Seguridad en sockets TCP

En alguna ocasión, bien porque necesitamos desarrollar una solución cliente / servidor, o bien porque queremos implementar otro servicio conocido, tenemos que programar un servidor TCP. Hay una serie de buenas prácticas que nos pueden ayudar a conseguir una mayor estabilidad frente a ataques o saturación del servicio.

Si participasteis en el primer wargame de SbD que organizamos hace unos meses, recordareis la primera prueba de networking que se trataba de un servidor que emulaba ser la configuración de un router. Estas buenas prácticas de las que hablamos fueron implementadas y, puede que gracias a ello, el servidor estuvo activo constantemente durante todo el concurso.

Está programado en ruby, y vamos a tomarlo como ejemplo. Hay que tener en cuenta que, al ser ruby un lenguaje de alto nivel, es posible que no necesitemos solucionar problemas que pueden darse en lenguajes de otro tipo, o de bajo nivel. Dicho ésto, ¡empezamos!

La estructura del programa es algo parecido a esto:

login
if correcto
  bucle
    menu
    leer_opción
    realizar_acción
  fin
fin

Como de casualidad el servidor está a la escucha y cuando recibe una nueva conexión crea un hilo nuevo para servir a ese cliente y volver a ponerse a la escucha.

server = TCPServer.new("", srvport)
loop do
  socket = server.accept
  if socket
    newclient(socket)
  end
end

En este caso la función newclient() toma el socket y crea el hilo.

Uno de los problemas que podemos encontrar en este punto es que si se reciben muchas conexiones de forma simultánea, se crearán más hilos de los que el lenguaje o el sistema puede soportar, por lo que el programa morirá.

Ésto depende mucho del lenguaje de programación y de la versión. Por ejemplo, en versiones antiguas de ruby sucedía, pero en las versiones más modernas parecen haberlo controlado de alguna forma.

Las soluciones que podemos tomar son variadas. Personalmente la que más me convence es poner un pequeño tiempo de espera entre que se acepta la conexión y se crea el hilo. Nuestro código quedaría de la siguiente forma:

server = TCPServer.new("", srvport)
loop do
  socket = server.accept
  sleep(0.05)
  if socket
    newclient(socket)
  end
end

Aunque controlemos el número de conexiones al incio, puede que alguien con malas intenciones realice conexiones y luego las deje sin actividad. Ésto podría causar que se llegara al límite de conexiones que soporta el sistema, haciendo que quede saturado.

Para solventar este problema podemos usar timeouts por inactividad, de forma que si un usuario no muestra actividad durante X tiempo, se cierre el socket y el hilo muera. Para ello, hice una función alternativa para leer del socket.

def read_socket(s, thread, tout = 15, size = 500)
  begin
    Timeout::timeout(tout) do
      info = s.recv(size)
      return info
    end
  rescue Timeout::Error
    s.close
    thread.kill
    return false
  end
end

La función recibe el socket y el hilo como parámetros, también podemos pasar el tiempo de timeout y el tamaño de lectura del socket. Si se supera el timeout se cierra el socket y se mata el hilo.

En nuesto caso particular hay otra cosa más con la que hay que contar. ¿Y si se crean conexiones de bots que entran en el bucle y realizan acciones para que no se les expulse por timeout?

Teniendo en cuenta esa posibilidad, la solución pasa por limitar el número de interacciones en el menú. En este caso estaba limitada a 50.

Tomando estas precauciones podemos conseguir un servicio bastante estable y resistente a ataques o saturación. ¿Conoces o sigues más medidas? ¡Compártelas en los comentarios!
Leer más...

20 junio 2011

Cómo registrar cualquier número de teléfono en WhatsApp

Seguimos con nuestra campaña de marketing viral sobre WhatsApp, hoy le toca al sistema de registro de usuarios.

En anteriores capítulos de SbD VS WhatsApp hablamos sobre:

En este post vamos a contar lo fácilmente que se puede registrar en la red WhatsApp cualquier número de teléfono, y cuando digo cualquier número me refiero a un número de teléfono ficticio, tu propio número o el de otra persona (pudiendo enviar mensajes en su nombre y recibir los destinados a el).

El objetivo del post es poder registrar un número de teléfono ficticio dentro del emulador de Android para tener WhatsApp en el PC. Evidentemente lo explicado aquí también sirve para suplantar el número de otra persona, así que tan solo me gustaría reseñar que probablemente hacer eso sea un delito. A partir de aquí ancha es Castilla.

Como todo usuario de WhatsApp sabe, para validar la instalación WhatsApp genera un auto-envío de un sms desde tu número de teléfono que sirve como elemento probatorio de que el número te pertenece, y por tanto, completar el registro en WhatsApp.

Por si este método no fuese confiable o fallase, WhatsApp permite alternativas, en concreto si echamos un vistazo a la FAQ nos encontramos con esto:

Ehmm Significa esto que si yo envío un SMS con un origen arbitrario y en el cuerpo del mensaje pongo un correo, ¿me enviarán a ese correo un pin para registrar ese número? Really ?

Pocas cosas en esta vida son menos fiables que un SMS, falsificar el origen de un mensaje es algo trivial, hay múltiples plataformas online disponibles que permiten hacer eso. A nosotros nos gusta la de lleida.net

Esquemáticamente el proceso para registrar un número arbitrario en WhatsApp (probado en un terminal Android y en el emulador) se resume en esto:

-Instalamos la aplicación 

-Ponemos como número de teléfono el que deseamos registrar

-Esperamos pacientemente (9 minutos) a que el proceso de validación por auto-sms falle

-Solicitamos el acceso a Pin por llamada

-WhatsApp lanzará el proceso de llamada a un número con prefijo 93, colgamos inmediatamente la llamada ya que no nos sirve de nada (si usamos el emulador esa llamada nunca ser hará, si es un terminal normal, hay que estar atento)

-Hacemos el envío del sms-spoof con origen [Número deseado] destino +44 7900 347295, cuerpo del mensaje un correo electrónico

-Introducimos en WhatsApp el Pin que nos ha llegado por correo

En este vídeo hay una demostración práctica de todo el proceso para registrar un número ficticio dentro de WhatsApp, he escogido un número con un prefijo 682 debido a que, a día de hoy, no se encuentra asignado / en uso por parte de ninguna operadora



Aunque la tentación es dura, (todos tenemos ex-novias/os, enemigos irreconciliables, etc) no hagáis el mal registrando números que pertenezcan a otras personas !

UPDATE: Este método ya no funciona porque WhatsApp parcheó el bug
Leer más...

19 junio 2011

Enlaces de la SECmana - 76


Leer más...