29 febrero 2012

Miembros de anonymous que publicaron datos de los GEO son detenidos.

Una breve línea para hacernos eco de la noticia que saltó ayer en algunos periódicos nacionales. Tal y como indica la imagen, se han detenido a cuatro miembros de anonymous en una operación internacional. Según parece, uno de ellos era ya conocido por la policia y profesional del sector de la seguridad de la información.

Leer más...

28 febrero 2012

Software actualizado: sí o sí

Hace unos años os hablamos de Secunia PSI, una aplicación para auditar el software de un PC, indicando aquel software que debe ser actualizado por problemas de seguridad.

Si os ocurre como a mí y estáis obsesionados con tener la última versión de cada producto. Existen otras alternativas que comprueban todo tipo de actualizaciones y nos mantienen frescos y seguros.

FileHippo Update Checker utiliza su propia página web FileHippo.com, desde la que también se pueden descargar las actualizaciones. Es bastante rápida y puede ser utilizada desde una aplicación portable.


Otra  herramienta no tan popular es Software Update Monitor (SUMo) de KC Software. Al igual que en casos anteriores localiza el software instalado consultando las librerías y sus versiones, envía la información a su página web (ojo, si esto os supone un problema) y muestra un informe de resultados. La descarga no es directa como en el caso de la utilidad anterior. 

La principal ventaja de SUMo, es que se mantiene mediante el funcionamiento de los usuarios y de cada aplicación, mostrará las estadísticas de informes que se han recibido. Lo que también puede ser muy útil para conocer la penetración de una versión de software en concreto.

Leer más...

27 febrero 2012

¿Image Basic Authentication?

A menudo, y de hecho es habitual, ver en sistemas de foros distintos usuarios con firmas y avatares. La mayoría de estos sistemas usan código html ( <img src=""></img> ) para cargar las imágenes y mostrarlas.

Así que, el otro día tratando de ver la seguridad de uploaders me acordé de que algunos, simplemente validan el valor de Content-type. Así que, cambiándolo, estaríamos pareciendo una imagen y necesitaríamos serlo únicamente?




Por alguna razón, no filtran (dentro de las etiquetas de imágenes) la carga desde php, asp, etc.

Bién es sabido que, podemos modificar la cabecera de un archivo php para que pase por una imagen y así poder llegar a ejecutar el código php (y si se desea cargar la imagen con echo) en el momento en que alguien accede a la carga de esa imagen.


Esto nos da la oportunidad de ejecutar código PHP. ¿Os acordáis de la Http Basic Authentication? Hablo de Basic y no diggest (porque para nada nos sirven los datos que queremos cifrados).

En el momento en qué alguien solicite la carga de nuestra imagen ,y no acceda directamente, se mostrará una basic authentication que informará de que el foro ha perdido la sesión y solicita reintroducir los datos de nuevo.


>> Descargar Image_Basic_Authentication

El script funciona de forma muy básica, de hecho podeis leer el código sin muchos problemas. La mayoría de usuarios lo tomarán como un ataque de phishing, yo sin embargo aún no sé como calificarlo.


Aunque se trate solamente de phishing, son muchos los usuarios que en sistemas de foros como phpBB, vBulletin, MyBB,etc caerían en la trampa (por así decirlo). Quizás hasta nos encontramos con un administrador de estos despistados :O

¡Un saludo y muchas gracias por leernos! :)

------------------------------------------------------
Artículo cortesía de Alberto, editor de seginformatica.net
Leer más...

26 febrero 2012

Enlaces de la SECmana - 112


Leer más...

25 febrero 2012

¿Por qué mienten los usuarios?


Hace un par de semanas, al imprimir mi tarjeta de embarque para el vuelo que tenía al día siguiente, me dí cuenta que había un error en el nombre del viajero. En vez de "Lorenzo Martínez" aparecía "Lorenzo Martín". Pensé, vaya, llevo treintaytantos años escribiendo mi nombre, y posiblemente por ir a la carrera, me he equivocado. Posteriormente caí que, a lo mejor, el maravilloso y proactivo auto-corrector, incluido a traición en Mac OS X Lion, haya tenido algo que ver. En mi caso el problema se solucionó en el mesón de facturación, con mi DNI y la tarjeta de crédito con la que compré el billete. Me lo cambiaron, imprimieron uno nuevo y a correr (bueno, a volar).

Estoy seguro que otra persona habría llegado al avión y, en el caso que alguien hubiese caido en la cuenta que el apellido estaba incompleto, habría montado la de San Quintín en la puerta de embarque indicando que, seguramente, la máquina.. o la aplicación web se equivocó al emitir el billete, pero que él/ella lo escribió correctamente.

Esto me lleva a pensar en cuántas veces he tenido que oir eso de: "No, no si yo no he tocado nada" o,.. "nunca abro ejecutables que me llegan por correo" o el colofón: "¿Yo? ¿Navegando por páginas porno??? Imposible!!"

Hay dos cosas que están claras: Los logs no mienten y las máquinas hacen lo que nosotros les decimos que hagan.

Pero la pregunta es ¿por qué mienten los usuarios a los poderosos sysadmins BOFHs que todo lo ven? En general, por no demostrar que su propia curiosidad ganó el pulso al sentido común, o porque por no poner suficiente atención a lo que se está haciendo, le dijo a la máquina que hiciera algo que no es lo que se quería hacer. Se entiende que los programas y los sistemas  tienen fallos, pero, aún, no tienen vida propia. 

Excepto en el 0,1% de los casos, en los que una situación MiTM puede llegar a alterar la realidad según la voluntad del atacante, en el otro 99,9% de los casos los errores se producen porque un humano se equivoca y toca, muchas veces por curiosidad, pero sin que nadie se de cuenta, lo que no debe tocar.

