28 febrero 2014

Ataques basados en diccionario en aplicaciones de escritorio

En una tarde de ocio dedicada al juego Guild Wars 2 observé como uno de los mapas estaba repleto de bots dando vueltas en círculos y matando todo bicho que apareciera en su camino para recolectar y generar oro virtual que intercambiar por dinero real en alguno de las muchas plataformas Web de venta de estos servicios:


Esta idea despertó mi curiosidad sobre cómo estarían desarrollados..., si repetirían un determinado flujo de paquetes en la red (lo que descarto porque debe ser una auténtica locura), o si se programaría simulando pulsaciones de teclado y capturando las respuestas de la aplicación.

En mi acercamiento a este problema opté por la segunda opción, y cuando tenía medio bot programado me di cuenta que tenía los elementos necesarios para realizar otro tipo de ataques...

Desktop Brute Forcer (DeBF)

Son habituales las herramientas de fuerza bruta como Intruder de Burp o ZAP en entornos Web, Medusa para atacar a múltiples protocolos..., pero no lo son tanto las orientadas a atacar un formulario de escritorio, aquí es donde mi medio-bot puede aportar una nueva mecánica:



El funcionamiento es sencillo:
  • En Path to dictionary file se introduce la ruta al diccionario de palabras que queréis utilizar en el ataque (podéis ayudaros con el botón examinar). La aplicación espera un diccionario donde tengáis las palabras separadas por saltos de línea y os propondrá un diccionario incluido con la aplicación.
  • En Keystrokes definimos las pulsaciones que hace falta enviar al formulario, ya sabéis, escribir la palabra, darle al ENTER para obtener el mensaje de clave incorrecta, darle otra vez al ENTER para cerrarlo, después a lo mejor tenemos que esperar unos instantes hasta que nos vuelve a mostrar el formulario de introducir contraseña..., para todo esto contáis con las siguientes palabras reservadas:
    • El símbolo $$ será reemplazado con la palabra del diccionario que se probará en esa iteración
    • El símbolo ##X##, donde X es un número, indica que se dormirá el proceso durante X milisegundos. Por ejemplo, ##100## es que dormimos 100 milisegundos
    • El símbolo {YYYY}, indica que hay que enviar una tecla especial. Por ejemplo enter sería {ENTER} y escape {ESC}. Si queréis presionar ALT+A escribiréis %(A), y si queréis presionar ALT, soltar, y después presionar A escribiréis $()A. Lo tenéis mejor documentado en este enlace de MSDN.
  • Una vez configuradas las pulsaciones hay que presionar "Smash the form!". La aplicación nos informará de que tenemos 3 segundos para establecer el foco sobre el formulario que se quiere atacar. Sólo queda dejarlo trabajar (no os perdáis los vídeos de los ejemplos de más abajo).
  • NOTA: Si se quiere cancelar el ataque sólo hay que ponerle el foco al formulario de DesktopBruteForcer durante el ataque

Algunos ejemplos de recetas de pulsaciones

Aplicación: Descompresor ZIP de Windows 7, para romper un ZIP protegido por contraseña
Vídeo: Enlace
Receta
$${ENTER}{ENTER}##100##
Descripción:
Escribe la palabra, presiona enter para comprobarla, presiona enter para cerrar el mensaje de error, espera 100 milisegundos antes de escribir la siguiente palabra.

Aplicación: Excel 2007, para romper la contraseña de un libro protegido
Vídeo: Enlace
Receta
%()AA##150##exc##100##e{DOWN}##300##{ENTER}$${ENTER}{ENTER}##100##
Descripción:
Presiona ALT, luego A (para abrir el menu), después A (para seleccionar la opción ABRIR). Espera 150ms y después escribe "exc" (porque el fichero protegido se llama Excel.xls), espera 100ms para que te sugiera el nombre, escribe otra "e" para asegurar el nombre, presiona abajo para seleccionar el nombre propuesto por el formulario, espera 150ms y le da al enter para seleccionar el nombre propuesto. En este momento salta el formulario de introducir clave, se escribe la clave, se envía con ENTER, y se cierra el mensaje de error con ENTER. Se esperan 100ms antes de volver a intentar la siguiente clave.
Nota: Para que funcione esta receta el fichero tiene que llamarse "Excel.xlsx" y estar en el directorio propuesto por la aplicación cuando se muestre el formulario de Excel.

Aplicación: KeePass 2.25, para romper la clave maestra de un fichero
Vídeo: Enlace
Receta
%(){DOWN 3}{RIGHT}{ENTER}##150##$${ENTER}##500##{ENTER}##100##{ESC}##100##
Descripción:
Presiona ALT, luego abajo 3 veces (para ir a la opción de abrir reciente), después derecha y luego ENTER (para seleccionar el primer elemento propuesto). Espera 150ms, escribe la contraseña y luego enter para comprobarla. Espera 500ms a que nos de error, presionar ENTER para cerrar la ventana de error, espera otros 100ms, después ESC para cancelar la ventana y volver al principio y espera otros 100ms antes de volver a empezar.
Nota: Para que funcione esta receta el fichero tiene que encontrarse el primero entre los ficheros recientes.
Nota2: ¿Cuál sería el resultado de buscar en google "ext:kdbx" y pasarle el diccionario top 100 claves de Adobe a los resultados?

Conclusiones

No deja de ser una prueba de concepto porque cualquier ataque contra un algoritmo en concreto será capaz de generar muchísimas más contraseñas por segundo y será más eficiente que este método, sin embargo en determinadas circunstancias puede que no podamos atacar el algoritmo y en esos casos este sistema puede daros una oportunidad.

Descarga de la herramienta

