Para hoy tenemos una nueva encuesta, que pueden contestar en esta entrada y en la columna de su derecha. La encuesta dice así:

¿Qué opinas de los congresos, jornadas, seminarios... de seguridad que actualmente hay en el panorama nacional?

• Algunos están bien, pero fastidia que solo hablen los patrocinadores... y para contar su libro. (51%, 33 Votos)
• Son apasionantes y muy en línea con la demanda del mercado y las inquietudes tecnológicas del sector. (18%, 12 Votos)
• Son tan útiles como un teclado sin intro. (17%, 11 Votos)
• Sólo se aprovechan comercialmente, en la hora del café (que ahora se llama coffee break). (14%, 9 Votos)

Votantes: 65

 Loading ...

Respecto a la encuesta anterior, los resultados se dividen entre los optimistas, que consideran que podremos mantener la privacidad en el futuro siempre que queramos renunciar a ciertos servicios, y los pesimistas, que piensan que hagamos lo que hagamos, es una batalla perdida. Como tercera alternativa, la idea de que la pérdida de la privacidad es algo positivo que es inherente al progreso que incorporan las nuevas tecnologías no parece tener demasiados seguidores, ya sea porque nadie considera en realidad que tal pérdida pueda ser considerado un avance, o porque las otras opciones estaban más definidas.

¿Está nuestra privacidad condenada a desaparecer?

• No, siempre que se esté dispuesto a renunciar a ciertos servicios. (53%, 57 Votos)
• Sí, nos forzarán a ello queramos o no. (42%, 45 Votos)
• Sí, pero es algo beneficioso que se llama progreso. (5%, 5 Votos)

Votantes: 107

 Loading ...

¡Esperamos sus respuestas!

Seguimos hablando de nuestro anonimato en Internet y de las diferentes formas existentes de identificación de usuarios que existen. En este caso, llegamos a este paper donde se explica como se puede llegar a obtener una “huella digital” de los usuarios que visitan una página web. El investigador Peter Eckersley se dio cuenta de que los
navegadores proporcionan mucha información sobre su configuración a la hora de visitar una página web, y que esta información puede utilizarse para identificar al navegador de forma única, y si entendemos que este navegador solo lo utiliza una persona o un conjunto de ellas, podríamos identificar a dicho usuario, o en el peor de los casos a la máquina utilizada.

En uno de los últimos portales web que he tenido que desarrollar una de las principales premisas era que tenía que ser muy seguro. El nuevo portal tenía que suplir a una versión hecha en html puro, sin código en el servidor. ¿Para qué cambiar si la versión anterior ya era segura? Tampoco entraré en más detalles pero, ¿os acordáis de esas “bonitas” webs con montones de gifs animados y colores espartanos? Esas páginas eran bonitas al lado de esta. Al grano. Para el desarrollo del nuevo portal se estuvieron haciendo pruebas con varios CMS (Gestores de contenidos) en PHP. ¿Por qué en PHP? Pues porque los recursos del servidor eran limitados, y porque me gusta. Al final nos decantamos por Drupal, ya que ofrecía a priori una robustez y seguridad que otros no. ¡Ah!, y porque me gusta.

Una vez tenía el portal ya bastante terminado, me puse a indagar como podía añadirle más seguridad. Al final, en todos los gestores terminas instalando una infinidad de “plugins” (módulos) hechos por terceros que, aunque sea una comunidad muy rápida en resolver los problemas de seguridad, siempre existe cierto riesgo. Fue entonces cuando di con un módulo de Drupal llamado PHPIDS. El módulo actúa de “envoltorio” del programa PHPIDS.

Recientemente he tenido la ocasión de leer un artículo titulado “Risky business” (Leah Hoffmann, Communications of the Association for Computing Machinery). Ya os adelanto que poco o nada tiene que ver con la película con la que comparte nombre y que protagoniza Tom Cruise. Este artículo ha sido publicado en la revista CACM (Communications of the Association for Computing Machinery) y como ya hemos hablado de esta revista en un post anterior, aprovecho para indicar que CACM es una publicación mensual con alrededor de 80.000 suscriptores donde podemos encontrar muchos artículos relacionados con la computación y los sistemas de información.

El artículo en cuestión, Risky Business, trata distintas cuestiones relacionadas con los ataques informáticos. Se citan, a modo de ejemplo, algunos de los ataques más sonados del último año:

Estimados lectores, el post de hoy parte del artículo “Privacy and Security, Security Risks in Next-Generation Emergency Services” escrito por Hannes Tschofenig [ver enlace $] y publicado en Communications of the ACM el pasado noviembre. En éste trataremos de plantear estudiar las implicaciones que conlleva la evolución del servicio 911 de un entorno “analógico” a un entorno “digital” 2.0.

La arquitectura a alto nivel de esta versión 2.0 del servicio 911 fue aprobada en Junio por la National Emergency Number Association (NENA), el nombre elegido es arquitectura “i3” y en ella básicamente se detallada cómo interactúan las redes y servicios para dar soporte a los ciudadanos. Dicha evolución conlleva una serie de riesgos propios de las nuevas tecnologías a soportar tales como los inherentes a la infraestructura del VoIP, o el uso de redes sociales.

