Archivos de Tags: Seguridad - Paginas 2

250mil dólares de recompensa por el creador de Conficker

250K dólares, unos 200K euros es la recompensa que está ofreciendo Microsoft por información que lleve al arresto del creador del gusano conficker, del que ya he hablado alguna que otra vez porque según ellos se trata de un ataque criminal.

La solución definitiva NO es detener al creador del gusano.

Lo que se consigue deteniendo al creador del gusano es eliminar a UN programador de malware, puede que incluso uno de los buenos y como mucho que sirva de escarmiento para algún otro… pero cuando estamos hablando de mafias, de profesionales del malware, … parece claro que, detener a un técnico, no es la solución definitiva.

El camino más eficiente para mitigar estos problemas es la CONCIENCIACIÓN.

  • Concienciación y formación a los desarrolladores de software, para que desarrollen con la seguridad en mente, evitando que sus programas dependan, por ejemplo, de su ejecución con más privilegios de los necesarios, sin controles ni medidas enfocadas a producir herramientas robustas.
  • Concienciación y formación a los administradores de sistemas y red, para que administren sus sistemas con la seguridad en mente, para que se instalen los parches necesarios y se mantengan los sistemas bien ajustados.
  • Concienciación y formación a los usuarios, para que no utilicen más privilegios de los necesarios, no instalen cualquier programa que les llegue, desconfíen de los mensajes, páginas o personas sospechosas , …
  • Concienciación y formación para los profesionales de la seguridad de la información, ingenieros, auditores, administradores de seguridad, … porque lo nuestro es una carrera y los malos van muchas veces por delante así que hay que estar al día en las nuevas técnicas y estrategias, intentar adelantarnos y detectar los problemas antes de que hagan daño.

Finanzas personales con Mint.com

A través de este apunte de LifeHacker he conocido Mint.com, un servicio on-line de finanzas personales.

A primera vista tiene MUY buena pinta… un interfaz cuidado, muchas funcionalidades, estadísticas que te permiten saber en qué gastas el dinero, te permite fijar alertas, notas, te avisa por correo electrónico, … un poco de todo.

Así que con una cuenta de correo electrónico que tengo para registros de este tipo me doy de alta… vamos a investigar un poco más qué es esto.

Piden cuenta de correo, una contraseña, nombre, apellido y código postal ¿?.
Una vez te has dado de alta… viene la ¿sorpresa?


Te piden directamente el usuario y contraseña de cada una de las cuentas de los bancos con los que trabajas para poder entrar en tus cuentas… esto es un poco difícilse acabó la prueba.

La verdad es que la idea es buena, muy buena… ellos tienen acceso a tus cuentas bancarias, se conectan, descargan todos tus movimientos, los categorizan, hacen los cílculos, preparan los gráficos, … y tú al día siguiente tienes toda la información actualizada, sabes en qué te gastas el dinero, puedes ver si te pasas de presupuesto, como llevas los pagos, … en dos palabras: parece perfecto.

Sólo tiene un problema… tienes que meterle el usuario y contraseña para darles acceso a tus cuentas bancarias y del phising ya hablaré otro día.

Robo de credenciales en Monster

El día 23 la web de empleo Monster.com anunció que se había producido un robo de las credenciales de los usuarios de su web. No dicen cómo se ha hecho… sólo que ha pasado.

Han puesto un comunicado en su web diciendo que los datos que se han robado son: id de usuario, contraseña, dirección de correo electrónico, nombre, teléfonos y lo que ellos llaman datos demográficos pero dicen que los ladrones no han conseguido los currículums… a saber.

Una de las preguntas es… ¿Cómo es que han conseguido las contraseñas? ¿Las guardaban en claro? ¿Ni siquiera un hash? (luego el MD5 se rompe pero eso es otra historia).

Para tranquilizarnos nos dicen que en su nueva web, la seguridad es primordial… 😛

En España, quiero pensar que, un problema de estos llevaría asociada una sanción de la Agencia Española de Protección de Datos. Si se trata sólo de esos datos, supongo que estarían clasificados como de nivel bajo pero a saber qué es exactamente lo que se ha perdido.

A los que tengais vuestros datos en Monster… ya podeis correr a cambiar las contraseñas de vuestros usuarios… y eso si no compartís cuenta de correo-e/contraseñas entre Monster y otros sitios… Una práctica tan poco recomendable como habitual es la de compartir datos de registro (correo-e y contraseña) en varios/muchos/todos los sitios web.

¡A cambiar contraseñas tocan!

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.

¿De quién nos fiamos?

Gracias al apunte de Enrique Dans en el que habla de el valor de ser la opción por defecto me acuerdo del apunte que yo publicaba aquí el otro día sobre el ataque a los certificados con MD5. No es exactamente lo mismo pero sí está relacionado.

En ese apunte comentaba el hecho de que los proveedores de navegadores web y sistemas operativos los que de manera habitual incluyen en las configuraciones predeterminadas un conjunto de certificados de CAs que ellos deciden que son de confianza, sin más.

CasiNadie desconfía de esos certificados que nuestros navegadores nos dicen que son de confianza pero dudo que mucha gente compruebe que lo son y simplemente nos fiamos.
Si el navegador dice que sí, es que sí.

La seguridad es una cuestión de confianza.

Los usuarios ponemos la seguridad de los accesos a nuestro banco, la de nuestras compras online, los billetes que compramos, nuestras transferencias de datos personales, … en fin, todas las idas y venidas de nuestros datos y los datos en sí en las manos de Microsoft y de Firefox principalmente y no sólo eso, sino que luego se permiten el lujo de implementar medidas y decir que, los sitios que no utilizan certificados de los que ellos dicen que son de confianza pueden ser peligrosos, falsos, maliciosos, …

Ahora bien… ¿Sería factible hacer que los usuarios tuvieran que comprobar uno a uno la validez de todos certificados de los sitios web a los que se conectan? ¿Cuantos no pulsarían en “aceptar” directamente, sin preguntar ni comprobar nada?

Hay que valorar, si decido que mi proveedor de software decida por mi qué sitio es de fiar y qué sitio no o bien me dedico a comprobar todos y cada uno de los sitios a los que me conecto como si ninguno fuera confiable.

Al final la seguridad es una cuestión de confianza.

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.

Kevin Mitnick: heroe o villano

Via Microsiervos me entero de que el día 17 se publicó una entrevista en El Mundo a Kevin Mitnick.

Para los que no sepais quien es este tal Kevin y no querais leer el enlace, resumiendo mucho diría que fue el primero de los ¿hackers/crackers? detenido y mandado a la carcel en EEUU.

¿Heroe o villano?

No le conozco personalmente pero me da a mi que este hombre, por lo que se cuenta por ahí más que hacker(*), lo que era es un experto en ingeniería social.

Lo que está claro es que le condenaron por cometer delitos como acceder a sistemas sin autorización, posesión de documentos falsos, … en fin de todo un poco.

A día de hoy se gana la vida como consultor de seguridad… claro, con la publicidad de su caso a qué mejor.

Comento esto porque me llama la atención que una persona con su historial conteste con un Que no les pillen… a la pregunta de ¿Algún consejo para los adolescentes que se inician en el hacking?.
También dice: Fui algo torpe porque estuve usando un móvil desde un punto fijo durante varios días, de modo que no lo hagáis…

Todo un ejemplo. Supongo que tenía ningún buen consejo que dar.

(*) No dudo de los conocimientos técnicos de Kevin que seguro que los tiene, pero me da a mi que consiguió mucho más engañando a la gente que mediante hacks técnicos.

El enemigo puede estar dentro

Los ingenieros de seguridad de la información pasan mucho tiempo con el Sistema de Gestión de la Seguridad de la Información estableciendo procedimientos y definiendo contramedidas para mitigar los riesgos de posibles atacantes externos: firewalls, IPS, DMZ, … Siempre pensando que es un atacante externo el que quiere acceder a nuestros recursos y robar nuestra información ya sea un robo de espionaje industrial, un robo de credenciales a nuestros usuarios, el script kiddie o el clásico y cada vez menos frecuente, ataque del hacker de la vieja escuela que lo hace por el mero reto intelectual.

Ahora bien… ¿qué pasa con la gente que tenemos detrás de los controles que definen la seguridad perimetral? ¿Qué pasa con todos nuestros empleados? Los usuarios, el personal subcontratado…
Esta gente puede tener las puertas abiertas a todos nuestros activos y recursos.

Es por ello imprescindible realizar buenos procesos de vetting para asegurarnos de la identidad e idoneidad del personal que se va a incorporar a nuestra organización, en especial cuando se trata de puestos clave, con grandes accesos y/o responsabilidades.

Además del vetting y del background check habrá que definir las medidas técnicas, procedimentales y organizativas para asegurarnos de que nuestros empleados y usuarios tienen acceso en función de su necesidad de conocer o need to know.

Las medidas técnicas son más o menos sencillas de implementar y dependen muchas veces sólo del presupuesto… segmentar las redes con firewalls internos, instalar productos de antivirus y antispyware (el robo de credenciales e información corporativa puede realizarse y se realiza muchas veces desde el exterior utilizando al personal interno mediante un virus o un troyano), detectores de intrusión, IPS, y los nuevos DLP (Data Leak Protection)…

Más difícil son las medidas organizativas y de procedimiento porque ahí la dificultad radica en no enfrentar en exceso las necesidades del negocio con las restricciones de seguridad.
Los usuarios habitualmente se quejarán de las medidas de seguridad exponiendo que no les dejan trabajar y es habitual que se produzcan choques entre usabilidad y seguridad.

Esa es una de las dificultades del trabajo del ingeniero de seguridad, hacer que las medidas sean lo menos intrusivas posible y adecuadas a las necesidades del 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.plugin cookies

ACEPTAR
Aviso de cookies