Enlaces de descarga a la herramienta:
  • Proyecto en GitHub. Es licencia GPL así que no dudéis en hacer vuestro propio fork ;) .
  • Zip con la aplicación compilada. Requiere .NET Framework 4 .

Artículo cortesía de Miguel Ángel García
Twitter: @nodoraiz
Leer más...

27 febrero 2014

Buenas prácticas de seguridad en Gestión de Dispositivos Móviles (MDM)


Esta semana se está celebrando en Barcelona el Mobile World Congress 2014. En este evento se concentra el "estado del arte" de la tecnología móvil. Lo que hay y lo que está por venir, las tendencias en cuanto a qué puede llegar a pasar con esos cacharros a los cuáles estamos pegados todo el santo día, y para cuya adicción ya hay hasta nombre de enfermedad: Nomofobia.

Las redes sociales, el Whatsapp Facebook, Twitter, Telegram, Apalabrados, Candy Crush, los juegos de casitas o hasta a veces el correo electrónico es lo que hace que estemos día y noche pendientes de un trasto que sólo tiene dos necesidades: batería y conexión a Internet. 

En el mundo laboral, los empleados de empresas que tienen necesidad de estar "Always On", requieren acceder a los recursos internos de sus empresas, así como manejar información sensible, desde dispositivos no considerados típicamente ordenadores portátiles.

Las tablets y los smartphones, tienen más roles que los típicamente conocidos: llamadas, SMS, juegos, fotos, redes sociales, etc,... es decir, que la probabilidad de que se instale malware, voluntaria o involuntariamente, o que nuestro tráfico o pulsaciones de teclado sean monitorizadas es mayor. Así, como se maneja información sensible a nivel de empresa desde ellos, han de tenerse en consideración como activos digitales de la organización, aplicando las medidas de seguridad necesarias.

A petición de uno de los clientes de Securízame, he elaborado un informe que recoge las recomendaciones de seguridad, según mi criterio y experiencia, a tener en cuenta a la hora de gestionar el parque móvil, unificando dispositivos móviles (smartphones y tablets) con los ordenadores portátiles convencionales.

Como el humilde blog de Securízame no tiene el mismo ritmo de visitas que Security By Default, he querido compartirlo con nuestros lectores de aquí. Como con todo aquello que escribo, diseño o programo,... si a alguien le sirve, me doy por satisfecho.

[+] Enlace de descarga de PDF (con licencia Creative Commons): Recomendaciones de Seguridad de Mobile Device Management (MDM) 


Leer más...

26 febrero 2014

Detectando celdas falsas GSM/GPRS con Cell Analysis

Introducción

Durante este último año, investigando los ataques y vulnerabilidades en la red GSM, me di de bruces con el ataque de la estación falsa BTS. Este consiste en un ataque "Man In The Middle" tradicional, en el que el atacante sitúa su propia antena entre nuestro terminal y la red. La base para que este ataque sea factible son dos vulnerabilidades muy sencillas:

  1. Nuestro terminal NO autentifica la red GSM a la que se conecta, la supone segura.
  2. El terminal se conecta siempre a la celda que mejor nivel de señal le proporcione.
Este tipo de ataques han sido documentados en varias conferencias de seguridad; BlackHat 2011, CCC, DefCon, etc. Como muestra el video de DefCon 18, de Chris Paget, "Practical Cellphone Spying"


Esto además se complica (o mejora para los posibles atacantes) al poder crear una celda falsa utilizando únicamente un teléfono compatible con osmocom y el software OpenBTS u Osmo-BTS. Ya no es necesario ningún hardware caro ni raro de conseguir, ni soldar y des-soldar las placas del USRP1, ni una BTS real: sólo un teléfono Osmocom.

¿Cómo protegernos de estos ataques?

El equipo de SRLabs (Karsten Nohl) ha creado la herramienta catchercatcher para detectar posibles ataques, tal y como publicaron en el 28C3, basándose por supuesto en OsmocomBB. Cuando lo he probado, hay algo que no me ha gustado: para que el software detecte los ataques necesitamos ejecutar el programa con una tarjeta SIM dentro del teléfono. ¿Qué pasa si me quiero desplazar a otro sitio? ¿Dejo de detectar posibles ataques? Lógicamente la necesidad de la tarjeta SIM tiene su explicación, ya que con este programa también se detectan los famosos SMS invisibles (para lo cual necesitamos estar registrados en la red GSM).

Respetando la idea de SRLabs he creado un proyecto nuevo: Cell Analysis, con un fin claro y sencillo: detectar celdas falsas (BTS falsas, IMSI Catcher o BTS Rogue, como queráis llamarlo). Para ello necesitaremos un teléfono osmocom y no vamos a utilizar ninguna tarjeta SIM, escanearemos todas las celdas independientemente de la operadora a la que pertenezcan.

La base de la detección es precisamente que una celda falsa nunca llevará el mismo tráfico de control que una celda real. ¿Qué es tráfico de control? En el standard GSM se han definido canales lógicos para transmitir y recibir la información según una jerarquía de canales:



Dentro del canal de control común ("CCCH") nos vamos a fijar en el canal de Paging ("PCH"), que es el que la red GSM utiliza para alertar a los abonados que tienen un servicio pendiente de entrega, donde el servicio será una llamada, un mensaje corto, etc. ¿Y que tiene una celda falsa que decirles a sus abonados? ... Nada o muy poco.

A continuación muestro dos capturas realizadas del tráfico del canal de control común en celdas de cada tipo: real y falsa:



