Tag Archives: Seguridad

Actualizando los servidores desde un iPhone

Ayer se publicó una actualización de bind que resuelve una vulnerabilidad crítica que permite a un atacante causar una denegación de servicio (DoS). No solo se ha publicado la vulnerabilidad sino que, además, ya hay circulando un exploit.

Había que actualizar… y hoy era el día que le tocaba a mis servidores.

Estas actualizaciones, en Debian, suelen ser muy sencillas de llevar a cabo así que desde el sofá, iPhone en mano y con el TouchTerm me he puesto manos a la obra.


¿El resultado? En unos 4-5 minutos, incluyendo el tiempo de conectar y teclear los comandos adecuados… tenía mis dos servidores actualizados. 🙂

Algunos dirán que es una frikada pero actualizar dos servidores de nombres desde el sofá a través del teléfono móvil es la mar de cómodo! 😛

El hábito no hace al monje pero ayuda a reconocerlo

Acababa de publicar el apunte anterior y estaba esperando la salida de mi avión…

Se acercan 4 ó 5 personas en el típico grupo donde se ve quien manda (uno habla y los demás sonríen, asienten y escuchan.

Casualmente deciden parar cerca de mi…

Que si hablé con fulano, que si tenemos que reunirnos con mengano, que si le dije al Ministro Patatín, que si el plan yo_que_se… Vamos que sin conocer a la persona esa se podían atar algunos cabos.

Una búsqueda en Google con 2 ó 3 términos clave que habían salido en la conversación de ese hombre y… ahí estaba, la foto de Don Fulanito, presidente de una gran empresa española, no diré el nombre porque no aporta nada al apunte.

Lo importante del apunte es la falta de concienciación, de las personas en general y la alta dirección en particular, en temas de seguridad corporativa.

Es el típico ejemplo: un aeropuerto, rodeado de gente a la que ni conoces, hablando, dando detalles, ¿pavoneandose? como si estuviera en su despacho rodeado de sus colaboradores…

A ese directivo y su equipo le hace mucha falta un plan de concienciación para proteger la información, planes y demás activos de la empresa.

¿Cómo puede un departamento de Seguridad de la Información atacar un problema así?

Ponencia en el Máster en Seguridad de la Información y las Comunicaciones de la UAX

No había tenido tiempo de comentar que los días 6 y 7 de febrero participé como ponente en el Master Oficial en Ingeniería de Seguridad y las Comunicaciones de la UAX.

La sesión trató sobre seguridad en sistemas UNIX/Linux, recomendaciones generales, buenas prácticas, securización de sistemas, … Vamos un poco de todo.

Creo que los alumnos quedaron contentos, la participación fue buena, hubo buen ambiente y cubrimos lo planificado tanto en contenido como en tiempo. Evidentemente mi presentación no fue perfecta y hay cosas que mejorar y que pulir…
Probablemente los alumnos habrían agradecido tener más tiempo para pegarse con los ordenadores pero el tiempo es limitado y, si los alumnos no tienen conocimientos de administración de sistemas Linux no se puede correr más de la cuenta pues hay que ir a una velocidad a la que todos puedan llegar.

La seguridad en sistemas UNIX y Linux es un tema amplio que es difícil de cubrir en sólo dos sesiones de 4’5h…

Yo lo pasé bien… Espero que los alumnos disfrutaran de la sesión y les resultara interesante.

Mi próxima sesión será sobre KDE en el Máster en Software Libre de la URJC, ya os contaré qué tal.

 

Vuelve Conficker y los problemas de no parchear

No es nuevo el problema, Microsoft publicaba el parche a finales de octubre en una distribución de esas críticas fuera de ciclo. El hecho de que hagan una distribución fuera de ciclo debe ser motivo para tomárselo en serio y en muchas de las grandes redes se iniciaron los procedimientos para actualizar e instalar dicha actualización cuanto antes.

En menos de un mes ya teníamos al menos un virus detectado y dando guerra. El Conficker se hizo presente. Como siempre, las primeras informaciones eran vagas (conficker, Gimmiv, ¿otro?) y había que fiarse de la intuición y experiencia para identificar como un virus determinados patrones ya sea en el tráfico de la red, en las incidencias de los usuarios, …

A los días las primeras infecciones ya eran masivas. Grandes redes infectadas por un gusano que se introducía en todas las máquinas que no tenían el parche aplicado (y habían reiniciado tras la actualización), los fabricantes de antivirus no daban con la tecla para limpiar las infecciones y sacaban varios patrones de firmas al día tratando de dar con la tecla, las redes mal segmentadas se bloqueaban con el tráfico que el gusano generaba, … caos.

Pasa el tiempo, los administradores (que no lo hicieron a tiempo) van parcheando, los fabricantes de antivirus generan y distribuyen las firmas del virus y parece que todo vuelve a la normalidad… pero no.

A principios del mes de enero, una variante de conficker vuelve a las redes y caen de nuevo las grandes redes. Cuentas de usuario bloqueadas, tráfico que colapsa los routers, los foros y webs echando humo, … en medio de la confusión Panda la caga con un falso positivo y hace que los síntomas de un virus se mezclen con los síntomas del falso positivo de Panda… vuelta a investigar, …

Esta vez la variante es más lista y no sólo se propaga con un gusano típico como en noviembre/diciembre… ahora también lo hace a través de los recursos compartidos, los discos USB, … la Ingeniería Social, crackeando contraseñas débiles usando diccionarios rudimentarios, … vuelta a investigar, vuelta a poner parches (¿pero… no estaban puestos ya? ¿Es que la gente no aprende?).

No se si alguna vez se ganará la guerra a los creadores de virus y malware. Me da que no, siempre vamos al menos un paso por detrás… generando parches y antivirus.

Aun quedan administradores que no ven la actualización de parches de seguridad como algo crítico de sus sistemas (si funciona no lo toques). El miedo a que algo deje de funcionar por instalar un parche sigue pesando más que el miedo a que toda la red deje de funcionar y no puedan dar servicio por una infección masiva (¿?) pero el caso es que los parches no se instalan… o no se hace a tiempo.

¿Qué cuesta más? ¿Mantener un parque de máquinas actualizadas y con los parches de seguridad y antivirus al día o quedarte sin servicio, sin previo aviso, tener que parchear a toda prisa y sin hacer las pruebas pertinentes el día de la catástrofe?

La Gestión de la Seguridad de la Información suele recomendar eso de parchear…

Datos biométricos en el pasaporte

¿Hasta dónde van a llegar para controlarnos? ¿Qué es lo que hay que proteger? ¿Dónde está el límite de la privacidad? ¿Cómo de intrusivos deben o pueden ser los sistemas de autenticación y seguridad? ¿Cuánto estamos los usuarios dispuestos a tragar? ¿Ni una protesta? ¿Nadie se queja?

La Eurocámara ha aprobado una medida que obliga a la inclusión de datos biométricos en los pasaportes.
¿Incluirá esta medida también los requisitos mínimos de seguridad que deben incluir los pasaportes para garantizar nuestra privacidad?

Tenemos dispositivos RFID y datos biométricos en los pasaportes… mala mezcla… los vendedores de carteras y fundas con jaulas de faraday se van a hartar a vender.

¿Han valorado el coste de lo que pretenden proteger y el coste de la implantación de esas medidas?

25 errores más peligrosos al desarrollar software

Leo en MITRE una lista donde detallan los 25 errores más peligrosos de la programación y creo que es una buena referencia que puede tomarse como una checklist, una lista a comprobar cuando los desarrolladores están realizando su trabajo.

Como dicen en su introducción, esa lista puede servir también de referencia a los educadores y profesores de programación, ingeniería del software, … para que los alumnos conozcan también estos típicos errores que generan vulnerabilidades peligrosas y tópicas.

Una breve enumeración:

  • No validar las entradas. (CWE-20)…
  • … y no formatear (o escapar) adecuadamente las salidas. (CWE-116).
  • Cuidado con la inyección de SQL. (CWE-89).
  • Cuidado con el Cross-site scripting (XSS). (CWE-79).
  • Atención a la ejecución de comandos. (CWE-78).
  • Falsificaciones de peticiones en sitios cruzados. (CWE-352).
  • Transmisión de información sensible en claro. (CWE-319).
  • Race conditions la expresión en español típica (condición de carrera) no es una traducción que me guste en exceso. (CWE-362).
  • Cuidado con la información de los mensajes de error, que no den más información de la cuenta. (CWE-209).
  • Desbordamientos de buffer. (CWE-119).
  • Cuidado con el almacenamiento de datos críticos, no sea que están accesibles. (CWE-642).
  • Cuidado con las rutas y ficheros, exposición de más información de la cuenta o acceso a rutas no necesarias. (CWE-73). Este me parece a mi un error más de configuración de sistemas que de desarrollo puro y duro pero es interesante. Es sencillo encontrar ejemplos de máquinas potencialmente vulnerables.
  • Control sobre el directorio de búsqueda de recursos. (CWE-426).
  • Generación de código. (CWE-94). Veo este error muy relacionado con los de validación de entradas y salidas… pero bueno, así comprobamos dos veces. 🙂
  • Cuidado con la reutilización. (CWE-494). ¡Para qué volver a reinventar la rueda…? pero eso sí, asegurémonos de que la rueda es redonda antes de ponerla.
  • La basura de un hombre es el tesoro de otro. (CWE-404).
  • Inicializa correctamente las variables y objetos. (CWE-665).
  • Cálculos incorrectos. (CWE-682). También relacionada con la validación de las entradas y el desbordamiento de buffer.
  • Control de acceso ineficaz. (CWE-285).
  • Utilización de algoritmos criptográficos débiles o rotos. (CWE-327).
  • No incluir contraseñas en el código. (CWE-259).
  • Asignación de permisos inseguros para recursos críticos. (CWE-732). ¿No es esto demasiado parecido al control de acceso ineficaz del que hablaban antes?
  • Aleatoriedad previsible. (CWE-330).
  • Utilización de más permisos de la cuenta. (CWE-250). Este también es un problema habitual. Muchos desarrolladores se acostumbran a desarrollar con usuarios privilegiados y generan código que requiere esos privilegios para ejecutarse cuando no hay necesidad real.
  • Confiar la seguridad del servidor al clientes. (CWE-602).

Se trata de una lista, unas recomendaciones muy útil para mejorar el desarrollo seguro y generar herramientas y programas con menos vulnerabilidades.
No tenemos por qué estar de acuerdo con todas las cosas que aquí dicen… pero desde luego que son cosas interesantes a tener en cuenta por los desarrolladores.

Ataque a certificados con MD5

Desde InfoSec News nos llega una noticia que ya tiene unos días pero es realmente interesante e importante.

Lo importante del tema es que por lo visto un grupo de investigadores de la Universidad de Eindhoven ha conseguido generar certificados digitales falsos. Las aplicaciones de estos certificados son muchas pero el ejemplo se centra en la falsificación de páginas web y por si aun queda alguien que no ve la importancia de este hallazgo añadirá que sería posible falsificar páginas de cualquier banco online, eBay, Paypal o cualquier otro sitio de pagos electrónicos, compras, …

¿Está ahora un poco más claro eso de que es importante?

¿Cómo es que pueden falsear la web de mi banco?

Los bancos (y demás “sitios seguros”) utilizan para identificarse y que sepamos que son el sitio correcto un certificado digital. Dicho certificado digital (un ejemplo sería como nuestro DNI) del banco debe estar firmado por una autoridad de certificación (CA) en la que nosotros confiemos (el equivalente sería la Fábrica Nacional de Moneda y Timbre).

Los navegadores suelen tener los certificados de las CA instalados (ya hablaré otro día de cómo es que permitimos que los fabricantes de navegadores decidan por nosotros en quien confiamos sin preguntar) y de esa forma, cuando navegamos por Internet podemos comprobar la validez de los certificados que nos presentan los servidores web que visitamos.

Como ya he dicho, las CA también tienen certificados por lo que si alguien consigue un certificado firmado por una CA de confianza para una CA maliciosa podrá generar/firmar certificados para cualquier sitio web y duplicar cualquier web segura de la red.
Nuestra confianza en los proveedores de certificados se basa en que suponemos que comprueban que los certificados que firman son realmente para las direcciones que dicen ser.

La imposibilidad de duplicar o falsificar estos certificados viene dada por el hash de ciertos datos del certificado. El hash del certificado se genera con SHA en muchas CA pero con MD5 en otras y es para este último algoritmo para el que han realizado el ataque.

Lo interesante es cómo lo hacen y viene perfectamente explicado en la web donde detallan cómo han conseguido demostrar que es posible crear una CA falsa y que el MD5 no es tan seguro como pensábamos. La explicación está llena de detalles y explicaciones pero aun así conviene tener algunos conceptos claros antes de aventurarse a leerla.
El ataque tiene algunas cosas menos “matemáticas” como que depende de la asignación de números secuenciales de certificado de algunas CA… y eso es fácilmente subsanable.

Tras la publicación del ataque, muy rápidamente, se han producido los movimientos adecuados en la industria de los certificados por lo que muchos han dejado de usar MD5 para pasarse a otros algoritmos de hash para generar las firmas… algo que tenían que haber hecho hace mucho.

Supongo que en breve tendremos actualizaciones de los navegadores con la instalación de nuevos certificados raiz.

Las empresas de certificación digital viven de la confianza… si los usuarios perdemos la confianza en ellas, se quedan sin negocio.

Este sitio web utiliza cookies para que usted tenga la mejor experiencia de usuario. Si continúa navegando está dando su consentimiento para la aceptación de las mencionadas cookies y la aceptación de nuestra política de cookies, pinche el enlace para mayor información.

ACEPTAR
Aviso de cookies