P.D: Mientras escribía estas reflexiones, ví en mis RSS un artículo de nuestro amigo @mkpositivo, que guarda estrecha relación con este tema, aunque cada uno en su ámbito, claro está ¿Por qué los contactos no te dicen la verdad?
Leer más...

24 febrero 2012

AngryHackers

Hoy vamos a contar algunos casos curiosos de hackers que por un lado desarrollan una solución de seguridad y por otro la atacan. Como los casos de Steffan Esser, alias i0n1c o Brad Splenger, alias spender.

La historia de Steffan se remonta a la época en la que formaba parte del prestigioso grupo de hacking TESO, donde publicó exploits para telnetd de BSD, php, o squid, vamos, casi nada. 

Luego comenzó Hardened-PHP y suhosin, proyecto para proveer a php de mayor seguridad mediante un parche para el código fuente y un módulo independiente. 

En el mundo IOS de Apple, creó la aplicación antid0te, con la que añadía protección al dispositivo con ASLR, aunque nunca llegó a ver la luz, ya que poco después Apple hizo su propia implantación de esta medida en la versión 4.3.

Por estos motivos es sorprendente ver que la misma persona facilitó un exploit para hacer jailbreak a los móviles con IOS 4.3.1, haciendo volar su seguridad por los aires.

De la misma forma y recientemente, después de que debian eliminara suhosin  por defecto de su paquete PHP, Esser nos ha recordado con varias decenas de tweets, y reportes de bugs que PHP tiene muchos problemas y que además el más peligroso de todos, se añadió en el "parche de seguridad", que se publicó para evitar la denegación de servicio de la colisión de tablas, y que estima, podría haber vendido en el mercado negro por tan solo $100.000.



El caso de Brad, uno de los principales creadores de grsecurity, es similar, ya que históricamente ha mantenido guerra abierta con SELinux, el sistema de protección del actual kernel de Linux y para el que también desarrolló varios exploits:


Seguro que tanto Stefan como Splenger están convencidos que para la comunidad opensource: la letra con sangre entra la seguridad, con exploits entra.
Leer más...

23 febrero 2012

Ea Ea Ea, Google se cabrea !

Para poner en antecedentes, el martes pasado presentábamos nuestra prueba de concepto sobre Bouncer, el sistema anti-malware de Google que teóricamente limpiara el market.

Como tal, fue una prueba de concepto, simplemente subimos la aplicación al market, dejamos que bouncer hiciese su trabajo y se retiró del market, no estaba accesible para descarga ya que el objetivo, evidentemente, no era 'troyanizar' a nadie.

El caso es durante el día tuvimos una serie de visitas desde Google un tanto extrañas, como nos mostraba statcounter:


Como se puede ver, visitas desde Google directas a nuestro post. Y no, no son del bot-araña de Google por varios motivos:

1- El bot NO se identifica a si mismo como navegador Chrome
2- El bot NO se identifica a si mismo como sistema operativo Mac
3- El bot NO renderiza el javascript de statcounter (que es el que cuenta las visitas)

Hasta aquí nada importante salvo porque al rato, me llega a mi cuenta de correo lo siguiente:

This is a notification that the application, Sexy Girl, with package ID com.kamasutraplus has been removed from Android Market due to a violation of Android Market developer terms. It has come to our attention that this application could be used in a way that is harmful to devices, networks, or users.

For specific policies pertaining to this suspension, please see:
Developer Distribution Agreement:
4.3 Use of the Market by You
4.4 Prohibited Actions
Content Policy:
Malicious Products

Please fully review the Content Policies, Developer Distribution Agreement, and Business and Program Policies before you create or upload additional applications. Please also consult our guidelines on rating your application.

Please be advised that this or additional violations may result in a suspension of your Android Market Publisher account, and may also result in actions, including possible suspension, taken against any associated Android Market Publisher, AdSense, Google Checkout, or AdMob accounts.

To appeal this decision, you may reply to this email, or visit the Android Market Help Center for additional information.

Thanks,
The Android Market Team

Lo que significa que:

1- De entrada eliminan toda evidencia de la aplicación (normalmente cuando se des-publica una aplicación sigue estando en el panel del desarrollador)
2- Bromas las justas, si decido persistir en hacer esa clase de pruebas, mi cuenta será cancelada.

Ya sabéis, a partir de ahora si Google dice que el market es inviolable, ver, oír y callar
Leer más...

22 febrero 2012

Seguridad en Fibra Óptica - Parte II: Requerimientos legales



Como complemento al post “Seguridad en Fibra Óptica - Parte I: Fundamentos, métodos de extracción y riesgos” publicado por Jorge García Carnicero lanzamos el presente post en el que intentaremos mostrar, de forma sumaria, los requerimientos legales exigibles, con carácter más general, en las comunicaciones a realizar.




1.- Principales Normas Aplicables a la Seguridad en Comunicaciones

Es múltiple y variada la normativa que exige medidas de seguridad adicionales en materia de comunicaciones.

Así, con carácter general las normas más aplicables son las siguientes:

A. Ley Orgánica de Protección de Datos de Carácter Personal (LO 15/1999, de 13 de diciembre), y su Reglamento de Desarrollo (aprobado por RD 1720/2007 de 21 de diciembre).

El objetivo principal de la normativa sobre Protección de Datos es “garantizar y proteger tratamiento de los datos personales en los ámbitos públicos y privados”, es decir, la protección de un derecho fundamental como es el derecho al honor, intimidad personal y familiar y a la propia imagen, reconocido por el art. 18 de la Constitución.