Siguiendo con la entrada que publicamos ayer sobre empresas que se dedican a recopilar digitalmente información de los usuarios, no podemos olvidar a otrasempresas más del “mundo analógico” que ejercen este tipo de actividades. Muchas veces estamos preocupados, y con razón, por nuestra privacidad en las redes sociales y en la vida real. Sin embargo, descuidamos otros aspectos que también pueden ser dañinos para nosotros o por lo menos bastante molestos. Esto es lo que a mí, que soy bastante cuidadosa con todo el que llama a mi puerta y con las fotos y comentarios que publico, me ha pasado.

Llevo un tiempo pensando en cambiar el seguro de mi coche a otra compañía más barata, así que se me ocurrió la feliz idea de solicitar información a un conocido comparador de seguros, llamémosle COMPARATUS.COM. Tras rellenar un formulario con ciertos datos personales obligatorios, ayer recibí el siguiente email:

Como se ha hablado en artículos anteriores (véase la serie sobre sistemas de monitorización social), hemos visto que existen diferentes sistemas de monitorización utilizados por los gobiernos para poder “garantizar la seguridad del estado”. Pero, ¿existen algunos sistemas más accesibles a la población de a pie?

Seguramente algunos de ustedes ya habrán oído hablar de RapLeaf, pero para aquellos que aún no sepan de su existencia, podemos decir a grandes rasgos que es una compañía cuyos beneficios provienen de la utilización de nuestros datos en Internet. RapLeaf construye bases de datos sobre individuos con toda aquella información de los usuarios que existe en Internet, como pueden ser redes sociales, historiales de compra o interacciones entre las diferentes webs.

Me gustaría compartir con vosotros unas reflexiones sobre el uso de ataques a cliente hoy en día en las pruebas de “Ethical Hacking”. Lo primero de todo es aclarar que cuando hablo de ataque a cliente me refiero a pruebas diseñas explícitamente para atacar al usuario final de una organización, donde estas pruebas o ataques pueden buscar cualquier usuario de la organización o buscar determinados perfiles (ataques dirigidos), como administradores de sistemas, directivos, responsables del departamento de compras, etcétera. Además, estas pruebas o ataques combinan ingeniería social y técnicas de explotación de software cliente para conseguir objetivo.

Una vez introducido el concepto de “ataque a cliente”, desde mi punto de vista no incluir este tipo de pruebas dentro de la batería de pruebas de un “Ethical Hacking” significa que no estamos poniendo a prueba nuestra organización frente a la vía principal de infección y ataque en la actualidad. Normalmente se contemplan pruebas sobre nuestras aplicaciones Web, sobre nuestro sistemas situados en el perímetro y sobre nuestra red interna; estas pruebas son totalmente necesarias, pero me pregunto ¿son suficientes? ¿nos hemos puesto a prueba realmente? Podemos estar aplicando muchas medidas de seguridad a diferentes niveles pero, ¿son efectivas ante un ataque a cliente?

Seguramente los más técnicos del lugar me dirán de todo por escribir un post tan genérico pero como ya se sabe que “en casa del herrero, cuchillo de palo”, vengo a invitar a todos los lectores del blog a aprovechar los buenos propósitos de año nuevo para cambiar todas esas contraseñas que nunca cambiamos y hacer una puesta a punto de la seguridad domestica: wifi de casa, PIN y código de desbloqueo del móvil, pines de tarjetas de crédito, contraseña y firma digital de banca online, esa cuenta de Ebay con la que hace años que no compramos, contraseña de administrador del equipo del niño, correo personal, contraseñas de foros varios, contraseña del control parental de los canales de pago, etc.

Y es que por norma general cambiamos periódicamente las contraseñas del trabajo pero en el ámbito doméstico la palabra “periódicamente” no existe, así que toca apuntar en el calendario cuando cambiar las contraseñas de casa, o establecer fechas señaladas como año nuevo, cumpleaños, primer fin de semana de liga o cada vez que empiezan a anunciar fascículos coleccionables por televisión.

Estos días he estado jugando un poco con Cymothoa. Para quien no lo conozca, esta herramienta te permite inyectar un payload dentro del espacio de direcciones de un proceso, o dicho de otro modo, troyanizar un proceso en Linux. Cymothoa está desarrollada en C y se encuentra disponible en Backtrack 5 dentro de /pentest/backdoors/cymothoa. (N.d.E. A su derecha pueden observar una imagen de una Cymothoa Exigua, un parásito que se adhiere a la lengua de determinados peces, la atrofia y acaba por reemplazarla por sí mismo, como si fuese un órgano más. Si tienen curiosidad, gogleen y verán que bicho tan interesante.)

Al no encontrar mucha información sobre su funcionamiento estuve indagando un poco sobre el código para ver exactamente como trabaja. La idea de esta herramienta es sobrescribir directamente el base address de alguna de las librerías utilizadas por el proceso, siendo por defecto el “dynamic linker/loader” (/libr/ld*.so). Los payloads utilizados por Cymothoa están embebidos en el propio binario y pueden verse con el parámetro -S aunque, como veremos a continuación, podremos incorporar los nuestros sin mucho esfuerzo: