Mostrando entradas con la etiqueta Seguridad. Mostrar todas las entradas
Mostrando entradas con la etiqueta Seguridad. Mostrar todas las entradas

martes, 20 de diciembre de 2011

Certificados, ficheros y claves privadas

Últimamente por motivos relacionados con mi trabajo me he tenido que ir introduciendo cada vez más y más en el mundo de la seguridad informática. Es un campo muy extenso e interesante pero también un tanto oscuro en algunos puntos. (sobre todo si no das con las fuentes de información adecuadas)

En este ecosistema de seguridad, como ya conocemos todos en mayor o menor medida, los certificados de seguridad juegan un papel de lo más importante. ¿Quien no ha oído hablar de los certificados X509?

Windows incluye una herramienta para gestionar los certificados que tenemos instalados en la máquina/máquinas. Más concretamente es un complemento de la Microsoft Management Console (a.k.a. navaja suiza) llamado “Certificates”. Esta herramienta es de lo más conocida y podéis encontrar mucha documentación sobre ella en el MSDN, por ejemplo aquí.

Curioseando con la instalación de los certificados me surgió la pregunta sobre donde Windows almacena la clave privada de los mismos. Leyendo una poco al respecto, encontré una herramienta que nos aporta dicha información llamada Find Private Key Tool.

Dicha herramienta nos permite a través de la línea de comandos, preguntar sobre un determinado certificado ( filtrando por diferentes características como su subject, thumbprint…). En caso de existir un certificado que se adapte a los parámetros solicitados,  nos retornara el nombre del fichero que le da soporte. Esta información nos puede ser necesaria en caso de tener que ajustar los permisos de las acciones que sobre el mismo se deben permitir. El caso más típico es acceder a la clave privada de un certificado (por código) con un usuario con permisos restringidos (por ejemplo el application pool identity de una aplicación ASP.NET)

Según la especificación de la herramienta:

  1: Usage: FindPrivateKey <storeName> <storeLocation> [{ {-n <subjectName>} | {-t <thumbprint>} } [-f | -d | -a]]
  2:        <subjectName> subject name of the certificate
  3:        <thumbprint>  thumbprint of the certificate (use certmgr.exe to get it)
  4:        -f            output file name only
  5:        -d            output directory only
  6:        -a            output absolute file name

Ejemplos de comandos:


Buscar en StoreName “My”  y Store Location “CurrentUser” un certificado con el Subject  CN=TESTCERT (CN es el Common Name, que forma parte del Subject)

  1: FindPrivateKey My CurrentUser -n "CN=TESTCERT"

Buscar en StoreName “My” y Store Location “LocalMachine” un certificado con el Thumbprint pasado por parámetro

  1: FindPrivateKey My LocalMachine -t "40 ee 7b 2f 10 59 38 99 4f 65 9f 8f 92 38 85 a3" –c

En caso de que el certificado solicitado exista, la herramienta nos devolverá algo como:

  1: Private key directory:
  2: C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys
  3: Private key file name:
  4: <GUID>

Siendo el GUID el nombre del fichero asociado que almacena la clave privada. Una vez localizado podemos modificar sus permisos si para alguno de nuestros procesos esto es necesario.

miércoles, 30 de enero de 2008

Diseño de especificaciones de seguridad (3 de 3)

Unos conceptos muy importantes relacionados con la seguridad son los de autenticar (demostrar que se es quien se dice ser) y autorizar (establecer que puede y que no puede hacer el usuario por ser quien es)

Para diseñar una estrategia de autenticación y autorización se necesita:

  1. Identificar los recursos.
  2. Seleccionar la estrategia de autorización.
  3. Seleccionar las identidades empleadas para acceder a los recursos.
  4. Considerar el flujo de identidad.
  5. Seleccionar el enfoque de autenticación.
  6. Decidir como debe fluir la identidad.
Con esta triada damos por finalizado (de momento) este repaso a conceptos generales relacionados con la seguridad.

martes, 29 de enero de 2008

Diseño de especificaciones de seguridad (2 de 3)

Continuemos viendo las especificaciones de seguridad. Como hemos identificado en el post anterio existen diferentes tipos o categorias de amenazas. Su concimiento nos permite crear un plan o metodología para contemplar una posible respuesta a dichos tipos de amenazas.

Con el fin de tener un guión a la hora planificar esta tarea podemos identificar una serie de pasos para crear un modelo de amenazas son:

  • Organizar una reunión de tormenta de ideas.
  • Aplicar la organización de categorías de seguridad STRIDE.
  • Listar todas las posibles amenazas.
  • Crear apuntes.
  • Investigar.
  • Clasificar el riesgo de cada amenaza.
Por supuesto estas actividades deben tener su soporte tecnológico. Los grandes fabricantes de entornos de desarrollo están ampliamanete sensibilizados con los problemas de seguridad (más les vale) y portan tecnología out-the-box para la correcta gestión de la seguridad de las aplicaciones que sobre ellos se desarrollan.

Por ejemplo, las características de seguridad del Microsoft .Net Framework incluyen:

  • Validaciones de Tipo seguro
  • Firmado de código.
  • Encriptación y firmado de datos.
  • Seguridad de acceso al código.
  • Seguridad basada en roles.
  • Almacenamiento separado.

Finalizaremos en el siguiente post.

Diseño de especificaciones de seguridad (1 de 3)

Vamos a analizar algunos aspectos relativos a la seguridad de las aplicaciones. Primero veamos los tipos más comunes de vulnerabilidades de seguridad:

  • Contraseñas débiles.
  • Software des-configurado o mal configurado.
  • Ingeniería social.
  • Conexiones de Internet.
  • Transferencia de datos sin encriptar.
  • Desbordamiento de buffer.
  • SQL Injection.
  • Secretos en código.

El conocimiento de dichos tipos de vulnerabilidades nos permite realizar una planificación más detallada de los pasos a seguir y aspectos a tener en cuenta.

Los pilares para crear una estrategia de seguridad incluyen:

  • Confiar en sistemas de seguridad probados.
  • Nunca confiar en las entradas externas.
  • Asumir que los sistemas externos no son seguros.
  • Aplicar el principio de mínimos privilegios.
  • Reducir la disponibilidad de componentes y datos.
  • Colocar como modo por defecto el modo seguro.
  • No confiar en la seguridad por ocultación.
  • Seguir los principios de STRIDE.
Continuaremos con el siguiente post.

viernes, 18 de enero de 2008

Phishing de lo más cutre

Hoy he recibido un mensaje de correo electrónico intentando hacer un Phishing que es de los más cutres que he visto nunca:



El texto dice:

"Debido a las ediciones recientes que aparecieron al la caixa servicio online estamos actualment lanzar un nuevo sistema de la seguridad para parar los escapes de la información.
Para beneficiar de las nuevas instalaciones seguir por favor el acoplamiento abajo.
Para poner al día tu estado de cuenta ***AUTHENTICAR*** y terminar por favor los pasos necesarios.
****Advertencia**** Si no terminas los pasos siguientes tu cuenta se puede exponer a las acciones del fraude. No contestar por favor a este mensaje. Para cualquier investigación, entrar en contacto con el Servicio de Cliente.

"

Usando la traducción automática las cosas no quedan bien rematadas...

En fin, sin más comentarios.

miércoles, 9 de enero de 2008

Que es el modelo de amenazas STRIDE? 2 de 2

  • Information disclosure (Revelación de información)
    Un usuario sin autorización obtiene datos privados, como números de tarjetas de crédito y fechas de espiración.

  • Denial of service (Denegación de servicio)
    Cualquier ataque que intenta evitar el acceso a un recurso computacional. Los ataques DoS pueden provocar:

    • Que una aplicación o el S.O deje de funcionar.
    • Utilización masiva de CPU en cálculos innecesarios.
    • Consumo de memoria del sistema de tal modo que se dañen las funcionalidades de las aplicaciones o del sistema operativo.
    • Reducción de ancho de banda.

  • Elevation of privilege (Escalada de privilegios)
    Un usuario consigue mayores privilegios que los planificados por el administrador, creando un usuario malintencionado para lanzar ataques de las demás categorías o amenazas de seguridad.

Pues ya tienen el STRIDE. No me digan que no es interesante.

martes, 8 de enero de 2008

Que es el modelo de amenazas STRIDE? 1 de 2

El modelo de amenazas es una técnica empleada para identificar y categorizar las amenazas de una aplicación.

  • Spoofing identity (Suplantación de Identidad)
    Un usuario malintencionado se hace pasar por una entidad de confianza.
    NOTA:
    IP spoofing es un caso especial de suplantación de identidad. Ocurre cuando un usuario malintencionado inserta una falsa dirección I.P. en una transmisión por Internet de tal manera que dicha transmisión parezca que proceda de una fuente segura. De esta manera el usuario malicioso puede conseguir acceso a un sistema.

  • Tampering (Falsificación)
    Un usuario consigue acceso autorizado a un ordenador y cambia sus operaciones, configuración o datos.

  • Repudiation (Repudio)
    Un administrador de sistemas o agente de seguridad es incapaz de probar que el usuario malicioso ha realizado cierta acción.

Ya tenemos STR... el próximos post el resto.

Bases para la creación de aplicaciones seguras.

Existen algunos conceptos a tener en cuenta a la hora de valorar la seguridad de nuestras aplicaciones:
  • Confiere en los sistemas de seguridad probados y testados. (relativamente, claro)
  • Nunca confíe en las entradas externas.
  • Asuma que los sistemas externos no son seguros.
  • Aplique los principios de privilegios mínimos.
  • Reduzca la disponibilidad de componentes y datos.
  • Por defecto, establezca un modo seguro.
  • No confíe en la seguridad por ocultación.
    Que no tenga ningún enlace no protege el fichero. (menos si Google nos lo indexa ;))
  • Siga los principios del STRIDE. (spoofing identity, tampering, repudiation, information disclosure, denial of service, and elevation of privilege.)
Aun con todos estas características puede que su aplicación no sea segura, pero tenarlos a la vista puede ser un buen hábito.

Saludos y feliz 2008 recién estrenado...

viernes, 14 de julio de 2006

Conceptos básicos sobre Criptografía

A día de hoy, con el desarrollo y las perspectivas de Internet, los usuarios de la red de redes no solo debemos conocer nuestros derechos sino asumir ciertas responsabilidades, concienciandonos de dos hechos reales como la vida misma:
  1. No estamos solos en Internet.
  2. No todo el mundo es bueno.
Con esta base, deberemos ser consciente de que toda la información que transite por la red es susceptible de ser interceptada por cualquier usuario con conocimientos básicos de informática.
Podemos elegir que cualquier ciber-cotilla lea nuestros datos, pero también podemos elegir que no lo haga y aqui es donde encaja la criptografía.

Solo para abrir boca comentemos algunos aspectos esenciales relacionados:
  • La privacidad, la información sólo pueda ser leída por personas autorizadas.
  • La integridad la información no pueda ser alterada en el transcurso de su transferencia.
  • La autenticidad permite que pueda confirmar que el mensaje recibido haya sido mandado por quien dice lo mando o que el mensaje recibido es el que se esperaba.
  • El no rechazo implica que no se pueda negar la autoría de un mensaje enviado.
Continuaremos hablando de criptografía pero de momento con tener claros estos conceptos es un buen inicio.

Origenes de la criptografía

Uno de los precursores de la criptografía moderna fue el emperador Romano Julio Cesar.

Cansado de los continuos ataques que sufrían sus mensajeros y de las consiguientes filtraciones hacia sus enemigos de informaciones sensibles para sus campañas ideó un mecanismo de encriptar la información de los mensajes que comunico a sus aliados.

Este mecanismo es conocido como el "Cuadrado de Cesar"...