Ya tiene unos días (y solución) pero quede aquí a título de inventario: Researchers attack my iPhone via SMS: mediante el envío de un mensaje especial el teléfono queda a merced del atacante (mediante más mensajes de control). Lo vi en Vulnerabilidad en los iPhone vía SMS.
Ya habíamos hablado de ataques a teléfonos de la marca Nokia en ‘Regalos’ navideños de seguridad y también a routers, Cross Site Scripting por SMS.
En HTTPS Data Exposure – GET vs POST un resumen rápido de la exposición de los datos que se transmiten mediante el protocolo cifrado https considerando GET, POST, si la conexión va cifrada o no y los diversos participantes en la transmisión y recepción.
Alguna empresa ya lo hacía (o decía que lo hacía, por ejemplo, lo contábamos en Gusanos: las defensas de IBM y HP . Me suena haber puesto algún ejemplo más pero no lo encuentro). Ahora nos cuentan una iniaciva en Australia, ¿PC infectado? Fuera de la red en Australia. No tengo muy claro cómo se vería esto por aquí (aunque a los políticos les ronda por la cabeza eso de desconectar a los usuarios de P2P). Supongo que complementado con un buen servicio de desinfección y reconexión podría tener su gracia.
Sin olvidar, claro, que se desconecta a los que tienen lo malo conocido, no las cosas malas que los antivirus/detectores y otros cacharritos no son capaces de detectar en un momento dado. Y sin olvidar también que siempre puede haber falsos positivos (gente que de positivo en las alertas sin estar infectado ni ser infecciosa).
En 10 add-ons for Firefox: Privacy and security. Ya conocía algunas pero me ha parecido especialmente interesante (a falta de probarla) la de BetterPrivacy por aquello de las cookies de Flash que los navegadores no manejan especialmente bien.
Ya habíamos hablado de Extensiones de Firefox que cuidan nuestra seguridad e intimidad y de Más extensiones de Firefox para la seguridad.
En State of the Art Post Exploitation in Hardened PHP Environments se habla del trabajo de Stefan Esser sobre fallos de seguridad y ataques realizados en instalaciones de PHP previamente fortalecidas. Es bastante técnico (al menos para mi) pero me pareció interesante la primera parte, donde hace un repaso de las medidas de protección disponibles en el lenguaje actualmente (y sus defectos y debilidades).
En HP researchers develop browser-based darknet y en un montón de notas, la verdad se habla de la idea de dos investigadores de HP, Billy Hoffman y Matt Wood sobre la posibilidad de establecer una de estas redes mediante tecnología web (HTML 5 y algunas cosas más) y los navegadores: en principio eso supone un avance a la hora de montar la infraestructura (no hace falta grandes conocimientos) y la dota de mayores niveles de descentralización; las aplicaciones de la darknet corren sobre el navegador.
Se puede descargar la presentación de Veiled en BlackHat (pdf) que da algunos detalles técnicos pero no he encontrado más información sobre el tema.
A mi me ha recordado aquellos experimentos sobre computación distribuida en el navegador que contábamos en ¿Me prestas unos ciclos? Hacia el supercomputador sigiloso y en ¿Me prestas unos ciclos? Hacia el supercomputador sigiloso.
En Estudio comparativo: ¿Cuánto tardan los grandes fabricantes de software en arreglar una vulnerabilidad? hablan justamente de eso. No es un estudio definitivo porque se habla de las vulnerabilidades informadas a través de un par de servicios de compra de este tipo de fallos, iDefense Vulnerabity Contributor Program y The Zero Day Initiative lo que deja fuera unas cuantas que no siguen ese camino y que, además, probablemente son públicas (estos sitios utilizan una política de divulgación ‘responsable’) y ejercen más presión sobre los fabricantes.
Por lo demás sólo Novell y Apple parece que resuelven (algo) más del 50% antes de tres meses, que no es mucho decir.
Ya hemos hablado del tema de las actualizaciones (Los parches hay que aplicarlos, La seguridad, los navegadores y las actualizaciones y La historia de Conficker).
En Secunia PSI WorldMap se puede ver el mapa del mundo (se puede llegar a nivel de autonomía, en España) donde aparecen los programas actualizados según el Secunia Personal Software Inspector (PSI), un escáner que permite saber para una máquina Windows y con la información que se tenga en cada momento el estado de los programas del PC. La verdad es que no me hago mucha idea de lo que significan esas cifras (por ejemplo, en media (?), en Aragón donde estamos -ver datos para España parece ser que hay una media de 88 programas parcheados por PC, en la media europea; en La Rioja serían 122 y en Extremadura 70, que no se si corresponde a que se tengan más o menos programas o a que son regiones más o menos inseguras).
Lo vi en Mapamundi d’ordinadors i actualitzacions.
Antes de las vacaciones leí en CSRF vulnerability in GMail service sobre un fallo de GMail a la hora de impedir los intentos repetidos de pruebas de claves. El fallo serviría para saber qué usuarios tendrían claves débiles (porque los mensajes son diferentes según la calidad de la clave y si corresponde o no a la clave del usuario). Con la característica adicicional de que, en ese uso, no exigían el CAPTCHA (Vicente Aguilera encontró un eslabón débil).
A la vuelta encontré como Bruce Schneier comentaba en Password Advice los consejos sobre qué hacer y qué no hacer basándose en Gmail flaw shows value of strong passwords donde se comentaba también el fallo descubierto por Aguilera:
According to Aguilera’s new security alert, Google allows anyone with a Gmail account to guess another Gmail user’s password 100 times every two hours, or 1,200 times per day. No “captcha” keeps hacker bots from guessing passwords in this way. Worst of all: If a hacker controls, say, 100 Gmail accounts, 120,000 guesses can be made per day. Because Gmail accounts are free, many hackers control far more than 100 accounts, of course.
No vamos a hablar de los consejos, pero algunas lecciones: los más grandes cometen errores, se puede atacar los eslabones débiles, y mucho cuidado con la realimentación que proporcionan nuestros programas (ya hablaba de ello Tanenbaum en el libro de Sistemas Operativos y ahí seguimos).
Uno de los avisos que siempre hay que dar sobre la seguridad del software libre es que hay que ser prudente: el hecho de poder mirar el código no significa que realmente alguien lo vaya a mirar; o que si lo mira, tenga los conocimientos adecuados para encontrar los problemas; o que mire en el sitio adecuado. Por eso viene bien este ejemplo Elevación de privilegios en el kernel Linux desde el año 2001.
Como el título indica, se trata de un fallo que estaba presente desde hace bastantes años, esperando a que cualquier auditor lo encontrara y que ha aparecido recientemente.
No estoy diciendo que eso pase frecuentemente, pero es algo que no debemos olvidar, sobre todo si nuestro proyecto no es uno de los ‘grandes’.