Fijaros bien en el contenido de los mensajes "Paging Request", porque en el caso de la celda falsa el campo "Mobile Identity" está siempre o casi siempre vacío, puesto que no hay usuarios reales a los que anunciarles la entrega de servicios. El porcentaje de mensajes sin un TMSI o un IMSI no puede apreciarse en la captura de pantalla, pero si en la celda falsa no hay ningún teléfono conectado será del 100%. Sin embargo en una celda real el campo "Mobile Identity", la mayor parte de la veces llevará un TMSI o IMSI en porcentajes elevados. Dependiendo de la hora del día, de la celda, de la operadora y más parámetros, variará el valor del porcentaje de mensajes de "Paging Request" con un abonado, pero nunca alcanzará el valor de la celda falsa.

Este análisis es el que va a realizar el programa para cada celda que encuentre y lo hará continuamente cada 10 minutos, hasta que decidamos parar la aplicación. Para cada una de las celdas que no son falsas, generará un fichero CSV con la fecha y hora así como los valores de abonados conectados y potencia con la que el teléfono osmocom recibe la señal de esa celda. Con cada celda falsa que encuentre enviará a una cuenta de correo configurada previamente un email de alarma. Por último, aquellas medidas que hayan tenido demasiados errores ("Dropping Frames", "BURST IND", etc) serán ignoradas guardándose en un tercer fichero de medidas ignoradas.

Para descargar Cell Analysis, esta es la web donde además podéis encontrar las instrucciones para instalarlo y configurarlo correctamente.

Test de Cell Analysis

Para probar la detección he elegido el escenario más simple, dos teléfono osmocom; uno corriendo Cell Analysis (monitorizando el tráfico) y el otro corriendo el SW de transmisión con OpenBTS (transmitiendo una celda falsa).


NOTA IMPORTANTE: transmitir en el espectro de frecuencias asignado a GSM es un delito, esta prueba debe ser llevada a cabo con una jaula de faraday para aislar el alcance de nuestra transmisión.

Una vez la celda falsa queda definida y configurada con valores reales (MCC 214, MNC 22 y ARFCN 1), tal y como se haría en un ataque real, el segundo teléfono osmocom empieza a transmitir:



El primer teléfono empieza a ejecutar Cell Analysis. Observar en la segunda ventana (al frente) el listado de las celdas que ha encontrado el teléfono y fijaros en la tercera celda (es la falsa):


Cuando Cell Analysis realiza el siguiente paso, que es la monitorización del trafico del canal de control común, sólo encuentra los mensajes "System Information" SI1 y SI3, pero no encuentra ningún abonado en la celda:


Por lo que se genera una alarma correspondiente en un fichero CSV y se envía por correo.

Conclusiones

- Como hemos visto, sí se pueden detectar sin problemas las celdas falsas y avisar para, desde luego apagar cualquier teléfono que pueda ser víctima del ataque ya que en nuestros terminales no podemos forzar o elegir a qué celda se deben conectar, lo harán a la que mejor señal les entregue.

- Cell Analysis también genera ficheros CSV para las celdas que no son falsas con medidas de potencia y número de abonados acampados en ella. Se pueden visualizar los resultados en Excel de manera muy sencilla:


- En toda monitorizacíón hay un parámetro que mide la eficacia: la cantidad (o ausencia) de alarmas falsas generadas. Durante semanas he tenido corriendo el programa y no ha detectado ninguna alarma falsa, pero lógicamente es más que probable que esto pueda suceder. Por ejemplo: si una celda real tiene una avería y  momentáneamente los abonados no pueden acampar en ella, sus "Paging Request" estarán vacíos.

Sobre FakeBTS.com

 - El proyecto Cell Analysis se encuentra recogido en la web fakebts.com donde seguiré actualizando siguientes versiones con mejoras pendientes de implementar:
  • Pequeño interfaz web para comprobar el estado de la monitorización y gestionar las alarmas
  • Recoger las medidas de las celdas con "rrdtool" para mostrar gráficas en el interfaz web en tiempo real
  • Crear paquetes .deb para facilitar la instalación en Ubuntu
  • Portar el proyecto a la plataforma ARM (Raspberry Pi)
  • Seguir investigando distintas celdas falsas en busca de nuevos retos a detectar
Autor: Pedro Cabrera

Leer más...

25 febrero 2014

VUESTROS "ETHERNET EXPOSED" - XXIII

Seguimos recibiendo más y más fotos con vuestros ETHERNET EXPOSED, imágenes que realizáis a tomas ethernet que se encuentren expuestas en lugares curiosos, transitados, accesibles... y que posteriormente nos enviáis a nuestra dirección de contacto.

En la edición de hoy contamos con las contribuciones de Óscar Rodríguez, Miguel Ángel, Xavier Rubio y Juan Segui.

En primer lugar, mostramos el Ethernet Exposed que nos envió Óscar Rodríguez a nuestra dirección de contacto, contándonos que se encontró lo siguiente en una conocida tienda de muebles, en el stand de consulta:


Una pena que esté tan a desmano, la verdad es que hay algunos nombres de muebles que les vendría bien alguna modificación...

Miguel Ángel nos envió la siguiente contribución a nuestro correo:
Hola!!! 
Como os he puesto por twitter, esto lo saqué la semana pasada en el restaurante Ribs del c.c. Diversia. Está además bastante escondidito entre las mesas (en la plataforma de enfrente de los baños) como para "investigar" a fondo mientras comes tranquilamente. :) Se ve que tenían algo conectado y los muy cenutrios en vez de desenchufar cortaron el cable. :-O así que imagino que al menos en esa boca hay algo. Si vuelvo, lo haré con el portátil a ver que hay. }:)


¿Costillas, salsa barbacoa, tiempo de espera y una red ethernet disponible? la combinación de los campeones.