Esta normativa califica los datos en función de su sensibilidad en tres niveles (básico, medio y alto), estableciendo medidas de seguridad tipificadas también en esos tres niveles.

Así, y en relación con la materia del presente post, el RD 1720/2007 establece como Medida de nivel alto, la Obligación de cifrar los datos en la transmisión de datos personales por redes de comunicaciones:

Art. 104 “la transmisión de datos de carácter personal a través de redes públicas o redes inalámbricas de comunicaciones electrónicas se realizará cifrando dichos datos o bien utilizando cualquier otro mecanismo que garantice que la información no sea inteligible ni manipulada por terceros”

En este sentido, se ha manifestado la Agencia Española de Protección de Datos a través de sus Informes Jurídicos, como por ejemplo, el Informe Jurídico 0494/2009 donde se establece:

Es necesario cifrar de forma que la información no sea inteligible ni manipulada por terceros. Sin esta última condición, no se cumplirá lo estipulado en el citado artículo 104 RD 1720/2007.
  • Que el sistema de cifrado a emplear no este comprometido – que no se conozca forma de romperlo.
  • La garantía necesaria para preservar la confidencialidad de las comunicaciones no sólo descansa en el sistema de cifrado, sino también en el sistema de gestión de claves y en el procedimiento de administración de material criptográfico.
En el mismo Informe, también expresaba la AEPD:

“La seguridad en el intercambio de información de carácter personal en la que hay que adoptar medidas de seguridad de nivel alto (requisitos de cifrado de datos), no es un tema baladí, ni un mero trámite administrativo... Es el medio técnico por el cuál se garantiza la protección de un derecho fundamental y al que hay que dedicar el tiempo y los recursos que sean necesarios para su correcta implementación.”

B. Ley de Prevención Blanqueo de Capitales y de la Financiación del Terrorismo (Ley 10/2010, de 28 de Abril).

El objeto de esta Ley es la protección de la integridad del sistema financiero y de otros sectores de actividad económica mediante el establecimiento de obligaciones de prevención de blanqueo de capitales y de la financiación del terrorismo.

La presente Ley es aplicable a todos los movimientos económicos que puedan llegar a suponer algún tipo de fraude contra el sistema financiero, así a modo de ejemplo, podemos nombrar a; entidades financieras, entidades aseguradoras, intermediarios en el otorgamiento de préstamos, créditos, servicios de inversión, promotores inmobiliarios, notarios, registradores, abogados, casinos de juego y un largo etc…

En relación con la protección de los datos de carácter personal que puedan ser tratados en las actividades sometidas a la presente Ley y las medidas de seguridad a implantar, el art. 32 establece:
  • Art. 32. Protección datos carácter personal -> El tratamiento de datos de carácter personal, así como los ficheros, automatizados o no, creados para el cumplimiento de las disposiciones de la presente Ley, se someterán a la LOPD.
  • Art. 32.5: “Serán de aplicación a los ficheros a los que se refiere este artículo las medidas de seguridad de nivel alto previstas en la normativa de protección de datos de carácter personal”.
Por tanto, y como hemos visto anteriormente, será de aplicación lo establecido en el art. 104 del RD 1720/2007, de 21 de Diciembre, en cuanto al cifrado de datos en la transmisión por redes de comunicaciones.

C. Esquema Nacional de Seguridad

El Esquema Nacional de Seguridad, aprobado por Real Decreto 2/2010 de 8 de enero, tiene como objetivo principal el establecimiento de los principios y requisitos de una política de seguridad que permita la adecuada protección de la información de manera que se creen las condiciones necesarias de confianza en el uso de los medios electrónicos.

Los Sujetos obligados a cumplir esta normativa son; Las Administraciones Públicas -> Administración General del Estado, CCAA, Entidades que integran la Administración Local, Entidades de Derecho Público vinculadas o dependientes de las mismas.

Las Medidas de seguridad exigidas por el Esquema Nacional de Seguridad deberán ser proporcionales a:



Así se establecen unos grupos de medidas de seguridad categorizadas como; Organizativas, Operacionales y de Protección.

El Esquema Nacional de Seguridad, establece en su artículo 21 la obligatoriedad de Protección de la información almacenada y en tránsito estableciendo “Se prestará especial atención a la información almacenada o en tránsito a través de entornos inseguros (portátiles, PDA, periféricos, soportes información y comunicación sobre redes abiertas o con cifrado débil)


D. PCI- DSS

La denominada PCI – DSS (Payment Card Industry – Data Security Standard) es un Estándar de seguridad de datos para la industria de tarjeta de pago, un Consejo de normas de seguridad de la Industria de Tarjetas de Pagos, formado por los principales proveedores de tarjetas (Visa, MasterCard, American Express…)

Este Estándar establece 12 requisitos de seguridad y sus correspondientes procedimientos de prueba.

El objetivo principal del PCI-DSS  es aunar esfuerzos en la securización del entorno de las tarjetas de pago, facilitar la adopción de medidas de seguridad consistentes a nivel muncial y reducir los casos de fraude.

Entre los requisitos de seguridad exigidos, cabe destacar el número 4 “Cifrar transmisión de datos del titular de la tarjeta en redes públicas abiertas” que establece:
  • “Utilice cifrado sólido y protocolos de seguridad (p.ej. SSL/TLS, IPSEC, SSH…), para proteger datos confidenciales del titular de la tarjeta durante la transmisión por redes públicas abiertas. 
