Category Archives: Seguridad

¿Qué sabe la RAE de hackers?

Emblema hacker

Nunca pensé que fuera a escribir un apunte en el blog tratando de enmendarle la plana a la RAE sobre la definición de una palabra.

Siempre pensé que la RAE hacía, al menos, algún estudio etimológico medianamente serio de las nuevas palabras que añadían al diccionario antes de hacerlo.

Nunca pensé que volverían a repetir las barbaridades de antaño, demostrando una ignorancia total del mundo tecnológico. Hace años ya se lucieron nuestros académicos con ejemplos como el de cederrón

Hoy nuestros académicos me han vuelto a dejar con la boca abierta.

Por un lado han aceptado la palabra “Hacker” y por otro, han demostrado que ni se leyeron la página del término en la Wikipedia, acusando de pirata informático a miles de hackers.

Una sola acepción, la de pirata informático, sin más. Dejando fuera el significado real de la palabra hacker.

Señores académicos: un hacker es mucho más que un pirata informático. La palabra que buscaban era cracker.

Déjenme recomendarles otra página de la Wikipedia, por no irnos a sitios raros. Lean la página de la ética hacker a ver si les parece la ética del pirata informático.

Me parece un gran atrevimiento el proponer una definición de la palabra hacker. Es una palabra con gran significado para muchos y muy lejos del simple y burdo pirata informatico pero, si me permiten ¿qué les parecería algo así?

Persona apasionada y, generalmente, con gran conocimiento sobre un tema.

Simple y concreto pero amplio, sin dejar a nadie fuera. Sin limitarnos a la seguridad informática, ni al software libre, ni a la electrónica, ni a la ingenieria, ni a las matemáticas, ni a la economía, ni a la medicina, ni al cine, … porque en todas las disciplinas existen hackers.

Señores academicos, entre sus sillones se encuentran algunos de los mejores hackers de las palabras de España. No me creo que no sean capaces de hacerlo mejor.

Un hacker.

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í?

¿Qué hacemos cuando nadie mira?

En el mundo real hay muchas personas que se comportan de forma diferente si piensan que nadie les mira. En función de si pensamos que nos miran o no hacemos o dejamos de hacer algunas cosas.

Alguno dirá – “no me importa que me miren, no tengo nada que esconder” – ya que es lo típico, lo que estoy harto de escuchar, pero claro, una cosa es que no tengamos nada que esconder y otra cosa es que no queramos tranquilidad para movernos sin tener a alguien encima, …

Como comenté hace unos días, el hecho es que cada vez es más difícil estar en una situación en la que no mire nadie. Lo sepamos o no, es muy probable que alguien está mirando. La privacidad está infravalorada.

Como experimento, hace unos meses monté PleaseProxy.me, un sistema de proxy anónimo a través del que, supuestamente, se puede navegar sin dejar rastros…
Evidentemente eso no es del todo cierto, cuando navegas dejas rastros, lo quieras o no los dejas en:

  • el ordenador desde el que navegas,
  • el servidor al que te conectas,
  • el proxy de tu proveedor de Internet o de tu oficina, …
  • el trayecto, posiblemente en los routers por los que pasan tus paquetes.

Con PleaseProxy.me limitas un poco el impacto en la privacidad de tu navegación pero como contrapartida (no hay nada gratis) dejas muchos de los rastros de tu navegación en PleaseProxy.me además de que tu proveedor (o en tu empresa si navegas desde la oficina) pensaré que tienes algo que esconder porque usas un proxy anónimo y el servidor al que te conectas puede denegarte el acceso por el mismo motivo.

Además los proxys anónimos no son del todo anónimos y todo depende del administrador del proxy en concreto.

Independientemente del tema del proxy y volviendo al título de este apunte, os dejo una captura de los sitios más visitados en PleaseProxy.me y cada cual que saque sus conclusiones. 🙂

Las redes sociales y el porno, eso es lo que hacemos en Internet cuando creemos que nadie mira.

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