Xavier Rubio nos envió un conjunto de imágenes de un cajero en Barcelona, en el cual se podía apreciar dentro de la oficina que existía un punto de acceso recién desmantelado cuya desinstalación parecía no haberse completado. Al igual que en muchas ocasiones, dicho punto quedaba cerca de la zona de espera de clientes:


Por último, le toca el turno a otro cajero de la mano de Juan Segui, en el que se aprecia algo muy parecido al caos y desorden exposed:
Buenas tardes, no sé si os habrán enviado esta foto antes, pero este "apaño" está encima del cajero automático junto al supermercado del Corte Inglés de Callao (Madrid). Lleva desde tiempos inmemoriables igual... ¿?

Alguien parece que se cree que puede colocar su miniCPD encima del cajero. Si bien podría parecer algo temporal por un posible mantenimiento, cuando han comentado que lleva así tiempos inmemoriables...se convierte en preocupante.

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 y hasta la próxima!

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

Leer más...

24 febrero 2014

El Desafío O-ISM3

La mayor parte de los profesionales de seguridad de la información, especialmente consultores y aquellos que tienen certificaciones de seguridad que no nombraré, así como numerosos estándares consideran que los conceptos de Confidencialidad, Integridad y Disponibilidad resumen adecuadamente los objetivos fundamentales de la seguridad de la información. Estos conceptos se utilizan en auditorias, análisis de riesgos, gestión y desarrollo de nuevos estándares. Ahora bien, estos conceptos presentan varios problemas que están sin resolver: 
  • Son incompletos. Hay quien complementa los tres conceptos mencionados con otros como. Posesion, Utilidad, Riesgo, Autenticación, Autorización, Auditoría, No-Repudio y Accountability. Esto implica que según qué cóctel de complemento haya elegido la persona o empresa que realiza una tarea relacionada con seguridad de la información, esta se realizará de una forma distinta (llamo a esto una variabilidad elevada). Puede que alguien no considere esto un problema. Pensar que según el médico que me toque me van a diagnosticar algo distinto, y que según el arquitecto que me toque, el edificio donde vivo durará cien años o se caerá mañana, no me parece una situación deseable. Cuando algo es realmente importante, es necesario que el trabajo se realice de la forma más consistente posible. 
  • Son ambiguos. Muchos profesionales e incluso estandares dan definiciones ligeramente distintas de Confidencialidad, Integridad y Disponibilidad. Esto aumenta la variabilidad, lo que no es deseable. 
  • No están definidos operacionalmente. Una definición operacional define un concepto mediante el proceso que se utiliza para medirlo, sin intentar definir su esencia. Al no ser definiciones operacionales, no es posible definir otros conceptos útiles como Amenazas, Incidentes, Vulnerabilidad o Debilidad en términos de Confidencialidad, Integridad y Disponibilidad, lo que incrementa la variabilidad. He visto numerosos debates en los que profesionales con años de experiencia no conseguían llegar a una acuerdo acerca de qué es un Incidente o una Vulnerabilidad. Me pregunto como puedes gestionar algo si ni siquiera lo puedes definir. Y no, una defnicion personal que sobre la que no hay un acuerdo amplio, no es válida. 
  • No tienen unidades de medida. Esto impide de forma cuantitativa la seguridad de la información. Sin medidas cuantitativas es imposible la optimización de recursos. 
El uso de conceptos ambiguos, incompletos y que no están definidos operacionalmente crea una serie de problemas para la gestión de la seguridad de la información. La comunicación entre especialistas y el negocio es difícil. Demostrar el valor que aporta al negocio la seguridad de la información es difícil. En general nos complican la vida más que nos la simplifican. Se desperdicia tiempo, se invierte donde no tiene sentido invertir, y se deja de invertir donde se debería.

Llevo varios años hablando en artículos y presentaciones sobre esto, recientemente en la NoConName y en la reunión de la ISACA Madrid, pero quizá está crítica no tiene sentido o no tiene valor, porque no he escuchado comentarios apoyándola.

Creo que las necesidades de seguridad de un negocio no tienen porque coincidir con las marcadas por ningún estándar de cumplimiento. Mis opiniones sobre el cumplimiento normativo mejor las expresaré en otra ocasión.

Inspirado por el James Randi Foundation Challenge, que ofrece un millón de dólares a quien pruebe tener capacidades paranormales, he decidido crear el Desafío O-ISM3. Con este desafío pretendo demostrar, mediante un caso práctico, que confidencialidad, integridad y disponibilidad no son imprescindibles, y de hecho ni siquiera son necesarias para entender las necesidades de seguridad de una organización.

Afortunadamente existe una alternativa, que es la utilización de conceptos definidos operacionalmente, que no son ambiguos, no son incompletos y tienen unidades de medida Estos conceptos son los "objetivos de seguridad" de O-ISM3, un estándar que vengo promoviendo desde hace años.

Os animo a difundir estas ideas, entrar en el debate y participar en el Desafío O-ISM3.

Contribución gracias a Vicente Aceituno
Leer más...

23 febrero 2014

Enlaces de la SECmana - 215


Leer más...

21 febrero 2014

Formación en Rooted CON - RootedLabs 2014

El mes pasado anunciábamos que se acercaba la RootedCON otro año más, y con el, los RootedLabs, talleres prácticos e intensivos (8 horas) en los que los asistentes aprenderán distintas especialidades de seguridad.

Desde entonces las plazas han empezado a volar y se han anunciado tres nuevos cursos: Rlab36 - Técnicas de ataque sobre clientes Wi-Fi de  Raúl Siles, Rlab 37 - Pentesting con FOCA de Chema Alonso y tras completarse el mío propio, se ha duplicado con una nueva sesión: Rlab33 Iniciación al Ethical Hacking con Kali, en el que como todos los años, introduciré interesantes cambios


Esta es la lista de los cursos que hay ahora mismo disponibles, los profesores y y las plazas disponibles hasta el momento. 

Lunes, 3 de Marzo
Rlab30 Reversing de aplicaciones y análisis forense en Android impartido por Luis Delgado [7]
Rlab35 Inteligencia Digital impartido por Dani Creus y Vicente Díaz   [7]
Rlab36 Técnicas de ataque sobre clientes Wi-Fi impartido por Raúl Siles [5]

Martes, 4 de Marzo
Rlab31 Metasploit para Pentesters impartido por Pablo González [6]
Rlab32 Auditoría y fortificación de infraestructuras  de Juan Garrido (Silverhack) COMPLETO
Rlab33 Iniciación al Ethical Hacking con Kali impartido por Alejandro Ramos [7]

Miércoles, 5 de Marzo
Rlab33 Iniciación al Ethical Hacking con Kali impartido Alejandro Ramos  COMPLETO
Rlab34 Seguridad y optimización en servidores GLAMP impartido por David Hernandez (dabo) [4]
Rlab37 Pentesting con FOCA impartido por Chema Alonso [6]

Tienes más información detallada sobre la localización y horarios en la sección RootedLabs dentro de la página de RootedCON.

Para mi es una alegría que después de 4 años consecutivos con este lab y más de 90 alumnos distintos, aún despierte interés el curso y algunos alumnos me comenten que están allí porque se lo han recomendado. ¡Gracias! 

Allí nos vemos \m/ 
Leer más...

20 febrero 2014

El SAT de Apple y mi privacidad




Muchas veces me habréis visto defender el servicio de Apple, que con el sobreprecio que se paga por cualquier dispositivo, te atiendan de una forma profesional cuanto menos.

Fue justo en el peor momento, en una presentación con un responsable de seguridad de una gran empresa, que mi MacBook Pro dio su primer aviso.

No detectaba el disco duro y me aparecía un icono que daba muy pocas esperanzas. Sin embargo, al tercer intento, como en las películas de terror, cuando el monstruo persigue a la protagonista, el mac arrancó, y pudimos cumplir con el objetivo de la reunión.

Lo que aún no os he dicho es que al día siguiente, me marchaba a un minitour de charlas, una en Palencia (las Terceras jornadas de Villamuriel de Cerrato) y al día siguiente en Logroño, organizado por el Gobierno de la Rioja y ANCITE. Os podéis imaginar que cuando llegué a casa, mi Macbook Pro definitivamente ni arrancaba. En vez de al sistema operativo, a quien le dio el Kernel Panic fue a mí.

Extraje el disco duro y lo pinché a un dock SATA-USB, y la información del disco seguía intacta y verificable, es decir, que lo que parecía que podía ser un bonito disco duro SSD muerto, apuntó a ser el cable SATA con el que éste se conecta 

Salí zumbando a la tienda Apple de Las Rozas en Madrid, sin cita previa ni nada a eso de las 20:00. Para conseguir una cita rápida y un trato preferente, no tuve que hacer ningún tipo de ingeniería social, sino decirle la verdad a quien me atendió, y tras ver la cara de desesperación que traía, accedieron a mirarme de inmediato el ordenador.

Siendo que he montado mis propios ordenadores desde hace montones de años, y que cosa que pillo la desarmo por hobby o vicio, les comenté que me vendiesen la pieza y que yo mismo la cambiaría, puesto que me aportaba poco valor que me la cambiasen allí a cambio de un precio/hora desmedido, a mi entender. La respuesta de ellos: Lo sentimos. Si tenemos la pieza la tiene que cambiar un ingeniero autorizado por Apple, no puede ser usted mismo. Ni lo entendí ni estuve de acuerdo, pero como la necesidad tiene cara de hereje, directamente accedí a que me la cambiasen y ya está.

Firmé un papel que aceptaba el presupuesto y un montón de cosas en letra pequeña, y me cambiaron esa pieza. Al ver que el Mac arrancaba, mi cara cambió, mi corazón dejó de sonar como el árbol de levas de un Fórmula 1 y pude relajarme un rato. Pedí que me dejasen ver la pieza defectuosa y, pese a que no le encontré problema físico alguno, está claro que hacía la diferencia. Cuando ya me iba, con mi Mac y el cable SATA en la mano, me dijeron: “Perdona, la pieza vieja nos la quedamos nosotros”. Mi respuesta: “oye que yo he pagado por la nueva y por la vieja, me la llevo y la miro con calma en casa”. Y según me dijeron: “Según lo que has firmado, esa pieza rota es propiedad de Apple”… Me quedé con cara de circunstancia, y sinceramente, ya que era “un cacho de plástico” me dio igual. 

Sin embargo, días después, mi exnovia me dice por Whatsapp que tuvo que llevar su Mac a una tienda Apple, y que lo que había cascado a nivel físico era el disco duro. Que le habían puesto uno nuevo, con el último sistema operativo, y que entre otras cosas, de las que no tenía backup, había perdido un montón de fotos que teníamos juntos, que se quedaron en el disco duro viejo. Mi contestación: “oye pero si tienes el disco, y es un tema de arranque, podemos intentar recuperar los datos igualmente”. Su respuesta: “No no, si es que el disco se lo han quedado allí”…. Increíble, es decir que por la misma regla de tres que con mi cable SATA (que no contiene datos personales) se quedan con un disco duro que puede tener fotos, videos o ficheros de cualquier índoles que son de la absoluta privacidad de ella (y por asociación, de la mía). 

Entiendo que Apple dirá que con la información contenida en ese disco (si es recuperable) se destruye sin intentarlo pero, entre que sale de la tienda Apple y llega a los servicios de “wipeado” de Apple, ¿quién tiene acceso a ello? ¿Quién me garantiza que nadie del SAT se pone a ver qué tenía ese disco dentro? Tengo claro que no sería la primera vez que estas cosas pasan.

Y es que cada vez empiezo a estar más harto que todo tenga que ceñirse a que hay una “política firmada”, o que hay que limitar la tecnología o las acciones posibles o de sentido común, porque hay una ley de la “República Independiente de mi Casa” que se amolda a los intereses y conveniencias de empresas como la todopoderosa Apple, importándoles un pimiento los derechos de los usuarios. Y es que en esta historia se han cometido, a mi parecer, dos irregularidades: Primero que no te vendan la pieza en concreto y que no me permitan ahorrarme un dinero innecesario en una mano de obra que no necesitaba (monopolismo y cohartamiento de mi libertad en la compra de un recambio), y por otra parte, que se queden con la pieza antigua, conteniendo ésta datos privados en el caso del disco duro defectuoso (vulnerando la privacidad de la información de sus clientes).


Como sucede con empresas que están en la situación de poder ante sus usuarios, en un caso porque, o compro la pieza a su manera o no puedo solucionar el problema, y en el otro por no saber cambiar un disco duro por otro nuevo, al final no nos queda otra que pasar por el aro, sin tener la posibilidad de elegir si quieres encargarte personalmente de la destrucción de tu información.
Leer más...

19 febrero 2014

Jugando con Cuadraditos

Hace poco llegó a mi otro juego de Google Play, en este caso se trata de Cuadraditos, juego en el que en turnos de 3 en 3 movimientos nos enfrentaremos a un contrincante seleccionando bordes y apuntándonos un punto cada vez que completemos el último borde de un cuadrado.

El giro de tuerca que propone el juego consiste en que para apuntarnos el borde tendremos que responder correctamente a una pregunta..., ¿o tal vez no?. Vamos a verlo.


Reuniendo información 

Empecemos analizando las peticiones que se intercambian cuando seleccionamos un borde:


En la petición ya vemos algunos campos a destacar:
  • access_token: Es un token de acceso que varía con cada inicio de sesión en la aplicación
  • match_id: Es el identificador de la partida en curso
  • version: Es el turno por el que nos vamos en el juego

Si vemos la respuesta que nos devuelve el servidor a la petición anterior encontraremos lo siguiente:


En la estructura JSON que el servidor nos devuelve al seleccionar un borde recibimos los siguientes campos a destacar:
  • question: Es la pregunta que nos realiza el juego
  • answers: Son las posibles respuestas
  • correct_answer: Es el hash con la respuesta correcta
  • ticket: Un token asociado a la pregunta que hemos recibido en este turno

Buceando en el código

Llegados a este punto lo primero que intentaremos será analizar el hash recibido enviándolo a la herramienta "hash-identifier":


Identifica que posiblemente se trate de un hash MD5 así que intentamos generar algunos resúmenes en busca del literal o literales a combinar sobre los que aplicar el hash:


Además de las cadenas más evidentes, se prueban distintas combinaciones en las que se incluye el turno, el ID de la pregunta, la propia pregunta, la posición de la respuesta correcta dentro del array de respuestas.., todo ello sin éxito. 

Vista la resistencia optamos por descargar y analizar el APK como ya lo hicimos en el caso del juego Pixel Dungeon con la diferencia de que esta vez no vamos a tener tanta suerte para analizar el código, se encuentra ofuscado:


Si os sentís fuertes para desenredar el código veréis que la palabra "correct_answer" que sería la que más nos aproximaría al resultado que buscamos no nos devolverá ningún resultado.
Buscar por otras palabras encontradas en la estructura JSON como "answers" y "question" sí nos devolverá resultados, sin embargo explorar esta vía será tedioso debido a la ofuscación, de modo que sin querer disuadir a nadie de resolver el misterio de este hash, aplicando pensamiento divergente voy a buscar otras vías de resolución.

Reuniendo más información

Continuemos capturando tráfico generado por la aplicación, veamos qué ocurre cuando acertamos una pregunta:


He resaltado en la petición los detalles más relevantes, pero comento los principales campos:
  • match_id: Identificador de la partida en curso
  • version: Turno por el que va la partida. Se envía un 1 porque estamos contestando a la pregunta anterior del primer turno
  • access_token: Token de sesión de juego. Coincide con el enviado al seleccionar el borde
  • message: Campo codificado que incluye el ticket asociado a la pregunta que nos han hecho en el turno 1 y el borde que queremos desbloquear. Podemos ver más claramente su contenido en la siguiente captura:


Sacamos entonces las siguientes conclusiones:
  • No se observa que en la dinámica de acierto se envíe de ningún modo la respuesta seleccionada al servidor, de modo que deducimos que la validación se realiza en nuestra aplicación
  • Hay que incluir en el campo version el mismo valor que obtuvimos al solicitar la pregunta, que será el número de turno de la partida 
  • En el campo message se incluye:
    • Un literal "take_border" que indica al servidor que se quiere capturar un borde
    • El valor del ticket que se había recibido al seleccionar un borde
    • Un número que indica el borde que se quiere desbloquear

Veamos ahora lo que ocurre cuando fallamos una pregunta:



Si observamos los datos enviados identificamos los siguientes campos importantes:
  • match_id: Identificador de la partida que estamos jugando
  • version: Turno que estamos jugando. En este caso es 7 porque yo he jugado 3 turnos y después mi contrincante otros 3
  • access_token. Token de sesión de juego
  • message. Campo codificado que indica que hemos fallado y el ticket asociado a la pregunta que nos han hecho en el turno 7. Se pueden ver sus valores más claramente en la siguiente captura:



Se confirman nuestras sospechas, en el caso de fallo vemos como sólo varían los campos de version (porque son turnos diferentes) y message (que incluye un literal "question_fail" y el ticket correspondiente a la pregunta fallida).


Conclusión final


Hemos visto a través del análisis entre acierto y fallo que la información que se envía al servidor se asume válida, de modo que si queremos falsear un acierto no necesitaremos conocer la respuesta correcta, nos valdrá con saber el turno en el que nos encontramos, el ticket asociado a la pregunta y el borde que queremos desbloquear.

Respecto a los bordes a desbloquear, realizar algunas pruebas refleja que los valores asignados parten de 0 y crecen en orden izquierdo, arriba y derecha. Os dejo en la siguiente imagen algunos valores:


Si tenemos que resumir el problema podemos indicar que comete un error habitual de algunas aplicaciones Web, un sistema no puede basar su confianza en validar en cliente sin realizar validación en servidor, de hacerlo así se permite a los usuarios malintencionados la posibilidad de alterar y falsificar las entradas.

Finalmente, os dejo un ejemplo en video de la explotación de esta "vulnerabilidad" del juego y un enlace de descarga:



Artículo cortesía de Miguel Ángel García.
Twitter: @nodoraiz
Leer más...

17 febrero 2014

[1/2] Seguridad en Redis - Fortificación

Si estás leyendo este artículo seguramente sea porque ya conoces Redis, un motor de base de datos basado en clave/valor que almacena los datos en memoria y que últimamente, debido al alto rendimiento que ofrece, está de moda.

En este artículo se detallarán medidas de seguridad a aplicar para asegurar su fortificación

En la mayoría de los sistemas Linux las instalaciones por defecto  ya tienen en consideración algunas de estas inquietudes, pero por requisitos o por instalaciones manuales en ocasiones son modificadas.

La propia documentación de Redis nos pone en aviso de que está diseñado pensando en los mundos de Yupi: "Redis is designed to be accessed by trusted clients inside trusted environments", algo extraño teniendo en cuenta que su autor es Salvatore Sanfilippo (antirez), al que conocemos de otros proyectos como hping 

1.- Escucha del servicio.
El demonio de redis debería escuchar únicamente en loopback o un socket de Unix. Si no, nuestro servicio será accesible a toda la red, por defecto, sin autenticación.

Para configurar las interfaces en las que escucha se debe modificar el fichero redis.conf y especificar las IPs en el parámetro bind y el puerto con el parámetro port, que en caso de ser 0, no permitirá conexiones TCP.

Tal y como comentaba inicialmente, esta configuración viene por defecto para 127.0.0.1 6379/tcp pero en ocasiones "pasan cosas", tal y como se puede ver en shodan 

port 6379
bind 127.0.0.1

En caso de que sea necesario el uso por red, es conveniente filtrar el puerto mediante un firewall en local.

# 6379 = redis port
# 10.1.2.3 = clientIP1
iptables -I INPUT -p tcp --dport 6379 -s 10.1.2.3 -j ACCEPT
iptables -I OUTPUT -p tcp --sport 6379 -d 10.1.2.3 -j ACCEPT
iptables -I INPUT -p tcp --dport 6379 -j DROP

Para habilitar el socket de unix se especifica mediante los siguientes valores.

unixsocket /var/run/redis/redis.sock
unixsocketperm 755

2.- Ejecución con los mínimos privilegios.
El servicio debe arrancarse bajo un usuario no privilegiado específico y si es posible, en un entorno enjaulado. Como veremos en el siguiente artículo esto puede volverse uno de los mayores problemas.

El cambio de usuario implica que los ficheros que utiliza el motor sean también propiedad de este usuario. Como son el fichero de PID (especificado mediante pidfile en redis.conf), el log (logfile) y los directorios de la base de datos (dir).

En caso de Ubuntu todos estos parámetros de arranque están en el propio script de inicio: /etc/init.d/redis-server, al igual que en CentOS: /etc/rc.d/init.d/redis

En general, estos parámetros también deben estar así si se instala un paquete, aunque por desgracia si se desea enjaular será necesario hacerlo manualmente.

pidfile /var/run/redis/redis-server.pid
logfile /var/log/redis/redis-server.log
dir /var/lib/redis

3.- Establecer autenticación. 
Este punto es crítico, ya que por defecto se puede acceder a la base de datos sin ningún tipo de autenticación. El acceso es total y permite ejecutar absolutamente todos los comandos de la base de datos.

Para establecer autenticación se debe especificar una contraseña (en texto claro) con el parámetro requirepass en el archivo redis.conf 

Redis no soporta usuarios ni roles, por lo que aquel que conecte tendrá todo o nada.

requirepass SuperInfinitoOOoOOoOO

Si la base de datos se replica, los esclavos deben de definir esta contraseña en su configuración.

masterauth SuperInfinitoOOoOOoOO

4.- Desactivar los comandos no usados.
La base de datos soporta decenas de comandos distintos. Algunos de ellos completamente innecesarios para el funcionamiento normal de la base de datos y mucho menos, para usuarios que no deberían tener privilegios de administración (como los desarrolladores).

Para desactivar un comando se renombra a "" (nada) y dejará de ser posible su uso. También se puede renombrar a algo desconocido para que solo aquellos que lo conozcan puedan hacer uso de la llamada.

Lo ideal es identificar los comandos que son necesarios y deshabilitar el resto, son especialmente peligrosos: FLUSHDB, FLUSHALL, CONFIG, DEBUG, MIGRATE, SLAVEOF y SHUTDOWN, Este último es usado para parar el servicio por los scripts de inicio y que por lo tanto requerirá que estos se modifiquen.

La lista completa de comandos se encuentra en: http://redis.io/commands

rename-command FLUSHALL ""
rename-command FLUSHDB ""
rename-command DEBUG ""
rename-command SHUTDOWN SHUTDOWNSECRET
rename-command CONFIG ""
rename-command MIGRATE ""
rename-command SLAVEOF ""
rename-command CLIENT ""
... otros rename-command ...

5.- Cifrado de tráfico entre cliente y servidor.
La comunicación entre cliente y servidor es en texto plano y nativamente no es posible aplicar ningún tipo de cifrado en esta conexión. Si la red no es confiable (ninguna lo es) se debe utilizar una segunda herramienta sobre la que delegarlo. Existen múltiples opciones como stunnel, socat o ssh.

# cliente
stunnel -c -d 6379 -r servidor_redis:1999
# servidor
stunnel -d 1999 -r localhost:6379 

6.- Almacenamiento  de registros.
Los ficheros de registro deben salvaguardarse en un directorio seguro. Estos archivos deben rotarse y mantener la misma política de seguridad que para otros registros del sistema. Si no se define logfile serán mandados a la salida estandar del sistema. Si el parámetro daemonize está activado, serán enviados a /dev/ null.

loglevel notice
logfile /var/log/redis/redis-server.log

Si fuera necesario, existe la posibilidad de mandar los ficheros a syslog.

syslog-enabled yes
syslog-ident redis
syslog-facility local0

7.- Ajustes de rendimiento.
Como comentábamos inicialmente redis está diseñado pensando en el rendimiento, por ese motivo cambiar ajustes que afecten a este aspecto es un problema importante. Desgraciadamente, obtener el máximo rendimiento y ser susceptible a una denegación de servicio abusando de los recursos de memoria o red suelen ir de la mano.

Para ajustar esta línea, se debe jugar con varios parámetros que permitirán que el servicio permanezca estable y siga siendo óptimo en su rendimiento. De momento no existe una fórmula mágica para definirlos, dependerá de las especificaciones hardware de los servidores, número de peticiones y otros factores.

maxclients XXXX
timeout XXX
tcp-keepalive XXX
maxmemory XXXXXXXXX

Referencias:
Leer más...

16 febrero 2014

Enlaces de la SECmana - 214


Leer más...

15 febrero 2014

Las fotos de tu perfil de twitter son para siempre.

El pasado día 28 de diciembre se celebraba en España el día de los santos inocentes, por ese motivo decidí cambiar la foto de mi perfil de Twitter por una idiotez, "jaja, que gracioso" y fin. Pero lo que no sabía en ese momento es que aquella foto ridícula quedaría almacenada ¿para siempre? en los servidores de Twitter.

Cuando un usuario se da de alta en un servicio presupone que podrá darse de baja y que los datos asociados se eliminarán. Esto se conoce como el derecho de cancelación y debe aplicarse como máximo en 10 días. Por lo menos en España, tal y como recoge la ley de protección de datos que puede consultarse en la web de la AGPD.

Pero parece que a nuestros compañeros del pájaro azul la protección de datos y las leyes fuera de California,  le importan bastante poco.

Fragmento Condiciones del Servicio de Twitter
En Twitter se pueden subir fotos y eliminarlas, este mecanismo funciona como se espera: eliminas un tweet con una imagen y aparentemente nadie podrá recuperar esa información. 

No ocurre lo mismo con las imágenes de los perfiles, que independientemente del número de veces que las cambies, las versiones anteriores seguirán estando almacenadas. Incluso si solicitas la eliminación completa de la cuenta en la red social, la imagen seguirá estando disponible en el sitio original al que se subió. 
Fragmento de la política de privacidad: https://twitter.com/privacy.
Como u suario personalmente podría aceptar  que se "fumen" el máximo de 10 días que impone la LOPD tal y como indican en su política de privacidad, y que se puede ver en la imagen superior, pero ya han pasado más de 30 días y las fotos siguen estando ahí. El problema aparentemente no parece demasiado grave, pero en determinadas circunstancias uno quiere ejercer su derecho al olvido.

La prueba de este hecho es la que se muestra en la siguiente imagen: https://pbs.twimg.com/profile_images/418900307062448128/Okj8mGku.png, de un perfil ya borrado, y que por lo que parece, estará ahí muuuucho tiempo.
Foto de un perfil de una cuenta ya eliminada



Leer más...

14 febrero 2014

Fuga de información en servidores IIS con autenticación NTLM

Justin Cacak de Gotham Digital Science ha publicado un script para nmap mediante el cual es posible obtener información de la infraestructura que se encuentra tras un servidor web IIS con la autenticación NTLM activada.



La información es tan suculenta que permite obtener datos como los siguientes:

  • Nombre del sistema
  • Nombre de dominio NetBIOS
  • Nombre DNS del sistema
  • Árbol DNS
  • Versión del sistema operativo
Esta información se obtiene gracias a enviar una petición de autenticación NTLM con credenciales nulas (a través de la cabecera Authorization). El servidor como respuesta enviará un mensaje NTLMSSP cuyo contenido incluye la información de la infraestructura que comentamos anteriormente.


Según comenta el propio Justin en el post, la única manera de evitar mostrar esta información sería...deshabilitar la autenticación NTLM por HTTP, algo bastante complicado. Por ser un problema de diseño, hasta el momento no se conoce ninguna manera de mitigar esta fuga de información en servidores IIS.

El script fue enviado a la lista de desarrollo de nmap el pasado 4 de febrero, y no se descarte que forme parte del conjunto por defecto de scripts que se distribuyen con la propia herramienta. Podéis acceder al código fuente del script en .nse en esta dirección

[+] HTTP NTLM Information Disclosure - blog.gdssecurity.com
Leer más...