Se consideran Redes públicas abiertas dentro del alcance del PCI-DDS (Internet,  tecnologías inalámbricas, GSM, GPRS… )              
  •  4.1.1 Utilización mejores prácticas industrias (IEEE 802.11i) a los efectos de implementar cifrados sólidos para la autenticación y transmisión.
  • 4.2 No enviar PAN (número de cuenta) no cifrados por medio de tecnologías de mensajería de usuario final (email, mensajería instantánea, chat)”
2.- Consecuencias ante la falta de cifrado según normativa legal

La Ley Orgánica de Protección de Datos, establece en los artículos 43 y siguientes la tipificación de infracciones y sanciones, a las que podrán enfrentarse responsables de ficheros y encargados de tratamiento.

Las infracciones se clasifican en Leves, Graves y Muy Graves

La falta de implantación de medidas de seguridad es tipificado por la LOPD como una infracción de carácter grave, estableciendo al efecto “mantener los ficheros, locales, programas o equipos que contengan datos de carácter personal sin las debidas condiciones de seguridad que por vía reglamentaria se determinen”.


Las infracciones cometidas serán castigadas con la imposición de las sanciones también previstas en la LOPD que se categorizan en:



A continuación se mencionan algunas resoluciones sancionadoras de la AEPD en materia de falta de medidas de seguridad, y en concreto, falta de cifrado de datos:
  • PS – 459 - 2008: Correduría de Seguros – Obtención de datos nivel alto por E.T– Falta medidas de seguridad -> Sanción de 60.101,21 € Encargado de tratamiento ->  Posibilitar acceso vía web a datos personales (de nivel alto) de terceros. No existencia procedimiento de cifrado.
  • PS – 353 - 2010: Centro Médico especializado – Envío datos salud por fax no cifrado a compañía aseguradora - Falta medidas de seguridad -> Sanción 3000 € -> Sanción reducida por disminución culpabilidad.
---------------------------------------------------------------------------------------------------------------

Contribución por María González Moreno
Leer más...

21 febrero 2012

Bouncer ¿Sirve para algo?

Que el malware y el poco control del market que ejerce Google es, tal vez, el mayor problema de Android es algo que no es nuevo, por eso, cuando Google anunció el lanzamiento de 'Bouncer'[El Androide libre] [Xataka Android], mucha gente aplaudió la iniciativa.

Bouncer actúa a modo de 'portero de discoteca' con las aplicaciones del market y en teoría bloquea aquellas que puedan ser susceptibles de resultar maliciosas. Y digo bien, en teoría, ya que la práctica deja mucho que desear.

Que Bouncer esté hecho por Google, a priori, se puede presuponer que se trate de un elaborado sistema de análisis basado en patrones, estadística y esas cosas que tan bien se le dan a Google.

Para comprobar la fiabilidad del sistema, le seguimos el juego a Google: Si Bouncer es 'el portero de discoteca', entonces, para subvertirlo necesitamos a la 'Tia sexy que nunca paga entrada'.

Le pedí al siempre brillante Luis Delgado que hiciese una aplicación para el market de Android que fuese MUY sexy y que además tuviese una funcionalidad oculta incluyendo funciones de troyano, en concreto control remoto, ideal para construir una botnet.

El resultado: Sexy Girl



Como se puede ver, no hemos tenido el menor problema en subirla al market de Android y ponerla a disposición del público.

En este vídeo se puede ver la funcionalidad oculta de la aplicación y como todo aquel que se la descargue, queda infectado con un troyano que permite controlar remotamente su dispositivo, en concreto el troyano permite:
  • Ejecución de comandos vía shell
  • Acceso al sistema de ficheros (incluida la tarjeta de memoria)
  • listar procesos y obtener información del dispositivo
  • Lanzar un ataque DDoS desde el teléfono
Y todo esto simplemente solicitando como permiso 'Acceso a Internet', uno de los más básicos


Conclusión: Sin duda la iniciativa es interesante y necesaria, pero aun le queda bastante para ser fiable y funcional. No, no es la bala de plata que sustituye al sentido común
Leer más...

20 febrero 2012

Liberado Nessus v5.0

La popular herramienta para el análisis de vulnerabilidades se ha actualizado a su versión 5, pese a que hay algunos cambios importantes, en general no hay grandes modificaciones, salvo la modificación de criticidades, que quedan en: Info, Low, Medium, High y Critical.

Una de las características nuevas es el cambio de instalación y configuración, donde ahora no es necesario en ningún caso editar ficheros de configuración y todo podrá ser realizado desde el panel de administración, incluida la actualización de plugins o el registro del escáner. Esta es una magnífica noticia, ya que estoy convencido que a todos los usuarios les encanta el diseño y usabilidad en Flash del GUI... *suspiro*



Donde posiblemente hayan metido un número mayor de mejoras sea en la parte de generación de reportes, añadiendo granularidad mediante el uso de filtros y permitiendo eliminar o añadir vulnerabilidades según criterios anidados.



Tal vez lo que más me ha gustado es la posibilidad de crear políticas usando filtros. Por ejemplo la siguiente captura tan solo analizará aquellas vulnerabilidades para las que haya exploit:



Otros cambios a tener en cuenta incluyen la modificación del XML con los resultados, algunos aspectos de diseño del interfaz y mejoras para visualizar resultados durante la ejecución de un análisis.

Podéis consultar un documento de Tenable con algún detalle más en la siguiente URL: http://static.tenable.com/documentation/WhatIsNewNessus5.pdf

Leer más...

19 febrero 2012

Enlaces de la SECmana - 111


Leer más...

18 febrero 2012

¡Si! otro libro de Informatica64. En esta ocasión es sobre el hacking y la seguridad en comunicaciones de redes móviles. Un tema de completa actualidad y no apto para principiantes.

Escrito por  José Picó y David Pérez de Taddong, obliga a un  lector que no conozca esta materia a leérselo con mucha calma, ya que son decenas de términos nuevos a asimilar.

En mi caso en particular y con mis conocimientos nulos en telecomunicaciones,  no es un libro en el que pueda hacer "scroll", ya que me pierdo si no lo sigo progresivamente, por algo tiene más de 20 páginas de referencias y exprime en 250 páginas miles de documentos de estándares y especificaciones.

Está estructurado en 4 capítulos: seguridad en comunicaciones GSM, GPRS, UMTS y 4G,  más la parte introductoria y las conclusiones finales.

Si os gusta este campo o queréis comenzar, es  un libro que no os puede faltar, ya que presenta el estado del arte y desarrolla conceptos desde el punto de vista más práctico y real de la seguridad, evitando caer en la explicación minuciosa. Si por el contrario solo os ha llamado la atención la palabra "hacking" del título, tal vez deberíais empezar por ver algunas presentaciones y publicaciones de Taddong y luego continuar.

Como siempre, está a la venta vía web por 20€ + gastos de envío.

Leer más...

17 febrero 2012

Vuestros "ETHERNET EXPOSED" - X

Nueva edición de nuestra sección Vuestros ETHERNET EXPOSED, posts en el que pretendemos recopilar aquellas imágenes que realizáis a tomas ethernet que se encuentren expuestas en lugares curiosos y que posteriormente nos enviáis a nuestra dirección de contacto.

Hoy os traemos contribuciones de Andriy, Kilian y Koldo.


Comenzamos con el ETHERNET EXPOSED, que nos envió Andriy a nuestra cuenta de contacto, encontrado en el Hospital de Navarra:


En esta ocasión tenemos varios EXPOSED:

  • La propia toma en si, que a su vez,
  • está conectada a un dispositivo que parece Wireless de CISCO
  • Etiqueta con información, que parece el nombre de este punto de acceso y algo más que no se distingue del todo bien...
Kilian nos enviaba el siguiente mensaje:


"Os paso unas fotos de un "casi" ethernet exposed ya que ese rack es facil de abrir y no habia ni camaras ni vigilancia, la tentacion era muy grande, esta junto a unas maquinas de renovacion de las tarjetas de un parquing de Barcelona.


Espero que sirva un saludo."


Y la foto en cuestión:



En ella se aprecia como la máquina de renovación de tarjetas se encuentra en la parte inferior derecha, por lo que está relativamente cerca. Yo creo que se podría haber puesto un poco más de cable y haber dejado esta caja en un lugar un poco menos....accesible.

Y para finalizar, incluimos lo que se encontró Koldo en un supermercado:

"...el otro día comprando en el centro comercial del pajarito, me acordé de vosotros y de como contribuir a la sección ethernet exposed."








Yo personalmente pienso que se trata del típico dispositivo para comprobar los precios. El tema..¿es necesario colocarlo ahí, y de esta manera tan...en BETA? Así parece como si lo pudieras comprar todo por 3,40€, estando en una estantería cualquiera. Qué cortamos, ¿el cable rojo o el verde?


Como siempre os decimos, nuestra dirección de correo sigue abierta a todas aquellas contribuciones de ETHERNET EXPOSED que os encontréis, ¡muchas gracias a todos!
---------------

Leer más...

16 febrero 2012

¿Por qué son noticia los incidentes de seguridad?

Comenzó el 2012 y en poco tiempo algunos incidentes de seguridad ya pusieron a la seguridad de la información e internet en la portada de muchos diarios y medios especializados. A lo que se sumó el cierre de Megaupload y las discusiones en torno a los derechos de autor, la privacidad y la libertad...todo eso en menos de 2 meses. El robo de código fuente de Symantec hace 6 años (si, hace 6 años) y los hackeos a Verisign durante 2010 (si, durante 2010) y en la última semana la llamada entre el FBI y Scotland Yard que pudo "interceptar" Anonymous...todo esto parece una película de ciencia ficción, pero es la realidad y así comenzó el año.

Este post no intenta profundizar en cada uno de los casos mencionados, dado que hay mucha información al respecto, sino abrir el debate en relación a ¿por qué son noticia los incidentes de seguridad?



Al leer sobre cada caso y comenzar a conocer la información que, a cuenta gotas se deja conocer, generalmente no nos encontramos con el "ataque sin precedentes" como el año pasado se encargó de comunicar Sony relacionado con los incidentes recurrentes de la PlayStation Network, de todas formas en este caso se presentó algo que se está convirtiendo en una costumbre en las organizaciones "víctimas" de los ataques y tiene que ver con la falta de comunicación acerca del impacto del incidente, sobre todo si están involucrados datos de los clientes (algo que comentamos en un post anterior).

De todas maneras, resulta interesante que en la mayoría de los casos se hayan aprovechado de la ausencia de controles básicos relacionados con la seguridad de la información: debilidades asociadas con la gestión de parches, ausencia de una correcta separación de ambientes, falta de aplicación del principio de mínimos privilegios, segmentación de redes, ausencia de hardening en los dispositivos, codificación insegura de aplicaciones, falta de controles de seguridad relacionados con los recursos humanos, falta de protección contra código malicioso (si, falta de antivirus), ausencia de logs de auditoria, utilización de cuentas genéricas y un extenso etcétera. Realmente con este panorama, ¿quién necesita el ataque sin precedentes? Quizás los únicos que lo necesitan son los que no están haciendo su trabajo en materia de seguridad de la información :)

Si algo podía empeorar la situación es que se está convirtiendo en una mala costumbre ocultar los incidentes, pero ahora no sólo a los clientes (algo de por sí grave), sino que se está conociendo que en algunos casos el incidente se oculta puertas adentro de la Organización y es el Directorio quien desconoce la situación

¿Imaginan a los Directivos de una Organización ajenos de tal situación? 

¿Si el incidente se le oculta al Directorio, puede el usuario final tener la esperanza de ser notificado?

Pues es lo que está sucediendo, la negligencia se está superando día a día y ahora no solo se le ocultan los incidentes a los clientes, sino que también se le ocultan a los Directivos.

Sin embargo si intentamos tener una visión positiva de la realidad, no es que está todo perdido, sino todo lo contrario. Es lógico que sean vulneradas las empresas dado que no consideran relevante a la seguridad de la información, es lo más lógico que está sucediendo. No es lógico que se oculten los incidentes, pero sí lo es que se presenten, dado que se están haciendo las cosas muy mal. Esto último es lo más esperanzador, porque quizás recién ahora  dejemos de escuchar, "nosotros no somos un banco" o "pero si venimos trabajando así y nunca nos pasó nada", quizás a partir de este momento se comience a gestionar verdaderamente la seguridad de la información. Lo que no debería suceder es que los negligentes de siempre encuentren excusas en los incidentes comentados para seguir leyendo el diario, pero sabemos que podríamos encontrar personajes como esos :(


De todas formas estamos ante una oportunidad de que nos escuche quién debe escucharnos, hace un tiempo lo comentaba en un antiguo post referido a quién le debería importar la seguridad de la información? Sin dudas a los Directivos de las organizaciones, son ellos los máximos responsables, y aunque se les oculte la información, no dejan de ser responsables de lo que sucede. Son los responsables de contratar gente competente y responsable, de mantenerlos capacitados y otorgarles los recursos requeridos para realizar su trabajo. Si esto no se presenta es muy probable que sigamos escuchando a diario acerca de las distintas fugas de información, ataques y demás variantes.

Por otro lado, los usuarios deberían comenzar a requerir seguridad al mismo nivel o aún superior que alguna otra característica al contratar un servicio o comprar un producto. Es lamentable ver como se entregan datos personales, gustos y hábitos por algunos GB de disco en la nube o una cuenta premium en algún servicio 2.0. Quizás recién una vez que los usuarios elijan un servicio seguro por sobre uno inseguro los Directivos comiencen a darle importancia a la seguridad y todo comience a girar...hasta tanto no se de...sólo nos queda escuchar como noticia los incidentes de seguridad.

--------------------------

Artículo cortesía de Mariano M. del Río @mmdelrio
Leer más...

15 febrero 2012

Sobre Hacklous Security, Xsellize security e iHackSecurity

Con la salida del último jailbreak para IOS5 y dispositivos A5 como el iPhone 4S o el iPad2 son miles los nuevos sistemas que lo primero que hacen es descargar de cydia "Install0us", la alternativa pirata de la AppleStore, que actúa como cliente para instalar el software de la web Apptrackr.org donde el contenido de los paquetes no es analizado y puede incluir malware.

Install0us no es la única vía de infección, ya que existen muchos otros repositorios piratas como xsellize o iHacksrepo que abren nuevas puertas de infección.

Es habitual encontrar entre estos repositorios una herramienta del tipo "Hacklous Security" o "Xsellize Security" y con este nombre, muchos usuarios puedan presuponer que instalándola ya estarán seguros de cualquier amenaza.

Nada mas lejos de la realidad.

Estas utilidades únicamente se aseguran que cuando algo es descargado de su repositorio, sea realmente de su repositorio de donde se descargan y no de otro falso. Esto lo hacen añadiendo  o borrando entradas estáticas de DNS en el archivo /etc/hosts del terminal.

Esto evita que un móvil sufra de pharming y descargue algo que realmente no deseaba descargar. Pero ni comprueba el fichero, ni verifica ningún otro punto, lo que posiblemente lleve a un usuario a tener una falsa sensación de seguridad.

En el caso por ejemplo de Xsellize Security (com.xsellize.xsecurity), su paquete se compone de un script que arranca al iniciar el iPhone y que elimina las entradas que haya en su repositorio:

iPhone:~/tmp root# dpkg -L com.xsellize.xsecurity
/.
/System
/System/Library
/System/Library/LaunchDaemons
/System/Library/LaunchDaemons/com.xsellize-security.plist
/usr
/usr/bin
/usr/bin/xsellize-security

iPhone:~/tmp root# plutil /System/Library/LaunchDaemons/com.xsellize-security.plist
{
    Label = "com.xsellize-security";
    LaunchOnlyOnce = 1;
    Nice = 2;
    OnDemand = 0;
    ProgramArguments =     (
        "/usr/bin/xsellize-security"
    );
    UserName = root;
}


iPhone:~/tmp root# cat /usr/bin/xsellize-security
if [ ! -e /etc/hosts ]; then
        echo "Hosts file does not exist"
else
        sed -e "s/xsellize/idontthinkso/g" -i /etc/hosts
        echo "Patched hosts"
        echo "Will automagically patch the hosts file on reboot if there is an entry"
        echo "with xSellize.com in the hosts file"
        echo
        echo
        echo "Please report any bugs to admin@xsellize.com"
fi


Para el caso de Hacklous Security, los hosts que son añadidos en el /etc/hosts con un "postinstall" script del paquete .deb:

iPhone:~/tmp root# dpkg -L us.hackulo.security
/.
/usr
/usr/lib
/usr/lib/hackulous
/usr/lib/hackulous/shosts.sign
/usr/lib/hackulous/.hackulous.security.pubkey.pem
/usr/lib/hackulous/shosts.data

iPhone:~/tmp root# cat /usr/lib/hackulous/shosts.data
188.165.196.30  appulous.org
188.165.196.30  www.appulous.org
188.165.196.30  cydia.appulous.org
188.165.196.30  apt.appulous.org
188.165.196.30  ftp.appulous.org
188.165.196.30  hackulous.org
188.165.196.30  www.hackulous.org
188.165.196.30  cydia.hackulous.org
...

Otra cuestión es si todos los piratas de 1€ merecen o no ser infectados ;-)
Leer más...

14 febrero 2012



El aumento de la demanda de ancho de banda en los sistemas de comunicación durante los últimos años ha provocado una inevitable migración de los medios de transmisión físicos tradicionales de cobre a nuevos medios más óptimos y con mayor capacidad de escalado, como es la fibra óptica. La utilización de una onda electromagnética guiada dentro de un medio supone grandes ventajas, con son:


  • Baja atenuación, lo que permite transmisiones a largas distancias sin necesidad de repetidores u otros componentes.
  • Inmunidad frente a interferencias electromagnéticas y por lo tanto con menor indice de errores en la transmisión de señales digitales.
  • En algunos ambientes peligrosos en los que las descargas eléctricas pueden provocar chispas no es posible utilizar otros medios.
  • Tienen menor peso y volumen comparándolos con los cables coaxiales
  • La manipulación de la fibra para extraer información es más compleja, aunque no imposible como veremos más adelante.
Fundamento físico de la fibra óptica

Pero, ¿qué es realmente una fibra óptica y cómo funciona?

Una fibra óptica es un filamento del tamaño de un pelo humano construido con material plástico o de cuarzo y que tiene un revestimiento también del mismo material. Ambos componentes tienen un índice refracción distinto, lo que provoca que la luz se vaya reflejando de pared a pared sin apenas refracción y, por lo tanto, sin pérdida de luz. La siguiente imagen muestra este comportamiento.



Despliegues de fibra óptica

En cuanto al despliegue, desde hace ya algún tiempo existe planta instalada de fibra óptica por prácticamente cualquier zona urbanizada, utilizando tanto canalizaciones ICT como canalizaciones del resto de servicios (gas, electricidad, etc). Normalmente se despliegan mangueras con varias fibras en su interior.



Hasta el inicio del despliegue de FTTH, estas fibras se dedicaban para conexiones punto a punto, llegando a ambos extremos mediante diferentes conexiones (dependiendo de la distancia) y pudiendo multiplexar en una misma señal varias longitudes de onda mediante CWDM o DWDM. Esto supone de forma práctica un ancho de banda casi ilimitado.

Las conexiones entre dos fibras ópticas se pueden realizar de dos formas distintas: mediante empalmes o mediante conectores. Estos últimos suelen estar en paneles de parcheo que normalmente estarán debidamente custodiados, bien en centrales telefónicas o en instalaciones con cierto nivel de seguridad.

En el caso de FTTH la situación es un poco particular, puesto que uno de los extremos siempre es la central de telefónica, pero el otro se diversifica mediante diferentes splitters para dar servicio a un número mayor de usuarios.

Métodos de extracción física de señal de la fibra óptica

Tradicionalmente se ha considerado que la fibra óptica era un medio prácticamente inexpugnable, puesto que al intentar extraer la luz de la fibra se dispersaría y, por lo tanto, no llegaría a su destino. Sin embargo, existen diferentes técnicas que pueden facilitar la extracción de luz de la fibra sin que la caída de potencia en el destino sea significativa y, por lo tanto, sin que sea detectado por la mayoría de los mecanismos que implementan las operadoras.

Básicamente podemos hablar de do métodos de extracción de señal:
  • Extracción mediante splitters o conectores Y (habituales para actividades de monitorización), por ejemplo utilizando una conectorización. Se requeriría un acceso físico al panel de parcheo
  • Extracción mediante curvatura de la fibra. Al curvar la fibra, el ángulo de incidencia sobre la pared del núcleo va a variar, por lo tanto no toda la luz se refleja, ya que un pequeño porcentaje se refracta. Si recogemos esa luz que se refracta sería posible regenerar la señal.
Existen dispositivos que están específicamente diseñados para realizar este tipo de extracciones, como es el caso del siguiente:



Estos dispositivos suelen introducir bastante atenuación (en nuestras pruebas prácticas unos 6db), por lo que en líneas en las que la potencia sea justa podrían provocar la caída del enlace.

Sin embargo, una vez introducido el equipo este es muy difícil de detectar puesto que es complicado poder distinguirlo entre los diferentes elementos que provocan atenuación (un conector o con un punto de curvatura).

Una vez extraída la información, esta deberá ser llevada a un equipo de transmisión que permita la recomposición de la señal a nivel de enlace. Esta recomposición podrá ser más o menos compleja en función de la transmisión que se esté llevando ente los extremos emisor y receptor, pudiendo incluso, en el caso de xWDM, tener que demultiplexar las diferentes longitudes de onda.

El siguiente vídeo muestra una maqueta en la que se demuestra que esta extracción de la información es posible.









Riesgos y consideraciones legales

Si hemos salvado todos los escollos mencionados, la extracción de información se realizará de forma continua y sin detección. Toda la información que viaje en claro será revelada.

Teniendo en cuenta que los enlaces de fibra óptica suelen corresponder a interconexiones de CPDs, estamos hablando de un riesgo realmente alto, en el que se pueden recuperar hasta bases de datos completas, por ejemplo a partir de un backup, si este no está cifrado.

----------------------------------------------------------------------------------------------------

Contribución por Jorge García Carnicero
Leer más...

13 febrero 2012

La protección de datos en la auditoría de aplicaciones IOS


El modelo de seguridad de iOS se basa en cuatro capas: seguridad del dispositivo (acceso físico), seguridad de los datos almacenados, seguridad de las comunicaciones y seguridad de las aplicaciones.

Tal vez el aspecto más importante a analizar durante una auditoría de aplicaciones móviles es el método para almacenar y acceder a datos personales o confidenciales. En la actualidad este es el problema que más veces se presenta y generalmente tienen una criticidad alta. Un ejemplo claro de esta vulnerabilidad es lo ocurrido y reportado a Whatsapp el año pasado por Yago.

En la entrada de hoy se van a enumerar los lugares y ficheros más comunes que se han de comprobar en un dispositivo, aunque tal vez lo mejor sea comenzar por comentar la estructura básica de una aplicación.

El directorio de cada aplicación (/var/mobile/Applications/[GUID]) se compone de:

NombreApp.app/: directorio con el binario y contenido estático de la aplicación.
  • Documents/: archivos que serán compartidos con el escritorio usando iTunes.
  • Library/: ficheros adicionales de la aplicación.
  • Library/Preferences/: ficheros de preferencias específicas de la aplicación.
  • Library/Caches/: ficheros que han de ser persistentes a distintas ejecuciones de la aplicación.
  • tmp/: ficheros temporales de cualquier tipo y que no han de ser persistentes en reinicios o distintas ejecuciones de la aplicación

FICHEROS PLIST
Como ya se ha visto anteriormente son ficheros que pueden incluir cualquier tipo de dato que crea conveniente el desarrollador, como credenciales, cookies, permisos, etc. En ocasiones pueden cifrar o codificar algún campo, por lo que se comprobará si es reversible o débil o incluso si hay datos confidenciales directamente en texto claro.

Los ficheros plist están en cualquier directorio dentro de la aplicación y se pueden abrir con un editor de texto en caso de los XML y con un editor como plist Editor si son binarios.

La captura siguiente es un ejemplo de iDelicious, una aplicación para consultar los bookmarks del servicio delicious:


FICHEROS DE BASES DE DATOS SQLITE
Ocurre exactamente lo mismo que en el caso anterior, solo que se almacenan en una base de datos del tipo SQLite y para abrirlos hará falta un interprete como: SQLite Administrator, también están en el directorio de la propia aplicación y tienen de extensión .sqlite o .db.

El mejor ejemplo la ya mencionada entrada de Yago, donde se mostraba que una vez borrabas una conversación desde la aplicación WhatsApp, está dejaba de ser mostrada, pero el contenido seguía presente.

FICHERO DE DICCIONARIO PREDICTIVO PARA TECLADO:
Es una base de datos donde se almacenan palabras que no están en el diccionario. En él se pueden guardar usuarios, contraseñas, PIN y cualquier dato de validación. Es similar al "autocomplete" de los formularios web. Por ese motivo la aplicación debe especificar en qué sitios no quieren que sean almacenados.

Se encuentra en el directorio: /private/var/mobile/Library/Keyboard/es_ES-dynamic-text.dat y pese a que su acceso no está permitido de forma nativa, un móvil infectado por malware si puede consultarlo y enviarlo.

CAPTURAS DE PANTALLA
Para crear el efecto "bonito" cada vez que se pulsa el botón "home" y se vuelve al menú del móvil, el sistema genera una captura de pantalla con el contenido que es almacenada en el directorio: Library/Caches/Snapshots/ de cada aplicación. El efecto se puede evitar en caso de que el contenido pueda ser confidencial, al igual que ocurre con las páginas cacheadas de un navegador. Otra opción es diseñar las vistas teniendo en cuenta este problema. 

COPIAR Y PEGAR
Si la aplicación utiliza la característica de copiar y pegar texto, este puede ser accedido por otra aplicación del portapapeles y es almacenada en el fichero: /var/mobile/Library/Caches/com.apple.UIKit.pboard, para analizar esto, tan solo hay que revisar en que sitios se permite copiar y pegar y pensar si "importa" que esos datos sean accedidos por otra aplicación. Por ejemplo, un campo password, nunca debería poder ser copiado.

Debido a que esto es conocido, en nuevas versiones de IOS ya no permite nunca copiar desde un campo de contraseña, aunque si en otros que se han de revisar. La siguiente imagen muestra un ejemplo de la aplicación gmail

Ejemplo: no se muestra opción "copiar"
FICHEROS CACHEADOS
En algunas aplicaciones  es posible que se almacene ficheros confidenciales o con algún tipo de dato de interés sin cifrar. Se han de revisar los directorios "Library/Caches", "tmp/" y "Documents/".

FICHEROS DE LOG
Generados en casos de errores o por los desarrolladores para incluir trazas de depuración, son susceptibles de incluir datos confidenciales. Se revisan en el propio sistema en la ruta /private/var/log/system.log, /User/Library/Logs/CrashReporter  y en los datos locales de iTunes de la estación de trabajo, en el directorio: C:\Users\[USER]\AppData\Roaming\Apple computer\Logs\CrashReporter/MobileDevice/[nombredispositivo]


ESQUEMAS URL
Son utilizados para invocar una acción determinada de una aplicación, por ejemplo "mailto://" para enviar un correo, o twitter:// para invocar el cliente de Twitter. Se definen en el archivo Info.plist mediante el uso de CFBundleURLSchemes, Es conveniente descifrar el binario y buscar strings para conocer sus métodos.

Un ataque podría provocar que se ejecuten acciones no deseadas, similar a un cross-site-request-forgery. Como por ejemplo añadir esto en una página: [iframe]twitter://post?soy_un_luser[/iframe]








Leer más...